Name: tb29552 Date: 05/12/98


A bug that was posted on April 29, 1998 (id # 4133480) was incorrectly labeld
as a duplicate of an earlier bug (id # 4034633).

The earlier bug addressed the fact that the SO_REUSEADDR option must be
set for multicast sockets. I cannot speak to that bug because I know very
little about multicast sockets.

However, the recent bug does NOT address multicast sockets, rather regular
run of the mill TCP sockets, as implemented in java.net.socket. The problem,
which is serious, is as follows:

If one tries to implement the FTP protocol as defined by RFC 959, one finds
that the default implementation is to have the USER process listen for a data
connection from the SERVER process ON THE SAME PORT that the USER process
is using for the control connection. This means that before the USER process
sends a request (over the control connection) for data to be sent via the data
connection, the user must have a socket listening on the default port (which
is, again, the same port that the control connection is using) for a connection
from the server.

To implement this in java, one must bind a java.net.Socket to some port, and
have a java.net.ServerSocket listening for a data connection from the server
on that same port. In the current API, if one tries to do this, java throws an
address in use exception, which is reasonable behavior, because really, the
address is in use by the socket we bound to the port for the control connection.

In order to be able to set up a server socket to listen on that same port, we
must be able to set the SO_REUSEADDR option on the socket we are using
for the control connection.

That is not possible in the current API. The SO_REUSEADDR option is private
data in the SocketOptions class in the java.net package. Unfortunately, this
class is only visible to the package. There is a function setOption in the
PlainSocketImpl class in java.net, however this class is also only visible at
package level. Moreover, this method (setOption) does not support the
SO_REUSEADDR option to begin with.

It seems to me that this bug should be easy to fix.

It should be said that this is a serious problem as it makes it impossible to
implement the default RFC 959 implementation of FTP in Java. It seems
that Java, which is advertised as having very powerful and easy-to-use
Internet / Networking capabilities, should at least be able to implement
a fully-featured version of FTP.

(Review ID: 30180)
======================================================================