[zeromq-dev] Comments on ZRE

[Michel Pelletier]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130205/8f84506b/attachment.htm>