When you set this option prior to connecting an outbound java.net.Socket, it has special semantics for TCP. W.R. Steven's book gives the semantics as different from what is described in the Javadoc:
SO_REUSEADDR: Allows the process to bind a port number that is already in use, but the IP address being bound (including the wildcard) must not already be bound to that port. For example, if an attached interface has the IP address 140.242.1.29 then one socket can be bound to 140.252.1.29, port 555; another socket can be bound to 127.0.0.1, port 555; and another socket can be bound to the wildcard address, port 5555.
[Stevens & Wright, TCP/IP Illustrated, Vol II, p. 720]
Specifically, setReuseAddress()/SO_REUSEADDR when applied to a Socket doesn't permit you to reuse the same outbound local port number while it is still in TIME_WAIT state. This is in contradistinction with its behaviour on a ServerSocket, where it allows you to start listening on a pport which currently has instances in the TIME_WAIT state left over from previously accepted connections from the previous instance of the ServerSocket.
This to preserve of the semantics of TIME_WAIT. This state is there as part of TCP/IP's delivery guarantee semantics, which say that you will receive exactly and only the TCP segments destined for the current connection. If TCP/IP allowed immediate re-use of an outbound port number which is in TIME_WAIT state, segments arriving for the old connection could be delivered to the new connection, which would violate this guarantee.
See the discussion in the Java Networking Forum for a fuller discussion.
|
Books
FAQs
