Sorry, I misread your explanation. The broadcast/reply use case is a good one. I've implemented that before in the VTX UDP transport (an early extension to ZeroMQ that was never put into the main line).
zbeacon is one option but I think a better design would be a libzmq udp:// transport, where this use case is then pub-sub on top of that. zbeacon itself should be refactored to use a UDP transport if/when we make that. -Pieter On Wed, Nov 27, 2013 at 12:52 PM, Pieter Hintjens <[email protected]> wrote: > The problem with sending a single UDP message is that there's a fair > chance of it getting lost. > > On Wed, Nov 27, 2013 at 12:24 PM, Bjorn Reese <[email protected]> > wrote: >> On 11/27/2013 12:03 PM, Michael Haberler wrote: >> >>> an application looking for services would broadcast (a) request(s) for the >>> services needed, and entities with matching services would reply with an >>> answer directed to the source IP address (i.e. non-broadcast); repeat until >>> all needed services acquired. >> >> This sounds like a good idea. >> >> Pieter mentions in his blog that zbeacon can be used to talk to existing >> UDP-based discovery services. With your addition, this possibility >> becomes real, because you have basically described how SSDP M-SEARCH >> works. >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
