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 <[email protected]>:
> On Tue, Dec 24, 2013 at 4:21 PM, Michael Haberler <[email protected]> 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
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
