Hi Michael, Chris,
a brief note on the possibility of stray packets.
For the test to receive data from external sources it would be necessary that
the senders are
using the same port ( as well as the mcast address) as your test (which is an
ephemeral port).
So the source of such stray data could be concurrently executing instances of
the tests
on other test machines when each test's ephemeral port coincidentally match !!
However, the fact that you are repairing a NumberformatException would indicate
that the source
was not another instance of this test, as the test would receive a string
representation of an integer.
However, Chris alludes to /test/java/nio/channels/DatagramChannel/Promiscuous,
and
this uses the same mcast address (pre your changes) as this test and its
integer data would not be interpretable by this test, afaik.
So it is the source of possible conflict and a NumberFormatException. --
depending on the same ephemeral port allocation taking place.
Should the test check that multicast is enabled on the test host?
the sender's address could always be output in the receive method ?
as a side issue:
Noting the idioms used in the test binding to wildcard address for the
receiving socket
so the test is open to receiving data on any address associated with the test
host, that is
destined to the ephemeral port allocated. The ephemeral port limits receipt of
stay data but
doesn't eliminates it. The alternative is to bind to mcast address.
Sender Datagram socket is unbound, so will send on the default interface (?)
What's the expectation when the test executes in multihomed environment?
This has been a problem for tests in the past (in my limited experience),
especially the
sending over the correct interface.
Is the assumption that if the test host is multihomed, then the appropriate OS
configuration for sending/receiving on the multicast exists, such that the send
will
go over an interface configured for your chosen mcast address?
That is to say, the sender will send on the appropriate interface
for the specified multicast address in a multihomed scenario.
It's assumed the default interface is multicast enabled
and that interface has a route specified.
maybe a few things to consider.
regards
Mark
________________________________
From: net-dev <net-dev-boun...@openjdk.java.net> on behalf of Michael McMahon
<michael.x.mcma...@oracle.com>
Sent: Friday 21 June 2019 16:27
To: Chris Hegarty
Cc: OpenJDK Network Dev list
Subject: Re: RFR: 8219804 ava/net/MulticastSocket/Promiscuous.java fails
intermittently due to NumberFormatException
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.
