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?
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 callconnect(). The kernel will make sure to pick a different source port for the second connection.