Using Recvfrom () to receive different performance of UDP packets on Windows and Linux platforms

1 UDP Receive principle

The UDP receiving process of the operating system is as follows: After receiving a UDP packet, after verifying that there is no error, put in a package queue, each element in the queue is a complete UDP packet. When the application is read by Recvfrom (), the OS takes out a corresponding full UDP packet and copies it to the user-supplied memory, the amount of memory provided by the physical user, and the OS will take out a UDP packet in full. If the user provides less than the size of the UDP packet, the remaining portion of the UDP packet is discarded after the slow memory is populated, and can no longer be retrieved.

This is completely different from TCP reception, TCP does not have the concept of a complete package, there is no boundary, the OS will only remove the user's requested size, the remaining remains in the OS, the next time you can continue to remove.

Socket programming is a de facto standard, and the interface functions provided by different platforms are very similar, but there is no strict standard. Therefore, the implementation of each platform is not fully compatible. Here's a look at the difference between the window platform and the Linux platform from the Recvfrom () function.

2 performance of the Windows platform

The declaration in the first review file:

Intwsaapirecvfrom (    _in_ SOCKET S,    _out_writes_bytes_to_ (len, return) __out_data_source (NETWORK) char FAR * buf ,    _in_ int len,    _in_ int flags,    _out_writes_bytes_to_opt_ (*fromlen, *fromlen) struct sockaddr FAR * from,
   _inout_opt_ int FAR * Fromlen    );

See the MSDN instructions again:

If the datagram or message is larger than the buffer specified, the buffer was filled with the first part of the datagram, and recvfrom generates the error wsaemsgsize. For unreliable protocols (for example, UDP) the excess data is lost.

As you can see, thebuf size is smaller than the UDP packet size, recvfrom () returns 1and sets the error wsaemsgsize.

The actual programming test verifies that this is indeed the case.

3 performance of the Linux platform

The declaration in the first review file:

__extern_always_inline ssize_t  recvfrom (int __fd, void *__restrict __buf, size_t __n, int __flags,        __sockaddr_ ARG __addr, socklen_t *__restrict __addr_len)

You can see the same function prototype as the Windows platform. However, in its man manual, there is no specific description of the UDP packet that is larger than the receive buffer condition.

The write code test shows thatwhen BUF is smaller than the UDP packet size ,recvfrom () still returns the number of bytes copied to the buffer , and the caller is not aware of the UDP packet being truncated.

4 Writing Code considerations

The UDP packet will not be larger than the underlying MTU, otherwise it cannot be sent and cannot be greater than 1500 on the Ethernet. Although for the Windows platform, recvfrom () can prompt the caller to buf too small a problem, but even if the error is obtained, the package is discarded. So in the case of receiving UDP packets, the BUF provided is large enough to be set to 1500, which avoids the packet truncation.

Using Recvfrom () to receive different performance of UDP packets on Windows and Linux platforms