[zeromq-dev] Implementing efficient recv timeouts [was Re: zmq::poll timeout returns immediately on MacOS/X 10.5]
matt_weinstein at yahoo.com
Fri Jun 11 20:48:47 CEST 2010
On Jun 11, 2010, at 2:05 PM, Martin Sustrik wrote:
> Hi Matt,
>> This device would have some intelligence about the flow of REQs and
>> REPs through it, and every N ms would synthesize an empty (or error)
>> response back to the REQ that was waiting by constructing a synthetic
>> X packet. Later, when the REP came through it would ignore it.
> This won't work if the connection from REQ to timout device is broken.
> The timeout must be built into the endpoint IMO.
I'm following this path now, with a local (inproc:) timeout device.
>> One problem that results is that the receiving socket would be in the
>> "ready" state after receiving the response, but the rest of the
>> network would not reflect that. If another request were sent with
>> same identity it could trounce state elsewhere.
>> Otherwise, I think you would have to build the device into zmq where
>> it could directly mangle the pipes and sockets :-)
> Yes. I think so. But it's not that difficult as it may seem.
> What's really difficult is that there's no cross-platform
> thread-friendly highly-efficient timer mechanism.
Too many platforms :-)
>> Also, I'm presuming identities are not recycled, meaning I can mark
>> identity as "down permanently" once a socket closes. That way I can
>> track all of the pending replies without worrying about the
>> application "walking around me" to another socket and reusing the
> Identity is either auto-generated (UUID) or set by user ZMQ_IDENTITY
> socket option.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev