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