Sockets TCP and UDP echo server using select function

The server first reads 2 bytes, determines the size of the data, and then reads all the data:

(ok, Header) = gen_tcp:recv(Socket, 2),<> = Header, (ok, Msg) = gen_tcp:recv(Socket, Size),

In the server code the functions start/0 And start/1 have not changed, the rest has changed a little:

Server(Port) -> io:format("start server at port ~p~n", ), (ok, ListenSocket) = gen_tcp:listen(Port, ), ) || ID<- lists:seq(1, 5)], timer:sleep(infinity), ok. accept(Id, ListenSocket) ->io:format("Socket #~p wait for client~n", ), (ok, Socket) = gen_tcp:accept(ListenSocket), io:format("Socket #~p, session started~n", ), handle_connection (Id, ListenSocket, Socket). handle_connection(Id, ListenSocket, Socket) -> case gen_tcp:recv(Socket, 2) of (ok, Header) -><> = Header, (ok, Msg) = gen_tcp:recv(Socket, Size), io:format("Socket #~p got message: ~p~n", ), gen_tcp:send(Socket, Msg), handle_connection( Id, ListenSocket, Socket); (error, closed) -> io:format("Socket #~p, session closed ~n", ), accept(Id, ListenSocket) end.

An example of a session from the client side:

2> Pid = client2:start(). Client<0.40.0>connects to "localhost":1234<0.40.0>3> client2:send(Pid,<<"Hello">>). Client<0.40.0>send<<"Hello">> ok Client<0.40.0>got message:<<"Hello">> 4> client2:send(Pid,<<"Hello again">>). Client<0.40.0>send<<"Hello again">> ok Client<0.40.0>got message:<<"Hello again">> 5> client2:stop(Pid). Client<0.40.0>closes connection and stops ok

And from the server side:

2> server2:start(). start server at port 1234 ok Socket #1 wait for client Socket #2 wait for client Socket #3 wait for client Socket #4 wait for client Socket #5 wait for client Socket #1, session started Socket #1 got message:<<"Hello">> Socket #1 got message:<<"Hello again">> Socket #1, session closed Socket #1 wait for client

This is all well and good, but there's really no need to manually deal with the header package. This has already been implemented in gen_tcp. You need to specify the size of the service packet in the settings when opening a socket on the client side:

(ok, Socket) = gen_tcp:connect(Host, Port, ),

and on the server side:

(ok, ListenSocket) = gen_tcp:listen(Port, ),

and the need to form and parse these headers yourself disappears.

On the client side, sending is simplified:

Gen_tcp:send(Socket, Msg),

and on the server side it makes it easier to get:

Handle_connection(Id, ListenSocket, Socket) -> case gen_tcp:recv(Socket, 0) of (ok, Msg) -> io:format("Socket #~p got message: ~p~n", ), gen_tcp:send (Socket, Msg), handle_connection(Id, ListenSocket, Socket); (error, closed) -> io:format("Socket #~p, session closed ~n", ), accept(Id, ListenSocket) end.

Now when calling gen_tcp:recv/2 we specify Length = 0. gen_tcp it knows how many bytes need to be read from the socket.

Working with text protocols

In addition to the service header option, there is another approach. You can read from the socket one byte at a time until a special byte is encountered, symbolizing the end of the packet. This can be a null byte, or a newline character.

This option is typical for text protocols (SMTP, POP3, FTP).

There is no need to write your own implementation of reading from a socket, everything is already implemented in gen_tcp. You just need to specify in the socket settings instead (packet, 2) option (packet, line).

(ok, ListenSocket) = gen_tcp:listen(Port, ),

Otherwise, the server code remains unchanged. But now we can return to the telnet client again.

$ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is "^]". hello hello hello again hello again ^] telnet> quit Connection closed.

We will need a TCP server, a text protocol and a telnet client in our course work.

Applications that use TCP and UDP are fundamentally different because UDP is an unreliable, connectionless datagram protocol and is fundamentally different from the connection-oriented, byte-stream-reliable transfer of TCP. However, there are cases where it makes sense to use UDP instead of TCP. We consider such cases in Section 22.4. Some popular apps built using UDP, such as DNS (Domain Name System), NFS (network file system- Network File System) and SNMP (Simple Network Management Protocol).

In Fig. Figure 8.1 shows function calls for a typical UDP client-server scheme. The client does not establish a connection to the server. Instead, the client simply sends a datagram to the server using the sendto function (described in the next section), which takes the recipient (server) address as an argument. Likewise, the server does not establish a connection with the client. Instead, the server just calls the recvfrom function, which waits for data to arrive from some client. The recvfrom function returns the client address (for a given protocol) along with the datagram, so that the server can send a response to the exact client that sent the datagram.

Rice. 8.1. Socket functions for the UDP client-server model

Figure 8.1 illustrates the timing diagram of a typical UDP datagram exchange scenario between a client and server. We can compare this example with the typical TCP exchange shown in Figure. 4.1.

In this chapter, we'll describe the new functions used with UDP sockets, recvfrom and sendto, and rework our client-server model to use UDP. We'll also look at using the connect function with a UDP socket and the concept of asynchronous errors.

8.2. recvfrom and sendto functions

These two functions are similar to the standard read and write functions, but require three additional arguments.

ssize_t recvfrom(int sockfd , void * buff , size_t nbytes , int flags ,

struct sockaddr * from , socklen_t * addrlen);

ssize_t sendto(int sockfd, const void * buff, size_t nbytes, int flags,

const struct sockaddr * to , socklen_t addrlen);

Both functions return the number of bytes written or read on success, -1 on error.

The first three arguments, sockfd , buff , and nbytes , are identical to the first three arguments of the read and write functions: a handle, a pointer to the buffer to read from or write to, and the number of bytes to read or write.

We'll cover the flags argument in Chapter 14, where we look at the recv, send, recvmsg, and sendmsg functions, since we don't need them in our simple example right now. For now we will always set the flags argument to zero.

The to argument to the sendto function is a socket address structure containing the protocol address (such as IP address and port number) of the destination. The size of this socket address structure is specified by the addrlen argument. The recvform function fills the socket address structure pointed to by the from argument with the protocol address of the datagram's sender. The number of bytes stored in the socket address structure is also returned to the calling process as the integer pointed to by the addrlen argument. Note that the last argument to sendto is an integer value, while the last argument to recvfrom is a pointer to an integer value (a value-result argument).

The last two arguments to the recvfrom function are the same as the last two arguments to the accept function: the contents of the socket address structure upon completion tell us who sent the datagram (in the case of UDP) or who initiated the connection (in the case of TCP). The last two arguments to the sendto function are similar to the last two arguments to the connect function: we fill the socket address structure with the protocol address of the datagram recipient (in the case of UDP) or the address of the host with which the connection will be established (in the case of TCP).

Both functions return as the function value the length of the data that was read or written. In a typical use of the recvfrom function with a datagram protocol, the return value is the amount of user data in the received datagram.

The datagram can have zero length. For UDP, this returns an IP datagram containing an IP header (typically 20 bytes for IPv4 or 40 bytes for IPv6), an 8-byte UDP header, and no data. This also means that a null return from recvfrom is acceptable for the datagram protocol: it does not indicate that the other party has closed the connection, as does a null return from read on a TCP socket. Since the UDP protocol is not connection-oriented, there is no such event as connection closure.

If the from argument to recvfrom is a null pointer, then the corresponding length argument (addrlen) must also be a null pointer, meaning that we are not interested in the address of the sender of the data.

Both the recvfrom and sendto functions can be used with TCP, although they are usually not necessary.

8.3. UDP echo server: main function

We will now rework our simple client-server model from Chapter 5 using UDP. A diagram of function calls in our UDP client and server programs is shown in Fig. 8.1. In Fig. 8.2 shows the functions used. Listing 8.1 shows the main server function.

Rice. 8.2. Simple model client-server using UDP

Listing 8.1. UDP echo server

//udpcliserv/udpserv01.с

1 #include "unp.h"

3 intmain(int argc, char **argv)

6 struct sockaddr_in servaddr, cliaddr;

7 sockfd = Socket(AF_INET, SOCK_DGRAM, 0);

8 bzero(&servaddr, sizeof(servaddr));

9 servaddr.sin_family = AF_INET;

10 servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

12 Bind(sockfd, (SA*)&servaddr, sizeof(servaddr));

13 dg_echo(sodkfd, (SA*)&cliaddr, sizeof(cliaddr));

Create a UDP socket, bind to a known port using the bind function

7-12 We create a UDP socket by specifying SOCK_DGRAM (an IPv4 datagram socket) as the second argument of the socket function. As in the TCP server example, the IPv4 address for the bind function is specified as INADDR_ANY , and the server's known port number is the SERV_PORT constant from the unp.h header.

13 The dg_echo function is then called to process the client request by the server.

8.4. UDP echo server: dg_echo function

Listing 8.2 shows the dg_echo function.

Listing 8.2. dg_echo function: echoing strings on a datagram socket

1 #include "unp.h"

3 dg_echo(int sockfd, SA *pcliaddr, socklen_t clilen)

6 socklen_t len;

7 char mesg;

10 n = Recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);

11 Sendto(sockfd, mesg, n, 0, pcliaddr, len);

Reading datagram, reflecting to sender

8-12 This function is a simple loop in which the next datagram arriving at the server port is read by the recvfrom function and sent back using the sendto function.

Despite the simplicity of this function, there are a number of important details to consider. Firstly, this function never completes. Because UDP is a connectionless protocol, there is no equivalent of the end-of-file flag used in TCP.

Secondly, this function allows you to create a serial server, rather than a parallel one, which we received in the case of TCP. Since there is no fork function call, one server process handles all client processing. In general, most TCP servers are parallel, and most UDP servers are serial.

For a socket at the UDP level, datagrams are implicitly buffered in the form of a queue. Indeed, every UDP socket has a receive buffer, and every datagram arriving on that socket is placed in its receive buffer. When a process calls the recvfrom function, the next datagram from the buffer is returned to the process in FIFO (First In, First Out) order. Thus, if many datagrams arrive on a socket before the process can read the data already queued for the socket, then the incoming datagrams are simply added to the socket's receive buffer. But this buffer has a limited size. We discussed this size and how to increase it using the SO_RCVBUF socket option in Section 7.5.

In Fig. Figure 8.3 shows a generalization of our TCP client-server model from Chapter 5, where two clients establish connections to a server.

Rice. 8.3. Generalization of the TCP client-server model with two clients

There are two attached sockets here, and each of the attached sockets on the server node has its own receive buffer. In Fig. Figure 8.4 shows a case where two clients are sending datagrams to a UDP server.

Rice. 8.4. Generalization of the UDP client-server model with two clients

There is only one server process, and it has one socket on which the server receives all incoming datagrams and from which it sends all responses. This socket has a receive buffer into which all incoming datagrams are placed.

The main function in Listing 8.1 is protocol-dependent (it creates an AF_INET family socket and then allocates and initializes an IPv4 socket address structure), but the dg_echo function is protocol-independent. The reason the dg_echo function is protocol independent is that the calling process (in our case the main function) must allocate a socket address structure of the correct size in memory, and a pointer to this structure along with its size is passed as arguments to the dg_echo function . The dg_echo function never digs into this structure: it simply passes a pointer to it to the recvfrom and sendto functions. The recvfrom function fills this structure with the client's IP address and port number, and since the same pointer (pcliaddr) is then passed to the sendto function as the destination address, the datagram is thus reflected back to the client that sent the datagram.

8.5. UDP echo client: main function

The UDP client's main function is shown in Listing 8.3.

Listing 8.3. UDP echo client

//udpcliserv/udpcli01.c

1 #include "unp.h"

3 main(int argc, char **argv)

6 struct sockaddr_in servaddr;

7 if (argc != 2)

8 err_quit("usage: udpcli ");

9 bzero(&servaddr, sizeof(servaddr));

10 servaddr.sin_family = AF_INET;

11 servaddr.sin_port = htons(SERV_PORT);

12 Inet_pton(AF_INET, argv, &servaddr.sin_addr);

13 sockfd = Socket(AF_INET, SOCK_DGRAM, 0);

14 dg_cli(stdin, sockfd, (SA*)&servaddr, sizeof(servaddr));

Filling the socket address structure with the server address

9-12 The IPv4 socket address structure is filled with the IP address and port number of the server. This structure will be passed to the dg_cli function. It determines where to send datagrams.

13-14 A UDP socket is created and the dg_cli function is called.

8.6. UDP echo client: dg_cli function

Listing 8.4 shows the dg_cli function, which does most of the work on the client side.

Listing 8.4. Function dg_cli: client loop

1 #include "unp.h"

7 while (Fgets(sendline, MAXLINE, fp) != NULL) (

8 Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

9 n = Recvfrom(sockfd, recvline, MAXLINE, 0, NULL, NULL);

10 recvline[n] = 0; /* null terminating */

11 Fputs(recvline, stdout);

7-12 There are four steps in the client-side processing loop: reading a string from standard input using fgets, sending the string to the server using sendto, reading the server's reflected response using recvfrom, and putting the reflected string to standard output using fputs functions.

Our client did not ask the kernel to assign a dynamically assigned port to its socket (whereas the TCP client did when calling connect). For a UDP socket, the first time sendto is called, the kernel selects a dynamically assigned port if no local port has already been associated with that socket. As with TCP, a client can call bind explicitly, but this is rarely done.

Note that when calling the recvfrom function, null pointers are specified as the fifth and sixth arguments. This tells the kernel that we are not interested in knowing who sent the response. There is a risk that any process, whether on the same node or on any other, can send a datagram to the client's IP address and port, which will be read by the client, assuming that it is a response from the server. We will consider this situation in section 8.8.

As with the dg_echo server function, the dg_cli client function is protocol independent, but the client main function is protocol dependent. The main function allocates and initializes a socket address structure of a particular protocol type, and then passes the dg_cli function a pointer to the structure along with its size.

8.7. Lost Datagrams

The UDP client and server in our example are unreliable. If the client's datagram is lost (let's say it is ignored by some router between the client and the server), the client will forever be blocked in its call to the recvfrom function inside the dg_cli function, waiting for a response from the server that will never come. Likewise, if a client datagram arrives at the server but the server's response is lost, the client will be permanently blocked in its call to the recvfrom function. The only way to prevent this situation is to put a timeout in the client's recvfrom function call. We'll look at this in section 14.2.

Simply putting a timeout in the recvfrom function call is not a complete solution. For example, if the specified timeout expires and no response is received, we cannot say for sure what is wrong - either our datagram did not reach the server, or the server's response did not come back. If the client's request contained a request like "transfer a certain amount of money from account A to account B" (as opposed to the case with our simple echo server), then there would be a big difference between losing the request and losing the response. We'll talk more about adding reliability to the UDP client-server model in Section 22.5.

8.8. Checking the received response

At the end of section 8.6, we mentioned that any process that knows the client's dynamically assigned port number can send datagrams to our client, and they will be mixed in with the server's normal responses. All we can do is modify the recvfrom function call in Listing 8.4 to return the IP address and port of the sender of the response, and ignore any datagrams that come from a server other than the one to which we are sending the datagram. However, there are several pitfalls here, as we will see.

First, we modify the main client function (see Listing 8.3) to work with the standard echo server (see Table 2.1). We simply replace the assignment

servaddr.sin_port = htons(SERV_PORT);

assignment

servaddr.sin_port = htons(7);

Now we can use any node running a standard echo server with our client.

We then rewrite the dg_cli function to allocate a different socket address structure in memory to hold the structure returned by recvfrom . We show it in Listing 8.5.

Listing 8.5. A version of the dg_cli function that checks the returned socket address

//udpcliserv/dgcliaddr.c

1 #include "unp.h"

3 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

6 char sendline, recvline;

7 socklen_t len;

8 struct sockaddr *preply_addr;

9 preply_addr = Malloc(servlen);

10 while (Fgets(sendline, MAXLINE, fp) != NULL) (

11 Sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

12 len = servlen;

13 n = Recvfrom(sockfd, recvline, MAXLINE, 0, preply_addr, &len);

14 if (len != servlen || memcmp(pservaddr, preply_addr, len) != 0) (

15 printf("reply from %s (ignored)\n",

18 recvline[n] = 0; /* null terminating */

19 Fputs(recvline, stdout);

Placing a different socket address structure in memory

9 We allocate another socket address structure in memory using malloc functions. Note that the dg_cli function is still protocol independent. Since we don't care what type of socket address structure we're dealing with, we only use its size in the malloc function call.

Comparison of returned addresses

12-13 In the recvfrom function call, we tell the kernel to return the source address of the datagram. We first compare the length returned by the recvfrom function as a value-result argument, and then compare the socket address structures themselves using the memcmp function.

The new version of our client works great if the server is on a host with a single IP address. But this program may not work if the server has several network interfaces (multihomed server). We run this program by accessing the freebsd4 node, which has two interfaces and two IP addresses:

macosx% host freebsd4

freebsd4.unpbook.com has address 172.24.37.94

freebsd4.unpbook.com has address 135.197.17.100

macosx% udpcli02 135.197.17.100

reply from 172.24.37.94:7 (ignored)

According to Fig. 1.7 you can see that we set an IP address from a different subnet. This is usually acceptable. Most IP implementations accept an incoming IP datagram destined for any of the host's IP addresses, regardless of the interface on which it arrives. RFC 1122 calls this the weak end system model. If a system were to implement what this document calls a strong end system model, it accepts an incoming datagram only if the datagram arrives on the interface to which it is destined.

The IP address returned by the recvfrom function (the source IP address of the UDP datagram) is not the IP address to which we sent the datagram. When the server sends its response, the recipient's IP address is 172.24.37.94. The kernel routing function on node freebsd4 selects 172.24.37.94 as the outgoing interface. Since the server has not associated an IP address with its socket (the server has associated a generic address with its socket, which we can verify by running the netstat program on the freebsd4 node), the kernel selects the source address of the IP datagram. This address becomes the primary IP address of the outgoing interface. If we send the datagram to something other than the primary IP address of the interface (that is, to an alternate name, an alias), then our test shown in Listing 8.5 will also fail.

One solution would be for the client to check the domain name of the responding host instead of its IP address. To do this, the server name is looked up in DNS (see Chapter 11) based on the IP address returned by the recvfrom function. Another solution is to have the UDP server create one socket for each IP address configured on the host, bind that IP address to the socket, call select on each of all those sockets (waiting for some either of them will become ready for reading) and then responded from the socket ready for reading. Since the socket used for the response is associated with the IP address that was the destination address of the client request (otherwise the datagram would not have been delivered to the socket), we can be sure that the sender of the response and the recipient of the request address are the same. We show these examples in Section 22.6.

NOTE

On a Solaris system with multiple network interfaces, the source IP address of the server response is the recipient IP address of the client request. The scenario described in this section applies to Berkeley-derived implementations that select a source IP address based on the outgoing interface.

8.9. Starting the client without starting the server

The next scenario we'll look at is starting the client without starting the server. If we do this and enter one line on the client side, nothing will happen. The client is forever blocked in its recvfrom function call, waiting for a server response that never comes. But that doesn't matter in this example because we're now looking to gain a deeper understanding of the protocols and what's going on with our network application.

We first run tcpdump on the macosx host, and then run the client on the same host, setting the server host to freebsd4. Then we enter one line, but this line is not reflected by the server.

macosx% udpcli01 172.24.37.94

hello, world we enter this line,

but we get nothing in response

Listing 8.6 shows the output of tcpdump.

Listing 8.6. tcpdump output when the server process is not running on the server node

01 0.0 arp who-has freebsd4 tell macosx

02 0.003576 (0.0036) arp reply freebsd4 is-at 0:40:5:42:d6:de

03 0.003601 (0.0000) macosx.51139 > freebsd4.9877: udp 13

04 0.009781 (0.0062) freebsd4 >

The first thing we notice is that the ARP request and response are received before the client host can send a UDP datagram to the server host. (We left this exchange in the program output to re-emphasize that an ARP request is always sent and a response is received before an IP datagram is sent.)

On line 3 we see that the client datagram is sent, but the server host responds on line 4 with an ICMP port unreachable message. (A length of 13 includes 12 characters plus a newline.) However, this ICMP error is not returned to the client process for reasons we'll briefly list below. Instead, the client is permanently blocked in the recvfrom function call in Listing 8.4. We also note that ICMPv6 has a "Port Unreachable" error similar to ICMPv4 (see Tables A.5 and A.6), so the results presented here are similar to those for IPv6.

This ICMP error is an asynchronous error. The error was caused by the sendto function, but the sendto function completed normally. Recall from Section 2.9 that a normal return from a UDP output operation means only that the datagram has been added to the link-layer output queue. The ICMP error is not returned until a certain amount of time has passed (4 ms for Listing 8.6), which is why it is called asynchronous.

The basic rule is that asynchronous errors are not returned for a UDP socket unless the socket has been attached. We show how to call the connect function on a UDP socket in Section 8.11. Not everyone understands why this decision was made when sockets were first implemented. (Implementation considerations are discussed on pages 748-749.) Consider a UDP client sequentially sending three datagrams to three different servers (that is, three different IP addresses) over a single UDP socket. The client enters a loop that calls the recvfrom function to read the responses. Two datagrams are delivered correctly (that is, the server was running on two of the three nodes), but the third node was not running the server, and the third node responds with an ICMP port unreachable message. This ICMP error message contains the IP header and UDP header of the datagram that caused the error. (ICMPv4 and ICMPv6 error messages always contain an IP header and all or part of a UDP header to allow the message recipient to determine which socket caused the error. This is shown in Figures 28.5 and 28.6.) A client that sent three datagrams should know the recipient of the datagram that caused the error to determine exactly which of the three datagrams caused the error. But how can the kernel communicate this information to the process? The only thing recvfrom can return is the value of the errno variable. But the recvfrom function cannot return the IP address and port number of the recipient of the UDP datagram in error. Consequently, it has been decided that these asynchronous errors are returned to a process only if the process has attached a UDP socket to only one specific peer.

NOTE

Linux returns most ICMP port unreachable errors, even for an unattached socket, unless the SO_DSBCOMPAT socket option is enabled. All recipient unreachable errors shown in Table 1 are returned. A.5, with the exception of errors with codes 0, 1, 4, 5, 11 and 12.

We'll return to the issue of asynchronous errors with UDP sockets in Section 28.7 and show a simple way to get these errors on an unattached socket using our own daemon.

8.10. Final example of a UDP client-server

In Fig. In Figure 8.5, the large black dots show the four values ​​that must be set or selected when a client sends a UDP datagram.

Rice. 8.5. Summarizing the UDP client-server model from the client's point of view

The client must specify the server's IP address and port number to call the sendto function. Typically the client's IP address and port number are automatically chosen by the kernel, although we noted that the client can call the bind function. We also noted that if these two values ​​are chosen for a client by the kernel, then the client's dynamically assigned port is chosen once, the first time sendto is called, and is never changed again. However, the client's IP address may change for each UDP datagram the client sends, assuming the client does not bind a specific IP address to the socket using the bind function. The reason is explained in Fig. 8.5: If the client node has several network interfaces, the client can switch between them (in Fig. 8.5, one address refers to the link layer shown on the left, the other refers to the one shown on the right). In the worst case of this scenario, the client IP address, chosen by the kernel based on the outgoing link layer, would change for each datagram.

What happens if a client binds an IP address to its socket, but the kernel decides that the outgoing datagram should be sent from some other link layer? In this case, the IP datagram will contain a source IP address that is different from the outgoing link layer IP address (see Exercise 8.6).

In Fig. Figure 8.6 shows the same four values, but from the server's point of view.

Rice. 8.6. Summarizing the UDP client-server model from the server's point of view

The server can find out by at least four parameters for each datagram received: source IP address, destination IP address, source port number, and destination port number. The calls that return this information to TCP and UDP servers are shown in Table. 8.1.

Table 8.1. Information, available to the server from an incoming IP datagram

The TCP server always has easy access to all four pieces of information for a connected socket, and these four values ​​remain constant for the lifetime of the connection. However, in the case of a UDP connection, the destination IP address can only be obtained by setting the socket option IP_RECVDSTADDR for IPv4 or IPV6_PKTINFO for IPv6 and then calling the recvmsg function instead of the recvfrom function. Because UDP is connectionless, the destination IP address can change for each datagram sent to the server. A UDP server can also receive datagrams destined for one of the host's broadcast addresses or a multicast address, which we discuss in Chapters 20 and 21. We'll show how to determine the destination address of a UDP datagram in Section 20.2 after we describe the recvmsg function.

8.11. connect function for UDP

NOTE

NOTE

NOTE

Table 8.2

NOTE

Rice. 8.7. UDP attached socket

Rice. 8.8

Calling connect multiple times on a UDP socket

A process with a connected UDP socket can again call the connect function on that socket to:

c – set a new IP address and port;

c – disconnect the socket.

The first case, specifying a new peer for a connected UDP socket, differs from using the connect function with a TCP socket: for a TCP socket, the connect function can only be called once.

To disconnect a UDP socket, we call the connect function, but set the family element of the socket address structure (sin_family for IPv4 or sin6_family for IPv6) to AF_UNSPEC . This may result in an EAFNOSUPPORT error, but this is normal. It is the process of calling the connect function on an already connected UDP socket that allows the socket to be disconnected.

NOTE

The BSD manual for the connect function traditionally stated: "Datagram sockets can break connections by connecting to invalid addresses, such as empty addresses." Unfortunately, neither manual says what constitutes an "empty address", nor does it mention that an error is returned as a result (which is normal). The POSIX standard explicitly states that the address family must be set to AF_UNSPEC, but then states that this call to connect may or may not return an EAFNOSUPPORT error.

Performance

When an application calls the sendto function on an unattached UDP socket, Berkeley-derived kernel implementations temporarily connect to the socket, send a datagram, and then disconnect from the socket. Thus, calling the sendto function to send two datagrams sequentially on an unattached socket involves the following six steps performed by the kernel:

c – attaching a socket;

c – output of the first datagram;

c – disconnecting the socket;

c – attaching a socket;

c – output of the second datagram;

c – disconnecting the socket.

NOTE

Another point to consider is the number of lookups in the routing table. The first temporary connection looks up the destination IP address in the routing table and stores (caches) this information. The second temporary connection notes that the recipient address matches the cached address from the routing table (we assume that both sendto functions are given the same recipient) and does not need to look up the routing table again.

When an application knows that it will send multiple datagrams to the same peer, it is more efficient to explicitly attach the socket. A call to connect followed by two calls to write will now involve the following steps performed by the kernel:

c – attaching a socket;

c – output of the first datagram;

c – output of the second datagram.

In this case, the kernel copies the socket address structure containing the destination IP address and port only once, and when sendingto is called twice, the copying is done twice. B notes that temporarily reattaching a disconnected UDP socket accounts for approximately one-third of the cost of each UDP transfer.

8.12. dg_cli function (continued)

Let's go back to the dg_cli function shown in Listing 8.4 and rewrite it to call the connect function. Listing 8.7 shows new feature.

Listing 8.7. The dg_cli function calling the connect function

//udpcliserv/dgcliconnect.c

1 #include "unp.h"

3 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

6 char sendline, recvline;

7 Connect(sockfd, (SA*)pservaddr, servlen);

8 while (Fgets(sendline, MAXLINE, fp) != NULL) (

9 Write(sockfd, sendline, strlen(sendline));

10 n = Read(sockfd, recvline, MAXLINE);

11 recvline[n] = 0; /* null terminating */

12 Fputs(recvline, stdout);

Changes compared to previous version- this is adding a call to the connect function and replacing calls to the sendto and recvfrom functions with calls to the write and read functions. The dg_cli function remains protocol independent because it does not delve into the socket address structure passed to the connect function. Our client's main function, shown in Listing 8.3, remains the same.

If we run the program on a macosx host, specifying the IP address of the freebsd4 host (which does not run our server on port 9877), we get the following output:

macosx% udpcli04 172.24.37.94

hello, world

read error: Connection refused

The first thing we notice is that we don't get an error when we start the client process. The error occurs only after we send the first datagram to the server. It is the sending of this datagram that causes an ICMP error from the server host. But when a TCP client calls connect , specifying a server node that is not running a server process, connect returns an error because the call to connect causes the first packet of the three-way to be sent TCP handshakes, and it is this packet that causes the RST segment to be received from the peer (see section 4.3).

Listing 8.8 shows the output of tcpdump.

Listing 8.8. Output from tcpdump when running dg_cli function

macosx% tcpdump

01 0.0 macosx.51139 > freebsd4 9877:udp 13

02 0.006180 (0.0062) freebsd4 > macosx: icmp: freebsd4 udp port 9877 unreachable

In table A.5 we also see that the kernel associates an ICMP error with an ECONNREFUSED error, which corresponds to the output of the Connection refused message string by the err_sys function.

NOTE

Unfortunately, not all kernels return ICMP messages to the attached UDP socket, as we showed in this section. Typically, Berkeley-derived kernels return this error, but System V kernels do not. For example, if we run the same client on a Solaris 2.4 host and use the connect function to connect to a host that is not running our server, then using tcpdump we can verify that the ICMP port unreachable error is returned by the server host, but caused by the client read function never completes. This situation has been corrected in Solaris 2.5. UnixWare does not return an error, while AIX, Digital Unix, HP-UX and Linux do.

8.13. Lack of flow control in UDP

Listing 8.9

//udpcliserv/dgcliloop1.c

1 #include "unp.h"

8char sendline;

Listing 8.10

//udpcliserv/dgecholoop1.c

1 #include "unp.h"

3 static int count;

7 socklen_t len;

8 char mesg;

11 len = clilen;

17 recvfrom_int(int signo)

Listing 8.11. Output on the server node

freebsd % netstat -s -p udp

71208 datagrams received

0 with incomplete header

0 with bad data length field

0 with bad checksum

0 with no checksum

832 dropped due to no socket

0 not for hashed pcb

137685 datagrams output

freebsd % udpserv06 launch our server

client sends datagrams

^C

freebsd % netstat -s -p udp

73208 datagrams received

0 with incomplete header

0 with bad data length field

0 with bad checksum

0 with no checksum

832 dropped due to no socket

16 broadcast/multicast datagrams dropped due to no socket

0 not for hashed pcb

137685 datagrams output

aix % udpserv06

^?

received 2000 datagrams

UDP socket receive buffer

The number of UDP datagrams queued for a given socket is limited by the size of its receive buffer. We can change this using the SO_RCVBUF socket option, as we showed in section 7.5. On FreeBSD, the default UDP socket receive buffer size is 42,080 bytes, which allows only 30 of our 1400-byte datagrams to be stored. If we increase the size of the socket receive buffer, we can expect the server to receive additional datagrams. Listing 8.12 is a modified dg_echo function from Listing 8.10 that increases the size of the socket receive buffer to 240 KB. If we run this server on a Sun system and the client on an RS/6000 system, the received datagram count will be 103. Since this is only slightly better than the previous example with the default buffer size, it is clear that we are still didn't get a solution to the problem.

Listing 8.12. dg_echo function, which increases the size of the socket receive buffer

//udpcliserv/dgecholooor2.c

1 #include "unp.h"

2 static void recvfrom_int(int);

3 static int count;

5 dg_echo(int sockfd, SA *pcliaddr, socklen_t clilen)

8 socklen_t len;

9 char mesg;

10 Signal(SIGINT, recvfrom_int);

11 n = 240 * 1024;

12 Setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &n, sizeof(n));

14 len = clilen;

15 Recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);

20 recvfrom_int(int signo)

22 printf("\nreceived %d datagrams\n", count);

NOTE

Why do we set the socket receive buffer size to 240G-1024 bytes in Listing 8.12? The default maximum socket receive buffer size in BSD/OS 2.1 is 262,144 bytes (256G-1024), but due to the way the buffer is allocated in memory (described in Chapter 2), it is actually limited to 246,723 bytes. Many earlier 4.3BSD-based systems limited the socket receive buffer size to approximately 52,000 bytes.

8.14. Defining the outgoing interface for UDP

You can also use the attached UDP socket to specify the outgoing interface that will be used to send datagrams to a specific recipient. This is due to a side effect of the connect function applied to a UDP socket: the kernel selects the local IP address (assuming the process has not yet called bind to set it explicitly). The local address is selected by looking up the destination address in the routing table, taking the primary IP address of the interface from which, according to the table, datagrams will be sent.

Listing 8.13 shows simple program UDP, which connects to the given IP address using the connect function and then calls the getsockname function, outputting the local IP address and port.

Listing 8.13. UDP program using connect function to determine outgoing interface

//udpcliserv/udpcli09.c

1 #include "unp.h"

3 main(int argc, char **argv)

6 socklen_t len;

7 struct sockaddr_in cliaddr, servaddr;

8 if (argc != 2)

9 err_quit("usage: udpcli ");

10 sockfd = Socket(AF_INET, SOCK_DGRAM, 0);

11 bzero(&servaddr, sizeof(servaddr));

12 servaddr.sin_family = AF_INET;

13 servaddr.sin_port = htons(SERV_PORT);

14 Inet_pton(AF_INET, argv, &servaddr.sin_addr);

15 Connect(sockfd, (SA*)&servaddr, sizeof(servaddr));

16 len = sizeof(cliaddr);

17 Getsockname(sockfd, (SA*)&cliaddr, &len);

18 printf("local address %s\n", Sock_ntop((SA*)&cliaddr, len));

If we run the program on a freebsd host with multiple network interfaces, we will get the following output:

freebsd % udpcli09 206.168.112.96

local address 12.106.32.254:52329

freebsd % udpcli09 192.168.42.2

local address 192.168.42.1:52330

freebsd % udpcli09 127.0.0.1

local address 127.0.0.1:52331

According to Fig. 1.7 we can see that when we run the program the first two times, the command line argument is the IP address in different networks Ethernet. The kernel assigns a local IP address to the primary interface address in the appropriate Ethernet networks. When calling connect on a UDP socket, nothing is sent to that host - it is a completely local operation that preserves the peer's IP address and port. We also see that calling connect on an unconnected UDP socket also assigns a dynamically assigned port to the socket.

NOTE

Unfortunately, this technology does not work in all implementations, which is especially true for kernels derived from SVR4. For example, this does not work on Solaris 2.5, but works on AIX, Digital Unix, Linux, MacOS X and Solaris 2.6.

8.15. TCP and UDP echo server using select function

We will now combine our parallel TCP echo server from Chapter 5 and our serial UDP echo server from this chapter into one server that uses the select function to multiplex TCP and UDP sockets. Listing 8.14 shows the first part of this server.

Listing 8.14. The first part of the echo server processing TCP and UDP sockets using the select function

//udpcliserv/udpservselect01.c

1 #include "unp.h"

3 main(int argc, char **argv)

5 int listenfd, connfd, udpfd, nready, maxfdp1;

6 char mesg;

7 pid_t childpid;

10 socklen_t len;

11 const int on = 1;

12 struct sockaddr_in cliaddr, servaddr;

13 void sig_chld(int);

14 /* create a TCP listening socket */

15 listenfd = Socket(AF_INET, SOCK_STREAM, 0);

16 bzero(&servaddr, sizeof(servaddr));

17 servaddr.sin_family = AF_INET;

18 servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

19 servaddr.sin_port = htons(SERV_PORT);

20 Setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

21 Bind(listenfd, (SA*)&servaddr, sizeof(servaddr));

22 Listen(listenfd, LISTENQ);

23 /* create a UDP socket */

24 udpfd = Socket(AF_INET, SOCK_DGRAM, 0);

25 bzero(&servaddr, sizeof(servaddr));

26 servaddr.sin_family = AF_INET;

27 servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

28 servaddr.sin_port = htons(SERV_PORT);

29 Bind(udpfd, (SA*)&servaddr, sizeof(servaddr));

Creating a TCP Listening Socket

14-22 A TCP listening socket is created and associated with a previously known port on the server. We set the socket option SO_REUSEADDR in case there are connections on this port.

Creating a UDP socket

23-29 A UDP socket is also created and associated with the same port. Even if the same port is used for TCP and UDP sockets, there is no need to set the SO_REUSEADDR socket option before this call to bind because TCP ports do not depend on UDP ports.

Listing 8.15 shows the second part of our server.

Listing 8.15. The second half of the echo server processing TCP and UDP using the select function

udpcliserv/udpservselect01.c

30 Signal(SIGCHLD, sig_chld); /* need to call waitpid() */

31 FD_ZERO(&rset);

32 maxfdp1 = max(listenfd, udpfd) + 1;

34 FD_SET(listenfd, &rset);

35 FD_SET(udpfd, &rset);

36 if ((nready = select(maxfdp1, &rset, NULL, NULL, NULL))

37 if (errno == EINTR)

38 continue; /* back to for() */

40 err_sys("select error");

42 if (FD_ISSET(listenfd, &rset)) (

43 len = sizeof(cliaddr);

44 connfd = Accept(listenfd, (SA*)&cliaddr, &len);

45 if ((childpid = Fork()) == 0) ( /* child process */

46 Close(listenfd); /* closes the listening socket */

47 str_echo(connfd); /* Processing request */

50 Close(connfd); /* parent closes the attached socket */

52 if (FD_ISSET(udpfd, &rset)) (

53 len = sizeof(cliaddr);

54 n = Recvfrom(udpfd, mesg, MAXLINE, 0, (SA*)&cliaddr, &len);

55 Sendto(udpfd, mesg, n, 0, (SA*)&cliaddr, len);

Installing the SIGCHLD signal handler

30 A handler is installed for the SIGCHLD signal because TCP connections will be handled by the child process. We showed this signal handler in Listing 5.8.

Preparing to Call the Select Function

31-32 We initialize a set of descriptors for the select function and calculate the maximum of the two descriptors, which we will wait for when ready.

Calling the select function

34-41 We call the select function, waiting only for the TCP socket or UDP socket we are listening on to be ready to read. Since our sig_chld signal handler may abort the select function call, we handle the EINTR error.

Handling a new client connection

42-51 Using the accept function we accept new things client connection, and when the listening TCP socket is ready for reading, we use the fork function to spawn a child process and call our str_echo function in the child process. This is the same sequence of steps we followed in Chapter 5.

Processing an incoming datagram

52-57 If the UDP socket is ready for reading, the datagram has arrived. We read it using the recvfrom function and send it back to the client using the sendto function.

8.16. Summary

Converting our echo client and echo server to use UDP instead of TCP was easy. But at the same time we lost many opportunities provided TCP protocol: detecting lost packets and retransmitting, checking whether packets come from the correct interlocutor, etc. We'll return to this topic in Section 22.5 and see how we can improve the reliability of a UDP application.

UDP sockets can generate asynchronous errors, which are errors that are reported some time after the packet has been sent. TCP sockets always report them to the application, but with UDP the socket must be connected to receive these errors.

UDP lacks flow control, which is very easy to demonstrate. This is usually not a problem since many UDP applications are built using a request-response model and are not intended to transmit large quantity data.

There are a number of other things to consider when writing UDP applications, but we'll cover them in Chapter 22 after covering the functions of interfaces, broadcast, and multicast.

Exercises

1. Let's say we have two applications, one uses TCP and the other uses UDP. The receive buffer for a TCP socket contains 4096 bytes of data, and the receive buffer for a UDP socket contains two datagrams of 2048 bytes. A TCP application calls the read function with a third argument of 4096, and a UDP application calls the recvfrom function with a third argument of 4096. Is there any difference between these calls?

2. In Listing 8.2, what happens if we replace the last argument of the sendto function (which we labeled len) with the argument clilen?

3. Compile and run the UDP server from Listings 8.1 and 8.4, and then the client from Listings 8.3 and 8.4. Make sure the client and server are working together.

4. Run the ping program in one window, specifying the -i option 60 (send one packet every 60 seconds; some systems use the I switch instead of i), the -v option (print all received ICMP error messages), and set the loopback address to itself ( usually 127.0.0.1). We will use this program to see the ICMP port unreachable error returned by the server host. Then run our client from the previous exercise in another window, specifying the IP address of some node that is not running the server. What's happening?

5. Looking at Fig. 8.3, we said that each connected TCP socket has its own receive buffer. Do you think the listening socket has its own receive buffer?

6. Use the sock program (see Section B.3) and a tool such as tcpdump (see Section B.5) to verify the statement in Section 8.10: if the client uses the bind function to bind an IP address to its socket, but sends a datagram originating on a different interface, then the resulting datagram contains the IP address that was associated with the socket, even if it does not match the originating interface.

7. Compile the programs from Section 8.13 and run the client and server on different nodes. Place a printf on the client every time a datagram is written to the socket. Does this change the percentage of packets received? Why? Call printf from the server every time a datagram is read from the socket. Does this change the percentage of packets received? Why?

8. What is the largest length we can pass to the sendto function for a UDP/IPv4 socket, that is, what is the largest amount of data that can fit in a UDP/IPv4 datagram? What changes in the case of UDP/IPv6?

Modify Listing 8.4 to send a single UDP datagram maximum size, read it back and print the number of bytes returned by the recvfrom function.

9. Modify Listing 8.15 to conform to RFC 1122: IP_RECVDSTADDR should be used for a UDP socket.

At the end of Section 8.9, we mentioned that asynchronous errors are not returned on a UDP socket if the socket has not been attached. We can actually call the connect function on a UDP socket (see section 4.3). But this will not result in anything like a TCP connection: there is no three-way handshake. The kernel simply checks to see if the destination is known to be unreachable, then records the peer's IP address and port number, which are contained in the socket address structure passed to the connect function, and immediately returns control to the calling process.

NOTE

Overloading the connect function with this new opportunity for UDP sockets it can be confusing. If the convention is used that sockname is the local protocol address and peername is the address remote protocol, then it would be better if this function was called setpeername. Likewise, the bind function would be better called setsockname.

With this in mind, it is necessary to understand the difference between the two types of UDP sockets.

c– An unconnected UDP socket is the default UDP socket created.

c– A connected UDP socket is the result of calling the connect function on a UDP socket.

A connected UDP socket has three differences from an unattached socket, which is created by default.

1. We can no longer set the destination IP address and port for the output operation. That is, we use the write or send function instead of the sendto function. Anything written to the connected UDP socket is automatically sent to the address (such as IP address and port) specified by the connect function.

NOTE

Similar to TCP, we can call the sendto function on an attached UDP socket, but we cannot specify the destination address. The fifth argument to the sendto function (a pointer to the socket address structure) must be a null pointer, and the sixth argument (the size of the socket address structure) must be null. The POSIX standard specifies that when the fifth argument is a null pointer, the sixth argument is ignored.

2. Instead of the recvfrom function, we use the read or recv function. The only datagrams returned by the kernel for an input operation on a connected UDP socket are datagrams coming from the address specified in the connect function. Datagrams destined for the local protocol address of a connected UDP socket (such as an IP address and port) but coming from a protocol address other than the one to which the socket was connected using the connect function are not sent to the connected socket. This restricts the attached UDP socket to allow it to exchange datagrams with one and only one peer.

NOTE

More precisely, datagrams are exchanged with only one IP address, and not with one interlocutor, since it can be a multicast IP address, thus representing a group of interlocutors.

3. Asynchronous errors are returned to the process only for operations on the attached UDP socket. As a result, as we already said, an unattached UDP socket does not receive any asynchronous errors.

In table 8.2 brings together the properties listed in the first paragraph as applied to 4.4BSD.

Table 8.2. TCP and UDP sockets: can the destination protocol address be specified

NOTE

POSIX specifies that a pin operation that does not specify a destination address on an unattached UDP socket must return an ENOTCONN error rather than an EDESTADDRREQ error.

Solaris 2.5 allows the sendto function, which specifies the destination address for an attached UDP socket. POSIX specifies that an EISCONN error should be returned in this situation.

In Fig. Section 8.7 summarizes information about the attached UDP socket.

Rice. 8.7. UDP attached socket

The application calls the connect function, specifying the IP address and port number of the interlocutor. It then uses the read and write functions to exchange data with the other party.

Datagrams coming from any other IP address or port (which we denote as "???" in Figure 8.7) are not sent to the attached socket because either the source IP address or UDP port does not match the protocol address. to which the socket is connected using the connect function. These datagrams may be delivered to some other UDP socket on the host. If there is no other matching socket for the incoming datagram, UDP will ignore it and generate an ICMP port unreachable message.

To summarize the above, we can state that a UDP client or server can call the connect function only if that process is using a UDP socket to communicate with only one interlocutor. Typically it is the UDP client that calls the connect function, but there are applications in which the UDP server communicates with a single client for an extended period of time (such as TFTP), in which case both the client and the server call the connect function.

Another example of long-term interaction is DNS (Figure 8.8).

Rice. 8.8. Example of DNS clients and servers and the connect function

A DNS client can be configured to use one or more servers, typically by listing the servers' IP addresses in the /etc/resolv.conf file. If there is only one server listed in this file (that client is the leftmost rectangle in the figure), the client can call the connect function, but if many servers are listed (the second right rectangle in the figure), the client cannot call the connect function. Usually DNS server handles any client requests as well, hence servers cannot call the connect function.

Now we will check how the application is affected by the absence of any flow control in UDP. First we'll change our dg_cli function so that it sends a fixed number of datagrams. It will no longer read from standard input. Listing 8.9 shows a new version functions. This function sends 2000 UDP datagrams of 1400 bytes each to the server.

Listing 8.9. The dg_cli function sends a fixed number of datagrams to the server

//udpcliserv/dgcliloop1.c

1 #include "unp.h"

2 #define NDG 2000 /* number of datagrams to send */

3 #define DGLEN 1400 /* length of each datagram */

5 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

8char sendline;

10 Sendto(sockfd, sendline, DGLEN, 0, pservaddr, servlen);

We then modify the server to receive datagrams and count the number of datagrams received. The server no longer reflects datagrams back to the client. Listing 8.10 shows the new dg_echo function. When we terminate the server process by pressing the interrupt key on the terminal (which causes a SIGINT signal to be sent to the process), the server prints the number of datagrams received and exits.

Listing 8.10. The dg_echo function, which counts received datagrams

//udpcliserv/dgecholoop1.c

1 #include "unp.h"

2 static void recvfrom_int(int);

3 static int count;

5 dg_echo(int sockfd, SA *pcliaddr, socklen_t clilen)

7 socklen_t len;

8 char mesg;

9 Signal(SIGINT, recvfrom_int);

11 len = clilen;

12 Recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);

17 recvfrom_int(int signo)

19 printf("\nreceived %d datagrams\n", count);

Now we run the server on the freebsd node, which is slow computer SPARCStation. We run the client on a much faster RS/6000 system with the aix operating system. They are connected to each other directly Ethernet channel at 100 Mbit/s. In addition, we run netstat -s on the server node both before and after the client and server are started, since the statistics output will show how many datagrams we lost. Listing 8.11 shows the server output.

Listing 8.11. Output on the server node

freebsd % netstat -s -p udp

71208 datagrams received

0 with incomplete header

0 with bad data length field

0 with bad checksum

0 with no checksum

832 dropped due to no socket

16 broadcast/multicast datagrams dropped due to no socket

1971 dropped due to full socket buffers

0 not for hashed pcb

137685 datagrams output

freebsd % udpserv06 launch our server

client sends datagrams

^C To end the client's work, enter our interrupt symbol

freebsd % netstat -s -p udp

73208 datagrams received

0 with incomplete header

0 with bad data length field

0 with bad checksum

0 with no checksum

832 dropped due to no socket

16 broadcast/multicast datagrams dropped due to no socket

3941 dropped due to full socket buffers

0 not for hashed pcb

137685 datagrams output

The client sent 2000 datagrams, but the server application only received 30 of them, meaning a loss rate of 98%. Neither the server nor the client receives a message that these datagrams are lost. As we said, UDP does not have flow control capabilities - it is unreliable. As we have shown, it is easy for a UDP sender to overflow the receiver's buffer.

If we look at the netstat output, we see that the total number of datagrams received by the server node (not the server application) is 2000 (73,208 - 71,208). The dropped due to full socket buffers counter shows how many datagrams were received by UDP and ignored because the receiving socket's receive buffer was full. This value is 1970 (3941 - 1971), which when added to the output of the application's datagrams received count (30), gives a total of 2000 datagrams received by the node. Unfortunately, netstat's count of datagrams discarded due to a full buffer is system wide. There is no way to determine which applications (eg which UDP ports) are affected.

The number of datagrams received by the server in this example is non-deterministic. It depends on many factors, such as network load, client node and server node load.

If we run the same client and the same server, but this time the client is on a slow Sun system and the server is on a fast RS/6000 system, no datagrams are lost.

aix % udpserv06

^? after the client has finished working, enter our interrupt symbol

received 2000 datagrams

At the end of Section 8.9, we mentioned that asynchronous errors are not returned on a UDP socket if the socket has not been attached. We can actually call the connect function on a UDP socket (see section 4.3). But this will not result in anything like a TCP connection: there is no three-way handshake. The kernel simply checks to see if the destination is known to be unreachable, then records the peer's IP address and port number, which are contained in the socket address structure passed to the connect function, and immediately returns control to the calling process.

NOTE

Overloading the connect function with this new feature for UDP sockets can be confusing. If the convention is that sockname is the local protocol address and peername is the remote protocol address, then this function would be better called setpeername. Likewise, the bind function would be better called setsockname.

With this in mind, it is necessary to understand the difference between the two types of UDP sockets.

c– An unconnected UDP socket is the default UDP socket created.

c– A connected UDP socket is the result of calling the connect function on a UDP socket.

A connected UDP socket has three differences from an unattached socket, which is created by default.

1. We can no longer set the destination IP address and port for the output operation. That is, we use the write or send function instead of the sendto function. Anything written to the connected UDP socket is automatically sent to the address (such as IP address and port) specified by the connect function.

NOTE

Similar to TCP, we can call the sendto function on an attached UDP socket, but we cannot specify the destination address. The fifth argument to the sendto function (a pointer to the socket address structure) must be a null pointer, and the sixth argument (the size of the socket address structure) must be null. The POSIX standard specifies that when the fifth argument is a null pointer, the sixth argument is ignored.

2. Instead of the recvfrom function, we use the read or recv function. The only datagrams returned by the kernel for an input operation on a connected UDP socket are datagrams coming from the address specified in the connect function. Datagrams destined for the local protocol address of a connected UDP socket (such as an IP address and port) but coming from a protocol address other than the one to which the socket was connected using the connect function are not sent to the connected socket. This restricts the attached UDP socket to allow it to exchange datagrams with one and only one peer.

NOTE

More precisely, datagrams are exchanged with only one IP address, and not with one interlocutor, since it can be a multicast IP address, thus representing a group of interlocutors.

3. Asynchronous errors are returned to the process only for operations on the attached UDP socket. As a result, as we already said, an unattached UDP socket does not receive any asynchronous errors.

In table 8.2 brings together the properties listed in the first paragraph as applied to 4.4BSD.

Table 8.2. TCP and UDP sockets: can the destination protocol address be specified

NOTE

POSIX specifies that a pin operation that does not specify a destination address on an unattached UDP socket must return an ENOTCONN error rather than an EDESTADDRREQ error.

Solaris 2.5 allows the sendto function, which specifies the destination address for an attached UDP socket. POSIX specifies that an EISCONN error should be returned in this situation.

In Fig. Section 8.7 summarizes information about the attached UDP socket.

Rice. 8.7. UDP attached socket

The application calls the connect function, specifying the IP address and port number of the interlocutor. It then uses the read and write functions to exchange data with the other party.

Datagrams coming from any other IP address or port (which we denote as "???" in Figure 8.7) are not sent to the attached socket because either the source IP address or UDP port does not match the protocol address. to which the socket is connected using the connect function. These datagrams may be delivered to some other UDP socket on the host. If there is no other matching socket for the incoming datagram, UDP will ignore it and generate an ICMP port unreachable message.

To summarize the above, we can state that a UDP client or server can call the connect function only if that process is using a UDP socket to communicate with only one interlocutor. Typically it is the UDP client that calls the connect function, but there are applications in which the UDP server communicates with a single client for an extended period of time (such as TFTP), in which case both the client and the server call the connect function.

Another example of long-term interaction is DNS (Figure 8.8).

Rice. 8.8. Example of DNS clients and servers and the connect function

A DNS client can be configured to use one or more servers, typically by listing the servers' IP addresses in the /etc/resolv.conf file. If there is only one server listed in this file (that client is the leftmost rectangle in the figure), the client can call the connect function, but if many servers are listed (the second right rectangle in the figure), the client cannot call the connect function. Typically, the DNS server also handles any client requests, so servers cannot call the connect function.

Now we will check how the application is affected by the absence of any flow control in UDP. First we'll change our dg_cli function so that it sends a fixed number of datagrams. It will no longer read from standard input. Listing 8.9 shows the new version of the function. This function sends 2000 UDP datagrams of 1400 bytes each to the server.

Listing 8.9. The dg_cli function sends a fixed number of datagrams to the server

//udpcliserv/dgcliloop1.c

1 #include "unp.h"

2 #define NDG 2000 /* number of datagrams to send */

3 #define DGLEN 1400 /* length of each datagram */

5 dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)

8char sendline;

10 Sendto(sockfd, sendline, DGLEN, 0, pservaddr, servlen);

We then modify the server to receive datagrams and count the number of datagrams received. The server no longer reflects datagrams back to the client. Listing 8.10 shows the new dg_echo function. When we terminate the server process by pressing the interrupt key on the terminal (which causes a SIGINT signal to be sent to the process), the server prints the number of datagrams received and exits.

Listing 8.10. The dg_echo function, which counts received datagrams

//udpcliserv/dgecholoop1.c

1 #include "unp.h"

2 static void recvfrom_int(int);

3 static int count;

5 dg_echo(int sockfd, SA *pcliaddr, socklen_t clilen)

7 socklen_t len;

8 char mesg;

9 Signal(SIGINT, recvfrom_int);

11 len = clilen;

12 Recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);

17 recvfrom_int(int signo)

19 printf("\nreceived %d datagrams\n", count);

We now run the server on node freebsd, which is a slow SPARCStation computer. We run the client on a much faster RS/6000 system with the aix operating system. They are connected directly to each other via a 100 Mbit/s Ethernet link. In addition, we run netstat -s on the server node both before and after the client and server are started, since the statistics output will show how many datagrams we lost. Listing 8.11 shows the server output.

Listing 8.11. Output on the server node

freebsd % netstat -s -p udp

71208 datagrams received

0 with incomplete header

0 with bad data length field

0 with bad checksum

0 with no checksum

832 dropped due to no socket

16 broadcast/multicast datagrams dropped due to no socket

1971 dropped due to full socket buffers

0 not for hashed pcb

137685 datagrams output

freebsd % udpserv06 launch our server

client sends datagrams

^C To end the client's work, enter our interrupt symbol

freebsd % netstat -s -p udp

73208 datagrams received

0 with incomplete header

0 with bad data length field

0 with bad checksum

0 with no checksum

832 dropped due to no socket

16 broadcast/multicast datagrams dropped due to no socket

3941 dropped due to full socket buffers

0 not for hashed pcb

137685 datagrams output

The client sent 2000 datagrams, but the server application only received 30 of them, meaning a loss rate of 98%. Neither the server nor the client receives a message that these datagrams are lost. As we said, UDP does not have flow control capabilities - it is unreliable. As we have shown, it is easy for a UDP sender to overflow the receiver's buffer.

If we look at the netstat output, we see that the total number of datagrams received by the server node (not the server application) is 2000 (73,208 - 71,208). The dropped due to full socket buffers counter shows how many datagrams were received by UDP and ignored because the receiving socket's receive buffer was full. This value is 1970 (3941 - 1971), which when added to the output of the application's datagrams received count (30), gives a total of 2000 datagrams received by the node. Unfortunately, netstat's count of datagrams discarded due to a full buffer is system wide. There is no way to determine which applications (eg which UDP ports) are affected.

The number of datagrams received by the server in this example is non-deterministic. It depends on many factors, such as network load, client node and server node load.

If we run the same client and the same server, but this time the client is on a slow Sun system and the server is on a fast RS/6000 system, no datagrams are lost.

aix % udpserv06

^? after the client has finished working, enter our interrupt symbol

received 2000 datagrams