On Sun, Jul 25, 2010 at 1:38 AM, Martin Sustrik <[email protected]> wrote:
> 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... > > This idea is not at all obvious, because I tend to think of 0MQ as TCP++. I agree that we should make this clearer in the documentation. > > 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 > -- 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
