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 <[email protected]>
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
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[email protected]
[email protected]
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
