[zeromq-dev] Any way to get info on subscribers?

Martin Sustrik sustrik at 250bpm.com
Sat Jul 24 18:01:00 CEST 2010


> I really like the idea of sticking to the connectionless model of 0MQ.
>  It takes a while to get used to, but we are finding that when we are
> forced to design without connection information, we write better apps.

Yes. That's the idea in the background: Enforcing scalable messaging 

Adding functionality like "get number of subscribers" breaks the 
scalability. You can use it as far as you need no devices in the middle. 
Once your business grows and you add devices to scale your application 
up the code using this feature would silently break.

The real problem here is that people have their applications written in 
non-scalable way and at the same time want to use 0MQ to replace their 
existing messaging infrastructure. The options are:

1. Forget about 0MQ, use BSD sockets (or something else) instead.
2. Refactor your app in a scalable way.
3. Add non-scalable features to 0MQ.

As 1 or 2 is often not an option, the idea proposed by Pieter (splitting 
0MQ into two pieces -- lower layer with no guaranteed scalability, but 
some useful features such as transport abstraction etc. and upper layer 
allowing only for scalable messaging patterns) makes sense.

>  But, we do end up creating applications that use other 0MQ sockets to
> communicate presence information.  To handle the case described here
> (knowing what SUBs are connected to a PUB), we would probably do:
> * Have the publisher also have an XREQ socket that the SUBS and use an
> XREP to notify the publisher of its presence.
> * For high availability/fault tolerance, give each subscriber a
> heartbeat and have the publisher monitor those to detect subscriber
> failures.
> While it take a bit to write this type of code, we find it works
> extremely well and honestly easier than handling connection logic in
> traditional TCP sockets.

I think the main use case here is that people often want two distinct 

1. "production subsystem" that handles the real work
2. "administrative subsystem" that keeps track of different components

(see attached diagram)

These two, IMO, should be clearly separated. However, with most legacy 
apps this is not the case.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsystems.png
Type: image/png
Size: 14615 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100724/653629f4/attachment.png>

More information about the zeromq-dev mailing list