Thanks to Chris the ZeroMQ Erlang bindings have been updated to 2.0.7. The repository also moved from saleyn.github.com to zeromq.github.com/erlzmq. All documentation references have been updated.
Serge On 7/24/2010 12:43 PM, Brian Granger wrote: > > > On Sat, Jul 24, 2010 at 9:01 AM, Martin Sustrik <[email protected] > <mailto:[email protected]>> wrote: > > Brian, > > > I really like the idea of sticking to the connectionless model > of 0MQ. > It takes a while to get used to, but we are finding that when > we are > forced to design without connection information, we write better > apps. > > > Yes. That's the idea in the background: Enforcing scalable messaging > patterns. > > Adding functionality like "get number of subscribers" breaks the > scalability. You can use it as far as you need no devices in the > middle. Once your business grows and you add devices to scale your > application up the code using this feature would silently break. > > The real problem here is that people have their applications written > in non-scalable way and at the same time want to use 0MQ to replace > their existing messaging infrastructure. The options are: > > 1. Forget about 0MQ, use BSD sockets (or something else) instead. > 2. Refactor your app in a scalable way. > 3. Add non-scalable features to 0MQ. > > As 1 or 2 is often not an option, the idea proposed by Pieter > (splitting 0MQ into two pieces -- lower layer with no guaranteed > scalability, but some useful features such as transport abstraction > etc. and upper layer allowing only for scalable messaging patterns) > makes sense. > > > 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 > > Here is a diagram of a system that we are using this approach for: > > http://github.com/ipython/ipython/commit/e21b32e89a634cb1393fd54c1a5657f63f40b1ff > > We used to be using a single TCP socket for this. > > > But, we do end up creating applications that use other 0MQ > sockets to > communicate presence information. To handle the case described here > (knowing what SUBs are connected to a PUB), we would probably do: > > * Have the publisher also have an XREQ socket that the SUBS and > use an > XREP to notify the publisher of its presence. > * For high availability/fault tolerance, give each subscriber a > heartbeat and have the publisher monitor those to detect subscriber > failures. > > While it take a bit to write this type of code, we find it works > extremely well and honestly easier than handling connection logic in > traditional TCP sockets. > > > 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. > > Cheers, > > Brian > > These two, IMO, should be clearly separated. However, with most > legacy apps this is not the case. > > Martin > > > > > -- > Brian E. Granger, Ph.D. > Assistant Professor of Physics > Cal Poly State University, San Luis Obispo > [email protected] <mailto:[email protected]> > [email protected] <mailto:[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
