Windows Azure Toolkit for Social Games Version 1.2.2 Released

Posted on January 26, 2012

Today, I released version 1.2.2 of the Windows Azure Toolkit for Social Games. You can download the self-extracting package here. This version does not add any new features compared to the last (Version 1.2.0 – Beta), but this release is considered stable. We added a number of performance enhancements as well as optimized the setup of the Autofac dependency injection. The big news with this release is that we have moved the project to Github.

For those who haven’t downloaded or used the social gaming toolkit yet I would encourage you to check it out. There are a lot of common patterns and tons of reusable code in the toolkit that applies for many scenarios besides the gaming space. With more and more applications relying on real-time communication, sharing, and feedback the mechanisms that are used in games can be applied to many kinds of software.

Github

Since we started this project Github has become an increasingly popular place to host the open source projects. Additionally, the Windows Azure SDKs are now open sourced and available on Github. We have seen a great deal of support from the community in this move and believe that Github is the right place to host this toolkit. Our hope is that with the amazing support Github offers for social coding such as forking, pull requests, etc. more users will be able to utilize and contribute to this project.

For those of you that have not used git or Github before I highly recommend watching the Mastering Git video on Tekpub. It costs $15, but it is worth it if you like learning though videos. If you like learning by doing and reading the instructions Github has a great set of help documentation on there site.

Cloning a Repository

Rather than simply downloading the zip or self-extracting package of the Social Gaming Toolkit, you may want to clone the repository. Doing this will make it easier to pull in changes when we release future updates. It also allows you to make local changes to the toolkit and still update code that changes in future versions without loosing all your work.

In order to clone a repository first you must have git installed on your computer. You can download git here. After you have git installed simply open the command prompt and clone the repository using the following command.

git clone git@github.com:WindowsAzure-Toolkits/wa-toolkit-games.git

Forking a Project

One of the best features of Github is that you can easily fork projects and make your own edits. If you use this toolkit and want to keep your own version simply create a fork and make your edits. Additionally, if you make a change that you think everyone would benefit from simply send a pull request and request that we add your change to our fork.

Forking a repository is easy. Simply click the fork button and select where you want the fork to live.

After you have forked the project, you can push changed to your own repository. If you have a change that you want to be added to the original repository all you have to do is send a pull request.

If your pull request is accepted, your changes will be added to the original repository for everybody to use. Feel free to add features or fix any bugs you find and send us a pull request.

As always, feel free to leave comments, feedback, or suggestions. I would love to hear how you are using the toolkit and what you think about using Github.

Unlocking files that are in use.

Link

Unlocking files that are in use.

This is more of a note to myself, but I thought others may find it useful. You can use the Process Explorer tool that is part of SysInternals to figure out which program is holding the lock on your file and kill it. Very handy.

Windows Azure Toolkit for Social Games Version 1.2.0 (beta) Released

Posted on December 7, 2011

Today, I released version 1.2.0 (beta) of the Windows Azure Toolkit for Social Games. You can download the self-extracting exe here or get the source directly here. This release is primarily a maintenance release that includes bug fixes and enhancements to the code base. There aren’t any additional features in the release, but you should notice improved performance and stability. This is a ‘point’ release because there are a few breaking changes with the APIs that were made to clean up the overall code base.

This release is a ‘beta’ release because it did not go through our full QA process, but all the tests pass and it should be stable. I will be releasing a stable version of the 1.2.x branch shortly that has undergone the full QA tests to ensure the quality is up to par.

The biggest changes in this release is that we are now using dependency injection throughout the solution. The toolkit uses the great Autofac library for injection, but you could easily swap out another library if you prefer.

Below you will see how we setup MVC3 and the WCF Web APIs to use Autofac for DI.

// Setup AutoFac
var builder = new ContainerBuilder();
DependancySetup(builder);
var container = builder.Build();

DependencyResolver.SetResolver(
new AutofacDependencyResolver(container));

// Setup WCF Web API Config
var config = new WebApiConfiguration();
config.EnableTestClient = true;
config.CreateInstance = ((t, i, h) =>
DependencyResolver.Current.GetService(t));
RouteTable.Routes.SetDefaultHttpConfiguration(config);

Additionally, we updated all the Nuget packages to their most recent versions. This includes the WCF Web APIs to Preview 6 and jQuery to version 1.7.1. Finally, we fixed a few bugs. There was a memory leak that some people were seeing in the worker role that should be fixed.

Download and deploy the toolkit to Windows Azure today. Let me know if you have any feedback, questions, or if you find any bugs.

Windows Azure Toolkit for Social Games Version 1.1.1

Posted on November 18, 2011

I just released a minor update to the Windows Azure Toolkit for Social Games Version 1.1. You can download this release here. This release updates the toolkit to use Windows Azure Tools and SDK Version 1.6. Additionally, this release includes a few minor, but significant, performance enhancements.

Benjamin Guinebertière discovered the performance issues and was kind enough to share the results. Benjamin noticed that the response time between when the server gets a request to the time when the response begins was about 4 seconds. You can see this below by measuring the difference between “ServerGotRequest” and “ServerBeginResponse”.

Request Count:  1
Bytes Sent:     3 011	(headers:2938; body:73)
Bytes Received: 228	(headers:225; body:3)

ACTUAL PERFORMANCE
--------------
ClientConnected:    	16:33:24.848
ClientBeginRequest: 	16:33:45.247
ClientDoneRequest:   	16:33:45.247
Determine Gateway:  	0ms
DNS Lookup:           	0ms
TCP/IP Connect:      	1ms
HTTPS Handshake: 	0ms
ServerConnected:   	16:33:45.249
FiddlerBeginRequest:  	16:33:45.249
ServerGotRequest: 	16:33:45.249
ServerBeginResponse: 	16:33:49.973
ServerDoneResponse: 	16:33:49.973
ClientBeginResponse: 	16:33:49.973
ClientDoneResponse:   	16:33:49.973

Overall Elapsed:     	00:00:04.7260980

RESPONSE CODES
--------------
HTTP/200:		1

RESPONSE BYTES (by Content-Type)
--------------
       ~headers~:	225
application/json:	3

Benjamin setup and ran some tests to investigate the bottleneck. You can see how he added the traces below.

The results of this trace are show below. Notice that the action takes less than half a second to run. This meant that there was something outside of the action that was causing the problem.

After some investigation we discovered that we were calling the EnsureExists() method on every request in the game service. This was a mistake on our part and definitely not a best practice. You can see how the EnsureExists() method is called every time the repository is instantiated.

public GameRepository(
    IAzureBlobContainer gameContainer,
    IAzureBlobContainer gameQueueContainer,
    IAzureQueue skirmishGameMessageQueue,
    IAzureQueue leaveGameMessageQueue,
    IAzureBlobContainer userContainer,
    IAzureQueue inviteQueue)
{
    this.skirmishGameQueue = skirmishGameMessageQueue;
    this.leaveGameQueue = leaveGameMessageQueue;

    this.gameContainer = gameContainer;
    this.gameContainer.EnsureExist(true);

    this.gameQueueContainer = gameQueueContainer;
    this.gameQueueContainer.EnsureExist(true);

    this.userContainer = userContainer;
    this.userContainer.EnsureExist(true);

    this.inviteQueue = inviteQueue;
    this.inviteQueue.EnsureExist();
}

To fix this issue we created an EnsureExists() method on the GameRepository and moved all the queue and storage initialization methods there.

public void EnsureExist()
{
    this.gameContainer.EnsureExist(true);
    this.gameQueueContainer.EnsureExist(true);
    this.userContainer.EnsureExist(true);
    this.inviteQueue.EnsureExist();
    this.skirmishGameQueue.EnsureExist();
    this.leaveGameQueue.EnsureExist();
}

Next, we call this new method only once in our Global.asax Application_Startup. You can see that below.

protected void Application_Start()
{
    CloudStorageAccount.SetConfigurationSettingPublisher(
       (configName, configSetter) =>
    {
        string configuration = RoleEnvironment.IsAvailable ?
            RoleEnvironment
                 .GetConfigurationSettingValue(configName) :
            ConfigurationManager.AppSettings[configName];

        configSetter(configuration);
    });

    AreaRegistration.RegisterAllAreas();

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);

    FederatedAuthentication.ServiceConfigurationCreated +=
        this.OnServiceConfigurationCreated;

    // initialize blob and queue resources
    new GameRepository().EnsureExist();
    new UserRepository().EnsureExist();
}

After these changes the time for a request went down to less than 2 seconds. You can see the request and response times below.

This is a good improvement, but there are still several more changes like this we can do. I hope to release a new version in the next week or so that improves performance even more. Until then, give the updated version a try and let me know if you have any feedback.

Windows Azure Toolkit for Social Games Version 1.1

Posted on November 16, 2011

I am happy to report that we have updated the Windows Azure Toolkit for Social Games to version 1.1. You can download the release here. This version is a significant step forward and enables developers to more easily and quickly build out their social games on the Windows Azure Platform.

The biggest change we have made in this release is to separate the core toolkit from the Tankster game. After we released the Tankster sample game we received a lot of feedback asking for a simpler game that developers could use to learn. To meet this need we developed two simple games, Tic-Tac-Toe and Four in a Row, and included in the toolkit. The Tankster game is now available separately as a sample built on top of the toolkit.

Below you can see the sample Tic-Tac-Toe game.

While the new games included in the toolkit are much simpler than Tankster, they still show the same core concepts. You can easily use these samples as a starting point to build out any number of types of games. Additionally, you will find that many of the core components of the game such as the leaderboard services, game command services can be used without any modification to the server side or client side code.

The features included in the new version of the Windows Azure Toolkit for Social Gaming are listed below.

Sample Games: Tic-Tac-Toe and Four in a Row
Game Invitations
Leaderboards
Game Friends
User Profile
Tests for both server and client code
Reusable JavaScript libraries

In order to make the toolkit easy to setup and start using we have included our improved dependency checker and setup scripts. When you run the default setup you simply have to open the toolkit solution and run it. Everything is preconfigured to run on your local developer machine. You can read the full instructions for the setup here.
Windows Azure Toolkit for Social Games dependency checker.

In addition to running the toolkit locally you can also use the setup tools to configuration the toolkit for deployment to Windows Azure. You can read the full instructions for deploying the toolkit here. Publishing the toolkit is even easier than before with the updated Windows Azure Tools and SDK Version 1.6. You can see the updated publish dialog below.

Windows Azure Publish Dialog

As I mentioned previously, the Tankster game is still available for download as a sample. We will continue to update and release future versions of the Tankster game. For now, you can download Version 1.0 of Tankster here.

Finally, if you want to see the toolkit in action you can access it at http://watgames4.cloudapp.net/. Feel free to login and play a couple games of Tic-Tac-Toe or Four in a Row. If you use multiple browsers you can even challenge yourself to a game!

As always, please let me know if you have any comments or feedback.

Command-Query Separation on Windows Azure

Posted on October 24, 2011

Command-query separation is a fairly common approach to software development. There are a lot of different flavors and opinions on how it should be implemented, but at the core it is about separating your write methods from your read methods. This post will discuss one of the most common ways to use that pattern on Windows Azure. I am going to focus on the big picture of this rather than some of the finer details. There are plenty of articles out there on building hard-core CQRS systems if you want to dive into the details.

To begin, lets review a few of the concepts behind the command-query pattern. First, the core principle is that every method should either send data or receive data, but never both. Second, while the pattern itself isn’t focused on building to scale it works very well for many high scale applications. By combining the command-query pattern with some of our Windows Azure best practices we can create a highly reliable and scalable system that is both easy to design and easy to maintain.

Below you will see the basic steps in the command-query process.

When you review the diagram there are a few things to note. First, is that we are performing our read operations directly from blob storage. This allows us to rely on the high scale of the Windows Azure storage systems and offload some of our HTTP requests from our Web Role.

Second, the heavy lifting of this application (Step 7) occurs in a Worker Role. This allows us to have fewer Web Roles and to ensure our web server is doing minimal work so that it is always extremely responsive.

Finally, because every command goes through our Windows Azure storage queues we can control the rate at which data is processed more easily. For example, if we had a third-party web service that could only handle say 100 requests per second and our system was processing 200 requests per second we could throttle the worker processing back to ensure we don’t overload the third party server.

Before we dive into the example, I want to setup the scenario. For the purposes of this article we are going to build a simple command-query user registration system. The user registration will contain a simple form with first name, last name, email, and date of birth. The goal will be to register the user and return a registration token to the client after the registration is successful.

To begin the user is presented with the simple registration form.

(Step 1) After the user clicks register, we submit the form using some simple ajax. The sample uses ASP.NET MVC3 for the single service, but you could use anything you like. Below you will find the controller action.

[HttpPost]
public ActionResult Register(RegisterModel model)
{
	var queue =
		new AzureQueue<UserRegistrationMessage>
		(account);
	var registrationBlob =
		new AzureBlobContainer<RegistrationTokenEntity>
		(account, true);

	var containerId = Guid.NewGuid().ToString();
	registrationBlob.Save
	(containerId, new RegistrationTokenEntity
	{
		RegistrationToken = null,
	});

	var expires = DateTime.Now.AddHours(1);

	var blobContainer = registrationBlob
		.GetSharedAccessSignature(containerId, expires);

	queue.AddMessage(new UserRegistrationMessage
	{
		DateOfBirth = model.DateOfBirth,
		Email = model.Email,
		FirstName = model.FirstName,
		LastName = model.LastName,
		ContainerId = containerId,
	});

	return Json(new { container = blobContainer });
}

(Steps 2, 3, and 4) As you can see a few things are happening here. First, we are creating a random ID for the container. Next, we save the the blob container. The container we save has our token value set to null. Finally, we create the shared access token for the blob and return the blob url to the client. Below you can see the contents of the registration result blob in its initial state.

registrationtokenentityCallback({"RegistrationToken":null})

(Step 5) After we send the register post to the server our browser will show us a waiting page. In the background the browser is continually requesting the contents of the registration result blob. If the registration token is set to null, the client continues to poll the blob. This continues indefinitely. Note, in the real world you would want to handle the situation where there is either a failure and the blob doesn’t update or the processing is taking longer than usual.

(Steps 6,7, and 8) While the client is waiting for the registration result blob to update our worker role is polling the registration queue for new registrations. In this case a new registration is in the queue so the worker role reads the message. This is the point where you would do your heavy lifting. This could be anything from saving the registration to a database, sending it to a web service, validating for duplicates, etc. After your worker role is done processing the registration it creates a token for the registration. The worker then updates the registration result blob with the token.

registrationtokenentityCallback(
   {"RegistrationToken":"665864095"}
)

After the registration result blob is updated with the registration token the client stops polling the blob and displays the result. You can see the polling script below.

var waitingId = null;
var tokenUrl = null;
$(document).ready(function () {
	step(0);
	$('#register').validate({
		submitHandler: function (form) {
			$(form).ajaxSubmit(function (result) {
				tokenUrl = result.container;
				waitingId =
                   setInterval('checkForToken()', 1000);
				step(1);
			});
		}
	})
});

function checkForToken() {
	try {
		$.ajax({
			type: "GET",
			url: tokenUrl,
			dataType: "jsonp",
			jsonpCallback: 'registrationtokenentityCallback'
		});
	} catch (ex) { }
}

function registrationtokenentityCallback(data) {
	var regToken = data.RegistrationToken;
	if (regToken != null) {
		clearInterval(waitingId);
		$('#txtToken').text(regToken);
		step(2);
	}
}

That is the entire process for this basic command query example. The result is a flexible and distributed systems that allows you to handle even the largest scale.

You can find the entire source for this example on GitHub here or download the zip file here. Additionally, you can find a deployed version at http://simplecq.cloudapp.net.

Let me know if you have any questions.

Editing a Local Windows Azure Project with the Emulator Running

Posted on October 21, 2011

While working on another blog post today I just discovered a hidden gem in the Windows Azure Emulator. You can now edit projects and files while the emulator is running and view these changes without restarting the Windows Azure emulator. For anyone who does lots of local development for Windows Azure this is a huge time saver. These changes were actually made in SDK 1.3 and refreshed in SDK 1.4.1, but somehow I did not notice them.

To refresh your memory on how inconvenient this used to be here are the steps you would have had to go through to make a minor CSS change and preview it while running in the local emulator.

Make your edit
Run your application either through debugging (F5) or just by running it (Ctrl+F5).
Wait for the Windows Azure emulator to redeploy and start
Load your site.
Repeat.

In all this process would take 30 seconds to a minute or so depending on the machine you are on. While generally not a huge deal for most work, when you are doing something like testing your CSS design or fine tuning some JavaScript this could become very inconvenient.

With the changes to the local emulator you can now edit static content while debugging your project and simply refresh the browser to see the changes. If you are just running your project (not debugging) you can actually make changes to your code as well. You can rebuild any of your project files and the changes will be immediately available to preview or test in the browser. The only thing you can not do is rebuild your entire solution.

This is a small minor change, but hopefully this helps you save a little time when developing on Windows Azure.

Windows Azure at Seattle Interactive Conference

Posted on October 14, 2011

The Cloud Experience track at SIC is for experienced developers who want to learn how to leverage the cloud for mobile, social and web app scenarios. No matter what platform or technology you choose to develop for, these sessions will provide you with a deeper understanding of cloud architecture, back end services and business models so you can scale for user demand and grow your business.

Register today using the promo code “azure 200” and attend SIC for only $150 (a $200 savings).

Attend a full day of technical sessions and learn more about leveraging the cloud for mobile, web and social scenarios. View the list of confirmed Cloud Experience speakers. Sessions include:
- Great Mobile Apps Make Money – Intro to Cloud Experience Track
- Mobile + Cloud, Building Mobile Applications with Windows Azure
- Zero to Hero: Windows Phone, Android, iOS Development in the Cloud
- Building Web Applications with Windows Azure
- Building Social Games on Windows Azure
Cloud Experience speakers and technical experts will be available to provide technical assistance and resources for developing, deploying and managing mobile, social and web apps in the cloud.

Seattle Interactive Conference (SIC): November 2-3, 2011, The Conference Center at WSCC

Running Processes in Windows Azure

Posted on September 27, 2011

One of the little known features of the Windows Azure SDK 1.5 (September 2011) Release is the ability to directly run executables on startup without writing custom code in your WorkerRole or WebRole entry point.

This feature is facilitated by a new section in the service definition for the roles. You can see the new section and subsections below.

<Runtime executionContext="[limited|elevated]">
  <Environment>
	 <Variable name="<variable-name>" value="<variable-value>">
		<RoleInstanceValue xpath="<xpath-to-role-environment-settings>"/>
	  </Variable>
  </Environment>
  <EntryPoint>
	 <NetFxEntryPoint assemblyName="<name-of-assembly-containing-entrypoint>" targetFrameworkVersion="<.net-framework-version>"/>
	 <ProgramEntryPoint commandLine="<application>" setReadyOnProcessStart="[true|false]" "/>
  </EntryPoint>
</Runtime>

For purposes of this example we are going to duplicate the simple NodeJS worker role that was created in a previous post, but we are going to use the new ProgramEntryPoint functionality.

To begin we create a standard Windows Azure project with a single Worker Role.

Our starting point is a standard Worker Role.

The first thing we need to do is delete the WorkerRole.cs file. We won’t be using that file or any other C# code for this project.

Next, we add our node.exe and app.js files. Make sure to set the to “Content” and “Copy if newer”.

Next, we need to tell Windows Azure to run our node application after the role starts. To do this open the ServiceDevinition.csdef file.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject11" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WorkerRole>
</ServiceDefinition>

Now add the following lines to the csdef file. These lines tell Windows Azure that your role entry point is “node.exe app.js” and that when that process starts the role is ready. Note that we also added an endpoint for NodeJS on port 80 and also removed the diagnostics import.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject11" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Runtime executionContext="limited">
      <EntryPoint>
        <ProgramEntryPoint commandLine="node.exe app.js" setReadyOnProcessStart="true" />
      </EntryPoint>
    </Runtime>
    <Endpoints>
      <InputEndpoint name="NodeJS" protocol="tcp" port="80" />
    </Endpoints>
  </WorkerRole>
</ServiceDefinition>

Finally, we are ready to deploy our project. After you deploy the project you will see your NodeJS server running all without writing a single line of .Net code.

Another thing to note is that if your NodeJS server shuts down for any reason the Worker Role will recycle and restart the process. This way you don’t have to worry about restarting the services yourself.

While our example used NodeJS, you can use pretty much any process like this. There are also ways of using .Net code in this fashion as well to make it even easier to transition your existing application to Windows Azure.

You can see my working demo deployed here: http://simplenodejs.cloudapp.net/

Let me know how this works or if you have any questions or feedback.