Detailed description of blocking and non-blocking Io Modes

In network programming, a network handle may encounter the concept of blocking Io and non-blocking Io. Here we will first describe these two sockets:

Blocking IO: the blocking mode of the socket means that the IO operation (including errors) must be completed before returning.

Non-blocking I/O: in non-blocking mode, no matter whether the operation is completed or not, it is necessary to determine whether the operation is successful in other ways. (For connect and accpet operations, select is used to determine, and Recv, recvfrom, send, and sendto are determined by the return value + error code ).

The method for handling whether a socket is in blocking or non-blocking mode is very simple. You can use fcntl to set it. The f_getfl parameter gets flags and f_setfl sets flags | o_nonblock. At the same time, Recv, when sending, use a non-blocking method to read and send messages, that is, set flags to msg_dontwait. The following uses the fcntl function to set (non-) blocking I/O mode for a socket handle:

Flags = fcntl (sockfd, f_getfl, 0); // obtain the flags value of the object. Fcntl (sockfd, f_setfl, flags | o_nonblock); // set to non-blocking mode; flags = fcntl (sockfd, f_getfl, 0); fcntl (sockfd, f_setfl, flags &~ O_nonblock); // set to blocking mode;/* And Recv when receiving and sending data. The last flag parameter of the send function is set to msg_dontwait */Recv (sockfd, buff, buff_size, msg_dontwait); // send messages in non-blocking mode (scokfd, buff, buff_size, msg_dontwait); // accept messages in non-blocking mode

There are two methods for file blocking mode or non-blocking mode:

Method 1: Use o_nonblock for open;

Method 2. Set fcntl using f_setfl, flags | o_nonblock;

The settings for sending and receiving a message in a message queue are as follows:

Msgsnd (sockfd, msgbuf, msgsize (excluding the type size), ipc_nowait) // non-blocking

Msgrcv (scokfd, msgbuf, msgsize (**), msgtype, ipc_nowait) // Blocking

 

The difference between blocking and non-blocking is whether to return immediately when no data arrives. The former waits, and the latter returns.

Read (Read/Recv/msgrcv): In essence, read cannot be read. In reality, the specific data reception is not performed by these calls because the system automatically completes the operation at the underlying layer. Read or Recv is only responsible for copying data from the underlying buffer to the specified position.

For read (read, or Recv), the Read/Recv/msgrcv behavior is as follows:

1. If no data is found to be waiting in the network buffer,

2. When data is found, the data will be read to the user-specified buffer zone. However, if the data read at this time is smaller than the length specified in the parameter, read does not keep waiting, but returns immediately.

The principle of read is how much data is read when it does not exceed the specified length, and it will wait until there is no data. Therefore, in general, we need to read data cyclically when reading data, because the length of data that we need cannot be read after one read operation is complete, after one read operation, you need to determine the length of the read data and determine whether to read the data again.

In the case of non-blocking, the read behavior is as follows:

1. If no data is found, return directly,

2. if data is found, the data is read and processed.

Therefore, after one read operation, you must determine the length of the read data and determine whether to read the data again.

 

For read, the difference between blocking and non-blocking is whether to return immediately when no data arrives. The Recv has a parameter msg_waitall: Recv (sockfd, buff, buff_size, msg_waitall ), under normal circumstances, the Recv will wait until the data of the buff_size length is read. However, the waitall here only tries its best to read the full data. In case of interruptions, the Recv may still be interrupted, the length of the specified buff_size is not read. So even if Recv is used
+ The waitall parameter still needs to consider whether loop reading is required. In most cases, the Recv (msg_waitall is used) can still be read through buff_size in the experiment, therefore, the performance is better than direct read for cyclic reading.

Note that when msg_waitall is used, sockfd must be in blocking mode; otherwise, waitall cannot work.

 

Write (send/Write/msgsnd)The essence of writing is not to send data, but to copy user-state data to the bottom layer of the system, and then the system will send the data, send, write, and return success, it only indicates that the data has been copied to the underlying buffer, not that the data has been sent, but not that the data has been received by the other port.

For write (or send), in the case of blocking, write will finish sending the data (but may be interrupted), if blocking is always waiting, this behavior is different from the read operation when the data in the write operation is completely returned.

The main reason for reading data is that when we read the data, we don't know whether there is any data on the peer end, and when the data is sent, if we keep waiting, it may lead to an endless loop, therefore, this issue has not been processed;

For write, since the length to be written is known, you can continue writing until you finish writing. however, the problem is that the write operation may be interrupted. As a result, the write operation only writes a part of data at a time. Therefore, the write process still needs to consider loop write, but in most cases, the write operation may be successful.

In the case of non-blocking write, the write policy is used. what is different from reading is that the number of reads is determined by whether data is transmitted to the end of the network, however, the number of data records that can be written is determined by local network congestion. When network congestion is serious, the network layer does not have enough memory for write operations, at this time, the write operation fails. When blocking occurs, the system tries its best (possibly interrupted) to wait until all data is sent. If the data is not blocked, the write operation is counted as much as once, if there is no interruption, write to a part will still occur.