[nanomsg] Re: a stupid load balancing question

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Mon, 05 May 2014 08:32:06 +0200

-----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-----

Other related posts: