[zeromq-dev] Implementing efficient recv timeouts [was Re: zmq::poll timeout returns immediately on MacOS/X 10.5]
matt_weinstein at yahoo.com
Sat Jun 12 17:11:28 CEST 2010
REQ(client) --- XREP --- [ QUEUE w/ TIMEOUT ] --- XREQ --- REP(server).
I'm going to craft a message to send up the XREP pipe to the REQ
client basically saying "error".
I'm going to return an error, but then should either force the REQ
side closed, or force it to change identity.
The XREQ channel is able to ignore the next response (it's in a
<map>), but it's not safe too reuse the identity because REQ could
send another request and trounce the distant REP's state.
Changing identity would be cleanest, because REQ can immediately
initiate a new request.
BTW, the actual cost of managing ms scale timeouts is quite light with
a simple timer list and a well designed <map> (first pass anyway).
Anyway, what do you think?
On Jun 12, 2010, at 3:23 AM, Martin Sustrik wrote:
> Hi Matt,
>> Question: what's the cleanest way to close or kill the underlying
>> so the user gets a bad read response? xdetach? xkill?
> Depends on what do you want to do. What's exactly the scenario for
> killing pipe? Keep in mind that the peer is going to reconnect shortly
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev