[zeromq-dev] Implementing efficient recv timeouts [was Re: zmq::poll timeout returns immediately on MacOS/X 10.5]

Matt Weinstein 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  
>> the
>> 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  
>> an
>> 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.
>
> Identity is either auto-generated (UUID) or set by user ZMQ_IDENTITY
> socket option.
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Thanks,
Matt



More information about the zeromq-dev mailing list