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
