Routing Patterns

Routing keys in RabbitMQ are made up of words separated by dots. For example, the routing key user.created is made up of two words: user and created. The routing key peril.game.won is made up of three words: peril, game, and won.

RabbitMQ supports two types of wildcards in routing keys:

• * (star) substitutes for exactly one word
• # (hash) substitutes for zero or more words

A queue bound to the key peril.# will pick up messages published to routing keys:

• peril.game.won
• peril.game.lost
• peril.player
• peril

It will not match:

• game.won
• perilgame.won

A queue bound to the key peril.*.won will pick up messages published to routing keys:

• peril.game.won
• peril.player.won

It will not match:

• peril.game.lost
• peril.won

Whenever a player (client) uses the move command in our "Peril" game, we want to broadcast the move to all other connected players. We'll publish the message to the army_moves.username routing key, where username is the name of the player who made the move.

Each client needs to bind a queue to the exchange using the routing key army_moves.* so that they get all the moves from other players.

1. Each game client should subscribe to moves from other players before starting its REPL.
   1. Bind to the army_moves.* routing key.
   2. Use army_moves.username as the queue name, where username is the name of the player.
   3. Use the peril_topic exchange.
   4. Use a transient queue
   5. The handler for new messages should use the GameState's HandleMove method and then print a new > prompt for the user.
2. The move command in the REPL should now publish a move.
   1. Publish the move to the army_moves.username routing key, where username is the name of the player.
   2. Use the peril_topic exchange.
   3. Log a message to the console stating that the move was published successfully.

Test the changes by running 2 or 3 clients. Have one of the clients spawn a couple of units:

spawn americas infantry
spawn antarctica cavalry

Then move the units:

move asia 1 2

All clients, including the one who made the move, should log a message that they successfully detected the move.

Run and submit the CLI tests with the clients still running (and therefore their queues and bindings still in existence).