[zeromq-dev] Use case suggestions?

[Steven McCoy]

On 20 June 2011 21:56, Gary Strangman <gary.strangman at gmail.com> wrote:

>
> I don't think 0MQ (or, in fact, anything) can do all of this, but maybe it
> can do a lot. I've considered lower level comm (e.g., pub/sub via
> multicast), but that requires too much wheel-reinvention. I've also
> considered RabbitMQ, but that appears less friendly on config and expects
> links will be more up/stable than I am promised. I briefly looked at bigger
> DDS options (openDDS, OpenSplice, RTI) but they seemed a combination of
> complete overkill in some areas and insufficient in others. Any suggestions
> on how to best utilize 0MQ in such a setting (with or without other
> packages)? Any (even random) thoughts are welcome. :-)
>


Note that The Guide
<https://mail.google.com/mail/u/1/goog_1433148145>™<http://zguide.zeromq.org/chapter:all>
has
most of this covered already, certainly queuing and queue functionality is
above the remit of basic ØMQ socket implementation.  This is also all
certainly possible with products like IBM WebSphere MQ, TIBCO Rendezvous,
etc, but there are obviously downsides with each product to be considered,
from expense to complexity.  It is definitely a good idea to head towards a
common middleware system that is flexible enough to be adapted to each
situation.

There are a few things not listed, such as disconnected proxies, high
data-loss aware transports, multi-pathing, and possibly congestion control,
rate limiting not explicitly mentioned but implied that certainly limit your
choices a bit.  Note that you can integrate solutions like both ØMQ and
RabbitMQ which may make disconnected operation significantly easier:

https://github.com/rabbitmq/rmq-0mq

Also, ØMQ  is already integrated with OpenPGM so you get a great TCP and
multicast interchangeable pub/sub system for scaling to a significant number
of recipients with options to target a variety of different deployments.

The only real question that springs to mind is in regard to performance
requirements and pricing limitations, it is clear some queuing and
synchronous storage looks required but it's not obvious how far you wish to
push beyond a basic queue system like SMTP or UUCP.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110620/4136c5e7/attachment.htm>