The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: sect4/para
Context English State
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.
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 <citerefentry><refentrytitle>htons</refentrytitle><manvolnum>3</manvolnum></citerefentry> and <citerefentry><refentrytitle>htonl</refentrytitle><manvolnum>3</manvolnum></citerefentry> C functions to convert a <varname>short</varname> and <varname>long</varname> respectively from the <emphasis>host byte order</emphasis> to the <emphasis>network byte order</emphasis>, and the <citerefentry><refentrytitle>ntohs</refentrytitle><manvolnum>3</manvolnum></citerefentry> and <citerefentry><refentrytitle>ntohl</refentrytitle><manvolnum>3</manvolnum></citerefentry> C functions to go the other way.
On <emphasis><acronym>MSB</acronym>-first</emphasis> systems these functions do nothing. On <emphasis><acronym>LSB</acronym>-first</emphasis> 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.
Client Functions
Typically, the client initiates the connection to the server. The client knows which server it is about to call: It knows its <acronym>IP</acronym> address, and it knows the <emphasis>port</emphasis> the server resides at. It is akin to you picking up the phone and dialing the number (the <emphasis>address</emphasis>), then, after someone answers, asking for the person in charge of wingdings (the <emphasis>port</emphasis>).
Once a client has created a socket, it needs to connect it to a specific port on a remote system. It uses <citerefentry><refentrytitle>connect</refentrytitle><manvolnum>2</manvolnum></citerefentry>:
int connect(int s, const struct sockaddr *name, socklen_t namelen);
The <varname>s</varname> argument is the socket, i.e., the value returned by the <function>socket</function> function. The <varname>name</varname> is a pointer to <varname>sockaddr</varname>, the structure we have talked about extensively. Finally, <varname>namelen</varname> informs the system how many bytes are in our <varname>sockaddr</varname> structure.
If <function>connect</function> is successful, it returns <constant>0</constant>. Otherwise it returns <constant>-1</constant> and stores the error code in <varname>errno</varname>.
There are many reasons why <function>connect</function> may fail. For example, with an attempt to an Internet connection, the <acronym>IP</acronym> address may not exist, or it may be down, or just too busy, or it may not have a server listening at the specified port. Or it may outright <emphasis>refuse</emphasis> any request for specific code.
Our First Client
We now know enough to write a very simple client, one that will get current time from <systemitem class="ipaddress"></systemitem> and print it to <filename>stdout</filename>.
* daytime.c
* Programmed by G. Adam Stanislav
#include &lt;stdio.h&gt;
#include &lt;string.h&gt;
#include &lt;sys/types.h&gt;
#include &lt;sys/socket.h&gt;
#include &lt;netinet/in.h&gt;

int main() {
register int s;
register int bytes;
struct sockaddr_in sa;
char buffer[BUFSIZ+1];

if ((s = socket(PF_INET, SOCK_STREAM, 0)) &lt; 0) {
return 1;

bzero(&amp;sa, sizeof sa);

sa.sin_family = AF_INET;
sa.sin_port = htons(13);
sa.sin_addr.s_addr = htonl((((((192 &lt;&lt; 8) | 43) &lt;&lt; 8) | 244) &lt;&lt; 8) | 18);
if (connect(s, (struct sockaddr *)&amp;sa, sizeof sa) &lt; 0) {
return 2;

while ((bytes = read(s, buffer, BUFSIZ)) &gt; 0)
write(1, buffer, bytes);

return 0;
Go ahead, enter it in your editor, save it as <filename>daytime.c</filename>, then compile and run it:
<prompt>%</prompt> <userinput>cc -O3 -o daytime daytime.c</userinput>
<prompt>%</prompt> <userinput>./daytime</userinput>

52079 01-06-19 02:29:25 50 0 1 543.9 UTC(NIST) *
In this case, the date was June 19, 2001, the time was 02:29:25 <acronym>UTC</acronym>. Naturally, your results will vary.
Server Functions
The typical server does not initiate the connection. Instead, it waits for a client to call it and request services. It does not know when the client will call, nor how many clients will call. It may be just sitting there, waiting patiently, one moment, The next moment, it can find itself swamped with requests from a number of clients, all calling in at the same time.
The sockets interface offers three basic functions to handle this.
Ports are like extensions to a phone line: After you dial a number, you dial the extension to get to a specific person or department.
There are 65535 <acronym>IP</acronym> ports, but a server usually processes requests that come in on only one of them. It is like telling the phone room operator that we are now at work and available to answer the phone at a specific extension. We use <citerefentry><refentrytitle>bind</refentrytitle><manvolnum>2</manvolnum></citerefentry> to tell sockets which port we want to serve.
int bind(int s, const struct sockaddr *addr, socklen_t addrlen);
Beside specifying the port in <varname>addr</varname>, the server may include its <acronym>IP</acronym> address. However, it can just use the symbolic constant <symbol>INADDR_ANY</symbol> to indicate it will serve all requests to the specified port regardless of what its <acronym>IP</acronym> address is. This symbol, along with several similar ones, is declared in <filename>netinet/in.h</filename>
#define INADDR_ANY (u_int32_t)0x00000000
Suppose we were writing a server for the <emphasis>daytime</emphasis> protocol over <acronym>TCP</acronym>/<acronym>IP</acronym>. Recall that it uses port 13. Our <varname>sockaddr_in</varname> structure would look like this:
_ external ref='sockets/sainserv' md5='__failed__'


No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

Following checks are failing:
Mismatched full stop: Portuguese (Brazil)
Trailing space: Portuguese (Brazil)


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 968