<div dir="ltr">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. <div>
<br><div>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.<br>
<div><br></div><div style>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.</div>
<div style><br></div><div style>On a crazier note, I think this would be a very useful core feature of 0mq.  Consider the following possible python example:</div><div style><br></div><div style>import zmq</div><div style>
<br></div><div style>c = zmq.Context()</div><div style>incoming = c.start_beacon(addr, port) # returns PAIR</div><div style><br></div><div style>r = zmq.socket(zmq.ROUTER)</div><div style>r.bind(...)</div><div style>c.register_beacon(r) # starts broadcasting 'r'</div>
<div style><br></div><div style>while True:</div><div style>  # poll incoming for beacons...</div><div style><br></div><div><div style><br></div><div style>-Michel</div></div></div></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Mon, Feb 18, 2013 at 4:33 AM, Pieter Hintjens <span dir="ltr"><<a href="mailto:ph@imatix.com" target="_blank">ph@imatix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Michel,<br>
<br>
I'm writing up this new ZRE-DISC spec and have some questions/comments:<br>
<br>
- since the service socket is used to receive messages from many<br>
nodes, it can only be ROUTER afaics. It certainly can't be PAIR, PUB,<br>
PUSH. If it was PULL, SUB, or DEALER, messages would have to all<br>
contain the sender UUID. This makes no sense afaics. So I'd like to<br>
drop this field from the header.<br>
<br>
- the network address to connect to only makes sense with TCP and PGM<br>
afaics. So I'd like to drop IPC as a transport.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Pieter<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, Feb 5, 2013 at 8:25 PM, Michel Pelletier<br>
<<a href="mailto:pelletier.michel@gmail.com">pelletier.michel@gmail.com</a>> wrote:<br>
> I've spent some time last weekend reading the ZRE spec and spiking an<br>
> implementation with pyzmq and gevent:<br>
><br>
> <a href="https://github.com/michelp/zypre" target="_blank">https://github.com/michelp/zypre</a><br>
><br>
> I got beacon sending/recving, heartbeating with deadbeat detection, and the<br>
> socket topology interconnection working.<br>
><br>
> As I was working on it I came up with some questions/comments on the ZRE<br>
> protocol.<br>
><br>
> The first is that the protocol definitely appears to have two essentially<br>
> independent mechanisms in play.  The beacon-interconnecting dance, and then<br>
> the actual protocol spoken over TCP (whisper, shout, etc.).  They seem so<br>
> cleanly disconnected from one another that it strikes me they could almost<br>
> be two specs, one is a UDP based socket discovery protocol, and the other is<br>
> TCP protocol that rides on top of it.<br>
><br>
> The second is that the connect back mechanism is to the IP address received<br>
> from UDP, but it's conceivable that the actual service socket being<br>
> broadcast could listen on another interface.  For example, Amazon's virtual<br>
> private cloud product does not support udp broadcast or multicast.   One<br>
> could use openvpn, which is fine for the beacons, but not as ideal for the<br>
> actual socket traffic.<br>
><br>
> The last comment is that the beacon format requires the DEALER callback to<br>
> ROUTER over TCP pattern, and the service socket is assumed to be a ROUTER.<br>
> This is likely fine for most cases, and yes all other socket patterns can be<br>
> implemented with ROUTER/DEALER, but this seems to exclude the ability to do<br>
> simple linkups with PUB/SUB, and means the PGM transport can't be used<br>
> either.<br>
><br>
> I would propose then an extension to the ZRE beacon format.  The original 22<br>
> byte beacon would still be valid, but another format of a different version<br>
> would continue with: an octet describing the transport, and octet describing<br>
> the service socket type, and 4 octets that contain the connect-back address,<br>
> or something like that.<br>
><br>
> Thoughts?<br>
><br>
> -Michel<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> zeromq-dev mailing list<br>
> <a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>
> <a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
><br>
_______________________________________________<br>
zeromq-dev mailing list<br>
<a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>
<a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
</div></div></blockquote></div><br></div>