This assignment can be done individually or as a pair.
You will build the multi-player game in pairs, so it might make sense to do the design as a pair.
In this project phase, you will be installing some software, doing some performance analysis, and working on a design plan for implementing your game.
Overview.
Your manager loves your single-player gem collector game so much, he wants you to make it into a multi-player online game.
Since it is a game, your manager is not really worried about high availability but it should be highly scalable.
Your manager has heard this memcached thingy has helped major web sites like YouTube, Flicr, and Craigslist scale.
So you should base your state management system around using memcached.
You can view a demo of the game you are designing.
You should assume there will be a web server farm running your game.
Players initially contact any server in the farm when they first start playing.
Your load balancer does NOT provide sticky sessions, so players may flop between web servers.
Each server in the farm will be running an instance of memcached.
You can make some use of MySQL if you really need to, but you'll have to justify it to your manager.
You can assume you can run persistent or periodic jobs (via Perl, Python, bash, whatever) on any or all the servers in the farm.
Game details.
All players in your game appear in the same world.
All players have to choose from the same set of avatars.
A player's avatar continues to appear in the game as long as the user has their browser open (even if they aren't currently moving around).
If a user closes their browser, their avatar disappears after a short period of time (approximately 5 seconds).
There is a 50% chance every 1 second a new gem appears, no more than 10 gems every appear in the game.
Game gems continue to be added regardless of the number of in-game players.
A gem can only be collected by one player.
You can see the name, point total, and any current chat message of all players in the game.
If your player collides with another player, both avatars stop moving (their target point becomes there current location).
Only a player can see where their current target position is (i.e. the cross mark).
Memcached.
Memcached is a high-performance, distributed, memory caching system.
Clients can contact the memcached daemon via TCP/UDP.
It is a key/value store based on hashing. It doesn't do anything very sophisticated compared to a SQL database.
Multiple instance of memcached can be running on the same server or on multiple servers.
A particular key/value pair is stored in a single location in the pool of memcache daemons.
Clients determine the server location based on a hashing the key and contacting the appropriate daemon.
Each daemon then finds the value by hashing the key as well.
Part 1: Installing memcached.
We can install the memcached server using Ubuntu's package management system.
Since we installed Apache/PHP from source, we have to install the PHP memcached extension directly using pecl.
Eventually you'll need to do this installation on both servers in your farm.
Edit your php.ini so it contains extension=memcached.so (usually this lives in /usr/local/lib/php.ini)
Start your Apache server, verify that memcached now appears in your phpinfo()
Investigate the various memcached startup option via memcached -h
Start your memcached server via memcached -d
Part 2: Benchmarking state management alternatives.
Being a good engineer, you decide to empirically test various state management options rather than just taking your manager's opinion on faith.
You will use ab to test incrementing 1000 unique keys using Apache file-based session state, MySQL, and memcached.
The file counter.zip has the PHP source code for the three benchmark pages.
Examine the code in counter_memcached.php to see how to use the memcached API.
You can find more details about the available memcached PHP function here.
You should probably have a look at the description for (at least) the get, set and check-and-set (CAS) methods.
For the PHP session benchmarking, be sure to send ab a fake PHPSESSID cookie using the -C switch. Otherwise your /tmp directory will fill with a session file for each request from ab
You will need to create the MySQL database and table by running counter.sql
Test with 10K requests with concurrency levels of 1, 8 and 16.
Report the requests per second as well as the time per request for each of the three methods (sessions, MySQL, memcached).
Part 3: State management design plan.
Create a text document describing the details of how, where, and what you plan to store to create your multi-player game.
This document should be detailed to the level of describing exactly what bits of state you are storing, how you are naming them, if and when they expire, etc.
Be sure to describe in the document your plan for handling the following situations:
When a new player first joins the game
When a player moves a bit in their client or types a new chat message
When a player needs to know the position of all the other players/gems
When a player intersects a gem
When two players intersect the same gem at nearly the same time
When a player doesn't interact with the game for awhile (but leaves the browser open)
When a player closes their web browser
When a player open their browser after be gone for awhile
When a player flops between servers in the web farm
Submission.
Submit your benchmark results and design document to the Moodle dropbox.
The Moodle timestamp is the completion time for the assignment.
