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