UDP send behaviour after connect()

Question

#include <stdio.h>  
#include <errno.h>  
#include <stdlib.h>  
#include <string.h>  
#include <sys/types.h>  
#include <sys/socket.h>  
#include <netinet/in.h>  
#include <arpa/inet.h>  

int main()  
{    
    struct sockaddr_in addr;  
    int fd, cnt,ret;  
    char ch = 'y',msg[] ="How are you";  

    if ((fd=socket(AF_INET,SOCK_DGRAM,0)) < 0) {  
        printf("Error: socket");  
        exit(1);  
    }
    printf("\nDone socket\n");  

    /* set up destination address */  
    memset(&addr,0,sizeof(addr));  
    addr.sin_family=AF_INET;  
    addr.sin_addr.s_addr=inet_addr("128.88.143.113");  
    addr.sin_port=htons(9090);  

    ret=connect(fd,(struct sockaddr *)&addr,sizeof(addr));  
    perror("Connect:");  

    while(ch == 'y'){  
        cnt =  send(fd,msg,sizeof(msg),0);  
        if(cnt < 0)  
        perror("send:");  
        printf("\nNumber of bytes sent = %d , \n",cnt);  
        printf("Continue (y/n)\n");  
        scanf(" %c",&ch);  

     }

     return 0;  
}  

The above code is compiled to run on a Linux machine.

Assume that the above code sends data to a machine at IP address 128.88.143.113. No UDP socket is bound to port 9090 at 128.88.143.113.

In the while loop, the first call to send() succeeds(the packet actually goes out on the wire; checked it using trace) and the second send() fails with Connection refused. The third send() succeeds and the forth fails and so on.

I suspect that after first send() the stack receives an ICMP error message(seen in tcpdump on the Linux machine) which is saved in the socket structure. The second send() fails upon seeing this error and no packet is actually sent out. The second send() also clears the error in the socket structure. Therefore the third send() succeeds and the forth fails and so on.

Questions:

1. Is this assumption correct?
2. What should be the correct behavior? Is there any RFC standard defining such behavior?
3. Since UDP does not maintain any connection state, shouldn't every send() succeed?

Answer 1

Your hypothesis is correct. The Linux udp(7) man page describes the situation thus:

All fatal errors will be passed to the user as an error return even when the socket is not connected. This includes asynchronous errors received from the network. You may get an error for an earlier packet that was sent on the same socket.
This behavior differs from many other BSD socket implementations which don't pass any errors unless the socket is connected. Linux's behavior is mandated by RFC 1122.

When the IP_RECVERR option is enabled all errors are stored in the socket error queue and can be received by recvmsg(2) with the MSG_ERRQUEUE flag set.

Answer 2

To start at the other end, if you connect a UDP socket you can collect errors on the next send. If you don't want that, don't connect!

Answer 3

It would be interesting to compare the equivalent code using sendto() rather than connect() and send().

Does the code shown fail in the same way if you leave a period of time between each send, i.e. is the ICMP error state being kept in the socket for a period of time, or would it still fail the second send() if you left it, say, an hour?

I expect that your assumption is correct, the network stack is trying to be clever. There's no other point when it could return 'connection refused' as nothing is sent when the connect() call is issued it simply stores the address given so that the socket is 'logically' connected and calls to send() can then work.

Answer 4

According to the linux man page for udp:

All fatal errors will be passed to the user as an error return even when the socket is not connected. This includes asynchronous errors received from the network. You may get an error for an earlier packet that was sent on the same socket. This behaviour differs from many other BSD socket implementations which don't pass any errors unless the socket is connected. Linux's behaviour is mandated by RFC 1122.

Specifically the RFC (4.1.3.3) states:

UDP MUST pass to the application layer all ICMP error messages that it receives from the IP layer. Conceptually at least, this may be accomplished with an upcall to the ERROR_REPORT routine

Answer 5

I had the same problem; and the is due to the fact that the udp message queue is filled if nobody is listening and emptying the queue.