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