[rabbitmq-discuss] How to sanely bind one queue to many exchanges?

Fri Aug 14 18:53:36 BST 2009

Hi Nathan,

On Fri, Aug 14, 2009 at 6:29 PM, Nathan Gray <n8gray at n8gray.org> wrote:

>
> Maybe, maybe not.  I've written a multiplayer boardgame.  I used
> Google App Engine for the server, which works fine but requires that
> the client poll the server to detect when someone has made a move,
> sent a chat, or otherwise generated an event.  (GAE doesn't allow
> long-lived connections or raw socket access.)  I'm hoping to use
> rabbitmq as an "event server" to get real-time updates to clients
> without pounding GAE with HTTP requests.  When an event is generated
> for a game, GAE publishes to the event server, which tells any
> connected clients of the game to ask GAE for an update.
>
> There will be many games running, and each game has 2-4 players.  The
> natural mapping (IMHO) to AMQP is to have one fanout exchange per
> game.  The server on GAE creates this (durable) exchange when a new
> game starts.  When the game ends there will be no more events from it,
> so the exchange is deleted.  It's possible for a game to end before
> the client connects (the last player can play while the client is
> offline).  Each player can play multiple games, thus the requirement
> to connect to multiple exchanges.  Clients connect with auto-delete
> queues, since message content is uninteresting -- it's only the timing
> they care about.
>
> If there's a better way to do this I'm happy to hear it.  I could use
> one big direct exchange with player names as routing keys, but that
> would require my publisher to send multiple messages for each game
> event, one for each player in the game.  I could use one big topic
> exchange with routing keys like "joe.sally.bob" and subscribe with
> patterns like "#.bob.#", but putting all the messages through one
> topic exchange doesn't seem like it would scale well.
>

Assuming that there is a known identifier for each game (database id, guid,
or equivalent), what about using a single direct exchange, with the routing
key being set to the game id each time. When a player connects, they
subscribe to the exchange with all of the routing keys for the games that
they are interested in.

As far as scalability is concerned, using a direct exchange with many
routing keys should hopefully be no worse than many fanout exchanges with no
routing keys. If you're considering the clustering scenario, exchange
information is replicated to all nodes - so it isn't like there is a single
point that all messages need to go through.

Thanks,
Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090814/0d729d01/attachment.htm 