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
