UDP common defects and examples of UNIX network programming

UDP compared to TCP, each has advantages and disadvantages, down to enumerate the shortcomings of UDP:

1.UDP is an unreliable protocol (lack of flow control)

Instance code:

Server.c

#include <stdlib.h>
#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>

int main ()
{
int sockfd;
struct sockaddr_in servaddr,clientaddr;
Char recv[1024];
Socklen_t Len;
int count = 0;

SOCKFD = socket (af_inet, SOCK_DGRAM, 0);

memset (&servaddr, ' n ', sizeof (SERVADDR));
memset (recv, ' 1024 ');
servaddr.sin_family = af_inet;
SERVADDR.SIN_ADDR.S_ADDR = htonl (Inaddr_any);
Servaddr.sin_port = htons (5000);

Bind (SOCKFD, (struct sockaddr *) &servaddr, sizeof (SERVADDR));

for (;;)
{
Recvfrom (SOCKFD, recv, 1024x768, 0, (struct sockaddr *) &clientaddr, &len);
memset (recv, ' 1024 ');
count++;
printf ("Count =%d\n", count);
}

Close (SOCKFD);
}

Client.c

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>

int main ()
{
int sockfd;
struct sockaddr_in servaddr;
Char buff[1024];
int count = 0;

memset (&servaddr, ' n ', sizeof (SERVADDR));
memset (Buff, ' n ', 1024);

servaddr.sin_family = af_inet;
Servaddr.sin_port = htons (5000);
SERVADDR.SIN_ADDR.S_ADDR = inet_addr ("192.168.59.129");
SOCKFD = socket (af_inet, SOCK_DGRAM, 0);

for (count; count < 4000; count++)
{
SendTo (SOCKFD, Buff, 1024x768, 0, (struct sockaddr *) &servaddr, sizeof (SERVADDR));
}

Close (SOCKFD);
return 0;
}

The client quickly sends 4,000 datagrams to the server, and then counts the number of datagrams received on the server side, discovering that the amount of datagrams received is less than 4000, because UDP is not a reliable protocol, and in the event of packet loss, there are no mechanisms to deal with this situation, such as a resend. The situation in the above program is mainly due to the server side buffer overflow caused by the receiver, once the buffer overflow, the subsequent datagram is discarded.

For the above scenario, we have two ways to handle this:

1. Use the socket option to modify the size of the receive buffer to accommodate more datagrams (set by the setsockopt function)

2. Each time the sender sends a datagram, it pauses for a period of time (i.e. do not send a large number of datagrams continuously, you can use functions such as usleep,sleep to suspend the process)

However, the above two methods can only be used to alleviate the situation of this packet loss, and can not be eliminated, this is the mechanism of UDP itself decided.

2.UDP is a non-connectivity protocol

Because UDP is not connected, the client can still run the client program even if no programs are running on the server side:

Client.c

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>

int main ()
{
int sockfd;
struct sockaddr_in servaddr;
Char recv[1024];
Char send[1024];
int Len;

memset (&servaddr, ' n ', sizeof (SERVADDR));
memset (recv, ' 1024 ');
memset (send, ' + ', 1024);

servaddr.sin_family = af_inet;
Servaddr.sin_port = htons (5000);
SERVADDR.SIN_ADDR.S_ADDR = inet_addr ("192.168.59.129");
SOCKFD = socket (af_inet, SOCK_DGRAM, 0);

SendTo (SOCKFD, send, 1024x768, 0, (struct sockaddr *) &servaddr, sizeof (SERVADDR));
printf ("Stop at Sendto\n");
Recvfrom (SOCKFD, recv, 1024x768, 0, (struct sockaddr *) &servaddr, &len);
printf ("Stop at Recvfrom\n");

Close (SOCKFD);
return 0;
}

We open the Tcpdump tool to see the datagram sent, and then run the client program, you can see the client program is working, but blocked in the Recvfrom function, and through tcpdump see the following situation:

that is, the data in the process of transmission in fact the error (the above example is the Port unreachable error, which is an ICMP message), but the client program is not aware of the error occurred, still blocking the recvfrom waiting for the data to return, so it is not conducive to us to quickly locate the error.

So is there any way to get the wrong message?
-An error message can be obtained using a connected UDP socket interface.

UNIX Network Programming This book says that for a connected UDP socket interface, you cannot specify an IP address and port number for the output operation, which can be as follows two ways:
1. Use the Write function instead of the SendTo function
2. The SendTo function is still used, but the IP address and port cannot be specified, that is, the fifth parameter of the SendTo function must be a null pointer (personally, this argument is too absolute)

However, in practice,the fifth parameter in SendTo can still specify the IP address and port, except that it needs to be consistent with the first parameter of the Connect function (that is, the parameters in connect).

Client.c

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>

int main ()
{
int sockfd;
struct sockaddr_in servaddr;
Char recv[1024];
Char send[1024];
int Len;

memset (&servaddr, ' n ', sizeof (SERVADDR));
memset (recv, ' 1024 ');
memset (send, ' + ', 1024);

servaddr.sin_family = af_inet;
Servaddr.sin_port = htons (5000);
SERVADDR.SIN_ADDR.S_ADDR = inet_addr ("192.168.59.129");
SOCKFD = socket (af_inet, SOCK_DGRAM, 0);

Connect (SOCKFD, (struct sockaddr *) &servaddr, sizeof (SERVADDR));
SendTo (SOCKFD, send, 1024x768, 0, (struct sockaddr *) &servaddr, sizeof (SERVADDR));
printf ("Stop at Sendto\n");
Recvfrom (SOCKFD, recv, 1024x768, 0, (struct sockaddr *) &servaddr, &len);
printf ("Stop at Recvfrom\n");
printf ("The Imformation of error is%s\n", recv);

Close (SOCKFD);
return 0;
}
This example has more than two statements compared to the previous example, but running in Ubuntu found that the program is not blocked on the Recvfrom function, because the connection through connect, the application has been able to get the error, but the final printing recv did not print any error messages, This is related to whether the kernel is sending ICMP messages back to the UDP socket interface. I did the experiment under Ubuntu and found that this ICMP message was not returned.

Attention:
If you call the Connect function in a TCP program, the server side does not run the program, and connect returns an error directly (because three handshakes are established at this time), but no error is returned in UDP.


several issues to be aware of:
1. In general, we do not specify the IP and port number at the client, in which case the port number has the kernel temporary allocation (the allocation port is determined the first time the SendTo function is called, and cannot subsequently be changed）。 However, if the client has multiple IP addresses, the source IP address of each UDP datagram sent by the client may be different.
2. If the client binds an IP address through the BIND function, but the kernel decides to emit the datagram using a different data link, the IP datagram will contain a source IP address that differs from the outgoing link IP address.
3. In the actual application, if there is such a change in the source IP address IP datagram, how to identify they belong to the same client?

UDP common defects and examples of UNIX network programming