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

[Pieter Hintjens]

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.

What do you think?

-Pieter