Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multicast recv sends to any open socket with a matching port #644

Open
dsgruss opened this issue Jul 28, 2022 · 0 comments
Open

Multicast recv sends to any open socket with a matching port #644

dsgruss opened this issue Jul 28, 2022 · 0 comments

Comments

@dsgruss
Copy link

dsgruss commented Jul 28, 2022

Currently, a UDP socket seems to accept any received multicast broadcast that is (1) in the list of multicast addresses on the interface and (2) has an open socket with a matching port (socket/udp.rs:373). Moreover, each incoming packet is given to the first socket that accepts it (iface/interface.rs:2489).

As a result, a client is unable to join two different multicast streams on separate addresses that share the same port. One can use a single socket to receive all the packets from each stream combined and then filter them on the client side, but the recv function only returns the IpEndpoint of the host that sent the packet and not the multicast address that the packet was sent to.

The way this works in the standard library, socket2, and most other socket apis is that the multicast group join is done as a socket-level option, rather than on the interface as a whole. Then the OS handles the group memberships across all of the sockets and makes sure that each socket that has joined the group gets a copy of the data.

I was able to hack around this in my own fork by removing the is_multicast check in udp.rs and then bind-ing the socket to the multicast address itself to at least get the packets filtered to the right sockets.

Let me know if this is expected/wanted behavior and I just fell into a weird use case. I'd be willing to put together a PR with a more comprehensive fix if there is interest. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant