Closed icorderi closed 7 years ago
@GGist
As of right now,
I'm still not sure about keeping:
#[cfg(not(linux))]
fn listen_any_on_port(port: u16) -> SSDPResult<SSDPReceiver<Self::Message>> {
Self::listen_on_port(port)
}
Having it fallback to listening on interfaces that are present at that moment is a bit misleading.
It would be nice to figure out why macOS is rejecting interface 0
.
If you can verify it works on Windows we can change the code to be flagged as #[cfg(not(macos))]
until we figure out how to make it work on it.
The first couple commits are on PR #36
@icorderi I agree that it is a bit confusing, though I also agree that this functionality is valuable.
I can confirm on Windows that joining with interface 0 will not work as intended as Windows will just join on the default interface if passed 0. The last time interface 0 came up in a previous PR I could not find out any way to achieve Linux like behavior for interface 0 on Windows.
The code looks good. Go ahead and remove this bit:
// Is is possible that binding on interface 0 works on the ipv6 stack in windows
// I have not tested it
And I'll merge it in.
Thanks!
On second thought, I think we should go ahead and just remove listen_any_on_port
for non Linux platforms.
@GGist, removed the non-linux platform bits
Thanks!
Some deployments require us to be able able continue listening even when the interfaces available change underneath us.
To do so, we must join a multicast group on any interface.