[zeromq-dev] RFC: zbeacon for dhcp-style discovery
mail17 at mah.priv.at
Wed Nov 27 13:52:08 CET 2013
Am 27.11.2013 um 13:11 schrieb Pieter Hintjens <ph at imatix.com>:
> 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.
sounds reasonable but a new transport is a bit above my paygrade for the scope I had in mind; happy to migrate once that exists
I'm semi-done with the czmq/zbeacon_send() code - should I still go ahead with it?
if yes, I'd appreciate a hint how to properly reference tcp_address_t::resolve_hostname() in czmq - seems this is for libzmq-internal use only?
> On Wed, Nov 27, 2013 at 12:52 PM, Pieter Hintjens <ph at imatix.com> 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 <breese at mail1.stofanet.dk> 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
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev