[zeromq-dev] Newbie question

Artem Vysochyn artem.vysochyn at gmail.com
Mon Oct 14 15:08:20 CEST 2013

Hi Howard,

Seems like you need something which could render "sticky" behaviour
between N-clients and M-workers. Right? If so, keep reading.

1. Read, understand and love socket identities.
2. Use ROUTER-ROUTER as a device-in-the-middle. I call it LRU-device.
3. Use socket identities on client side and worker side.

Here's your algorithm:

-- workers have to ping LRU-device in order to populate LRU-cache
(keep reading).
-- LRU-device have to keep LRU-cache (help yourself with cache)  for
worker identities which obtained from messages on backend (regardless,
whether it were "ping" or "regular reply").
-- clients have to retrieve identity from LRU-cache, __if__
client-message so far doesn't have sticky_socket_identity among
client-message-headres (help yourself with headers in message).
-- clients have to proceed omitting LRU-cache retrieval, __if__ they
have sticky_socket_identity retrieved previously inside

Hope this helps.

2013/10/12 Matt Connolly <matt.connolly at me.com>:
> Hi Howard,
> Welcome to the list.
> Have a look at figure 32 which uses a router on both sides. In that example,
> messages are sent to workers on a least recently used basis. You could alter
> this to send messages to the worker who is known to be servicing that
> client.
> Another approach may be to have the clients talk directly to the servers and
> have a “dealer” simply let the client know which worker they should talk to
> directly, so the client then opens a new socket and connects to that worker
> directly. This may not fit your network though.
> Regards,
> Matt.
> On 12 Oct 2013, at 4:53 am, Howard <howard at renci.org> wrote:
> Hi all
> I hope you will forgive a newbie question. Please feel free to send me to a
> different resource if this question is in the wrong forum.
> I've been teaching myself zeromq in combination with protobuffers.  I've
> been using the request/reply sockets and it's working perfectly in my simple
> test codes. But now I need a slightly more complicated pattern and I'm not
> quite sure how to do it. Here is my situation:
> On one side I have a short lived client program with I would like to connect
> to a server.  Because there can be a few of these simultaneously I would
> like my server to be multi-threaded.  The situation is similar to Figure 20
> in http://zguide.zeromq.org/page:all.  So far so good.  The issue however,
> is that I want each of my clients to interact with the same server thread
> over the life of it's invocation.  This is because the threads of the server
> are interacting with a stateful resource and multiple transactions between
> client and server are required to complete an operation. From what I
> understand of zeromq, it seems to me that I want either to
> Have the dealer make sure it forwards each request from a particular client
> to the same worker thread.  Is there a recommended technique for this?
> Have each client socket connect directly to a socket in the worker thread
> using some pattern that I don't see in the documentation. It seems possible
> to me that this idea is antithetical to the zeromq paradigm, so I wonder if
> I have some fundamental misunderstanding of zeromq or if I just missed
> something or maybe both.  Well, I did say I was a newbie. :)
> Rethink the idea that each client should only communication with the same
> thread.  I'm not sure if this is a possibility, but if 1 and 2 are
> difficult, I may want to investigate this further. At the least, I need each
> worker thread to understand which client thread it is communicating with.  I
> suppose I could put some type of session key in the message protocol if I
> knew how to get this info from zeromq.
> Any comments or suggestions (even RTFM with a pointer to the correct
> section) would be greatly appreciated.
> Thanks
> Howard
> --
> Howard Lander
> Senior Research Software Developer
> Renaissance Computing Institute (RENCI)
> The University of North Carolina at Chapel Hill
> Duke University
> North Carolina State University
> 100 Europa Drive
> Suite 540
> Chapel Hill, NC 27517
> 919-445-9651
> _______________________________________________
> 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