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

[Michael Haberler]

rationale for the UDP unicast send/receive pattern:


my application scenario:

- several services exported by potentially several hosts, using several different protocols (socket type/message patterns)
- clients need to connect to several service processes

to avoid pre-configuring URI's and hence configuration information over several hosts, use DHCP-style discovery:

- a client broadcasts a service probe, specifying the service description(s) ({protocol, version, service_id} tuples)
- server processes listen for these broadcasts, and reply with one or several service descriptions, including the IP address and portnumbers of sockets
- clients retry probe broadcasts until all required services discovered, or a timeout elapsed
- security is handled at the per-socket level during connect

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. 

- Michael

Am 25.12.2013 um 10:41 schrieb Pieter Hintjens <ph at imatix.com>:

> On Tue, Dec 24, 2013 at 4:21 PM, Michael Haberler <mail17 at mah.priv.at> wrote:
> 
>> no, let's have that sit a while until Pieter's latest changes shake out a bit, and wrap those eventually
> 
> Speaking of this, is there a description of the problem you were
> aiming to solve? I didn't see that anywhere. From the code it seems
> you were doing a request-reply over UDP. It's unclear to me why, and
> why this would not work e.g. over tcp://.
> 
> As a general rule (and it's actually part of our process), it is
> necessary to explain the problem driving a change, either in a
> separate issue or in the pull request itself. That's how we can judge
> different solutions. Without a stated rationale, the code is almost by
> definition wrong. (The rationale may be obvious, but here it's not.)
> 
> Cheers
> Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev