How to tunnel multi-player game data over HTTP with IIS to minimize latency?

Question

I would like to create a browser-based network game. To ensure it can be used by as many people as possible, I'd like to embed all the traffic in standard HTTP packages.

Assuming I use IIS as my back end, how should I code this to minimize latency?

Is it reasonable to start with an ASP application of some kind (ASP.NET MVC perhaps) using shared state in memory? Or should I plan from the outset on writing some kind of IIS plugin of my own? Or should I abandon IIS and write a custom server instead?

Is it reasonable to start with each client repeatedly querying, say ten times per second, or should I make the data more stream-like somehow (and if so how)?

Answer 1

Designing an app to hit a web server 10 times a second is not a good idea. Web servers are designed for less frequent client requests and probably larger processing times and reponse sizes than your game will be using. That's not to say a web server wouldn't be able to cope just that it would not be an efficient client-server match.

For any type of app that requires multiple packets per second you really should think about a lighter protocol than HTTP which is fairly verbose. For example if your game needs to send 4 bytes to register a user's battleship co-ordinates you don't really want to transmit an extra few hundred bytes of HTTP headers.

I'd recommend a browser plugin technology like Siverlight of Flash. Both of those support TCP socket connections. You would need to write your own server to sit at the other end of the TCP socket. With that approach you'd also have the advantage of being able to push data out to the clients without having to rely on client polling mechanisms which are required with HTTP, e.g. AJAX.

Answer 2

This can work just fine, but you're going to have to do something less "conventional."

To make this work, don't do individual requests, keep the request open and then transmit data with the open connection.

You could try using a protocol like Bayeux, but there are no rules here.

Here's an example with ASP.NET using COMET.

Answer 3

One problem you will face with standard HTTP messages is the size (and lack of control) over the header data.

I was involved in the design of a flash game which was played by several million people. We needed to communicate with the server every few seconds and ended up using ultra-lightweight JSON messages to save on bandwidth and keep it snappy.

Size of JSON message: 16 bytes

Size of HTTP Header: 200+ bytes

HTTP is not really a good protocol for high traffic, low latency requirements. It was designed for larger, less frequent request/response models and has status codes like 304 Not Modified for this very reason.

You'll probably want to drop down to a custom TCP/IP implementation.