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

Martin Sustrik sustrik at 250bpm.com
Sat Jun 12 17:32:58 CEST 2010

Hi Matt,

> 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 mailing list