[zeromq-dev] Router Example & questions

Pieter Hintjens ph at imatix.com
Sun Mar 9 22:14:06 CET 2014

The design from Chapter 8 is the simplest and most robust one I've found.

Identifying a peer by IP address isn't great. What if you want to run
100 peers on the same IP address? You should use a identifier that's
independent of physical address. On some networks (WiFi), a peer can
be disconnected and then reconnect with a different IP address, but
should continue to run.


On Sun, Mar 9, 2014 at 9:40 PM, Troy Settle <troy.settle at gmail.com> wrote:
> Pieter,
> Thanks for the reply.  The problem I have with the dealer, is the
> round-robin style of sending messages.  The fix given in Chapter 8 to use
> one dealer per peer is workable, but would seem to complicate things too
> much.
> I'm not sure I see the fragility introduced by the ROUTER-ROUTER pair, but
> this is something that would be handled by the application.  If N1 sends a
> request to N2 and does not receive a reply, that's ok... we want to be as
> tolerant of lost peers as possible.
> The pattern I envision, is that every node is running identical code with
> identical capabilities.  To keep the underlying protocol handling as simple
> as possible, the sockets should be identical on both sides of every
> connection.
> Any thoughts on the other part of my message regarding the peer identity?
> Is an part doable without incurring additional expense in the library?
> Thanks!
> -----Original Message-----
> From: zeromq-dev-bounces at lists.zeromq.org
> [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
> Sent: Sunday, March 9, 2014 4:12 PM
> To: ZeroMQ development list
> Subject: Re: [zeromq-dev] Router Example & questions
> Hi Troy,
> There's a pattern for fully decentralized clusters, in Chapter 8. To ensure
> we don't lose messages randomly, we use dealer-router in a symmetric way.
> Pure router-router is fragile in several ways, and I'd not recommend it.
> -Pieter
> On Sun, Mar 9, 2014 at 8:20 PM, Troy Settle <troy.settle at gmail.com> wrote:
>> I've been digging around 0MQ for a short time now, and one of the
>> things that is not discussed heavily in the guide, is the ROUTER to
>> ROUTER pair, which would be highly useful in a completely
>> decentralized P2P network.  So, after working through some of the
>> examples in the Guide, I came up with this code.  It's in PHP, and if
>> nobody takes my fun away, I'll write it also in C and/or C++ (assuming
>> I can get back up to speed in them).  Please feel free to use this in the
> 0MQ Guide (with or without cleanup).
>> http://pastebin.com/zW548wpN
>> I called it node.php.  There's probably a better name as a piece of
>> example code.
>> $ php node.php <port> <peers>
>> It will fork out as many peers as you want (at least 2), each binding
>> to <port>+n and connecting to each previous node that's already bound.
>> What you end up with, is any number of nodes, all connected (in some
>> way) to all the other nodes.  If you launch a few nodes, all messages will
> be received.
>> If you launch many nodes, messages will dropped, as the oldest and
>> youngest nodes don't overlap quite enough.  You can play with the
>> sleep on line 60 to have some fun.  Comment out the printf() and echo
>> statements in the loop if you want to reduce the noise.  The
>> zhelpers.php include isn't necessary, it was left over from a previous
> experiment.
>> My test machine is a single CPU VM running FreeBSD 10 and PHP 5.5.9.
>> The largest test I ran was 100 nodes which was much fun to watch.
>> ---
>> One thing that I find seriously lacking, is the ability to identify a
>> peer by IP address.  I've seen the recent patch for ZMQ_SRCFD, which
>> will be handy in C and presumably in other languages as patches are
>> made to the bindings.  I'm wondering, though, if the ROUTER and STREAM
>> sockets couldn't be configured (perhaps by default) to providing some
>> useful information in the identity string such as the descriptor,
>> address family, address, port, and perhaps topic.
>> One other thing that I'm wondering, if there couldn't be a low-level
>> broadcast/flood mechanism built into the ROUTER/STREAM socket.  Sure,
>> it's easy enough to iterate through all peers, but if I want to send
>> the same message to several hundred peers, doing so at the lowest
>> level in the 0MQ API should make the operation much less expensive.
>> Of course, not all peers will want to receive floods, so we would probably
> need a flag for that.
>> Perhaps the first byte of the identity string could be used for flagging.
>> 0x00 - Random 32bit ID  (current)
>> 0x01 - Peer generated ID (minor change)
>> 0x02 - Socket Info ID (added functionality)
>> 0x04 - Can receive floods (capability flag) ...
>> 0xFF - Broadcast a flood (sending only)
>> All in all, I'm not even close to being up to speed in C/C++ to do
>> this myself, mostly I'm just thinking about ways to extend
>> functionality without incurring too much cost and hoping to catch
>> someone's attention.  We would probably need much discussion to flesh
>> these ideas out if it is to go anywhere at all.
>> -Troy
>> _______________________________________________
>> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list