[zeromq-dev] How to detect if a remote socket has closed

[Pieter Hintjens]

On Tue, Aug 17, 2010 at 1:59 PM,  <David.Briant at ubs.com> wrote:

> I have a bunch of applications and services that I want to be able to communicate on an adhoc / peer basis. E.g. AppA can initiate connection and send messages to AppB or vice versa. AppA discovers AppB (or the other way round) using a directory (similar to zeroconf). If AppB crashes, the port (which is randomly assigned) is no longer connected to AppB, and potentially AppC could reuse it. So AppA needs to know that AppB is no longer available and needs to inform the user and potentially search for another peer that can be called instead of AppB.

Consider using a broker as in http://www.zeromq.org/docs:user-guide#toc23.

> If messages are lost (transparently) whilst AppA is down or the pairs can't reconnect automatically and have the queued messages sent on restart of AppA then I'm going to have to implement reliability at the application level - which seems a bit of a shame.

It's a bit of a shame if you're used to traditional messaging, but 0MQ
does not do any recovery in case of crashed nodes.  It's something I
want to provide some reusable answers for in the user guide.

> The implication of requiring a bind and connect means something needs to know / decide / coordinate who is connecting and who is binding. I.e. the application level needs to know who is listening for connection requests. If that is the case then the application level also needs to know if the listener is no longer available because it needs to find another listener (in my case using a directory for address lookup).

You are IMO still at the learning stage where your knowledge of TCP
sockets is messing with how you understand 0MQ sockets.
http://www.zeromq.org/docs:user-guide#toc9

Not that you can't do this at the application level, but it won't
happen as you expect.

> I'm also wanting something a bit more asynchronous than the REQ/REP socket. I.e. I'd like to be able to fire off several requests and wait for the responses, rather than have to wait.

The ideal pattern for asynchronous task distribution is PUSH/PULL (aka
DOWNSTREAM/UPSTREAM).  There is a worked example in the guide now.
http://www.zeromq.org/docs:user-guide#toc6

-
Pieter Hintjens
iMatix - www.imatix.com