[zeromq-dev] zmq_poll: timeout issue

[Matt Weinstein]

Even C++ needs wrappers (libs, STL, Boost, etc.) :-)

What's interesting about ØMQ is how quickly you can implement a stable  
solution at the endpoints using REQ-REP, PUB-SUB, etc., then do  
plumbing transparently in the middle without changing the endpoint API  
or semantics.

Also, I haven't focused on patterns for the endpoints yet, there are  
some evolving in my work.

Best,
Matt

On Aug 11, 2010, at 4:30 AM, Ilja Golshtein wrote:

> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev