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.
-Pieter On Sun, Mar 9, 2014 at 9:40 PM, Troy Settle <[email protected]> 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: [email protected] > [mailto:[email protected]] 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 <[email protected]> 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 >> [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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
