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 [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
