Source string Read only

(itstool) path: sect4/para
Context English State
_ external ref='sockets/sainlsb' md5='__failed__'
0 1 2 3
0 | 0 | 2 | 13 | 0 |
4 | 18 | 244 | 43 | 192 |
8 | 0 |
12 | 0 |
<imageobject> <imagedata fileref="sockets/sainlsb"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>sockaddr_in on an Intel system</phrase> </textobject>
On a different system, it might look like this:
_ external ref='sockets/sainmsb' md5='__failed__'
0 1 2 3
0 | 0 | 2 | 0 | 13 |
4 | 192 | 43 | 244 | 18 |
8 | 0 |
12 | 0 |
<imageobject> <imagedata fileref="sockets/sainmsb"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>sockaddr_in on an MSB system</phrase> </textobject>
And on a PDP it might look different yet. But the above two are the most common ways in use today.
Ordinarily, wanting to write portable code, programmers pretend that these differences do not exist. And they get away with it (except when they code in assembly language). Alas, you cannot get away with it that easily when coding for sockets.
Because when communicating with another computer, you usually do not know whether it stores data <emphasis>most significant byte</emphasis> (<acronym>MSB</acronym>) or <emphasis>least significant byte</emphasis> (<acronym>LSB</acronym>) first.
You might be wondering, <emphasis><quote>So, will sockets not handle it for me?</quote></emphasis>
It will not.
While that answer may surprise you at first, remember that the general sockets interface only understands the <varname>sa_len</varname> and <varname>sa_family</varname> fields of the <varname>sockaddr</varname> structure. You do not have to worry about the byte order there (of course, on FreeBSD <varname>sa_family</varname> is only 1 byte anyway, but many other <trademark class="registered">UNIX</trademark> systems do not have <varname>sa_len</varname> and use 2 bytes for <varname>sa_family</varname>, and expect the data in whatever order is native to the computer).
But the rest of the data is just <varname>sa_data[14]</varname> as far as sockets goes. Depending on the <emphasis>address family</emphasis>, sockets just forwards that data to its destination.
Indeed, when we enter a port number, it is because we want the other computer to know what service we are asking for. And, when we are the server, we read the port number so we know what service the other computer is expecting from us. Either way, sockets only has to forward the port number as data. It does not interpret it in any way.
Similarly, we enter the <acronym>IP</acronym> address to tell everyone on the way where to send our data to. Sockets, again, only forwards it as data.
That is why, we (the <emphasis>programmers</emphasis>, not the <emphasis>sockets</emphasis>) have to distinguish between the byte order used by our computer and a conventional byte order to send the data in to the other computer.
We will call the byte order our computer uses the <emphasis>host byte order</emphasis>, or just the <emphasis>host order</emphasis>.
There is a convention of sending the multi-byte data over <acronym>IP</acronym> <emphasis><acronym>MSB</acronym> first</emphasis>. This, we will refer to as the <emphasis>network byte order</emphasis>, or simply the <emphasis>network order</emphasis>.
Now, if we compiled the above code for an Intel based computer, our <emphasis>host byte order</emphasis> would produce:
<imageobject> <imagedata fileref="sockets/sainlsb"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Host byte order on an Intel system</phrase> </textobject>
But the <emphasis>network byte order</emphasis> requires that we store the data <acronym>MSB</acronym> first:
<imageobject> <imagedata fileref="sockets/sainmsb"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Network byte order</phrase> </textobject>
Unfortunately, our <emphasis>host order</emphasis> is the exact opposite of the <emphasis>network order</emphasis>.
We have several ways of dealing with it. One would be to <emphasis>reverse</emphasis> the values in our code:
sa.sin_family = AF_INET;
sa.sin_port = 13 &lt;&lt; 8;
sa.sin_addr.s_addr = (((((18 &lt;&lt; 8) | 244) &lt;&lt; 8) | 43) &lt;&lt; 8) | 192;
This will <emphasis>trick</emphasis> our compiler into storing the data in the <emphasis>network byte order</emphasis>. In some cases, this is exactly the way to do it (e.g., when programming in assembly language). In most cases, however, it can cause a problem.
Suppose, you wrote a sockets-based program in C. You know it is going to run on a <trademark class="registered">Pentium</trademark>, so you enter all your constants in reverse and force them to the <emphasis>network byte order</emphasis>. It works well.
Then, some day, your trusted old <trademark class="registered">Pentium</trademark> becomes a rusty old <trademark class="registered">Pentium</trademark>. You replace it with a system whose <emphasis>host order</emphasis> is the same as the <emphasis>network order</emphasis>. You need to recompile all your software. All of your software continues to perform well, except the one program you wrote.
You have since forgotten that you had forced all of your constants to the opposite of the <emphasis>host order</emphasis>. You spend some quality time tearing out your hair, calling the names of all gods you ever heard of (and some you made up), hitting your monitor with a nerf bat, and performing all the other traditional ceremonies of trying to figure out why something that has worked so well is suddenly not working at all.


No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks



English English
No related strings found in the glossary.

Source information

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