[zeromq-dev] ZRE interface address and disconnect beacon
ph at imatix.com
Thu Feb 28 20:21:24 CET 2013
On Thu, Feb 28, 2013 at 6:58 PM, Markus Mayer
<widemeadows at googlemail.com> wrote:
> I have noticed that in the current draft of ZRE the sender's IP address in
> the HELLO command is encoded as a string. Is there a particular reason for
> not encoding it as a 4OCTET in case of IPv4 - and then, what about IPv6?
> Sending this as a VCHAR sequence seems like overkill.
There's no cost (HELLO is sent rarely) and strings are easier to
debug. Binary would be fine too.
> I am also seeing a problem here when binding on "all" interfaces; It is not
> clear which address should be sent in that case. If I receive an UDP beacon
> on a specific interface I could obviously send that, but the draft doesn't
> explicitely specify it.
Yes, this is a known problem. There's still some work to be done to
design sane behaviour, e.g. beacon on all interfaces rather than just
the most appealing one. Then, a node could connect to multiple
networks at the same time. However that will cause split brain
effects, unless one or more nodes does forwarding. It starts to get
complex, and it's not discussed properly in the spec.
> A second thought is something like a GOODBYE command or beacon.
Using a beacon for this would be... interesting. But I'd rather send
an explicit command over TCP. The reality of applications is that they
rarely know when they're going to be leaving. Users walk away or close
their laptops, but rarely take the time to sign out nicely. Do you
have a use case where GOODBYE solves a problem (rather than just being
> Then: Are there any thoughts about using multicast instead of broadcast?
Sure. Multicast works very much like broadcast except that it doesn't
pass some stacks. We had specific trouble with Android when a node is
acting as an access point (mobile hotspot): the WiFi stack then simply
discards incoming multicast packets. ZRE does solve this by
handshaking the connect so IMO you could swap out broadcast with
multicast in the beacon code (zbeacon, in CZMQ) and it would work
If you wish to try this, the place to start is in the code, prove it
works, and then we can adjust the spec.
More information about the zeromq-dev