> > > > 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. -Steven
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
