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

[David.Briant at ubs.com]

Okay, I think that's a problem for my application.

Let me describe the situation.

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.

Also let me check my understanding of the reconnect behaviour.

If I have two pairs, then if either the bind (AppA) or connect process (AppB) crashes I should be able to just create the correct one. This implies that I can do connect (AppB) before I do bind (AppA) but that isn't working for me. Also I can't crash the process that did the bind (AppA) and have the pairs reconnect when I start a new process that does a bind (a new instance of AppA). Also I haven't figured out how to check the out queue (in AppB) to see what's happening to any messages that are queued whilst the binding process (AppA) is down.

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.

Rather than requiring bind and connect (which implies a connection being established but as you say I don't have access to connection state) I'd prefer either a connectionless interface (a la UDP) or a connect oriented protocol (i.e. with the distinction of bind and connect) with access to the connection state (happy for that to be abstracted so I don't actually see the TCP etc state). 

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).

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.

Any thoughts?




-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
Sent: Mon 16-Aug-2010 20:02
To: 0MQ development list
Subject: Re: [zeromq-dev] How to detect if a remote socket has closed

On Mon, Aug 16, 2010 at 7:26 PM,  <David.Briant at ubs.com> wrote:

> I'm coding in python and I can't figure out how to detect if a remote
> process has closed or terminated (I exited my python server and judging from
> the cpu usage zmq is trying to re-establish connection but I just can't see
> how to determine that in the API). Is it possible? and if so how do I do it.

You can't detect it, and that is deliberate.  From the Guide
(http://www.zeromq.org/docs:user-guide):

"In the ØMQ universe, sockets are clever multithreaded applications
that manage a whole set of connections automagically for you. You
can't see, work with, open, close, or attach state to these
connections. Whether you use blocking send or receive, or poll, all
you can talk to is the socket, not the connections it manages for you.
The connections are private and invisible, and this is the key to
ØMQ's scalability."

-
Pieter Hintjens
iMatix - www.imatix.com
_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.
	
E-mails are not encrypted and cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses.  The sender 
therefore does not accept liability for any errors or omissions in the 
contents of this message which arise as a result of e-mail transmission.  
If verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities 
or related financial instruments.

UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue,
London, EC2M 2PP, United Kingdom.

UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.

UBS Clearing and Execution Services Limited is a company registered
in England & Wales under company number 03123037, whose registered
office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
 
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.