> Maybe having the state reset itself on every write would be enough for REQ to be used in production without any hacks.
Sounds good to me. I also think REQ should send requestid,0,data... instead of just 0,data... and expect a reply with the same first two frames. Otherwise the wrong reply could be matched to a request in some cases, even with the fixes in master. This behavior would probably need to be hidden behind an option to preserve backwards compatibility. Christian Justin Karneges <[email protected]> wrote: >On 07/18/2013 04:09 PM, Steven McCoy wrote: >> On 18 July 2013 16:43, Matt Connolly <[email protected] >> <mailto:[email protected]>> wrote: >> >> What is the correct way to handle the timeout? >> >> If the REQ socket is in the receive state, the only way it seems to >> me is to close the socket and make a new socket with a new >> connection. Is that right? >> >> >> Yes, REQ and REP are pretty much "L-plate >> <http://en.wikipedia.org/wiki/L-plate>" sockets but also incredibly >> useful for rapid prototyping of environments. Heading towards >> production you want to replace with DEALER and ROUTER to remove the >> fatal blocking states. > >If that's true, it's not something I recall being at all clear from the >guide. It sounds like there are some fixes in the right direction on zmq >master at least. Maybe having the state reset itself on every write >would be enough for REQ to be used in production without any hacks. > >Also, I don't think there's any issue with REP is there? One could use >REP for a server and DEALER for a client without any gotchas. > >Justin >_______________________________________________ >zeromq-dev mailing list >[email protected] >http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
