TCP/IP send data and receive data sequence

Question

I am using uIP Open Source TCP Stack on my Embedded Microcontroller. I have read many post of TCP/IP which looks similar to this question but still I couldn't get the answer I was looking for. Thus I am asking this.

I know send data will be saved in Ethernet Controller(Server) Tx Buffer in sequence. And Receive data will be saved in Ethernet Controller(Client) Rx Buffer in sequence.

If I have 100 bytes of message which I send (using PSOCK_SEND method ) all together to client using TCP. I know if I send all together receiver will guarantee receive all together.

Now If I send two 50 bytes one by one, it there any possibility that second 50 bytes sent can be received first. And first 50 bytes sent can be received second?

My understanding is that this is possible in HTTP Protocol. But in TCP regardless of bytes sent in two steps or one, the receive will receive in the same sequence. So TCP will keep sending first 50 bytes until it will be successful or time out. And only then it will send second 50 bytes.

Answer 1

I know if I send all together receiver will guarantee receive all together.

The above is not guaranteed. TCP is a byte-stream oriented protocol, not a message-oriented protocol, so it does not guarantee anything other than that the data bytes will be received in the same order that they were sent. The receiver might receive all 100 bytes via a single recv() call, or it might (at least in principle) receive 1 byte at a time across 100 recv() calls, or anywhere in between, and it is up to the receiving code to be prepared to handle the incoming data correctly regardless of what the sizes are of the chunks that it arrives in.

Now If I send two 50 bytes one by one, it there any possibility that second 50 bytes sent can be received first. And first 50 bytes sent can be received second?

As far as the application is concerned, no. TCP guarantees in-order reception of the TCP data at the application level. (The underlying packets might be received out of order by the TCP stack, but the TCP stack won't present them to the application layer out of order. Rather, it will wait until it has some more data ready in the correct order before causing recv() to return with more data)

My understanding is that this is possible in HTTP Protocol.

Since HTTP is built on top of TCP, any guarantees that TCP makes will also be true for HTTP. In particular, HTTP data will be received in the order in which the sender sent it. (You might be a little confused by something in the HTTP spec that says eg that the sender can send HTTP headers in different orders, but note that whatever order the sender sends them in will nevertheless be the exact same order that the receiver receives them in, since they are all going over the TCP layer's byte-stream which is strictly FIFO)

Answer 2

So TCP will keep sending first 50 bytes until it will be successful or time out. And only then it will send second 50 bytes.

Sorry, but your understanding of how TCP works is not correct. TCP has a window size which is the number of bytes that can be sent on a connection without waiting for an acknowledgement from the receiver.

So for example, if you send two 50 byte packets, and the TCP window is at least 100 bytes, then the packets can both be sent without waiting for a response. And depending on network conditions, the packets may arrive at the receiver in reverse order. Therefore, the packets that you read from the Ethernet Controller(Client) Rx Buffer are not necessarily in order.

It's up to the TCP Stack software to re-order the packets as needed, before passing the packet payloads to the higher level protocol (which in your case is HTTP). Because the TCP Stack software reorders the packets, the HTTP software will always see the bytes in the same order that they were sent.

---

In response to the comment:

I have got two contrasting answers which I want to clarify. Is this means, for application layer, the bytes will be in order regardless of TCP Window Size? (1) As far as the application is concerned, TCP guarantees in-order reception of the TCP data at the application level. (2) TCP has a window size: if you send two 50 byte packets, and the TCP window is at least 100 bytes, then depending on network conditions, the packets may arrive at the receiver in reverse order.

Statement (1) applies to the interface between the TCP layer and the application layer. Statement (2) applies to the interface between the hardware and the TCP layer. There is no contradiction in the two statements because the TCP layer re-orders packets as necessary.