Closed holgerfriedrich closed 11 months ago
It's a regression, it was implemented with MulticastSocket
which always returns an interface; now with using a datagram channel it doesn't if not specifically set.
One could also assign Net.defaultNetif
in ReceiverLoop
ctor if the netif is null. I am not sure how important the old behavior is; one advantage might be that a user doesn't have to null check netif in Result
.
Looking at the code, I converted Result
to a record and fixed this issue at the same time.
As a side note, using startSearch(netif, timeout, wait)
with netif null
is mainly either for a host with a (stable) single interface (i.e., the default netif and routing table is straight forward), or if you specifically rely on the routing table. In case of discovery with unicast responses, this also requires an appropriate config of the localhost setting. So I would in general use startSearch(timeout, wait)
which checks all usable interfaces.
@bmalinowsky thanks for the hint. I had implemented iterating over all network interfaces in the meantime to get it running with 2.5.1 release. Somehow I have overlooked the method startSearch
with only 2 parameters. That's much cleaner now.
Regarding the PR - as you have fixed the root cause, this PR seems no longer necessary. Closing. And thanks for looking into it.
The following code should work - if I read the javadoc correctly:
However,
toString()
fails withand during detection I see
Both is fixed by more restrictive null checks.
Or did I get the usage instructions wrong and a network interface should be supplied?