RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

Daniel Fuchs daniel.fuchs at oracle.com
Mon Mar 9 18:08:06 UTC 2020


Hi Alan,

On 09/03/2020 17:01, Alan Bateman wrote:
> On 09/03/2020 12:39, Patrick Concannon wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8239355
>> webrev: 
>> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html 
>>
> This is a change to the DatagramChannel implementation. I guess I 
> assumed there would be a DatagramChannel test that checked that 
> getOption(SO_SNDBUF) returned a minimum value for both the IPv4 and IPv6 
> cases.

+1. It's so obvious I didn't think of it when Patrick & I discussed
the test.

> Testing send is a good idea but I'm concerned it is testing 
> DatagramSocket implementation details that are a bit questionable. It's 
> mostly SOCKET_SNDBUF = IPV4_SENDBUF that I'm concerned about because 
> PlainDatagramSocketImpl isn't quite right (it shouldn't set SO_RCVBUF, 
> it shouldn't set SO_SNDBUF if the default is larger, and it's not quite 
> right for the IPv6 case).

Yes - these are known limitations/issues with the current DatagramSocket
implementation on macOS.

> Will the test need further work when 
> DatagramSocket is changed to delegate to a socket adaptor?

Yes the test will need to change, and I believe that's OK.
Patrick already has already a change for that in the
JEP 373 branch.

> Maybe we 
> should change PlainDatagramSocketImpl at the same time?

I would advise against it. I think we should leave the
legacy stack unchanged.

best regards,

-- daniel

> 
> -Alan




More information about the net-dev mailing list