Le 14/01/2014 09:09, Martin Sustrik a écrit :
-----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.
Hi Martin,
I have some doubts and a very naive question to remove it:
Considering your above assessment, is parallelizing tasks in several
workers possible with REQ/REP ?
Let's recall my architecture:
-------------- server ------------------
client (REQ) ---------- (REP) proxy (REP) ---------- (REP) worker
socket names REP_PC REP_PW REP_W
Say I have two clients C1 and C2, and two workers, W1 and W2. Idealy,
the proxy shall be able to forward messages from C1 to W1 and from C2
to W2 in parallel if W1 was first assigned to C1.
If C1 sends a message, first it is catched by REP_PC with a receive.
The receive operation stores the channel ID of C1 in the backtrace
storage of the socket REP_PC which them waits until it has to send
something for which it will retrieve the channel ID previously stored.
If this behaviour is correct, them I need only one worker since only
one worker at a time actually works. What is dumb.
Or is it a queue per pipe and a backtrace storage per pipe ?
If yes, is there a map with channel IDs as keys and pipe pointer as
value ?
Cheers,
Laurent
