Can UDP overwrite without blocking with fewer bytes than requested?

Question

I have an application that sends data points to a point from the sender to the recipient via a link that can operate in simplex (one-way transmission) or duplex (in two directions). In simplex mode, the application sends data using UDP, and in duplex, it uses TCP. Since writing to a TCP socket can be blocked, we use Non Blocking IO (ioctl with FIONBIO - O_NONBLOCK and fcntl are not supported in this distribution) and the select () system call to determine when data can be written. NIO is used so that we can refuse to send after a timeout, if necessary, if the network conditions deteriorate. I would like to use the same base code to send, but instead change TCP / UDP with a higher abstraction. This works great for TCP.

However, I am concerned about how a non-blocking IO works for a UDP socket. I may not read the man pages correctly, but since write () may return indicating fewer bytes sent than requested, does this mean that the client will receive fewer bytes in its datagram? To send this data buffer, you may need to write multiple times, which may be the case since I use non-blocking IO. I am concerned that this translates to several UDP datagrams received by the client.

I am new to socket programming, so please forgive me if you have some misconceptions. Thanks.

Answer 1

Assuming a valid (unbroken) UDP implementation, each sender / sendmsg / sendto will correspond to exactly one integer datagram, and each recv / recvmsg / recvfrom will correspond to exactly one integer received datagram.

If the UDP message cannot be transmitted completely, you should receive an EMSGSIZE error. The sent message may still not work due to the size at some point on the network, in which case it simply will not be sent. But it will not be delivered to pieces (unless the IP stack is badly damaged).

A good rule of thumb is for your UDP payload size to be no more than 1400 bytes. This is very rough and leaves plenty of room for various forms of tunneling to avoid fragmentation.