-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Drew, See my answer to your previous email. Martin On 05/05/14 08:18, Drew Crawford wrote: > I have what is a pretty stupid question, however the > documentation/blog posts are a little unclear on this subject so it > may be worth asking here. > > I have a topology with many clients and many workers, that are > connected through the use of a single broker. A client wants to > use a REQ-like pattern to make a request and receive a response, > and the worker’s role is to prepare a response for a given client > request. A sketch of the topology is attached. This is about what > you would expect for an HTTP load balanced application, for > example. > > > The way that the ZeroMQ guide advises one to achieve this is > through REQ on the client, REQ on the worker, and a ROUTER/DEALER > message broker that a programmer would write themselves to > implement the load balancing. Sample code is available for ZeroMQ > here > <http://zguide.zeromq.org/page:all#ROUTER-Broker-and-REQ-Workers>. > > I googled a bit about what the recommended design pattern for load > balancing is in nanomsg,particularly since there is no direct > ROUTER/DEALER equivalent, and I found this blog post > <http://250bpm.com/blog:14> from Martin. However, there are > several things that are not very clear: > > * The blog post says "Similar to ZeroMQ, load balancing is done by > REQ and PUSH sockets”. Admittedly, REQ/PUSH can be used to achieve > load balancing in ZeroMQ if you don’t care about the response. > However the ZeroMQ book spends much more time on the ROUTER/DEALER > broker pattern for load balancing, and that is probably the typical > way that a ZeroMQ programmer would approach a load balancing > problem. Thus the statement that REQ/PUSH is “similar” to the way > things are done in ZeroMQ was momentarily surprising * The blog > post goes on to use REQ and REP in its diagrams instead of REQ/PUSH > as you might expect from an introduction explaining that load > balancing is done with REQ/PUSH. Many of the diagrams are rather > similar to my topology, but the directionality of the arrows > suggests PUSH may have been intended where other socket types are > indicated, so I am not entirely convinced these diagrams intend to > show bidirectional socket types * The first code snippet creates a > socket called “req”, sets options on a distinct and undeclared > socket called “push”, and then sends and receives messages on “req” > again. I think what was intended here was to refer to a single > socket throughout, but I am thoroughly confused about what type was > intended * One of the most promising diagrams calls the broker a > “REQ/REP device”, and the accompanying text suggests that this is a > feature built into nanomsg, possibly this feature > <http://nanomsg.org/v0.1/nn_device.3.html>. However a plain > reading of the linked documentation suggests the feature passes > messages between exactly 2 sockets, not an arbitrary number of > clients and workers as depicted in the blog post’s diagram. > > > So my question is, what is the best practice to achieve my > (non-prioritized, vanilla, plain ordinary) load balancer in > nanomsg? I see some obvious ideas, but surely there is some golden > path to achieve this, that somebody has been thinking about much > longer than I have. > > Drew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTZzBmAAoJENTpVjxCNN9YbbMH/icdD1TGKjUb/evM0ArCHo1A Mpx4xAOljDyDqi/9Xh4twqA1I/Q9sYBb4M6QcKI3EIc5PIjrrDutBBhGvsVVHS1a BLR7SUMnO0mhXt0VPhzMkW6XBGQOJYuAuQJXO5yxhTaBzsaQ40X7w23NxTZ1OQaQ BEuTco+DMEXXK55+vd5HYneIC7BEaaTLVeQ5RsPxrjlGaro0Z9cKllkRcccE+tQM /ET0UK8lLJhOTucdFRFulvEy7xMjAofMMLQEfcBDaAHBAmt7R38Bf6sR/n82VXcL qMXdK9GHPq+UZzkUCqjMjkAk7JsaFffEc7emoc5tklZN+YGqX79t2JOiZ0qqoZA= =ovRK -----END PGP SIGNATURE-----