My solution to this involved setting up a common DNS name for a central
registry, and then using the surveyor pattern. There are probably lots of
other options available, but if you don’t control DNS you’re going to need
to either do the mDNS thing, or invent a new multicast protocol of your own
for the first phases of service discovery — nanomsg only speaks unicast TCP
for establishing sessions.
On Thu, Feb 11, 2016 at 12:33 PM, Gerard Toonstra <gtoonstra@xxxxxxxxx>
wrote:
If the number of clients are not huge you could look into bonjour or
avahi. Or set up a centralized directory server. Or use a p2p distributed
hash approach, which finds local clients and which is decentralized.
Sent from my iPhone
On Feb 11, 2016, at 17:09, Miao Song <skettysm@xxxxxxxxx> wrote:
Hey, Nanomsg team:
We came across this great Nanomsg, and plan to do distributed
communication based on that in the local network. However, every
nano_connect() or nano_bind() call through tcp needs to provide an endpoint
string url, and the url has to come from somewhere, now how to get the
remote url or broadcast/multicast its local url to the interested peers in
the local network is the key issue.
We wonder Nanomsg has something doing now to support this remote
service/device discovery? There are not so much materials on the network
address this issue, http://hintjens.com/blog:32 is taking the broadcast
based udp solution, but this is tightly bind to Zeromq, and it is broadcast
(we need to use multicast instead, our devices will filter out broadcast
packet). Any pointers are very appreciated. Thanks a lot.
