Should the send () function in TCP Guaranteed come in order?
It is known that the return value of send () may be less than the length, which means that part of the message, not the whole, has arrived. I have to send 2 packets, the contents of which are "ABC" and "DEF" respectively, and their length is 3. I want to send "DEF" by send () after send () has been called to send "ABC". However, there is a case where the return value of send () for "ABC" is less than its length, 3. I think there is a possibility that messages are not delivered in order. For example, if the return value for "ABC" is 2, the received message is "ABDEF".
Is TCP Guaranteed send () OK?
source to share
First of all, send () does not guarantee anything by itself, send () only writes the data you want to send over the network in the socket buffer. There it is segmented (placed in TCP segments) by the operating system, which manages the reliability of the transmission. If the underlying buffer is full, then you will get a return value that is less than the number of bytes you want to write. This usually indicates that the operating system is not freeing the buffer quickly enough, that is, the speed of writing data to the buffer is higher than the data transfer rate to the network).
Secondly, TCP is a streaming protocol, if you send () "ABC" and then "DEF", there is no guarantee as to how this data will be segmented, it might be in one packet or six packets. Just like writing data to a file.
Third, the network stack (the implementation of TCP / IP in the OS) guarantees delivery on demand, as well as other nice things that TCP promised - reliability, congestion control, flow control, etc.
source to share