[zeromq-dev] Comments on ZRE

[Pieter Hintjens]

Michel,

I'm writing up this new ZRE-DISC spec and have some questions/comments:

- since the service socket is used to receive messages from many
nodes, it can only be ROUTER afaics. It certainly can't be PAIR, PUB,
PUSH. If it was PULL, SUB, or DEALER, messages would have to all
contain the sender UUID. This makes no sense afaics. So I'd like to
drop this field from the header.

- the network address to connect to only makes sense with TCP and PGM
afaics. So I'd like to drop IPC as a transport.

-Pieter


On Tue, Feb 5, 2013 at 8:25 PM, Michel Pelletier
<pelletier.michel at gmail.com> wrote:
> I've spent some time last weekend reading the ZRE spec and spiking an
> implementation with pyzmq and gevent:
>
> https://github.com/michelp/zypre
>
> I got beacon sending/recving, heartbeating with deadbeat detection, and the
> socket topology interconnection working.
>
> As I was working on it I came up with some questions/comments on the ZRE
> protocol.
>
> The first is that the protocol definitely appears to have two essentially
> independent mechanisms in play.  The beacon-interconnecting dance, and then
> the actual protocol spoken over TCP (whisper, shout, etc.).  They seem so
> cleanly disconnected from one another that it strikes me they could almost
> be two specs, one is a UDP based socket discovery protocol, and the other is
> TCP protocol that rides on top of it.
>
> The second is that the connect back mechanism is to the IP address received
> from UDP, but it's conceivable that the actual service socket being
> broadcast could listen on another interface.  For example, Amazon's virtual
> private cloud product does not support udp broadcast or multicast.   One
> could use openvpn, which is fine for the beacons, but not as ideal for the
> actual socket traffic.
>
> The last comment is that the beacon format requires the DEALER callback to
> ROUTER over TCP pattern, and the service socket is assumed to be a ROUTER.
> This is likely fine for most cases, and yes all other socket patterns can be
> implemented with ROUTER/DEALER, but this seems to exclude the ability to do
> simple linkups with PUB/SUB, and means the PGM transport can't be used
> either.
>
> I would propose then an extension to the ZRE beacon format.  The original 22
> byte beacon would still be valid, but another format of a different version
> would continue with: an octet describing the transport, and octet describing
> the service socket type, and 4 octets that contain the connect-back address,
> or something like that.
>
> Thoughts?
>
> -Michel
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>