Source string Read only

(itstool) path: sect2/para
141/1410
Context English State
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>
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.
The Unconnected Socket
Nowhere, in the <function>socket</function> function have we specified to what other system we should be connected. Our newly created socket remains <emphasis>unconnected</emphasis>.
This is on purpose: To use a telephone analogy, we have just attached a modem to the phone line. We have neither told the modem to make a call, nor to answer if the phone rings.
<varname>sockaddr</varname>

Loading…

No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

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