Source string Read only

(itstool) path: sect1/para
Context English State
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>).
If you asked for <constant>SOCK_DGRAM</constant>, you would be requesting a <emphasis>connectionless datagram delivery service</emphasis> (in our case, <acronym>UDP</acronym>).
If you wanted to be in charge of the low-level protocols (such as <acronym>IP</acronym>), or even network interfaces (e.g., the Ethernet), you would need to specify <constant>SOCK_RAW</constant>.
Finally, the <varname>protocol</varname> argument depends on the previous two arguments, and is not always meaningful. In that case, use <constant>0</constant> for its value.


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