Connectionless and Connected Datagram Sockets

---

By default, datagram sockets are connectionless. This useful feature of UDP means that there is no single peer connected to the datagram socket, and, instead, a packet can be directed to the peer with remote address information provided with the data. This differs from TCP sockets in that there is a single peer associated with the socket. For this reason, when referencing a TCP socket, there is no need to specify remote addressing because it’s already been cached in the Sockets layer.

Datagram sockets can be connected like stream sockets, but without the setup required by a stream socket. For example, when a stream socket connects to a peer, a handshake takes place to synchronize the two ends of the connection. Because datagram sockets are message-based, there is no such synchronization. Therefore, connectedness in a datagram socket simply means that there is no need to specify peer address information with every write; it’s cached in the stack like stream sockets.

Let’s look at some examples to better understand what’s happening here. In the first example, Listing 6.12, we look at a typical datagram socket that is connectionless. This is the standard mode for datagrams.

Listing 6.12 Datagram socket in an unconnected state.

int sock, ret; struct sockaddr_in saddr; char buffer[MAX_BUFFER]; sock = socket( AF_INET, SOCK_DGRAM, 0 ); memset( &saddr, 0, sizeof(saddr) ); saddr.sin_family = AF_INET; saddr.sin_port = htons( MY_PORT ); saddr.sin_addr.s_addr = inet_aton( "192.168.1.1" ); ... ret = sendto( sock, buffer, strlen(buffer),                (struct sockaddr_in *)&saddr, sizeof(saddr) );

As shown in Listing 6.12, the sendto call is needed for datagram sockets in the unconnected state because the peer address information must be specified.

Now let’s look at a datagram socket in the connected state. In this example, Listing 6.13, we see that a connect has been used to place our datagram socket in the connected state. Unlike TCP sockets, this simply caches the peer address information in the stack and does not perform the typical three-way handshake as required by TCP. Also shown is use of the send call instead of sendto. Because the peer address is already cached in the stack, we don’t need to recall this information for sendto, and send works identically in this case.

Listing 6.13 Datagram socket in a connected state.

int sock, ret; struct sockaddr_in saddr; char buffer[MAX_BUFFER]; sock = socket( AF_INET, SOCK_DGRAM, 0 ); memset( &saddr, 0, sizeof(saddr) ); saddr.sin_family = AF_INET; saddr.sin_port = htons( MY_PORT ); saddr.sin_addr.s_addr = inet_aton( "192.168.1.1" ); ret = connect( sock,                (struct sockaddr_in *)&saddr, sizeof(saddr) ); ... ret = send( sock, buffer, strlen(buffer), 0 );

One of the primary advantages of this approach is that it’s much cleaner and can be less error-prone. In some cases, it can be a performance advantage because there are fewer arguments passed between the Application layer and the stack.

---