[zeromq-dev] will receive fail if TCP goes down in REQ socket

Mohit Jaggi mohitjaggi at gmail.com
Wed Dec 18 00:12:17 CET 2013


@Matt,,
I like the inband heartbeats better than the pirate patterns in ZMQ guide.
@Justin,
Yes, a DEALER socket can be used but will the reconnect not work? It is
simpler and actual reconnects will be rare so it isn't really less
performant.


On Sun, Dec 15, 2013 at 11:05 AM, Justin Karneges <justin at affinix.com>wrote:

> Cool. Is there a reason the relaxed behavior is to close and reconnect
> in order to reset the state? I'd think all you'd need to do here is
> change a local state variable in the client and just reuse the same
> connection. As it stands, I'd still want to roll my own REQ over a
> DEALER socket unless I'm missing something.
>
> On 12/13/2013 10:24 PM, Pieter Hintjens wrote:
> > The ZMQ_REQ_RELAXED option on ZeroMQ v4, lets you resend requests.
> >
> > On Sat, Dec 14, 2013 at 3:46 AM, Justin Karneges <justin at affinix.com>
> wrote:
> >> ZeroMQ does not resend messages, so while the reconnect/queuing logic
> >> will protect you to some degree, you still need to account for message
> loss.
> >>
> >> If you're using REQ then you'll need to timeout the request, otherwise
> >> if a request or response message is lost then you'll never be able to
> >> make a request on the socket ever again. So don't just indefinitely
> >> block on a send or receive. Further, ZeroMQ historically hasn't had a
> >> way to get a REQ socket out of the "waiting for response" state in the
> >> event of a timeout other than by closing the socket and starting over.
> >> This means the REQ type is not really usable in production. Better to
> >> use DEALER and format a REQ-compatible message yourself. REP does not
> >> suffer from these problems, so you can keep on using that and have
> >> DEALER talk to REP.
> >>
> >> Note: it is possible that very recent versions of ZeroMQ allow REQ
> >> sockets to revert state on error but I haven't been following this
> closely.
> >>
> >> On 12/13/2013 04:17 PM, Sean Robertson wrote:
> >>> I believe the REQ will simply wait for the REP to come back up,
> >>> re-bind and send something.
> >>>
> >>> On Fri, Dec 13, 2013 at 2:53 PM, Mohit Jaggi <mohitjaggi at gmail.com>
> wrote:
> >>>> Hi,
> >>>> In most ZMQ sockets, the underlying TCP socket can change
> transparently.
> >>>> Does that apply to REQ-REP sockets as well? Or will the receive call
> to ZMQ
> >>>> socket fail?
> >>>>
> >>>> sock = new REQ socket;
> >>>> connect(sock);
> >>>> while(1) {
> >>>> request = receive(...);
> >>>> ...
> >>>> send(response);
> >>>> }
> >>>>
> >>>> For example in the above code, let us say that the server with REP
> socket on
> >>>> the other side crashed and restarted. What will happen?
> >>>>
> >>>> Thanks,
> >>>> Mohit.
> >>>>
> >>>> _______________________________________________
> >>>> zeromq-dev mailing list
> >>>> zeromq-dev at lists.zeromq.org
> >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>>>
> >>> _______________________________________________
> >>> zeromq-dev mailing list
> >>> zeromq-dev at lists.zeromq.org
> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>>
> >>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131217/8b2949dd/attachment.htm>


More information about the zeromq-dev mailing list