[zeromq-dev] zeromq-dev Digest, Vol 34, Issue 124

[Martin Sustrik]

On 10/27/2010 04:26 AM, Thijs Terlouw wrote:

> +1 for connect/disconnect! We are working on a very similar scenario.
> We don't use ZeroConf, but our own discovery mechanism, but besides
> that almost everything Kelly described is what we want to do, and we
> too have run into the same issues that Kelly mentioned.

Let me first shortly repeat why I believe the connect/disconnect is a 
bad thing. Then I'll discuss some options of how to address the problem.

Connect/disconnect notifications work only if node A is connected to 
node B directly.

Say, there's a TCP connection between them, application A fails, B gets 
notified about the event by TCP. Easy.

If there's an intermediary node C in between A and B, B has no way to 
find out that connection between A and C have failed.

That in turn breaks the scalability. The scenario goes like this: You 
start with a simple distributed application where A speaks to B. Later 
on your business grows and you want to scale your application up. To do 
so you add intermediary node C. At that point the original code that was 
using connect/disconnect notifications stops to work :(

Now, I suppose those that need connect/disconnect functionality need it 
in cases where 0MQ library acts as a simple client with a single 
connection to the rest of the system. (Please, correct me if I am wrong.)

There are several options of how to solve the problem:

1. Implement a dumb sync client that happens to speak 0MQ wire-protocol.
2. Create a connect/disconnect patch and distribute it out of the 0MQ 
mainline.
3. Try to solve the problem in a systematic manner. That, AFAIU, boils 
down to a presence service, as seen in XMPP. The problem I see with that 
approach is that 0MQ is meant to be able to handle much larger number of 
potential peers than XMPP where you mostly have just a few buddies.

Martin