Recently I have re-written a multiplayer game engine I wrote a couple of years ago to use sessions with the Azure Service Bus. I did not see a performance change in the handling of the messages in regards to elapsed time, but the pattern made the solution more scalable, more robust and less complicated. The re-write was inspired after a talk I attended by Dan Rosonova on Advanced Messaging Scenarios with Azure Service Bus Messaging. Thanks Dan!
In the previous platform, I have multiple worker roles running a collection of threads. Each thread is created to monitor and actively handle the interaction between 2+ players. This worked but I had to build in a mechanism to spawn a thread when a new game was started and to handle situations where the thread or the worker role might stop unexpectedly. The engine supports games that span multiple days so being able to load the game state on demand was also important.
I re-worked this to use the ability of the Service Bus to register a session handler in the worker role and to handle each game as a session (IMessageSessionHandler). The advantage over the previous implementation was instead of having a thread per game always active and waiting for messages from players, I now have a mechanism to launch handlers (i.e., threads) as messages were published to the Service Bus. As the hosted games could span days, this was a huge benefit.
I thought this was really cool so I distilled the essence of this into a MSDN Sample Project: Turn-based Game Engine built on Azure Service Bus.
The project implements tic-tac-toe to show how a session handler could be used to spawn a game engine for new games and when games are started again after an elapsed period of time.
The persistence was implemented by using Azure Table Storage. This meant that game state only lives on the server so the messages from the clients (re., players) would only consist of the move they made. The result of the move would then be persisted into storage and the result pushed back to the players.
Hope you enjoy!