Hi Mark
On 23/06/2019, 13:53, mark sheppard wrote:
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 !!
That's correct. The sender needs to send to the same port, and the port
is essentially random,
though the range is far from unlimited, and the test has only failed a
couple of times
in many thousands of runs.
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.
Right, I did say the cause was not likely the same test, because the
test is reading 100 zero bytes.
I just added that protection as an additional measure.
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?
Doesn't seem to be necessary as the test is receiving something.
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.
Since the socket is receiving something unexpected, I think I agree that
binding
to the multicast address could be worth doing as well. That would filter out
packets that perhaps broadcast or just sent directly to the bound port,
independent
of the multicast group. I will try out that suggestion and if it works okay,
I'll include it in the change.
Thanks
Michael
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
<http://cr.openjdk.java.net/%7Emichaelm/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/
<http://cr.openjdk.java.net/%7Emichaelm/8219804/webrev.2/>
Thanks,
Michael.
