[nanomsg] Re: Where "Channel ID" are managed in the code ?
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Wed, 15 Jan 2014 22:05:10 +0200
Hi Martin,
On Tue, Jan 14, 2014 at 10:09 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Laurent,
>
> On 13/01/14 19:36, Laurent Alebarde wrote:
> > Analysing rep.c / nn_rep_recv, my understanding is that the
> > backtrace (channel IDs stack) is stored in the socket and that if
> > the REP socket receives a second message before nn_rep_send was
> > performed on the first one, then the first message is cancelled. Do
> > you confirm ?
>
> Yes, the stack from the request is stored in the socket, so that it
> can be re-attached to the reply.
>
> And no. If new request is received while on old one is still being
> processed it's queued in TCP buffers and not yet read by nanomsg.
>
> > For intermediate devices, I can imagine the send is prioritary over
> > the receive. Then I assume no message is cancelled. But for an end
> > point, say a worker, what happens if the worker processing is long
> > compared to the typical requests interval ? Isn't the service down
> > as all messages may be cancelled ?
>
> The pushback is applied. I.e. While the device is processing a message
> it doesn't read any more messages from TCP.
>
> All in all, to achieve your goal I would suggest doing the following:
>
> 1. Add new socket option, say NN_REQ_SCHEDULER, with possible values
> of NN_REQ_ROUND_ROBIN (current implementation, the default) and
> NN_REQ_STICKY. The latter, when applied to a REQ socket would cause
> requests from the same client to be sent, if possible, to the same
> worker. If the old worker is not available, the message will be sent
> to a different worker.
>
> 2. Add a new dispatching mechanism to xreq.c. It should work in the
> following way: It keeps a map of clients & corresponding workers. When
> new request arrives it will check the top of the stack (the client ID)
> and find the corresponding worker. If there's no entry for the client
> in the map, it will create one, assigning a worker with the smallest
> number of clinet already assigned. Also, when connection with the
> worker breaks, it will remove corresponding entries from the map.
> Finally, it would be good to do a clean-up of the map once in a while
> and remove entries that haven't been used for a long time, so that map
> doesn't grow without bounds.
>
> How does that sound?
How does this work for with devices? I think it breaks the scalability
principle.
--
Paul
Other related posts:
