Translation

(itstool) path: sect1/para
Alas, if all we received was the <acronym>PNG</acronym> file, our software would be facing a serious problem: How is it supposed to know the data is representing an image, as opposed to some text, or perhaps a sound, or what not? Secondly, how is it supposed to know the image is in the <acronym>PNG</acronym> format as opposed to <acronym>GIF</acronym>, or <acronym>JPEG</acronym>, or some other image format?
0/4100
Context English Persian State
Protocols
قرارداد‌ها (پروتکل‌ها)
While various programming languages tend to have complex syntax and use a number of multi-letter reserved words (which makes them easy for the human programmer to understand), the languages of data communications tend to be very terse. Instead of multi-byte words, they often use individual <emphasis>bits</emphasis>. There is a very convincing reason for it: While data travels <emphasis>inside</emphasis> your computer at speeds approaching the speed of light, it often travels considerably slower between two computers.
در حالی که زبان‌های مختلف برنامه‌نویسی دارای قواعد نحوی پیچیده‌ای هستند و از تعدادی واژگان چند حرفی رزرو شده استفاده می‌کنند (که درک آنها را برای انسان برنامه‌نویس آسان می‌کند)، زبان‌های ارتباطات داده بسیار مختصر هستند. به جای واژگان چند-بایتی، اغلب از <emphasis>بیت‌های</emphasis> منفرد استفاده می‌کنند. یک دلیل بسیار قانع کننده برای آن وجود دارد: در حالی که داده <emphasis>داخل</emphasis> رایانهٔ شما با سرعتی نزدیک به سرعت نور حرکت می‌کند، غالباً بین دو رایانه به‌طور قابل توجهی کندتر حرکت می‌کند.
Because the languages used in data communications are so terse, we usually refer to them as <emphasis>protocols</emphasis> rather than languages.
از آن رو که زبان‌های استفاده شده در ارتباطات داده بسیار مختصرند، ما به‌طور معمول به آنها به جای زبان‌ها، به‌عنوان <emphasis>قراردادها</emphasis> (protocols) اشاره می‌کنیم.
As data travels from one computer to another, it always uses more than one protocol. These protocols are <emphasis>layered</emphasis>. The data can be compared to the inside of an onion: You have to peel off several layers of <quote>skin</quote> to get to the data. This is best illustrated with a picture:
وقتی داده از رایانه‌ای به رایانه‌ای دیگر حرکت می‌کند، همیشه از بیش از یک قرارداد استفاده می‌کند. این قراردادها <emphasis>لایه‌لایه</emphasis> هستند. داده را می‌توان با داخل یک پیاز قیاس کرد: باید رسیدن به داده، باید چند لایه از <quote>پوست</quote> را جدا کنید. این موضوع بهتر است با یک تصویر تشریح شود:
_
external ref='sockets/layers' md5='__failed__'
external ref='sockets/layers' md5='__failed__'
+----------------+
| Ethernet |
|+--------------+|
|| IP ||
||+------------+||
||| TCP |||
|||+----------+|||
|||| HTTP ||||
||||+--------+||||
||||| PNG |||||
|||||+------+|||||
|||||| Data ||||||
|||||+------+|||||
||||+--------+||||
|||+----------+|||
||+------------+||
|+--------------+|
+----------------+
+----------------+
| Ethernet |
|+--------------+|
|| IP ||
||+------------+||
||| TCP |||
|||+----------+|||
|||| HTTP ||||
||||+--------+||||
||||| PNG |||||
|||||+------+|||||
|||||| Data ||||||
|||||+------+|||||
||||+--------+||||
|||+----------+|||
||+------------+||
|+--------------+|
+----------------+
<imageobject> <imagedata fileref="sockets/layers"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Protocol Layers</phrase> </textobject>
<imageobject> <imagedata fileref="sockets/layers"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>لایه‌های قرارداد</phrase> </textobject>
In this example, we are trying to get an image from a web page we are connected to via an Ethernet.
در این مثال، ما خواهان دریافت یک عکس از صفحهٔ وبی هستیم که توسط یک Ethernet به آن وصل شده‌ایم.
The image consists of raw data, which is simply a sequence of <acronym>RGB</acronym> values that our software can process, i.e., convert into an image and display on our monitor.
این عکس متشکل از دادهٔ خام است، که در حقیقت دنباله‌ای از مقادیر <acronym>RGB</acronym> هستند که نرم‌افزار ما آن را می‌تواند پردازش کند، به‌گفته‌ای دیگر، به عکسی قابل نمایش بر روی صفحه نمایش ما تبدیل کند.
Alas, our software has no way of knowing how the raw data is organized: Is it a sequence of <acronym>RGB</acronym> values, or a sequence of grayscale intensities, or perhaps of <acronym>CMYK</acronym> encoded colors? Is the data represented by 8-bit quanta, or are they 16 bits in size, or perhaps 4 bits? How many rows and columns does the image consist of? Should certain pixels be transparent?
افسوس، نرم‌افزار ما هیچ راهی برای تشخیص نحوهٔ سازماندهی داده‌های خام ندارد: آیا این یک دنبالهٔ مقادیر <acronym>RGB</acronym> است، یا دنباله‌ای از شدت طیف خاکستری‌ها، یا شاید هم رنگ‌های کدگذاری شدهٔ <acronym>CMYK</acronym>؟ این داده‌ها توسط ذرات هشت بیتی نمایش داده شده‌اند، یا اندازهٔ آنها شانزده بیت، و یا شاید چهار بیت است؟ تصویر متشکل از چند ردیف و ستون است؟ آیا پیکسل‌های خاصی باید شفاف باشند؟
I think you get the picture...
به گمانم که درک کردید...
To inform our software how to handle the raw data, it is encoded as a <acronym>PNG</acronym> file. It could be a <acronym>GIF</acronym>, or a <acronym>JPEG</acronym>, but it is a <acronym>PNG</acronym>.
برای مطلع‌سازی نرم‌افزار ما از نحوهٔ مدیریت داده‌های خام، تصویر به‌عنوان یک پروندهٔ <acronym>PNG</acronym> کدگذاری شده‌است. می‌توانست یک <acronym>GIF</acronym>، یا یک <acronym>JPEG</acronym> باشد، اما یک <acronym>PNG</acronym> است.
And <acronym>PNG</acronym> is a protocol.
و <acronym>PNG</acronym> یک قرارداد است.
At this point, I can hear some of you yelling, <emphasis><quote>No, it is not! It is a file format!</quote></emphasis>
در این مرحله، می‌توانم برخی از شما را بشنوم که دارید فریاد می‌زنید، <emphasis><quote>نه، اینطور نیست! این یک قالب پرونده است!</quote></emphasis>
Well, of course it is a file format. But from the perspective of data communications, a file format is a protocol: The file structure is a <emphasis>language</emphasis>, a terse one at that, communicating to our <emphasis>process</emphasis> how the data is organized. Ergo, it is a <emphasis>protocol</emphasis>.
البته که این یک قالب پرونده است. اما از منظر ارتباطات داده، یک قالب پرونده یک قرارداد است. ساختار پرونده یک <emphasis>زبان</emphasis> است، یک زبان مختصر، که <emphasis>فرآیند</emphasis> ما را در روند سازمان‌دهی داده مطلع می‌سازد. بنابراین، یک <emphasis>قرارداد</emphasis> است.
Alas, if all we received was the <acronym>PNG</acronym> file, our software would be facing a serious problem: How is it supposed to know the data is representing an image, as opposed to some text, or perhaps a sound, or what not? Secondly, how is it supposed to know the image is in the <acronym>PNG</acronym> format as opposed to <acronym>GIF</acronym>, or <acronym>JPEG</acronym>, or some other image format?
 
To obtain that information, we are using another protocol: <acronym>HTTP</acronym>. This protocol can tell us exactly that the data represents an image, and that it uses the <acronym>PNG</acronym> protocol. It can also tell us some other things, but let us stay focused on protocol layers here.
 
So, now we have some data wrapped in the <acronym>PNG</acronym> protocol, wrapped in the <acronym>HTTP</acronym> protocol. How did we get it from the server?
 
By using <acronym>TCP/IP</acronym> over Ethernet, that is how. Indeed, that is three more protocols. Instead of continuing inside out, I am now going to talk about Ethernet, simply because it is easier to explain the rest that way.
 
Ethernet is an interesting system of connecting computers in a <emphasis>local area network</emphasis> (<acronym>LAN</acronym>). Each computer has a <emphasis>network interface card</emphasis> (<acronym>NIC</acronym>), which has a unique 48-bit <acronym>ID</acronym> called its <emphasis>address</emphasis>. No two Ethernet <acronym>NIC</acronym>s in the world have the same address.
 
These <acronym>NIC</acronym>s are all connected with each other. Whenever one computer wants to communicate with another in the same Ethernet <acronym>LAN</acronym>, it sends a message over the network. Every <acronym>NIC</acronym> sees the message. But as part of the Ethernet <emphasis>protocol</emphasis>, the data contains the address of the destination <acronym>NIC</acronym> (among other things). So, only one of all the network interface cards will pay attention to it, the rest will ignore it.
 
But not all computers are connected to the same network. Just because we have received the data over our Ethernet does not mean it originated in our own local area network. It could have come to us from some other network (which may not even be Ethernet based) connected with our own network via the Internet.
 
All data is transferred over the Internet using <acronym>IP</acronym>, which stands for <emphasis>Internet Protocol</emphasis>. Its basic role is to let us know where in the world the data has arrived from, and where it is supposed to go to. It does not <emphasis>guarantee</emphasis> we will receive the data, only that we will know where it came from <emphasis>if</emphasis> we do receive it.
 
Even if we do receive the data, <acronym>IP</acronym> does not guarantee we will receive various chunks of data in the same order the other computer has sent it to us. So, we can receive the center of our image before we receive the upper left corner and after the lower right, for example.
 
It is <acronym>TCP</acronym> (<emphasis>Transmission Control Protocol</emphasis>) that asks the sender to resend any lost data and that places it all into the proper order.
این <acronym>TCP</acronym> (<emphasis>قرارداد هدایت انتقال</emphasis>) است که از فرستنده درخواست ارسال مجدد هر دادهٔ گم‌شده را می‌کند و تمام آن را در ترتیب درست قرار می‌دهد.
All in all, it took <emphasis>five</emphasis> different protocols for one computer to communicate to another what an image looks like. We received the data wrapped into the <acronym>PNG</acronym> protocol, which was wrapped into the <acronym>HTTP</acronym> protocol, which was wrapped into the <acronym>TCP</acronym> protocol, which was wrapped into the <acronym>IP</acronym> protocol, which was wrapped into the <acronym>Ethernet</acronym> protocol.
 
Oh, and by the way, there probably were several other protocols involved somewhere on the way. For example, if our <acronym>LAN</acronym> was connected to the Internet through a dial-up call, it used the <acronym>PPP</acronym> protocol over the modem which used one (or several) of the various modem protocols, et cetera, et cetera, et cetera...
 
As a developer you should be asking by now, <emphasis><quote>How am I supposed to handle it all?</quote></emphasis>
به‌عنوان یک توسعه‌دهنده، این سؤال باید برایتان پیش آمده باشد که <emphasis><quote>چطور باید همهٔ این را مدیریت کنم؟</quote></emphasis>
Luckily for you, you are <emphasis>not</emphasis> supposed to handle it all. You <emphasis>are</emphasis> supposed to handle some of it, but not all of it. Specifically, you need not worry about the physical connection (in our case Ethernet and possibly <acronym>PPP</acronym>, etc). Nor do you need to handle the Internet Protocol, or the Transmission Control Protocol.
 
In other words, you do not have to do anything to receive the data from the other computer. Well, you do have to <emphasis>ask</emphasis> for it, but that is almost as simple as opening a file.
 
Once you have received the data, it is up to you to figure out what to do with it. In our case, you would need to understand the <acronym>HTTP</acronym> protocol and the <acronym>PNG</acronym> file structure.
 

Loading…

No matching activity found.

Browse all component changes

Glossary

English Persian
Contributed Software نرم‌افزارهای اعطا شده FreeBSD Doc
Data validation اعتبارسنجی داده FreeBSD Doc
Core file پروندهٔ حافظه FreeBSD Doc
Object file پروندهٔ هدف FreeBSD Doc
File پرونده FreeBSD Doc
File System سامانهٔ پرونده FreeBSD Doc

Source information

Source string comment
(itstool) path: sect1/para
Labels
No labels currently set.
Source string location
book.translate.xml:5041
Source string age
2 months ago
Translation file
books/fa/developers-handbook.po, string 842