Fwd: a socket impl question?

[Sand Stone]

Fwd to net-dev per Alan's suggestion.

My primary interest to see if there is a way without JNI to enable
fast_path on Win2012 sever. It does not look possible at the moment.

Also if there is a clean/simple way to bind to the underlying OS ioctl more
directly, that would be groovy.

====
Alan Bateman
12:23 PM (44 minutes ago)
to me, Chris, jdk7u-dev
On 13/01/2013 09:46, Sand Stone wrote:

>     2. Or provide a code path to allow framework builders to set OS
> specific
> custom socket options? This could be a general mechanism without JDK
> changes.
>
> The support that is there is intended to allow implementations support
socket options beyond those defined by the Java SE spec, it's not intended
to allow someone using the API to pass in arbitrary values that the
implementation uses without mapping.

I would suggest following up on net-dev (as jdk7u-dev is for discussions
about the jdk7u releases).


-Alan.
---------- Forwarded message ----------
From: Sand Stone <sand.m.stone at gmail.com>
Date: Sun, Jan 13, 2013 at 1:46 AM
Subject: Re: a socket impl question?
To: Chris Hegarty <chris.hegarty at oracle.com>
Cc: jdk7u-dev at openjdk.java.net


Thanks for the quick reply, Chris.

Some clarification. Currently I am trying to set non std socket options at
a per Socket instance basis without going through JNI code.  And I take the
statement on Linux back, one could not pass down unknown option value down
at the socket fd level either (the exceptions are different between Windows
and Linux).

Take a specific case, Windows added fast path in the loopback path:

http://blogs.technet.com/b/wincat/archive/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path.aspx
One could see in the article that .NET/CLR supports custom option flags.
Also note that the setting has to be done prior to any actual binding.

A couple of questions:
   1. Is there a plan to support this new ioctl flag for Windows? This will
improve (by 4x) many existing Java based solutions doing LRPC on Windows.
   2. Or provide a code path to allow framework builders to set OS specific
custom socket options? This could be a general mechanism without JDK
changes.
   3. Ideally getting solutions for one of the above backed ported to JDK6
and JDK7.

Doing a custom JNI is a viable option (though one has to trick the current
JDK7 code to create a "fd" without the actual binding, because just "new
Socket()" does not materialize a "fd" until later). It's a pain to
distribute and maintain the native code plus related reflection code.


On Sun, Jan 13, 2013 at 12:22 AM, Chris Hegarty <chris.hegarty at oracle.com>wrote:

> On 12/01/2013 23:20, Sand Stone wrote:
>
>> Hi, JDK devs.
>>
>> Is there a reason the impl not there below?
>>
>
> This is a bug, fixed in jdk8, 7107020: "java.net.PlainSocketImpl.**socketSetOption()
> calls itself"
>
> This bug did not create a much of a problem since setOption() is usually
> called for setting socket options.
>
>
>  jdk/src/windows/classes/java/**net/PlainSocketImpl.java
>>
>>      public void setOption(int opt, Object val) throws SocketException {
>>          setOption(opt, val);   // Why not impl.setOption(opt, val);?
>>      }
>>
>>      public Object getOption(int opt) throws SocketException {
>>          return impl.getOption(opt);
>>      }
>>
>> More generally, is there a general way to pass a non
>> StandardSocketOptions option
>> the down to the socket fd without having to go through the JNI path on
>> Windows?
>>
>
> Not that I am aware of.
>
>
>  Note that on Linux at least the option can be passed directly to the
>> built-in C native path.
>>
>
> Sorry, I don't get this.
>
> -Chris.
>
>
>> Thanks much!
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130113/60f3140c/attachment.html