Source string Read only

(itstool) path: sect1/title
Context English State
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__'
|||| 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
The one function used by both, clients and servers, is <citerefentry><refentrytitle>socket</refentrytitle><manvolnum>2</manvolnum></citerefentry>. It is declared this way:
int socket(int domain, int type, int protocol);
The return value is of the same type as that of <function>open</function>, an integer. FreeBSD allocates its value from the same pool as that of file handles. That is what allows sockets to be treated the same way as files.
The <varname>domain</varname> argument tells the system what <emphasis>protocol family</emphasis> you want it to use. Many of them exist, some are vendor specific, others are very common. They are declared in <filename>sys/socket.h</filename>.
Use <constant>PF_INET</constant> for <acronym>UDP</acronym>, <acronym>TCP</acronym> and other Internet protocols (<acronym>IP</acronym>v4).
Five values are defined for the <varname>type</varname> argument, again, in <filename>sys/socket.h</filename>. All of them start with <quote><constant>SOCK_</constant></quote>. The most common one is <constant>SOCK_STREAM</constant>, which tells the system you are asking for a <emphasis>reliable stream delivery service</emphasis> (which is <acronym>TCP</acronym> when used with <constant>PF_INET</constant>).


No matching activity found.

Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/title
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/developers-handbook.pot, string 873