SIO_LOOPBACK_FAST_PATH must be set on the socket passed to accept.

The way I think about this is the socket instance passed to listen represents 
the port while the socket instance passed to accept represents a single TCP 
stream. SIO_LOOPBACK_FAST_PATH has no effect when applied to a port, but does 
have an effect when applied to a TCP stream.

Given that we are open to suggestions for a better organization of the code to 
set SIO_LOOPBACK_FAST_PATH on the sockets passed to accept.

Thanks,
Kirk

Software Design Engineer
Microsoft Open Technologies, Inc.

MS Open Tech is hiring (http://aka.ms/msopentechjobs)!
Ask me for details if anyone you know is interested.

From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Wednesday, September 24, 2014 12:51 AM
To: Martin Sawicki (MS OPEN TECH); net-dev@openjdk.java.net
Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH); nio-dev
Subject: Re: Taking advantage of TCP Loopback fast path in Windows

On 24/09/2014 02:19, Martin Sawicki (MS OPEN TECH) wrote:
Hello
We're proposing an improvement to the OpenJDK which enables users to take 
advantage of the TCP loopback fast path mechanism in Windows for significantly 
higher performance of sockets whose both end points are on the same machine.  
This is especially relevant in distributed server-side/cloud scenarios, such as 
Hadoop.

We have the code figured out and tested internally. I've uploaded our webrev 
package here (too big to send as an attachment):

https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20140918.zip

The crux of the change lies in enabling the SIO_LOOPBACK_FAST_PATH IOCTL flag 
on each socket creation call in Windows.

As for activating this optimization, we're proposing the conservative approach 
of keeping it off by default and adding a command line argument to activate it:
-Dwindows.enableFastLocalTcpLoopback=true | false

(IMHO though, it'd be great to eventually just have it on by default).

We'd appreciate a review and acceptance of this improvement.

And, as we are new in the OpenJDK community and this may as well be our first 
contribution to Java, I apologize for any steps in the submission process that 
I may have missed here and would appreciate guidance as needed.

Welcome, it's good to see Microsoft engineers on OpenJDK lists.

If I understand this ioctl correctly then it should only need to be set once on 
a SOCKET. I'm curious about the listener oriented channels (ServerSocketChannel 
etc.) where it is being set prior to each call to accept. Is this needed? If 
not then I assume that we can just set it when creating the SOCKET, 
sun.nio.ch.Net.socket0 of SocketChannel, ServerSocketChannel, etc. You'll see 
that it already goes some Windows specific setup and that might be the place to 
put it (and I think should eliminate the need for most of the changes to the 
NIO code).

-Alan

Reply via email to