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 isudpserver.c:

#include <stdio.h>

#include <sys/socket.h>

#include <strings.h>

#include <netinet/in.h>

int main()

{

int sfd, n;

socklen_t len;

char line[128];

struct sockaddr_in saddr, caddr;

sfd = socket(AF_INET, SOCK_DGRAM, 0);

bzero(&saddr, sizeof(saddr));

saddr.sin_family = AF_INET;

saddr.sin_addr.s_addr = htonl(INADDR_ANY);

saddr.sin_port = htons(2910);

bind(sfd, (struct sockaddr *)&saddr, sizeof(saddr));

printf("Server running\n");

for(;;) {

len=sizeof(caddr);

n=recvfrom(sfd, line, 128, 0, (struct sockaddr *)&caddr, &len);

sendto(sfd, line, n, 0, (struct sockaddr *)&caddr, len);

}

return 0;

}

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():

#include <sys/socket.h>

ssize_t recvfrom (int sockfd, void *buf, size_t nbytes,

int flags, struct sockaddr *from, socklen_t *addrlen);

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():

#include <sys/socket.h>

ssize_t sendto (int sockfd, const void *buf, size_t nbytes,

int flags, const struct sockaddr *to, socklen_t addrlen);

This function sends the *buf data of size nbytes through sockfd to the address stored in the *tostructure. 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:

/**

#include <sys/socket.h>

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);

**/

#include <stdio.h>

#include <sys/socket.h>

#include <string.h>

#include <netinet/in.h>

#define MAX 100

int main(int argc, char** argv)

{

int sfd, n;

socklen_t len;

char sline[MAX], rline[MAX+1];

struct sockaddr_in saddr;

if(argc!=2) {

printf("Usage: %s ipaddress\n", argv[0]);

return -1;

}

sfd = socket(AF_INET, SOCK_DGRAM, 0);

bzero(&saddr, sizeof(saddr));

saddr.sin_family = AF_INET;

inet_pton(AF_INET, argv[1], &saddr.sin_addr);

saddr.sin_port = htons(2910);

printf("Client Running\n");

while(fgets(sline, MAX, stdin)!=NULL) {

len=sizeof(saddr);

sendto(sfd, sline, strlen(sline), 0, (struct sockaddr *)&saddr, len);

n=recvfrom(sfd, rline, MAX, 0, NULL, NULL);

rline[n]=0;

fputs(rline, stdout);

}

return 0;

}

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!”