Patch for adding SO_REUSEPORT socket option

[Lu, Yingqi]

Hi Alan,

Thank you very much for your suggestions. This is my first time contributing to OpenJDK. Really appreciate your help :)

In java.net.StandardSocketOptions, I modify the specification for SO_REUSEPORT as following. Please let me know your feedback. Once we agree on this, we can continue to other JavaDocs. At the meantime, I will modify the tests to use SupportedOptions instead of parsing exception message.

    /**
     * Re-use port.
     *
     * <p> The value of this socket option is a {@code Boolean} that represents
     * whether the option is enabled or disabled. Enabling this option may increase
     * the performance of network server applications running on top of
     * multicore systems. The exact semantics of this socket option are socket
     * type and system dependent.
     *
     * <p> In the case of stream-oriented sockets, this socket option will usually
     * determine whether multiple listening sockets can be bound to the same
     * address and port.
     *
     * <p> For datagram-oriented sockets the socket option is used to allow
     * multiple UDP sockets to be bound to the same address and port. Although
     * SO_REUSEADDR option already enables similar functionality, SO_REUSEPORT
     * prevents port hijacking and distributes the involving datagrams evenly
     * across all of the receiving threads.
     *
     * <p> An implementation allows this socket option to be set before the
     * socket is bound or connected. Changing the value of this socket option
     * after the socket is bound has no effect.
     *
     * @see <a href="https://lwn.net/Articles/542629/"></a>
     * @see ServerSocket#setReusePort
     */

Thanks,
Lucy

From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
Sent: Sunday, November 22, 2015 12:25 AM
To: Lu, Yingqi <yingqi.lu at intel.com>; Kharbas, Kishor <kishor.kharbas at intel.com>; net-dev at openjdk.java.net
Subject: Re: Patch for adding SO_REUSEPORT socket option

On 21/11/2015 02:08, Lu, Yingqi wrote:

Hi Alan,

Please let me know if there is anything we can do at the meantime to help. We are more than happy to help.

Sorry, I wasn't clear. I meant that you will need to work on the javadoc. In many of the classes you've added the following to the spec:

"In case of Windows and Solaris, this function  should throw SocketException with message "Invalid option". In case of Linux with 3.8 and older kernel, this founction should throw SocketException with message "Protocol not available"."

but this is implementation specific, maybe even locale specific too.

So I think it's best to start with java.net.StandardSocketOptions and try to get agreement on how the socket option is specified. You should also get familiar with the API tags to distinguish specification and implementation [1]. Once there is agreement on StandardSocketOptions then the javadoc for the java.net set/get methods should be straight-forward.

For the NetworkChannels (SocketChannel, etc) then you might consider just dropping it from the javadoc. The reason is that these tables are the socket options that are supported by all implementations and this is not the case here. Instead you can leave to the implementation, which is okay because NetworkChannels allow for socket options beyond those listed in the tables. The other thing to be aware of is that setOption/getOption methods are specified to throw UOE when invoked to set/get a socket option that is not supported by the implementation. This will also help with the tests as you will be able to use the supportedOptions method to test if a socket option is supported, no need to parse exception messages.

-Alan.

[1] http://openjdk.java.net/jeps/8068562
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20151122/dbcc6c3f/attachment-0001.html>