Source string Read only

(itstool) path: sect1/para
231/2310
Context English State
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:
_ external ref='sockets/layers' md5='__failed__'
+----------------+
| Ethernet |
|+--------------+|
|| IP ||
||+------------+||
||| TCP |||
|||+----------+|||
|||| HTTP ||||
||||+--------+||||
||||| PNG |||||
|||||+------+|||||
|||||| Data ||||||
|||||+------+|||||
||||+--------+||||
|||+----------+|||
||+------------+||
|+--------------+|
+----------------+
<imageobject> <imagedata fileref="sockets/layers"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Protocol Layers</phrase> </textobject>
In this example, we are trying to get an image from a web page we are connected to via an 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.
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?
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>.
And <acronym>PNG</acronym> is a protocol.
At this point, I can hear some of you yelling, <emphasis><quote>No, it is not! It is a file format!</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>.
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.
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>
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.
To use an analogy, all the internetworking protocols become a gray area: Not so much because we do not understand how it works, but because we are no longer concerned about it. The sockets interface takes care of this gray area for us:
_ external ref='sockets/slayers' md5='__failed__'
+----------------+
|xxxxEthernetxxxx|
|+--------------+|
||xxxxxxIPxxxxxx||
||+------------+||
|||xxxxxTCPxxxx|||
|||+----------+|||
|||| HTTP ||||
||||+--------+||||
||||| PNG |||||
|||||+------+|||||
|||||| Data ||||||
|||||+------+|||||
||||+--------+||||
|||+----------+|||
||+------------+||
|+--------------+|
+----------------+

Loading…

No matching activity found.

Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Flags
read-only
Source string location
book.translate.xml:5101
String age
a year ago
Source string age
a year ago
Translation file
books/developers-handbook.pot, string 855