RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'
Alan Bateman
Alan.Bateman at oracle.com
Mon Mar 9 17:01:25 UTC 2020
On 09/03/2020 12:39, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my fix for JDK-8239355 '(dc) Initial value
> of SO_SNDBUF should allow sending large datagrams (macOS)' ?
>
> By default, macOS imposes a size of 9216on Datagrams which limits
> applications that don't set the SO_SNDBUF option - legacy
> DatagramSocket sets the value to 65507 at creation time.
> This fix updates DatagramChannel so that the SO_SNDBUF is set to a
> minimum value of 65527 for IPv6 sockets and 65507 for IPv4 sockets on
> macOS.
>
>
> 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. 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). Will the test need further work when
DatagramSocket is changed to delegate to a socket adaptor? Maybe we
should change PlainDatagramSocketImpl at the same time?
-Alan
More information about the net-dev
mailing list