In my case for 2 servers with RHEL8.1 the NapiId was non-zero for the
DatagramSocket after the 'receive' call.
Output looks like:
Server1 (.154)
# java -Dnapi.mode=server -Dnapi.addr=137.137.101.154 ExtOptionNAPITest
DatagramSocket receive: NapiId=8386
Server2 (.203)
# java -Dnapi.mode=client -Dnapi.addr=137.137.101.154 ExtOptionNAPITest
DatagramSocket send: NapiId=0
The code similar to:
# receive part
DatagramSocket ds = new DatagramSocket(addr);
byte[] buf = new byte[256];
DatagramPacket dp = new DatagramPacket(buf, buf.length);
ds.receive(dp);
sNapiId = ds.getOption(SO_INCOMING_NAPI_ID);
System.out.println("DatagramSocket receive: NapiId=" + sNapiId);
#send part
DatagramSocket ds = new DatagramSocket();
String str = "Hello";
DatagramPacket dp = new DatagramPacket(str.getBytes(),
str.length(), addr);
ds.send(dp);
cNapiId = ds.getOption(SO_INCOMING_NAPI_ID);
System.out.println("DatagramSocket send: NapiId=" + cNapiId);
Thanks, Vladimir
-----Original Message-----
From: Alan Bateman <alan.bate...@oracle.com>
Sent: Thursday, May 7, 2020 11:42 AM
To: Ivanov, Vladimir A <vladimir.a.iva...@intel.com>; OpenJDK Network Dev list
<net-dev@openjdk.java.net>
Subject: Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support
On 07/05/2020 17:53, Ivanov, Vladimir A wrote:
> Thanks.
> The Javadoc was updated:
> http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.09/
> Also test was updated. Now it have no client/server architecture but looks
> more easy to maintain.
>
Do you have any update on UDP sockets? I haven't found a system where
SO_INCOMING_NAPI_ID is non-0 after receiving a datagram. I'm just wondering if
we need to tweak the javadoc to specify it only for connected streams sockets
and put in some wording that it may or may not be supported for datagram
sockets.
-Alan
