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