Java documentation says that a ServerSocket, x, that is listening on, say, port 5555 returns a new Socket, y, from its accept() method such that:
-
the local port of
yis set to5555; and -
xcontinues to listen on port5555toaccept()new connections.
I have verified that the above is indeed the case.
However, this wikipedia entry on Port has this to say:
This process is known as listening and involves the receipt of a
request on the well-known port and reestablishing one-to-one
server-client communications on another private port, so that other
clients may also contact the well-known service port.
To me, the above wikipedia excerpt tends to make more sense… since from what I’ve read and understood about TCP/IP,
-
the destination IP address helps deliver the packet to the right host; and
-
the destination port helps deliver the packet to the right process on the destination host
Thus, the given the documentation and behavior of accept() in Java, I’m wondering how could packet delivery be possibly achieved in case of a multithreaded client attempting to talk to a multithreaded server (by opening two communication channels, one in each thread)? In such a case, how would Java (or, the underlying TCP/IP stack) know which packet belongs to which channel when all packets would have the same destination IP address and port values set?
EDIT: Please see EJP’s response and also Nikolai’s comment below. According to them, the above wikipedia claim was wrong. EJP went ahead and fixed the wikipedia entry.
The listening socket is special. The kernel delivers to it only those TCP segments that are part of the three-way handshake, which have explicit flags in the header. Once that completes you have an established TCP connection that is identified by a full tuple
(src addr, src port, dst addr, dst port).Thus there’s no ambiguity inside the network stack between listening and connected socket bound to the same local port.
It might also help to study the TCP state diagram to get a better mental picture of how all this comes together.