[zeromq-dev] Comment on ZRE spec flaw

[Pieter Hintjens]

On Sat, Feb 23, 2013 at 11:56 AM, Bjorn Reese <breese at mail1.stofanet.dk> wrote:

>>> Not true on WiFi.
> Can you elaborate?

What I meant to say was that piggy-backing more information into the
UDP message would make it larger; there's no wasted space in a 802.11
frame. So unless there's a real overhead for separate frames, it won't
change anything to coalesce beacons.

TBH even on a stressed WiFi network the UDP beaconing isn't an
overhead. What is deadly is TCP heartbeating, which is why ZRE doesn't
do that except as a last resort when a node seems to have vanished.

> A more important issue is that if you intend this discovery protocol to
> be used by other 0MQ project than Zyre, then we need the ability to add
> meta-data (attributes/properties) to the beacons.

ZRE does this in the HELLO message of a new connection (key/value
pairs), which is simple and optimal. Enlarging beacons is a mistake
IMO. It's especially bad on WiFi where every byte you send has a cost.

However I've moved the code itself into CZMQ:
http://czmq.zeromq.org/manual:zbeacon so its easy to build your own
discovery protocols with whatever you like in the beacons.

> Also consider introducing a type field into the beacons. For instance,
> one for appearance, another for disapparance, and possibly one for
> querying the neighbourhood (like the SSDP M-SEARCH).
>
> Oh, and perhaps a protocol/service identifier too. This can be used to
> distinguish if the peer supports Zyre or something else.

I do appreciate the feedback but I'm not even sure how to discuss your
proposals without a clear understanding of the problems they're
addressing (which may or may not be present in our use cases).

E.g. you propose to coalesce beacons, presumably to save network
capacity, but you then propose to add key-value meta data to the
beacon, which would make beacons far larger. Either network capacity
is an issue, or it's not.

If you could point to specific problems with the current design and/or
implementation, we can usefully discuss how to fix these problems. But
a list of suggestions of things to change seems not very useful in
itself.

Cheers
Pieter