[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 22:26:20 CEST 2010

I tried playing with different types of responses, and got:

	Assertion failed: msg_->flags & ZMQ_MSG_MORE (req.cpp:225)

when I sent the zero length end of header packet without a  
ZMQ_SNDMORE.  That's good, since this let me know about a handy spot  
to wedge the client's socket with a custom message.

Question: what's the cleanest way to close or kill the underlying pipe  
so the user gets a bad read response?  xdetach? xkill?

Am I missing any other spots?



On Jun 11, 2010, at 2:48 PM, Matt Weinstein wrote:

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

More information about the zeromq-dev mailing list