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

[David.Briant at ubs.com]

I don't think I've explained the situation well enough. Let me make it
very concrete.

I have two copies of Excel and I wrap zmq in a VB6 dll for example.

I want to send data from one copy of excel to the other.

I press a button in Excel A that registers itself with the directory
saying it can receive data. I press a button in Excel B that looks in
the directory for something that can receive data, and sends it. Excel B
relies on Excel A retaining state.

If Excel A crashes, then Excel B needs to be able to say hey I need to
find someone else to send data to.

Now I could write a broker that acts as an interface to Excel A, but it
means I now have another dependency in the system. Additionally I need a
meta-protocol to set up a broker as this was a spreadsheet I wrote this
morning.

The challenge here is not one-to-many or many-to-many communication
between sockets but the setup of network topology. I'm looking for a
dynamic topology with mechanisms to inform me as part of the topology
needs to change (e.g. due to crashes, shutdowns, new peers becoming
available, etc).

Traditionally messaging can't do this. Creating brokers is adding
another component to the system.


I'm getting errors if I start up a client socket (REQ) before the server
socket (REP). - "Assertion failed: fetched (z:\my
documents\development\c++\zeromq-2.0.7\src\rep.cpp:232)" happens in my
server process as I do the bind.


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

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