I think this may be achieved by the following arch:
1. Establish 2 ROUTER sockets, router #1 is responsible for receiving
incoming requests, and router #2 is connected to router #1;
2. Establish a DEALER socket per thread, and connect to router #2. And
upon connected, tell router #2 its interested "topic".
3. Whenever a request comes in, router #1 just send it to router #2.
Router #2 send the message to different thread through the DEALER socket
according to the DEALER socket's interested "topic" and the message's type.
I believe the above arch is some pattern in the guide (however, I just
can't recall it).
On 2014?01?16? 23:54, Lindley French wrote:
A problem I was wrestling with was, how do I deal with a TCP
connection where messages of different types may arrive, and may need
to be dealt with in different threads? The TCP socket can't be touched
directly by multiple threads, of course. The obvious solution was to
immediately forward messages arriving on the TCP socket to an inproc
socket.
I then took it one step further: why not make that inproc socket a PUB
socket and make the first part of each message be a topic identifier,
so that whichever thread knows how to deal with a particular message
can just subscribe to it and ignore the rest?
That's a great design, right up until I try to do it with the TCP
socket being a ROUTER. Now, no matter what the first part of the sent
message is, the identity will end up being the first part on the
receiving end. The PUB/SUB won't work without some tweaking.
I don't want to just drop the identity; that's useful information. I
could swap the first two parts; that will work, but it's unintuitive
and could cause confusion down the road.
Any other ideas?
_______________________________________________
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
