using `pnet` may break builds

[rlidwka]

This is what I have on windows after cargo update to RustDDS 0.11.5:

  = note: LINK : fatal error LNK1181: cannot open input file 'Packet.lib'

Turns out, pnet (and, in turn, RustDDS now) has some additional requirements that weren't there before:
https://github.com/libpnet/libpnet?tab=readme-ov-file#windows

Question: why is that library needed, and can it be turned off (i.e. be an optional dependency)?

[jhelovuo]

This library was added due to some improvements contributed by @onkoe . The stated purpose of using pnet is to portably detect multicast-capable IP network interfaces.

Please see commits 28d8ad2 and d703718 for all the details.

Yes, it could be made optional, and possibly even dropped completely, if someone comes up with a way to do the interface detection without it. Can you suggest a better way? Or even make a PR?

We currently test on Linux and MacOS, but contributions to improve Windows support are welcome.

[onkoe]

I'm sorry for the difficulties here!

pnet automates the (annoying) task of collecting helpful information from network interfaces. I didn't look at their GitHub README - only their lib.rs docs - but on GitHub, they note some pretty strong requirements for Windows compilation.

In my view, a default multicast_detection feature with a new semver bump could address this appropriately, though it's unfortunate that Windows wouldn't havr support. Preferably, there'd be some specific Windows-oriented crate for support there, too!

It's also odd for a DDS implementation to feature-flag multicast support, which is generally configured at runtime, if at all.

Still, spinning this yourself doesn't seem fun, and I didn't see any well-established alternatives for this purpose. If you're aware of one, please let me know - I'm happy to migrate with quick PR.

For now, yanking 0.11.5 for an identical 0.12.0 release would address the semantic versioning concerns. My apologies for any difficulties you faced from my changes.

[jhelovuo]

It's also odd for a DDS implementation to feature-flag multicast support, which is generally configured at runtime, if at all.

The only standard-specified, and therefore interoperable, Discovery method between DDS implementations is the SPDP and SEDP protocols from the RTPS specification. In order for them to work without address configuration beforehand, they need multicast. That is why multicast should be included and be enabled by default.

It is plausible to make it configurable, e.g. to turn it off completely, but not as a default.

[carlocorradini]

Same issue 😥