-
Notifications
You must be signed in to change notification settings - Fork 22
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
Broadcast discovery of servers on a local network #12
Comments
@cjcliffe If you feel like giving this a shot, try this branch: https:/pothosware/SoapyRemote/commits/ssdp_work It works, but its not well tested. We will have to see how portable the multicast code ends up being across platforms. |
Here is an interesting quirk of SSDP (at least in my mind). So we have this system where anyone should be able to open a UDP socket, join the multi-cast group and discover and share information. But the service provider replies to the MSEARCH queries through unicast UDP. So when you have multiple processes on the same host, only one of them is going to actually receive the unicast response, and its not always going to be the one that sent the multicast MSEARCH request. That's not a problem when a host only runs one instance of the SSDP service, and there are some platform specific means to query from the deamon/service what network services have been discovered. But for this use case, I want the SoapyRemote implementation to be portable, so it must talk to a socket and not a platform-specific interface. Also, I want localhost clients to be able to discover localhost servers. Or even multiple of such clients. For reference, here is another with the same problem: https://stackoverflow.com/questions/12794761/upnp-multicast-missing-answers-from-m-search-discovery The work-a-round of using a different port would not fix the multiple processes issue. It basically makes its own domain-specific multi-cast group separate from the other SSDP traffic, which would also be technically OK for SoapyRemote. Anyway, my workaround for this issue was to simply respond to MSEARCH with multicast. The usual unicast MSEARCH response is still sent. In addition, the server responds with a multicast NOTIFY packet. NOTIFY packets are part of the specification, and this way the client always gets notified ASAP, one way or the other. Triggering a NOTIFY from an MSEARCH may or may not be typical, but judging from my local network (with wireshark), NOTIFY packets are like a forest full of birds in spring all trying to get their mating calls heard. |
OSX Update
|
Will try this out here on OSX this weekend -- should be able to get a couple systems on the network and see how it goes. |
@cjcliffe Let me know if you get the IPV6_JOIN_GROUP error as well. Its harmless, it just means the ipv6 part of the service doesn't run. You are welcome to mess around with sockets. But more to the point, if every every apple is going to dump an error here, I will just ifdef out the ipv6 multicast for osx. To test it, just run |
merged. We will just have to see what errors come up. |
@guruofquality aye; haven't had a chance to spin it up here yet been battling some CubicSDR crashes and gain updates :) |
No problem. I tested enough so that things should be safe to use -- worst case, the feature doesn't work. And I did some tweaks to the error reporting so that any failures wouldn’t look obnoxious. |
Relevant comments about the OSX IPv6 issue, it may not support the automatic interface (ipv6mr_interface = 0): syncthing/syncthing#1563 |
This was the work-around, basically logic to automatically select an interface thats up, not loopback, and supports multicast: 43a5bef So everything seems to be working as far as I can test. Closing off. |
awesome work, actually building on Raspberry Pi for testing some remote stuff at the moment; will be trying discovery soon |
Multicast discovery means that the device enumeration routine can discover devices without an explicit addresses specified.
https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
The text was updated successfully, but these errors were encountered: