As far as I am aware, the answer to this question is "yes", however I wanted to check my understanding and hopefully get a more detailed an in-depth understanding.
Do calls to send correspond 1:1 with calls to recv?
To express this in another way, if a program calls send to send some data via a network socket to another network connected program, will there be exactly 1 and only 1 call made to recv on the receiving side of the connection? (Assuming the recv buffer is large enough.)
I am aware that Operating Systems and other network hardware may fragment an IP packet. However, my understanding is that the Operating System on the receiving side will re-combine fragmented packets before presenting the recombined packet to a client application via recv.
The reason for asking is I am trying to figure out whether or not I might, under some circumstances, need to call recv multiple times to get all of the data sent by a call to send on some other machine.
The obvious reason why this might be required is because send sends more data than can fit in the buffer used by recv. However, for the purposes of this question let's assume the largest quantity of data sent by send will fit inside the buffer used by recv.
The answer is mostly yes for datagram sockets like UDP and no for stream sockets like TCP. Wrongly assuming that a 1:1 relationship between send and recv exists also with TCP is a very common programming error. Similar wrong with stream sockets is the assumptions that send will send everything (check the return value how much was really send) and that recv will try to read all of the given size (check return value how much was really read).
And even for datagram sockets the answer is not always yes. Contrary to TCP a UDP socket is not reliable and thus datagrams might be lost (only full datagrams, not parts). This means there might be a send with no matching recv since the packet got lost.