[zeromq-dev] Implementing efficient recv timeouts [was Re: zmq::poll timeout returns immediately on MacOS/X 10.5]
sustrik at 250bpm.com
Sat Jun 12 17:32:58 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.
> Anyway, what do you think?
My way of thinking about it is to understand XREQ/XREP network as IP
network (unnreliable) and REQ/REP as reliable TCP endpoints on that network.
Basically, REQ/REP can be a reliability layer implemented on top of
What's needed is:
1. REQ socket attaches a unique ID to each request (UUID?)
2. REP socket copies the ID to the reply (if ID is added as a message
part, just before the delimiter message part, no code change is needed here)
3. When REQ socket waits for reply it checks whether the ID of the reply
matches the ID of the request it have sent. If it does not, it drops the
The above points would ensure that duplicates and stray replies are ignored.
1. REQ socket starts a timer when it sends a request.
2. When timer expires before getting a reply, REQ socket will re-send
the request (using the same request ID).
That should do IMO.
> 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).
I always regarded the timers as a problem. If you have a simple way to
deal with them, please, let share it with the list.
More information about the zeromq-dev