Source string Read only

(itstool) path: sect1/para
208/2080
Context English State
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 ||||||
|||||+------+|||||
||||+--------+||||
|||+----------+|||
||+------------+||
|+--------------+|
+----------------+
<imageobject> <imagedata fileref="sockets/slayers"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Sockets Covered Protocol Layers</phrase> </textobject>
We only need to understand any protocols that tell us how to <emphasis>interpret the data</emphasis>, not how to <emphasis>receive</emphasis> it from another process, nor how to <emphasis>send</emphasis> it to another process.
The Sockets Model
<acronym>BSD</acronym> sockets are built on the basic <trademark class="registered">UNIX</trademark> model: <emphasis>Everything is a file.</emphasis> In our example, then, sockets would let us receive an <emphasis>HTTP file</emphasis>, so to speak. It would then be up to us to extract the <emphasis><acronym>PNG</acronym> file</emphasis> from it.
Because of the complexity of internetworking, we cannot just use the <function role="syscall">open</function> system call, or the <function>open()</function> C function. Instead, we need to take several steps to <quote>opening</quote> a socket.
Once we do, however, we can start treating the <emphasis>socket</emphasis> the same way we treat any <emphasis>file descriptor</emphasis>: We can <function>read</function> from it, <function>write</function> to it, <function>pipe</function> it, and, eventually, <function>close</function> it.
Essential Socket Functions
While FreeBSD offers different functions to work with sockets, we only <emphasis>need</emphasis> four to <quote>open</quote> a socket. And in some cases we only need two.
The Client-Server Difference
Typically, one of the ends of a socket-based data communication is a <emphasis>server</emphasis>, the other is a <emphasis>client</emphasis>.
The Common Elements
<function>socket</function>

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:5183
String age
a year ago
Source string age
a year ago
Translation file
books/developers-handbook.pot, string 867