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
