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?
Thanks!
Best,
Matt
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
>> [email protected]
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> Thanks,
> Matt
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
