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

Steven Clark steven.p.clark at gmail.com
Sun Jul 25 16:36:36 CEST 2010

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

Original poster here. Thanks for all the replies. I understand the concept
that 0MQ supports multiple transports, and that a notion of "connectedness"
only makes sense for some of them. However, I "know" that I am using TCP
(since I'm the one that created the bind string, of course). It seems
unfortunate that I am limited to functionality in the lowest common
denominator of all the transport types.

My use case is as follows: pretend there are two PUB sockets. One broadcasts
telemetry from NASA Rover A, one broadcasts telemetry from Rover B. Each
Subscriber is a technician that is observing a telemetry stream. I want to
be able to provide the technicians with a list of who is watching each of
the Rovers, such that the technicians could (if they choose) spread
themselves more evenly among the two Rovers, or perhaps call more people in
to work if there aren't enough eyes on a given Rover.

I was hoping to accomplish this with 2 PUB sockets, and N SUB sockets, but I
guess it jus' ain't that easy? What pattern of 0MQ sockets makes sense here?
(A further wrinkle: I want at most one of the N Subscribers to have
"command" capability to a given Rover. I was planning on making this take
place on a separate PAIR channel -- is this a good way?)

I agree that I need to have a mental-paradigm-shift to make better use of
0MQ. Brian's comment that "1 connection oriented TPC socket ==> multiple 0MQ
sockets bundled together" seems strange...isn't the role of middle-ware
usually to reduce complexity/reduce the number of things I need to create to
get the job done?

Thanks again for the discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100725/a7a1ccc9/attachment.htm>

More information about the zeromq-dev mailing list