What's the difference between a Web Server and a Game Server?

Question

I'd like to build a turn-based, multiplayer iPhone game that will require a game server somewhere to connect the players and dish out the world state data. I'm trying to understand how the game server will work so I can begin designing and building it. Up until now, I only have experience with building web applications and so naturally my mind wants to design the game server to work in a similar fashion as a web server, but can it?

The ASP.NET MVC web servers I've used in the past work by the client sending a request for some web page data to the server and the server generates the HTML or XML or JSON and returns it to the client in an HTTP packet. This process sounds exactly the same for a multiplayer game, except the client probably won't be requesting HTML, but it would make sense to request XML or JSON data, right?

So my questions are...

1. Can a game server be written using ASP.NET MVC and work the same as a web server using a RESTful API designed by me?
2. Is there a better approach to requesting and receiving game data than using HTTP packets with XML or JSON data packed into them? The data being returned from the game server will be small.
3. Using a RESTful API to access data from a web server makes good sense, but using a RESTful API to request game data from a game server doesn't make sense and, in fact, sounds like it could cause security issues, your thoughts?
4. Lastly, can anyone recommend any good game books that show examples on how to build a decent game server?

Thanks so much in advance for your help!

Answer 1

The main difference is that a web server generates a lot of relatively static content using (relatively) little or no state information. Even when state is used, it is usually specific to the session or user. Reads are a lot more frequent than writes, so caching can help increase throughput. You can also trust web browsers to pass some state data and cookies in a (relatively) reliable way.

A game server on the contrary most of the time handles updates from clients, keeps a large amount of global state (all game, player, status state) and sends status updates to clients when they request them. Caching is impossible and you can't trust your clients to tell you the time of day - you have to assume they will try to cheat in whatever way they can.

Using a REST API is not such a problem, as you can use the standard authentication mechanisms you use already.

Chapter 3 of the book "Beautiful Architecture" describes the architecture of the Darkstar (now RedDwarf) project, a scalable application server for online games and virtual worlds. While the scale of RedDwarf is MUCH bigger than what you want, the book does describe what you need to address when creating a game server.