Closed mhowlett closed 10 years ago
Will this allow the return path to be passed along when using Req / Rep sockets. i.e. through a load balancer to a set of worker threads?
The message control information could be used for that, but honestly it'd make more sense to me to maintain an array parallel to your list of socket file descriptors (that are passed to nn_poll) containing callback information, and update the two lists atomically.
I couldn't say more without more visibility into the threading/balancing scenario you have in mind, though. Suffice it to say that the intention of the change is to allow more efficient sends of serialized data structures, as the use of scatter buffers avoids several forms of overallocation.
Let us know if you see other opportunities though!
I was thinking a multithreaded server where there is one TCP socket accepting requests and passing them through via inproc to multiple worker threads. I am new to nanomsg and where I got stuck was I get the request from the TCP socket, send it via inproc to one of the workers, the worker sends a reply but then how do I send it to the correct client? I only have one listener socket.
I'd recommend having a look at the following:
Req/rep example of fair queueing https://github.com/nanomsg/nanomsg/blob/master/tests/reqrep.c
Req/rep topology design http://250bpm.com/blog:14
You'll have multiple rep sockets on the same address. Each of them will handle a single request at a time, and thus a reply sent on them will be to the correct client. So each worker will need to receive some sort of context of the reply socket that they should be sending on.
I'd suggest taking this to its own issue if you feel this functionality isn't correctly or conveniently provided, so that it can be properly addressed. I'm actually closing this one, as it was handled by the earlier change set.
I've been looking into this. Here's my current take.
Once the streaming send and receive are done, I'll try and put together some protocol buffer demos.