[rabbitmq-discuss] Is rabbitmq appropriate for messaging to thousands of transient clients?

[Tony Garnock-Jones]

Hi Josh,

Josh Gruenberg wrote:
> Is this a good idea?

OK, so we're looking at peaks of 10000 clients, each talking about once
a second. That message rate is fine, but you'll have to do the usual
kind of C10K tuning and tweaking to get your kernel and Erlang VM able
to accept that many connections at once.

> 1. The intuitive implementation would involve creating a private queue
> for each client to receive messages.  This would imply 10k
> client-specific queues and 10k connections.  Any concerns there?

Not on the queues front, and on the connections front, it should just be
down to kernel and erlang VM tuning. Should. If there are problems, we
definitely need to know so that they can be fixed! Your scale of
deployment is something Rabbit squarely aims to cover, IMO.

> 2. Mobile gaming sessions are typically short-lived; current
> projections suggest we may sometimes see 10 sessions starting/ending
> per second (implying 10 connections and queues being created and
> destroyed per sec, with several associated bindings each).  Will this
> thrashing be sustainable?

Oo. OK, that's interesting. It *should* be ok... but I haven't tried it
myself.

> Will AMQP/rabbit help with
> this, or would we need to implement our own deduplication logic?

Currently, deduplication is a pure client-side issue. We do support the
AMQP "redelivered" flag, though which

 - is guaranteed false if this is known by the server to be the very
   first time this message has been sent out from a queue to a consumer
   or getter

 - is guaranteed true if there's any doubt, that is, if there's even
   the slightest possibility a receiving client may have seen the
   message before

This lets you avoid any dedup buffer lookups for messages that are
guaranteed first-time deliveries.

> 4. Security is obviously a concern. We've brainstormed the following strategy:
>     - provision temporary credentials for each client session to
> authorize access to the shared vhost (revoked upon session expiry)
>     - create each client queue from the server, sending its name to the client
>     - manage all queue bindings from the server in response to client requests
> This way, all routing configuration would be handled by the server,
> and clients would only know the name of their one queue (and a few
> exchanges for messaging specific server-side actors.)  Is this wise?

It seems reasonable. Others may have more detailed comments. ;-)

> Do these characteristics spell trouble?  Are there existing real-world
> installations that successfully connect large client-bases directly to
> rabbitmq?

I believe so, but others can confirm or deny for sure.

Another approach you could take, given the high disconnect/reconnect
load you anticipate, and the custom security requirements you have, is
to hack your existing TCP transport so that it backs into the AMQP
routing, queueing and delivery model. That way you get to reuse the core
of RabbitMQ, and all of the careful design of AMQP, with a
lighter-weight and more domain-focussed wire protocol. How's your
Erlang? ;-) (See, e.g., the STOMP adapter for an example of how this
might be done.)

Regards,
  Tony