15-440 Distributed Project 3

• Frontend: 2048 web client mainly done in Javascript.
• Backend: A cluster of Go servers that stores the game state.
• Client-server communication: We are using websockets(which are supported in both Go and Javascript) to facilitate communication between the client and servers.
• Initial connection: We have a "central server" that gives connecting clients the hostport of the specific server that they should connect to.
• Distributed replication: We are using Paxos as a consensus and backup protocol among the servers.

This project uses the excellent go websockets implementation found at http://godoc.org/code.google.com/p/go.net/websocket. Please run go get "code.google.com/p/go.net/websocket" before running anything.

We will first launch the central server and provide a specific number of game servers that we expect to be connected. Next we will launch the game servers that will register with the central server.

Users will first go to a website that we are serving. On the client end, the website will do a GET request to the central server, which will give a response detailing the hostport of an available gameserver.

The website then facilitates a websocket connection attempt from the client to the game server. At this stage, users can use arrow keys and WSAD to do 'moves', which are sent to the gameserver via the websocket connection.

The servers agree on a majority move and update their respective game states, sending the game state back to the client. On the user-end, the website receives the game state and updates the 2048 board that the user sees.

Each server collects the moves sent by all of its clients within a set interval of time. That would be considered as a 'commit'. If this list of moves is non-empty, the server proposes the commit to the cluster via paxos. If it goes through, all the servers are now updated with a list of 'client moves'. This is how we maintain a common gate state among the servers.

We use a simple algorithm to estimate the number of clients. If the commit has x length, we know that there are roughly x active clients connected to that server. Thus we multiply by y, the total number of servers, to get z, target number of move votes. When z votes are collected, we simply count the majority vote and that will be the next move for the common game state. The update shall be propagated to the clients.

We are able to tolerate at most p failures given 2p+1 total servers courtesy of the paxos protocol. Upon connection failure, a client will repeatedly query the central server until it receives a new game server to connect to. This game server is not guaranteed to be alive. If it is not, the client will again ask the central server for a new server.

We wrote a Go client that runs on the command line specifically for testing purposes. In terms of functionality it is exactly the same as the javascript client. However, we modified it such that it could take a sequence of moves and send them at specified intervals to a gameserver, and is able to return the game state at any point in time. We have a function that simulates running an expected sequence of moves to arrive at some game state. We would then compare the board states to test if the outcome is as expected. We wrote tests with differing number of clients and servers and various scenarios to verify the robustness, correctness, and capacity of the system.

Test files are run exactly as they are without necessary arguments.

• simpletest.sh: A single test that serves more of an end-to-end sanity check that everything works as it should.
• stresstests.sh: Tests with increasing number of clients, moves, and decreasing move intervals.
• interruptedtests.sh: Introducing random delays (a.k.a. lag) of increasing length into the Paxos instances, so that RPC calls time out and message ordering is totally messed up.
• failtest.sh: Kill servers and check that game clients reconnect to another server, game state is preserved and replicated correctly via successful Paxos rounds.
• killall.sh: Not a test file, but useful for killing test processes if user Ctrl+C out of the test.

The Javascript 2048 client was taken from the 2048 project repository by Gabriele Cirulli and contributors and modified for our purposes.