[zeromq-dev] service discovery - problem description (was: Re: Poll on sockets OR child process)

[Michael Haberler]

Am 25.12.2013 um 14:16 schrieb Pieter Hintjens <ph at imatix.com>:

> On Wed, Dec 25, 2013 at 1:44 PM, Michael Haberler <mail17 at mah.priv.at> wrote:
> 
>> rationale for the UDP unicast send/receive pattern:
>> my application scenario:
>> This suggests a 'query broadcast', followed by 'reply unicast' sequence is the 'minimal noise' solution; there is no need for permanent broadcasting of service descriptions ala zbeacon.
> 
> OK, thanks for explaining this, it's clear. It's the same use case I
> addressed in my old UDP virtual transport for ZMQ (the VTX project).
> Broadcast request, unicast reply. The challenge is that UDP replies
> can get easily lost.
> 
> If we had a udp:// transport, this would fit to a pub-sub (subscribe
> to multicast address, send to multicast address) plus a request-reply
> (acknowledged reply). As it is we can make this using a mix of zbeacon
> for requests, and UDP unicast + retries for replies.
> 
> My proposal is to hide the fact we don't have a udp:// transport, and
> build a zservice class that provides explicit service announcement and
> discovery. Eventually we can expand this to other transports.
> 
> zservice would build on zbeacon, though it has a different use case,
> and we can make this clear in the man pages. Beaconing is for dynamic
> networks where discovery is the same problem as presence, solved by
> heartbeating, and where TCP heartbeating does not scale. Service
> discovery is for more static networks where multiple hosts may provide
> a service.
> 
> If you like this, I'll build a skeleton for zservice and see if the
> metaphor holds.

It would indeed cover my paltry needs

if we can get away without an API change once the UDP transport is slid in underneath that'd be really cool!


- Michael


> 
> What do you think?
> 
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev