[zeromq-dev] Comments on ZRE

[Michel Pelletier]

For the ZRE "chat" protocol, yes, it can only be a ROUTER, but the udp
beacon protocol is useful to broadcast the existence of PUB/PUSH sockets as
service sources and SUB/PULL as service sinks.  The protocol spoken from
that point forward wouldn't be ZRE (ie, whisper, shout, etc.) but it's
still useful to have generic socket discovery.

Of course, one could easily implement the beacon protocol as a simple
one-off, as I have done, and not call that ZRE at all, but they are so
similar at this point, it's only a single backwards compatible byte field
in the header that is different, that's very tempting to have a single
functional unit that can handle beacons, ZRE or otherwise, on which various
other infrastructure could be hung.

If you want to stick with ZRE only on top of the beacon protocol in this
particular spec, than there's really no changes needed, since PGM is
meaningless as a transport for ROUTER/DEALER no?  I've never used pgm  but
i assume it would only produce a benefit for PUB/SUB.

On a crazier note, I think this would be a very useful core feature of 0mq.
 Consider the following possible python example:

import zmq

c = zmq.Context()
incoming = c.start_beacon(addr, port) # returns PAIR

r = zmq.socket(zmq.ROUTER)
r.bind(...)
c.register_beacon(r) # starts broadcasting 'r'

while True:
  # poll incoming for beacons...


-Michel


On Mon, Feb 18, 2013 at 4:33 AM, Pieter Hintjens <ph at imatix.com> wrote:

> 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
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130218/4da67062/attachment.htm>