[zeromq-dev] Router Example & questions

[Troy Settle]

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