From owner-svn-doc-head@freebsd.org Sun Aug 26 18:34:51 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16D07107DFAF; Sun, 26 Aug 2018 18:34:51 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C04078B128; Sun, 26 Aug 2018 18:34:50 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A23ED12ACC; Sun, 26 Aug 2018 18:34:50 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7QIYo9f009735; Sun, 26 Aug 2018 18:34:50 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7QIYoBa009734; Sun, 26 Aug 2018 18:34:50 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201808261834.w7QIYoBa009734@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Sun, 26 Aug 2018 18:34:50 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52177 - head/en_US.ISO8859-1/books/developers-handbook/sockets X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/developers-handbook/sockets X-SVN-Commit-Revision: 52177 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 18:34:51 -0000 Author: bcr Date: Sun Aug 26 18:34:50 2018 New Revision: 52177 URL: https://svnweb.freebsd.org/changeset/doc/52177 Log: Correct errors reported by textproc/igor: - wrap long lines - add two spaces after a sentence stop - use tabs instead of spaces - bad tag indent Modified: head/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.xml Modified: head/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.xml Sun Aug 26 15:56:45 2018 (r52176) +++ head/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.xml Sun Aug 26 18:34:50 2018 (r52177) @@ -4,29 +4,37 @@ $FreeBSD$ --> - - Sockets + + + Sockets + - G. AdamStanislavContributed by + + + G. Adam + Stanislav + + Contributed by + - - Synopsis BSD sockets take interprocess - communications to a new level. It is no longer necessary for the - communicating processes to run on the same machine. They still - can, but they do not have to. + communications to a new level. It is no longer necessary for + the communicating processes to run on the same machine. They + still can, but they do not have to. Not only do these processes not have to run on the same machine, they do not have to run under the same operating - system. Thanks to BSD sockets, your FreeBSD + system. Thanks to BSD sockets, your FreeBSD software can smoothly cooperate with a program running on a - &macintosh;, another one running on a &sun; workstation, yet another - one running under &windows; 2000, all connected with an + &macintosh;, another one running on a &sun; workstation, yet + another one running under &windows; 2000, all connected with an Ethernet-based local area network. But your software can equally well cooperate with processes @@ -44,40 +52,40 @@ Networking and Diversity We have already hinted on the diversity - of networking. Many different systems have to talk to each - other. And they have to speak the same language. They also have - to understand the same language the same - way. + of networking. Many different systems have to talk to each + other. And they have to speak the same language. They also + have to understand the same language the + same way. People often think that body language - is universal. But it is not. Back in my early teens, my father - took me to Bulgaria. We were sitting at a table in a park in + is universal. But it is not. Back in my early teens, my father + took me to Bulgaria. We were sitting at a table in a park in Sofia, when a vendor approached us trying to sell us some roasted almonds. I had not learned much Bulgarian by then, so, instead of saying no, I shook my head from side to side, the universal body language for - no. The vendor quickly started serving us + no. The vendor quickly started serving us some almonds. I then remembered I had been told that in Bulgaria shaking - your head sideways meant yes. Quickly, I - started nodding my head up and down. The vendor noticed, took - his almonds, and walked away. To an uninformed observer, I did + your head sideways meant yes. Quickly, I + started nodding my head up and down. The vendor noticed, took + his almonds, and walked away. To an uninformed observer, I did not change the body language: I continued using the language of - shaking and nodding my head. What changed was the - meaning of the body language. At first, the - vendor and I interpreted the same language as having completely - different meaning. I had to adjust my own interpretation of that - language so the vendor would understand. + shaking and nodding my head. What changed was the + meaning of the body language. At first, + the vendor and I interpreted the same language as having + completely different meaning. I had to adjust my own + interpretation of that language so the vendor would + understand. It is the same with computers: The same symbols may have - different, even outright opposite meaning. Therefore, for - two computers to understand each other, they must not only - agree on the same language, but on the - same interpretation of the language. - + different, even outright opposite meaning. Therefore, for two + computers to understand each other, they must not only agree on + the same language, but on the same + interpretation of the language. @@ -86,7 +94,7 @@ While various programming languages tend to have complex syntax and use a number of multi-letter reserved words (which makes them easy for the human programmer to understand), the - languages of data communications tend to be very terse. Instead + languages of data communications tend to be very terse. Instead of multi-byte words, they often use individual bits. There is a very convincing reason for it: While data travels inside your @@ -98,7 +106,7 @@ protocols rather than languages. As data travels from one computer to another, it always uses - more than one protocol. These protocols are + more than one protocol. These protocols are layered. The data can be compared to the inside of an onion: You have to peel off several layers of skin to get to the data. This is best @@ -106,11 +114,11 @@ - + - +----------------+ + +----------------+ | Ethernet | |+--------------+| || IP || @@ -131,7 +139,7 @@ - Protocol Layers + Protocol Layers @@ -153,7 +161,7 @@ I think you get the picture... To inform our software how to handle the raw data, it is - encoded as a PNG file. It could be a + encoded as a PNG file. It could be a GIF, or a JPEG, but it is a PNG. @@ -161,13 +169,13 @@ At this point, I can hear some of you yelling, No, it is not! It is a file - format! + format! - Well, of course it is a file format. But from the + Well, of course it is a file format. But from the perspective of data communications, a file format is a protocol: The file structure is a language, a terse one at that, communicating to our process - how the data is organized. Ergo, it is a + how the data is organized. Ergo, it is a protocol. Alas, if all we received was the PNG @@ -179,63 +187,63 @@ JPEG, or some other image format? To obtain that information, we are using another protocol: - HTTP. This protocol can tell us exactly that + HTTP. This protocol can tell us exactly that the data represents an image, and that it uses the - PNG protocol. It can also tell us some other - things, but let us stay focused on protocol layers here. - + PNG 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 PNG - protocol, wrapped in the HTTP protocol. - How did we get it from the server? + So, now we have some data wrapped in the + PNG protocol, wrapped in the + HTTP protocol. How did we get it from the + server? By using TCP/IP over Ethernet, that is - how. Indeed, that is three more protocols. Instead of + 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 local area network (LAN). Each computer has a network - interface card (NIC), which has a - unique 48-bit ID called its - address. No two Ethernet - NICs in the world have the same address. - + interface card (NIC), which has + a unique 48-bit ID called its + address. No two Ethernet + NICs in the world have the same + address. These NICs are all connected with each - other. Whenever one computer wants to communicate with another + other. Whenever one computer wants to communicate with another in the same Ethernet LAN, it sends a message - over the network. Every NIC sees the - message. But as part of the Ethernet + over the network. Every NIC sees the + message. But as part of the Ethernet protocol, the data contains the address of - the destination NIC (among other things). So, - only one of all the network interface cards will pay attention - to it, the rest will ignore it. + the destination NIC (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. + 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 IP, which stands for Internet - Protocol. 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 guarantee we will + Protocol. 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 guarantee we will receive the data, only that we will know where it came from if we do receive it. Even if we do receive the data, IP 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 + 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 TCP (Transmission Control - Protocol) that asks the sender to resend any lost + Protocol) that asks the sender to resend any lost data and that places it all into the proper order. All in all, it took five different @@ -248,7 +256,7 @@ Ethernet protocol. Oh, and by the way, there probably were several other - protocols involved somewhere on the way. For example, if our + protocols involved somewhere on the way. For example, if our LAN was connected to the Internet through a dial-up call, it used the PPP protocol over the modem which used one (or several) of the various modem @@ -256,38 +264,38 @@ As a developer you should be asking by now, How am I supposed to handle it - all? + all? Luckily for you, you are not supposed - to handle it all. You are 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 PPP, etc). Nor do you need to handle - the Internet Protocol, or the Transmission Control + to handle it all. You are 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 PPP, 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 + the data from the other computer. Well, you do have to ask 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 + out what to do with it. In our case, you would need to understand the HTTP protocol and the PNG 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 + works, but because we are no longer concerned about it. The sockets interface takes care of this gray area for us: - + - +----------------+ + +----------------+ |xxxxEthernetxxxx| |+--------------+| ||xxxxxxIPxxxxxx|| @@ -308,7 +316,7 @@ - Sockets Covered Protocol Layers + Sockets Covered Protocol Layers @@ -325,14 +333,13 @@ BSD sockets are built on the basic &unix; model: Everything is a file. In our example, then, sockets would let us receive an HTTP - file, so to speak. It would then be up to us to + file, so to speak. It would then be up to us to extract the PNG file - from it. - + from it. Because of the complexity of internetworking, we cannot just use the open system call, or - the open() C function. Instead, we need to + the open() C function. Instead, we need to take several steps to opening a socket. Once we do, however, we can start treating the @@ -356,32 +363,30 @@ The Client-Server Difference Typically, one of the ends of a socket-based data - communication is a server, the other is a - client. + communication is a server, the other is a + client. - The Common Elements + The Common Elements - + <function>socket</function> The one function used by both, clients and servers, is - &man.socket.2;. It is declared this way: + &man.socket.2;. It is declared this way: - -int socket(int domain, int type, int protocol); - + int socket(int domain, int type, int protocol); - The return value is of the same type as that of - open, an integer. FreeBSD allocates + The return value is of the same type as that of + open, 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 domain argument tells the system what protocol family you want - it to use. Many of them exist, some are vendor specific, - others are very common. They are declared in + it to use. Many of them exist, some are vendor specific, + others are very common. They are declared in sys/socket.h. Use PF_INET for @@ -422,25 +427,24 @@ int socket(int domain, int type, int protocol); unconnected. This is on purpose: To use a telephone analogy, we - have just attached a modem to the phone line. We have + 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> Various functions of the sockets family expect the - address of (or pointer to, to use C terminology) a small - area of the memory. The various C declarations in the - sys/socket.h refer to it as - struct sockaddr. This structure is - declared in the same file: + address of (or pointer to, to use C terminology) a small + area of the memory. The various C declarations in the + sys/socket.h refer to it as + struct sockaddr. This structure is + declared in the same file: - -/* + /* * Structure used by kernel to store most * addresses. */ @@ -449,17 +453,16 @@ struct sockaddr { sa_family_t sa_family; /* address family */ char sa_data[14]; /* actually longer; address value */ }; -#define SOCK_MAXADDRLEN 255 /* longest possible addresses */ - +#define SOCK_MAXADDRLEN 255 /* longest possible addresses */ - Please note the vagueness with + Please note the vagueness with which the sa_data field is declared, just as an array of 14 bytes, with the comment hinting there can be more than 14 of them. - This vagueness is quite deliberate. Sockets is a very - powerful interface. While most people perhaps think of it + This vagueness is quite deliberate. Sockets is a very + powerful interface. While most people perhaps think of it as nothing more than the Internet interface—and most applications probably use it for that nowadays—sockets can be used for just about @@ -473,8 +476,7 @@ struct sockaddr { right before the definition of sockaddr: - -/* + /* * Address families. */ #define AF_UNSPEC 0 /* unspecified */ @@ -519,11 +521,9 @@ struct sockaddr { #define AF_SCLUSTER 34 /* Sitara cluster protocol */ #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ -#define AF_MAX 37 +#define AF_MAX 37 - - - The one used for IP is + The one used for IP is AF_INET. It is a symbol for the constant 2. @@ -534,13 +534,12 @@ struct sockaddr { used. Specifically, whenever the address - family is AF_INET, we can use - struct sockaddr_in found in + family is AF_INET, we can + use struct sockaddr_in found in netinet/in.h, wherever sockaddr is expected: - -/* + /* * Socket address, internet style. */ struct sockaddr_in { @@ -549,18 +548,17 @@ struct sockaddr_in { in_port_t sin_port; struct in_addr sin_addr; char sin_zero[8]; -}; - +}; - We can visualize its organization this way: + We can visualize its organization this way: - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+-----------------+ 0 | 0 | Family | Port | +--------+--------+-----------------+ @@ -570,39 +568,41 @@ struct sockaddr_in { +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - sockaddr_in - - + + sockaddr_in + + - The three important fields are + The three important fields are sin_family, which is byte 1 of the structure, sin_port, a 16-bit value found in bytes 2 and 3, and sin_addr, a 32-bit integer representation of the IP address, stored in bytes 4-7. - Now, let us try to fill it out. Let us assume we are + Now, let us try to fill it out. Let us assume we are trying to write a client for the daytime protocol, which simply states that its server will write a text string representing the - current date and time to port 13. We want to use + current date and time to port 13. We want to use TCP/IP, so we need to specify - AF_INET in the address family - field. AF_INET is defined as - 2. Let us use the - IP address of 192.43.244.18, which is the time - server of US federal government (time.nist.gov). + AF_INET in the address family field. + AF_INET is defined as + 2. Let us use the + IP address of 192.43.244.18, which is + the time server of US federal government (time.nist.gov). - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+-----------------+ 0 | 0 | 2 | 13 | +-----------------+-----------------+ @@ -612,59 +612,58 @@ struct sockaddr_in { +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - Specific example of sockaddr_in - - + + Specific example of sockaddr_in + + - By the way the sin_addr field is - declared as being of the struct in_addr - type, which is defined in - netinet/in.h: + By the way the sin_addr field is + declared as being of the struct in_addr + type, which is defined in + netinet/in.h: - -/* + /* * Internet address (a structure for historical reasons) */ struct in_addr { in_addr_t s_addr; -}; - +}; - In addition, in_addr_t is a 32-bit - integer. + In addition, in_addr_t is a 32-bit + integer. - The 192.43.244.18 is - just a convenient notation of expressing a 32-bit integer - by listing all of its 8-bit bytes, starting with the + The 192.43.244.18 is just a + convenient notation of expressing a 32-bit integer by + listing all of its 8-bit bytes, starting with the most significant one. - So far, we have viewed sockaddr as + So far, we have viewed sockaddr as an abstraction. Our computer does not store short integers as a single 16-bit - entity, but as a sequence of 2 bytes. Similarly, it stores - 32-bit integers as a sequence of 4 bytes. + entity, but as a sequence of 2 bytes. Similarly, it + stores 32-bit integers as a sequence of 4 bytes. - Suppose we coded something like this: + Suppose we coded something like this: sa.sin_family = AF_INET; sa.sin_port = 13; sa.sin_addr.s_addr = (((((192 << 8) | 43) << 8) | 244) << 8) | 18; - What would the result look like? + What would the result look like? - Well, that depends, of course. On a &pentium;, or other - x86, based computer, it would look like this: + Well, that depends, of course. On a &pentium;, or + other x86, based computer, it would look like this: - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+--------+--------+ 0 | 0 | 2 | 13 | 0 | +--------+--------+--------+--------+ @@ -674,23 +673,22 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - sockaddr_in on an Intel system - - + + sockaddr_in on an Intel system + + - On a different system, it might look like this: - + On a different system, it might look like this: - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+--------+--------+ 0 | 0 | 2 | 0 | 13 | +--------+--------+--------+--------+ @@ -700,21 +698,21 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - sockaddr_in on an MSB system - - + + sockaddr_in on an MSB system + + - And on a PDP it might look different yet. But the + 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. + 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. Why? @@ -725,37 +723,38 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l (LSB) first. You might be wondering, So, will - sockets not handle it for me? + sockets not handle it for + me? It will not. While that answer may surprise you at first, remember - that the general sockets interface only understands the - sa_len and sa_family - fields of the sockaddr structure. You - do not have to worry about the byte order there (of - course, on FreeBSD sa_family is only 1 - byte anyway, but many other &unix; systems do not have - sa_len and use 2 bytes for - sa_family, and expect the data in - whatever order is native to the computer). + that the general sockets interface only understands the + sa_len and sa_family + fields of the sockaddr structure. You + do not have to worry about the byte order there (of + course, on FreeBSD sa_family is only 1 + byte anyway, but many other &unix; systems do not have + sa_len and use 2 bytes for + sa_family, and expect the data in + whatever order is native to the computer). But the rest of the data is just - sa_data[14] as far as sockets - goes. Depending on the address - family, sockets just forwards that data to its - destination. + sa_data[14] as far as sockets goes. + Depending on the address family, + 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 + 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. + 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 IP address - to tell everyone on the way where to send our data - to. Sockets, again, only forwards it as data. + to tell everyone on the way where to send our data to. + Sockets, again, only forwards it as data. That is why, we (the programmers, not the sockets) have to distinguish @@ -771,8 +770,8 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l over IP MSB first. This, we will refer to as the network byte - order, or simply the network - order. + order, or simply the network + order. Now, if we compiled the above code for an Intel based computer, our host byte order would @@ -780,11 +779,11 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l - - + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+--------+--------+ 0 | 0 | 2 | 13 | 0 | +--------+--------+--------+--------+ @@ -794,24 +793,24 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - Host byte order on an Intel system - - + + Host byte order on an Intel system + + - But the network byte order - requires that we store the data MSB - first: + But the network byte order + requires that we store the data MSB + first: - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+--------+--------+ 0 | 0 | 2 | 0 | 13 | +--------+--------+--------+--------+ @@ -821,135 +820,130 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - Network byte order - - + + Network byte order + + - Unfortunately, our host order is + Unfortunately, our host order is the exact opposite of the network - order. + order. - We have several ways of dealing with it. One would be - to reverse the values in our code: - + We have several ways of dealing with it. One would be + to reverse the values in our + code: sa.sin_family = AF_INET; sa.sin_port = 13 << 8; sa.sin_addr.s_addr = (((((18 << 8) | 244) << 8) | 43) << 8) | 192; - This will trick our compiler - into storing the data in the network byte - order. 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. + This will trick our compiler into + storing the data in the network byte + order. 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 &pentium;, so you enter all - your constants in reverse and force them to the - network byte order. It works - well. + Suppose, you wrote a sockets-based program in C. You + know it is going to run on a &pentium;, so you enter all + your constants in reverse and force them to the + network byte order. It works + well. - Then, some day, your trusted old &pentium; becomes a - rusty old &pentium;. You replace it with a system whose - host order is the same as the - network order. You need to recompile - all your software. All of your software continues to - perform well, except the one program you wrote. + Then, some day, your trusted old &pentium; becomes a + rusty old &pentium;. You replace it with a system whose + host order is the same as the + network order. 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 host - order. 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. + You have since forgotten that you had forced all of + your constants to the opposite of the host + order. 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. - Eventually, you figure it out, say a couple of swear - words, and start rewriting your code. + Eventually, you figure it out, say a couple of swear + words, and start rewriting your code. - Luckily, you are not the first one to face the - problem. Someone else has created the &man.htons.3; and - &man.htonl.3; C functions to convert a - short and long - respectively from the host byte - order to the network byte - order, and the &man.ntohs.3; and &man.ntohl.3; - C functions to go the other way. + Luckily, you are not the first one to face the + problem. Someone else has created the &man.htons.3; and + &man.htonl.3; C functions to convert a + short and long + respectively from the host byte order + to the network byte order, and the + &man.ntohs.3; and &man.ntohl.3; C functions to go the + other way. - On MSB-first - systems these functions do nothing. On - LSB-first systems - they convert values to the proper order. + On MSB-first + systems these functions do nothing. On + LSB-first systems + they convert values to the proper order. - So, regardless of what system your software is - compiled on, your data will end up in the correct order - if you use these functions. - - - + So, regardless of what system your software is + compiled on, your data will end up in the correct order if + you use these functions. + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***