The Socket API, Part 4: Datagrams

转：http://www.linuxforu.com/2011/11/socket-api-part-4-datagrams/

By Pankaj Tanwar on November 1, 2011 in Coding, Developers · 0 Comments



Let’s try to develop server clients using UDP, the protocol behind some important services like DNS, NFS, etc.
UDP, the User Datagram Protocol, is a connectionless protocol. This means you don’t establish a connection before sending data (like the three-way handshake for TCP); you just send the data in the form of a datagram, to the target address. That’s why we also call it a unreliable protocol, as we do not know or care if the datagram reached the recipient or not.

The code

Now, as we usually do, let’s jump to the program. The code in this article is a modified version of the echo server/clients programs in the UNIX Network Programming by Stevens et al. This file is

udpserver.c

:

This is almost like the previous code; let, let’s discuss the differences. First, the call to

socket()

: the

SOCK_STREAM

that was for TCP/SCTP is replaced with

SOCK_DGRAM

. Then we did a

bind()

to the address and port, and the server was ready to receive data from the client (which, in this case, is simple text that fits in a single packet).

Next, you see there is no

listen()

call. Instead you are waiting to receive data at

recvform()

and when received, echo it back to the client using

sendto()

.

Before looking into these functions, observe that your server does not

fork()

to serve each request, but iteratively serves requests at each iteration in the infinite loop. That’s because in TCP, you have to maintain a connection with each client, and so need a separate thread, but in UDP you just reply to a single client at a time, and it’s free to receive data from the next client in the next iteration.

Thus, you see that we need a buffer for the server that will hold data from clients in queue, to serve in a first-in-first-out order. Most TCP servers are concurrent, and UDP servers are iterative.

Sending and receiving

Let’s cover the new functions used for datagrams; first is

recvfrom()

:

This function blocks the server until it receives some data at

sockfd

from the address specified in the

*from

argument, and writes

nbytes

to

*buf

. The flag argument is formed by

OR

-ing one or more values, but we’re not using it, so it is 0. The last argument,

*addrlen

, is a pointer to the size of the socket address structure.

Now, send data using

sendto()

:

This function sends the

*buf

data of size

nbytes

through

sockfd

to the address stored in the

*to

structure. Its size is

addrlen

, and do note that it is not a reference, as it was in

recvfrom()

. The flags argument is as in

recvfrom()

. Both functions return the number of bytes read/written.

And the code for the client,

udpclient.c

, is as follows:

The client program is very simple -– it just sends the line read from the standard input to the server using

sendto()

, and reads the reply from the server using

recvfrom()

.

Here, don’t specify the address and port you are receiving from, so any random client/server can send data to you if it knows the port number assigned to your client. If you are interested in replies from a specific server, you can store the structure returned by the

recvfrom()

and compare it with the structure used in

sendto()

.

This may be a problem if your server is multi-homed (with multiple IPs), and the server has not bound the address like we usually do, using

INADDR_ANY

.




Figure 1: Starting server




Figure 2: Client running

Before ending, let’s look into some problems with UDP.

First, there is no way to know if your datagram has reached the other side. You cannot know whether the request or the reply is lost. This is okay for a server, but your client may keep on waiting for a reply. In that case, you can specify a time-out in the call to

recvfrom

, so it doesn’t wait forever.

And here, I end the article, signing out with my usual, “FOSS ROCKS!”