[zeromq-dev] Comment on ZRE spec flaw
breese at mail1.stofanet.dk
Sat Feb 23 11:56:57 CET 2013
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
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.
More information about the zeromq-dev