[zeromq-dev] zmq_poll: timeout issue

Ilja Golshtein ilejncs at narod.ru
Wed Aug 11 10:30:30 CEST 2010

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_weinstein at 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

More information about the zeromq-dev mailing list