[zeromq-dev] zmq_poll: timeout issue

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


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_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