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

[Daniel Fuchs]

Hi Alan,

On 10/03/2020 19:59, Alan Bateman wrote:
> On 10/03/2020 18:32, Patrick Concannon wrote:
>>> http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.02
>>
> Thanks for adding a test for getOption(SO_SNDBUF). That test 
> (testGetOption) should be checking that SO_SNDBUF is >= expected value  
> as it's okay for net.inet.udp.maxdgram to have a larger than what the 
> test expects.

+1

> testSend sends to the loopback address but I think we need this test to 
> send datagrams on the network (sending to the loopback is okay too but I 
> think you want this test to send a datagram on the network because we 
> want fragmentation on the network(.

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.
In other words, we want to check that setting SO_SNDBUF was
effective and that it was really passed to the underlying
system stack and taken into account.
But maybe you have a different scenario in mind?

Using the loopback is also expedient because a machine that has IPv6
might not have an IPv6 external address configured, but it should have
an IPv6 loopback (::1) always. I assume we could loop over the network
interfaces and try to find one that has an IPv6 address configured which
is not the loopback - but that complicates the test. We can do it
if there's a strong reason to do it (we don't want to test that the
network itself actually supports ~64k datagrams, we just want to test
that we would be able to send them if it supported it?)

> The java.net.preferIPv6Addresses system property is about configuring 
> the order of name service lookup. These runs shouldn't impact anything 
> here, dual and preferIPv4Stack=true should be all that is needed.

Yes and no - and the test is there to verify that it doesn't have any
unexpected side effects (we know it shouldn't).

> A minor nit is that we should probably find a name for the test that is 
> consistent with the other tests in this area. Something like 
> LargeDatagram or MinSendBufferSize is okay.

+1

best regards,

-- daniel
> 
> -Alan