Brian, > 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 > > (see attached diagram) > > > One thing that we did recently was to implement a 3 socket device that > is basically a queue device with an additional monitoring socket that > allows an administrator to monitor the device. Right. People do need all kind of bells and whistles for the intermediate nodes (devices). I believe that aside of making webservers, databases etc. 0MQ-enabled it would be extremely useful to provide 0MQ connectivity for existing "messaging brokers" (RabbitMQ, ActiveMQ, etc.) That way users would be able to get features such as complex monitoring, persistence etc. just by incorporating a broker into their topology. The performance impact would be pretty severe, but in some cases it may be acceptable. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
