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

[david.briant at ubs.com]

I have a UI thread (where I don't control the pump - e.g. in wxPython,
PyQT, etc) so the only way I can listen for events is to poll on a timer
- which isn't ideal as it's slower than getting events on the UI loop.

zmq might be good for inter-thread comms though I imagine only if it is
the exclusive mechanism. I may still use it for IPC - I'm not totally
sure yet since I need to create three zmq sockets for each peer
connection (PAIR/PAIR to do async messages, REQ/REP to establish the
PAIR/PAIR address, and a PAIR/PAIR heatbeat or a PUB/SUB to tell the
caller that the callee is terminating. I still haven't figured out the
crash scenario yet - probably requires a heartbeat on the PAIR/PAIR
connection. 

I'd prefer to have a dynamic addressing system (with a zero conf style
directory) which allows a plastic topology rather than a intermediating
broker making a more rigid topology.

David

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

On Tue, Aug 24, 2010 at 5:41 PM,  <david.briant at ubs.com> wrote:

> Just rereading this thread. Why shouldn't I be using pairs in normal
> code?
>
> I want to do simple point-to-point (often asynchronous) messaging
> between many peers. The REQ/REP and PUB/SUB paradigms don't fit.
> Additionally I want to do dynamic resource discovery which concretely
> binding to a port negates.

You might consider putting a broker in between peers, that helps you
make a more dynamic topology.

PAIR/PAIR does not reconnect if either node breaks and comes back, and
it's exclusive, so the bound endpoint can accept exactly one
connection at a time.  This makes it a good pattern for inter-thread
signalling, for example, but not great for connecting more nodes.

Have you looked at XREQ/XREP?  They're not documented yet, only a
little in the guide, but that might be what you need.

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