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

[Matt Weinstein]

Historical note:

A few early PubSub implementations used specially crafted control  
messages (e.g. messages starting with '.' or '_') within the pubsub  
stream.  A service process on each node would subscribe to these  
messages and tweak the network configuration, suppress unneeded  
publishes, manage connectivity, heartbeats, retransmissions, etc.

Your application could also subscribe and monitor the health of the  
system.


On Jul 24, 2010, at 12:46 PM, Brian Granger wrote:

>
>
> On Sat, Jul 24, 2010 at 7:38 AM, Martin Sustrik <sustrik at 250bpm.com>  
> wrote:
> Pieter,
>
> >> This info is in principle not available. 0MQ abstracts from the  
> notion
> >> of individual connections. All you have is an opaque cloud of  
> peers.
> >
> > Does that cloud have to be opaque by definition?  For example, the
> > publisher socket knows how many clients have connected to it, and
> > could report this to the application via getsocketopt...
>
> My rationale for hiding the info is that the semantics are not
> consistent across different topologies:
>
> 1. In direct PUB/SUB over TCP you get number of consuming apps.
> 2. With PUB/SUB over multicast you get no sane value.
> 3. With TCP and a device(s) in the middle you'll get more or less  
> random
> number that has nothing to do with number of subscribing apps.
>
>
> What about using 0MQ identities for this?  They are uniform across  
> transports and can propagate across devices.
> It seems like identities are the main abstraction in 0MQ for a  
> remote endpoint.
>
>
> >> All in all, if you need to handle individual connections  
> manually, you
> >> should go for standard sockets rather than 0MQ.
> >
> > 0MQ sockets do several useful things above TCP sockets:
> >
> > * transport abstraction
> > * message queuing
> > * message bundling
> > * automatic reconnection
> > * message framing incl. multipart
> > * routing patterns
> >
> > Using TCP sockets forces one to recreate all this work, which is
> > pretty horrid.  If one wants to use a custom routing pattern (e.g.  
> to
> > do content based routing), then 0MQ might offer "raw" sockets that  
> do
> > all the work except the routing, and allow the application to do  
> that.
> >  It still adds significant value over TCP.
>
> Can be done. Of course, it means splitting the 0MQ codebase into two
> parts, meaning a *lot* of both design and implementation work.
>
> Martin
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> -- 
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu
> ellisonbg at gmail.com
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100724/0899eaa9/attachment.htm>