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

Matt Connolly matt.connolly at me.com
Sun Dec 15 04:42:44 CET 2013

Hi Mohit,

I went through the same thing recently. Not only does the worker need to know if the broker has gone, the broker also needs to know the worker has gone:

1. worker connects to broker (based on lbbroker3 example)
2. worker sends “ready” command and waits for work.
3. broker sends idle commands every X seconds when there is no work to do. 
4. worker replies to idle commands immediately.

In this way both the worker and broker know that they are still connected to each other.

The broker removes the worker from being available until it replies from the idle command.

If the worker doesn’t receive an idle command, it closes the socket and makes a new connection.

This allows the worker to use a simple REQ socket. There is always one request to one response over the connection.

If the broker can exit gracefully (deliberate shutdown, onto a crash), it could also send a message to the workers to tell them to close their sockets and make a new connection with another ready command.


On 15 Dec 2013, at 9:20 am, Mohit Jaggi <mohitjaggi at gmail.com> wrote:

> Thanks all for your comments. I should clarify my use case better. I am using the lbbroker3 pattern, where the worker uses a REQ socket to connect to a ROUTER socket on the broker. It sends "I'm READY" to let the broker know that it can serve a request. After the first request, the response serves as the "I'm READY" indication to the broker. Now, if the broker restarts it will wait for an "I'm READY" message but worker won't send any. How can worker know that broker restarted? 
> On Fri, Dec 13, 2013 at 10:24 PM, Pieter Hintjens <ph at imatix.com> 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.
> >>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131215/04fd0158/attachment.htm>

More information about the zeromq-dev mailing list