Hi Nathan,<br><br><br><div class="gmail_quote">On Fri, Aug 14, 2009 at 6:29 PM, Nathan Gray <span dir="ltr"><<a href="mailto:n8gray@n8gray.org">n8gray@n8gray.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Maybe, maybe not. I've written a multiplayer boardgame. I used<br>
Google App Engine for the server, which works fine but requires that<br>
the client poll the server to detect when someone has made a move,<br>
sent a chat, or otherwise generated an event. (GAE doesn't allow<br>
long-lived connections or raw socket access.) I'm hoping to use<br>
rabbitmq as an "event server" to get real-time updates to clients<br>
without pounding GAE with HTTP requests. When an event is generated<br>
for a game, GAE publishes to the event server, which tells any<br>
connected clients of the game to ask GAE for an update.<br>
<br>
There will be many games running, and each game has 2-4 players. The<br>
natural mapping (IMHO) to AMQP is to have one fanout exchange per<br>
game. The server on GAE creates this (durable) exchange when a new<br>
game starts. When the game ends there will be no more events from it,<br>
so the exchange is deleted. It's possible for a game to end before<br>
the client connects (the last player can play while the client is<br>
offline). Each player can play multiple games, thus the requirement<br>
to connect to multiple exchanges. Clients connect with auto-delete<br>
queues, since message content is uninteresting -- it's only the timing<br>
they care about.<br>
<br>
If there's a better way to do this I'm happy to hear it. I could use<br>
one big direct exchange with player names as routing keys, but that<br>
would require my publisher to send multiple messages for each game<br>
event, one for each player in the game. I could use one big topic<br>
exchange with routing keys like "joe.sally.bob" and subscribe with<br>
patterns like "#.bob.#", but putting all the messages through one<br>
topic exchange doesn't seem like it would scale well.<br>
</blockquote><div><br>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. <br>
<br>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.<br>
<br>Thanks,<br>Paul.<br></div></div>