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

[Martin Sustrik]

Brian,

> I think there is a 4th option that I tend to prefer:
> 
> 4.  Implement the needed features (such as connection focused API and 
> presence features) on top of the scalable 0MQ core.  Here are some ideas...
> 
> We are finding that one of the keys to using 0MQ effectively is to stop 
> trying to replace each single TCP connection with a single 0MQ socket. 
>  Instead, the following mapping is much more useful:
> 
> 1 connection oriented TPC socket ==> multiple 0MQ sockets bundled together

WOW!!! You've put down the basic principle that nobody explicitly 
expressed so far! It should be put at the beginning of any 0MQ 
documentation in BIG RED LETTERS.

Let's think about how to convey the idea to people struggling to port 
their existing architectures to 0MQ...

>     I think the main use case here is that people often want two
>     distinct functionalities:
> 
>     1. "production subsystem" that handles the real work
>     2. "administrative subsystem" that keeps track of different components
> 
>     (see attached diagram)
> 
> 
> One thing that we did recently was to implement a 3 socket device that 
> is basically a queue device with an additional monitoring socket that 
> allows an administrator to monitor the device.  

Right. People do need all kind of bells and whistles for the 
intermediate nodes (devices).

I believe that aside of making webservers, databases etc. 0MQ-enabled it 
would be extremely useful to provide 0MQ connectivity for existing 
"messaging brokers" (RabbitMQ, ActiveMQ, etc.) That way users would be 
able to get features such as complex monitoring, persistence etc. just 
by incorporating a broker into their topology. The performance impact 
would be pretty severe, but in some cases it may be acceptable.

Martin