Matt, thank you. Learning zmq_reactor and your suggestions.
It is slightly disappointing elegant and crystal 0mq interface is unusable in production and requires wrappers and complications ... not a low hanging fruit. 10.08.2010, 21:35, "Matt Weinstein" <matt_weinst...@yahoo.com>: > Basically -- reverse the normal "server" paradigm, and use an XREP > socket on the device side, then have each server send a single message > when it wakes up on its REQ socket. This message identifies the > server to the device side by UUID. The server will be back to > alternative recv-send cycles (just offset by one). > > [[ clients ]] -- [REQ] = [XREP] --- DEVICE --- [XREP] = [REQ] -- > [[ servers ]] > > The server UUIDs go into a "server free list", which can then be used > to schedule clients. > > When you read the client packet stream (UUID,NULLPACKET,data) to > service a client, you need to keep the <serverUUID, clientUUID> pair > in a(n unordered) map, so when the server finishes the client response > can be transmitted, and the server pushed back to the freelist. > > If there is no server when you receive a client request > ( server_free_list.empty() ) you can then respond back immediately > with a failure message. > > Alternatively, if you don't want to dequeue requests until a server is > free, just poll ONLY the server list while server_free_list.empty(). > > If you need to handle a timeout scenario, either pull the client > requests out of the XREP, put them into unrolled lists of zmq_msg_t or > equivalent, and build a small timer chain to return an error and kill > a set (or unordered_map) with the requests. > > (The zmq_reactor library should help a bit here, that's what I'm using > for all this...) > > Best, > > Matt -- Best regards Ilja Golshtein _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
