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 client-message-headres. Hope this helps. 2013/10/12 Matt Connolly <[email protected]>: > 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 <[email protected]> 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 > [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
