Hi Chris,
On 21/06/2019, 12:32, Chris Hegarty wrote:
Michael,
On 21/06/2019 11:53, Michael McMahon wrote:
Small test case update. The test has failed a couple of times where
it appears
to be receiving input on a multicast socket which could not be
generated by the test case itself.
The test happens to use multicast groups that are assigned by IANA,
and globally routable.
So, it is conceivable that other entities are sending packets picked
up by the test.
The test also does not protect against other instances of itself
running on different hosts
at the same time, though that doesn't seem to be the cause of this
failure.
The change is to use non-routable multicast groups and to add some
hopefully unique data
to the test in case the test might be running on multiple hosts on
the same subnet simultaneously.
http://cr.openjdk.java.net/~michaelm/8219804/webrev.1/index.html
I think this is ok.
With this change, the negative scenarios ( that are expected to
timeout ), are susceptible to retrying when/if rogue packets are
received ( I guess this is less likely now, since the groups are
non-routable ). Would it be helpful to just print out the ignored
packet / data ( in case of future reliability issues )?
Yeah, I'll add some logging for that eventuality.
There is a nio test, java/nio/channels/DatagramChannel/Promiscuous.java
that follows a similar pattern. Should it be updated in a similar way?
I notice that test uses a "reserved" multicast address, which applications
are not supposed to use. Maybe, routers won't forward those packets either.
I think I'd prefer to leave that test as it is, for now, especially
seeing as it
hasn't failed.
Updated at:
http://cr.openjdk.java.net/~michaelm/8219804/webrev.2/
Thanks,
Michael.
