On Mon, Feb 18, 2013 at 6:43 PM, Michel Pelletier <[email protected]> wrote:
> 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. If we provide physical socket information we also have to specify whether it's bound or connected. We could alternatively specify a protocol mechanism, e.g. "ZRE" that the beacon carries, which implies a specific socket type and bind/connect direction, and if needed, transport. I'd prefer that. Then the beacon protocol can become a general-use service discovery protocol as you envision. Each service would be specified as a profile formally, or informally. In that case, I'd revert the changes to RFC 20 and leave it as-is, and then start a new pair of RFCs. One for the beacon protocol and one for a new ZRE that uses it. > On a crazier note, I think this would be a very useful core feature of 0mq. Perhaps a zbeacon class in CZMQ? Then other languages can reimplement it (like zloop in JZMQ), or wrap it (as Perl-ZMQ wraps CZMQ). -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
