[zeromq-dev] using REQ in a real application

[Pieter Hintjens]

The Guide doesn't say it explicitly, but it does show how to use REQ
reliably at some stage (Lazy Pirate pattern).

REQ could be made to work better when a peer dies or does not respond
within some timeout. I do like the idea of resetting the state when
sending a message, this is simple and allows the application to decide
the timeouts etc.

REP doesn't have this issue.

One new thing in ZMTP 3.0 but not yet implemented in libzmq is
heartbeating, which would make REQ work better.

-Pieter

On Fri, Jul 19, 2013 at 4:56 AM, 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