As I understand, TCP takes a chunk of data and cuts it into segments that are transmitted over a TCP session.

Now suppose that I, as a client, have two chunks A, B of data that I want sent to a server. Each chunk is cut into 3 segments, forming a total of 6 segments.

I will send those 6 segments over the Internet, but I cannot guaranty the order the server will receive them. Fortunately, the TCP server rearranges out-of-order segments for me.

However, for my application, chunks A and B are completely independent, so I don't want the server to be waiting for A segments if all B segments have been received, or vice versa. In effect, I want two independent TCP sessions for chunks A and B.

Is it possible for a client and a server to have parallel, independent TCP sessions? Looking at the TCP header entries, I see no "session number". I am forced to use different source or destination ports?

  • Of course a server can handle multiple simultaneous connections. Please remember that we prefer practical questions here. As a hypothetical question, this is likely to be closed. – Michael Hampton Oct 18 '12 at 18:48
  • The phrasing is theoretical, but the origin is practical. I've just subsumed my complex problem into a manageable question. – Randomblue Oct 18 '12 at 19:04
  • This is exactly what SCTP en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol is used for. – Matthew Ife Feb 15 '14 at 8:35

Of course you can have two parallel, independent TCP sessions between the same client and server. Otherwise, just for one example, web browsers wouldn't be able to fetch an HTML page and an image, or two images from a web server at the same time.

The discriminator for TCP sessions is not a "session number" but the tuple (local-address, local-port, remote-address, remote-port). As long as at least one of those is different, it's a different TCP session.

So in answer to your question, yes, you are forced to use a different source OR destination port. Your TCP stack will refuse to make the connection (giving you error EADDRINUSE) if you try to use the same source AND destination port. This is all assuming that the local-address and remote-address are the same throughout.

But this is not something you usually have to worry about. Usually, TCP initiators (clients) don't need to bind to a particular port. They let the kernel pick a source port automatically by not calling bind() before they call connect(). The kernel will make sure to pick a different source port for the second connection.

| improve this answer | |

The accepted answer is correct and answers the question, but the question addresses a problem that has a different answer than using multiple TCP streams.

The "head of line blocking" problem you are describing is one motivation behind the Quick UDP Internet Connections (QUIC) protocol. I recommend watching this webcast from Google about QUIC if you're interested about how this solves that and other problems.

Of course, there's QUIC on Wikipedia too.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.