Under the Hood - TCP/IP Sockets in Java Practical Guide for Programmers - page 107

The final subtlety of closing a TCP connection revolves around the need for the Time-
Wait state. The TCP specification requires that when a connection terminates, at least one of
the sockets persists in the Time-Wait state for a period of time after both closing handshakes
complete. This requirement is motivated by the possibility of messages being delayed in the
network. If both ends' underlying structures go away as soon as both closing handshakes
complete, and a new connection is immediately established between the same pair of socket
addresses, a message from the previous connection, which happened to be delayed in the
network, could arrive just after the new connection is established. Because it would contain
the same source and destination addresses, the old message could be mistaken for a message
belonging to the new connection, and its data might (incorrectly) be delivered to the application.
Unlikely though this scenario may be, TCP employs multiple mechanisms to prevent it,
including the Time-Wait state. The Time-Wait state ensures that every TCP connection ends
with a quiet time, during which no data is sent. The quiet time is supposed to be equal to
twice the maximum amount of time a packet can remain in the network. Thus, by the time a
connection goes away completely (i.e., the socket structure leaves the Time-Wait state and is
deallocated) and clears the way for a new connection between the same pair of addresses, no
messages from the old instance can still be in the network. In practice, the length of the quiet
time is implementation dependent, because there is no real mechanism that limits how long a
packet can be delayed by the network. Values in use range from 4 minutes down to 30 seconds
or even shorter.
The most important consequence of Time-Wait is that as long as the underlying socket
structure exists, no other socket is permitted to be associated with the same local port. In
particular, any attempt to create a Socket instance using that port will throw an IOException .

5.5 Demultiplexing Demystified

The fact that different sockets on the same machine can have the same local address and
port number is implicit in the discussions above. For example, on a machine with only one
IP address, every new Socket instance accept() ed via a ServerSocket will have the same local
port number as the ServerSocket . Clearly the process of deciding to which socket an incoming
packet should be delivered—that is, the demultiplexing process—involves looking at more than
just the packet's destination address and port. Otherwise there could be ambiguity about which
socket an incoming packet is intended for. The process of matching an incoming packet to a
socket is actually the same for both TCP and UDP, and can be summarized by the following
points:

The local port in the socket structure must match the destination port number in the
incoming packet.

Any address fields in the socket structure that contain the wildcard value (*) are consid-
ered to match any value in the corresponding field in the packet.

If there is more than one socket structure that matches an incoming packet for all four
address fields, the one that matches using the fewest wildcards gets the packet.