Home / server / Questions / 439936
Accepted
Randomblue
Asked: 2012-10-19 10:26:28 +0800 CST

Parallel TCP sessions for fixed destination and source ports

  • 772

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?

tcp

2 Answers

  1. Best Answer

    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.

    • 5

  2. 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.

    • 0