[zeromq-dev] Comment on ZRE spec flaw

[Bjorn Reese]

On 2013-02-21 16:07, Pieter Hintjens wrote:

> 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?

There is no need for explicit coordination. Everything can be handled
using local rules.

Initially B does not know anything about A and vice versa. A will beacon
about itself, and B will beacon about itself. Afterwards they know each
other. Peer A does not know in advance that peer B is going to beacon
for it, and it does not need to. Instead, when A beacons about itself,
it includes information about B. B notices that the beacon from A
contains information about B, and B may therefore omit its own beacon
since everybody has just been informed about its presence. If B decides
to beacon about itself anyways, then that is just fine (this is just a
missed optimization opportunity.)

What is left, is to figure out how to detect that B has disappeared, as
A is beaconing on its behalf.

There are several possibilities:

1. Specify that A can only beacon about B within a given time period or
    N number of beacons.

2. Introduce a disappearance beacon. If peer C wants to use B, C will
    detect that B has gone (this is a normal scenario under any
    circumstances), and can therefore beacon a "B has gone" event. Such
    an event is also useful for B to beacon if it is about to shut down.

3. Zyre already has a heartbeat mechanism (or at least it is referred
    to in the "Interconnect Model" section) and once A detects the
    disappearance of B, it will omit it from its beacons.

>>> 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.

Can you elaborate?

The idea I presented is to piggy-back as much information into the UDP
package that you are going to send anyways, whereby we can avoid other
host from sending their UDP package. I fail to see how this could not
work on WiFi.

I should stress that the above is just a suggestion to improve
scalability. You can take it or leave it. I have no strong feeling for
it.

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. All other discovery
protocols have this, and it is very useful. This is typically used to
convey information such as lease times, MAC addresses, and security
keys. A simple list of key-value pairs will suffice.

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.