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

Fri Aug 14 19:17:50 BST 2009

On Fri, Aug 14, 2009 at 10:53 AM, Paul Jones<pauljones23 at gmail.com> wrote:
> 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.

Can you subscribe one queue to one exchange with multiple keys, or is
the idea that each player would use one queue per game?

> 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.

Good to know.  I wasn't too worried about using one direct exchange,
but using one topic exchange seemed like a bad idea.

Thanks,
-n8

-- 
http://n8gray.org