[zeromq-dev] using REQ in a real application
Christian Kamm
kamm at incasoftware.de
Fri Jul 19 09:25:51 CEST 2013
> 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 <justin at affinix.com> wrote:
>On 07/18/2013 04:09 PM, Steven McCoy wrote:
>> On 18 July 2013 16:43, Matt Connolly <matt.connolly at me.com
>> <mailto:matt.connolly at me.com>> 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
>zeromq-dev at lists.zeromq.org
>http://lists.zeromq.org/mailman/listinfo/zeromq-dev
More information about the zeromq-dev
mailing list