The non blocking mode set to Linux UDP socket differs from the blocking mode

The non-blocking mode set to Linux UDP socket differs from the blocking mode

UDP socket is set to non-blocking mode

Len = recvfrom(SocketFD, szRecvBuf, sizeof(szRecvBuf), MSG_DONTWAIT, (struct sockaddr *)&SockAddr,&ScokAddrLen);

UDP socket is set to block mode

Len = recvfrom(SocketFD, szRecvBuf, sizeof(szRecvBuf), 0, (struct sockaddr *)&SockAddr,&ScokAddrLen);

Block and non-block sockets for Linux socket programming

There is one send buffer for each TCP interface. You can change the size of this buffer with the SO_SNDBUF interface option. When an application process calls write, the kernel copies all data from the application process's buffer to the socket interface's send buffer. If the interface's send buffer does not hold all of the application's data (or if the application process's buffer is larger than the interface's send buffer, or if the interface's send buffer contains other data), the application process will be suspended (sleep). This assumes that the sleeve interface is blocked, which is the usual default. The kernel will not return from the write system call until all the data in the application process buffer is copied to the nested interface send buffer. So the successful return from the write call to write an TCP suite interface simply means that we can reuse the buffer of the application process. It does not tell us that TCP or the application process has received the data on the opposite side.

TCP fetches the interface and sends the buffer data and sends it to the opposite TCP, based on all the rules of the TCP data transfer. The opposite TCP must confirm the received data. Only when the opposite ACK is received can the same TCP delete the confirmed data in the interface send buffer. TCP must keep a copy of the data until the other end confirms it.

1 input operation: read, readv, recv, recvfrom, recvmsg

If a process calls one of these input functions on a blocked TCP interface, and there is no data in the receive buffer for that interface to read, the process is put to sleep until it reaches some data. Since TCP is a byte stream protocol, the wake up of the process is to reach only 1 bit of data: this data can be either a single byte or a full TCP segment. If you want to wait until a fixed number of data is readable, you can call the readn function or specify the MSG_WAITALL flag.

Since UDP is the datagram protocol, if the receive buffer of a blocked UDP interface is empty, the process that calls the input function to it will be put to sleep until it reaches an UDP datagram.

For a non-blocking nested interface, if the input operation cannot be satisfied (at least 1 byte of data is readable for the TCP nested interface, and a complete datagram is readable for the UDP nested interface), the corresponding call will immediately return an EWOULDBLOCK error.

2 output operations: write, writev, send, sendto, sendmsg

For an TCP interface, the kernel copies data from the buffer of the application process to the send buffer of the interface. For a blocked nested interface, if there is no room in its send buffer, the process is put to sleep until there is room.

For a non-blocking TCP sleeve interface, if there is no space in the send buffer at all, the output function call will immediately return an EWOULDBLOCK error. If it has some space in its send buffer, the return value will be the number of bytes the kernel can copy into that buffer. This byte count is also known as an undercount (short count)

UDP set interface can not be in the real send buffer. The kernel simply copies the application process data and passes it down the stack, incrementally leading to the UDP header and the IP header. Therefore, for 1 blocked UDP sleeve interface, the output function call will not be blocked for the same reason as TCP sleeve interface 1, but it may be blocked for other reasons.

Thank you for reading, I hope to help you, thank you for your support of this site!