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

[Daniel Fuchs]

Hi Alan,

On 11/03/2020 12:08, Alan Bateman wrote:
>> Do we really? I am not sure we do.
>> We just want to verify that we don't get the "packet too large"
>> exception caused by the SO_SNDBUF buffer being too small.
> It would be great if we had a test to send large datagrams on the 
> network as that is the only way to properly test that they can be 
> re-assembled and received. I don't mind if it's a separate test, I agree 
> it can be tricky on systems that have unusual configurations. I'm just 
> pointing out that testing that the send doesn't fail and that the 
> datagram can be received through the loopback may not be enough here.
Our test doesn't even try to receive the datagram. It just sends it.
We can write a new test that does the full roundtrip if you think
it's worthwile.

>> Yes and no - and the test is there to verify that it doesn't have any
>> unexpected side effects (we know it shouldn't).
> My preference would be to drop these so the test only runs twice. The 
> reason is that the effect of setting java.net.preferIPv6Addresses is not 
> widely known and it will confuse anyone that needs to maintain this test 
> in the future.

OK - then we can remove the preferIPv6Addresses property and replace:

  114         populateDataProvider(testcases, datagramChannel, MAX_PAYLOAD,
  117                 null);

with

       if (hasIPv4())
           populateDataProvider(testcases, datagramChannel, IPV4_SNDBUF,
                      StandardProtocolFamily.INET);
       if (hasIPv6() && !preferIPv4Stack())
           populateDataProvider(testcases, datagramChannel, IPV6_SNDBUF,
                      StandardProtocolFamily.INET6);


to verify that the channel opened with the no-arg DatagramChannel.open()
can be used to send both IPv4 and IPv6 datagrams.

cheers,

-- daniel