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 XREQ/XREP. 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 reply. The above points would ensure that duplicates and stray replies are ignored. Furthermore: 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. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
