Re: RFR[8242885]: 'PlainDatagramSocketImpl doesn’t allow for the sending of IPv6 datagrams on macOS with sizes between 65508-65527 bytes'

[Alan Bateman]

On 08/05/2020 14:43, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my fix for JDK-8242885 
> 'PlainDatagramSocketImpl doesn’t allow for the sending of IPv6 
> datagrams on macOS with sizes between 65508-65527 bytes'?
>
> This fix changes the current max size for IPv6 datagrams on macOS from 
> it's current size of 65507, which is the IPv4 limit, to65527, the 
> actual limit for IPv6 on macOS. This will get around the issue of not 
> being able to send datagrams with sizes between65508-65527 bytes.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8242885
> webrev: http://cr.openjdk.java.net/~pconcannon/8242885/webrevs/webrev.00/
Given that PDSI will not be used by default then I think this minimal 
fix is okay. If PDSI were to remain the default then the right thing 
would be to check the initial value of SO_SNDBUF first so that this code 
doesn't reduce the size when it has been configured to a larger value 
(with sysctl). The code to change SO_RCVBUF would also be removed.

You added SetGetSendBufferSize.java recently to test the 
set/getSendBufferSize methods. The test in this webrev overlaps a bit. 
Does testInitialSendBufferSize go away or change to test the limit when 
the socket is IPv6?

In the new test, sendLargeDatagram sends large datagrams through the 
loopback but it doesn't check that they can be received. I think an 
end-to-end test would be more useful.  I don't know if there is any 
equivalent of fragmentation when sending large datagrams through the 
loopback interface on macOS. I think we will only have confidence with 
an end-to-end test if it sends it on the network (not the loopback).

-Alan