I'm wondering why message overlap is even a problem in a TCP stream? The data is always in order and guaranteed.

TCP data is always in order and guaranteed, this is true. TCP is, however, a stream, so what is not guaranteed is data grouping.

Let us say that I generate 5 50-byte logical packets. Each is sent during a separate frame.

I could get all five at once (a single 250 byte blob). I could get 250 one byte receives, I could get anything in between.

This is why we need some kind of framing in the logical packet itself; there is nothing in the TCP stream that does it for us because there is no guaranteed correlation between the number and size of TCP sends and the number and size of the corresponding TCP receives.

 

I'm wondering why message overlap is even a problem in a TCP stream? The data is always in order and guaranteed.

 

TCP data is always in order and guaranteed, this is true. TCP is, however, a stream, so what is not guaranteed is data grouping.

Let us say that I generate 5 50-byte logical packets. Each is sent during a separate frame.

I could get all five at once (a single 250 byte blob). I could get 250 one byte receives, I could get anything in between.

This is why we need some kind of framing in the logical packet itself; there is nothing in the TCP stream that does it for us because there is no guaranteed correlation between the number and size of TCP sends and the number and size of the corresponding TCP receives.