Search code examples
c++socketstcpposix

if send() returns x bytes, does recv() get the same amount of bytes in one call?

I'm aware of the need to call send() in a loop until the desired amount of bytes have been sent. Also on the receiving side.

Here is a part of wrapper around recv I wrote:

do{
            result = socket->receiveData(m_recvBuf + recv_len , BUF_LENGTH - recv_len);
            recv_len += result;
.....

I'm a little confused about couple of things, so here goes:

  1. if the send() returns 10 bytes, are those ten bytes still only at the sender side, but ready to be sent. Or have the bytes physically arrived to the receiver computer?

  2. If the answer to the above is yes, does then calling recv() always return those 10 bytes as they have already arrived?

  3. I could also put it this way; if send has been called three times each time returning 10, so total bytes sent supposedly being 30. Does then calling recv(), one time, return 30 bytes?

Question 1. edited as "still only at the receiver side" should be "still only at the sender side".

Scenario: My program in pc1 calls send(); send() returns 1; My code things that one byte has been sent to the receiver program in pc2. The network cable got eaten by a dog the moment after my send() function returned 1.

If that is the case in real life, I surely have misunderstood the benefits of TCP vs UDP.

Thanks all for giving time in answering.

Solution

  • if the send() returns 10 bytes, are those ten bytes still only at the sender side, but ready to be sent. Or have the bytes physically arrived to the receiver computer?

    You cannot tell where the 10 bytes are exactly, some of them can be waiting somewhere in the sending machine, some over some wire and some waiting somewhere in the receiving machine.

    If the answer to the above is yes, does then calling recv() always return those 10 bytes as they have already arrived?

    N/A

    I could also put it this way; if send has been called three times each time returning 10, so total bytes sent supposedly being 30. Does then calling recv(), one time, return 30 bytes?

    You cannot tell! The only thing you can say, in TCP mode, is that bytes are received in the same order that they have being sent.

    Scenario: My program in pc1 calls send(); send() returns 1; My code things that one byte has been sent to the receiver program in pc2. The network cable got eaten by a dog the moment after my send() function returned 1.

    Then you cannot say anything...

    If that is the case in real life, I surely have misunderstood the benefits of TCP vs UDP.

    UDP is datagram-oriented semantic, like postal sytem (no preserved order, no guaranty of any kind, loss is possible, duplicate, etc)

    TCP is stream-oriented semantic, like phone system (preserved order and no loss).

    Of course in case of hard network failure, TCP cannot ensure anything!

    As TCP is build on top of IP (datagram) what is sent over TCP is fragmented to be sent via IP, and you don't control such fragmentation (I forgot to tell about caching, etc).