Whether in blocking or non-blocking mode, the Data Length returned by send (...) only indicates the Data Length copied to the protocol stack buffer. It is not the actual data volume sent or the data volume received by the other party. For Recv (...), only the received data is obtained from the buffer zone. The sender first copies the data to the protocol stack buffer. TCP will ensure that the data in the buffer is sent to the receiver's buffer. As for how data can be reliably delivered, the underlying protocol has already done a lot of work for us, so upper-layer applications do not have to consider it.
Blocking and non-blocking are not much different from the underlying protocol (I think so now). In blocking mode, the data to be sent will be copied to the buffer during sending, if the Buffer Zone capacity cannot accommodate the data to be sent, wait for the data in the buffer zone to be sent until the buffer zone can accommodate the data and then return the method. In non-blocking mode, if the Buffer Zone capacity cannot accommodate the data to be sent, it first fills up the buffer zone and directly returns the Data Length filled in the buffer zone.
Some good articles:
Research on Non-blocking TCP for socket programming in Linux
Recv, Seng, read, and write return values in case of socket blocking or non-blocking
Differences between socket blocking and non-blocking