[zeromq-dev] Comment on ZRE spec flaw

Pieter Hintjens ph at imatix.com
Thu Feb 21 16:07:33 CET 2013


On Thu, Feb 21, 2013 at 3:47 PM, Pieter Hintjens <ph at imatix.com> wrote:
> On Thu, Feb 21, 2013 at 10:31 AM, Bjorn Reese <breese at mail1.stofanet.dk> wrote:
>
>> If the beacon not only contains information about the sending node, but
>> also the peers that the sender is aware of, then those peers do not
>> need to broadcast themselves, thus saving network traffic.

How does peer A know that peer B is going to beacon for it? What's the
cost of setting this coordination up in terms of complexity and
network overhead and what savings do you make?

These aren't arbitrary questions. On WiFi, which is ZRE's main target,
over-complex discovery is toxic. The main response of an access point
to excess load is to simply drop clients. Meaning, the cost of joining
a network, and the simplicity of this protocol is key to a usable
application.

-Pieter

On Thu, Feb 21, 2013 at 3:47 PM, Pieter Hintjens <ph at imatix.com> wrote:
> On Thu, Feb 21, 2013 at 10:31 AM, Bjorn Reese <breese at mail1.stofanet.dk> wrote:
>
>> If the beacon not only contains information about the sending node, but
>> also the peers that the sender is aware of, then those peers do not
>> need to broadcast themselves, thus saving network traffic.
>
> Not true on WiFi.
>
>> PS: What is the rationale for creating the Zyre discovery protocol
>> rather than reusing one of the existing discovery protocols (ZeroConf,
>> SSDP, SLP, etc.) ?
>
> Over-complex for the most part, unsuitable for WiFi in other cases,
> and none are designed to carry a 0MQ network. But I'm happy to be
> proven wrong here; if you can show me a simpler and more effective
> discovery for WiFi networks that supports Zyre, that'd be great.
>
> -Pieter



More information about the zeromq-dev mailing list