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.st...@gmail.com> Date: Sun, Jan 13, 2013 at 1:46 AM Subject: Re: a socket impl question? To: Chris Hegarty <chris.hega...@oracle.com> Cc: jdk7u-...@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.hega...@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! >> >
