On Thu, Feb 28, 2013 at 6:58 PM, Markus Mayer <[email protected]> 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 neat). > 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 identically. If you wish to try this, the place to start is in the code, prove it works, and then we can adjust the spec. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
