How online-game clients are able to exchange data

问题:

Let's imagine really simple game... We have a labirinth and two players trying to find out exit in real time through internet.

On every move game client should send player's coordinates to server and accept current coordinates of another client. How is it possible to make this exchange so fast (as all modern games do).

Ok, we can use memcache or similar technology to reduce data mining operations on server side. We can also use fastest webserver etc., but we still will have problems with timings.

So, the questions are...

1. What protocol game clients are usually using for exchanging information with server?
2. What server technologies are coming to solve this problem?
3. What algorithms are applied for fighting with delays during game etc.

回答1:

Usually with Network Interpolation and prediction. Gamedev is a good resource: http://www.gamedev.net/reference/list.asp?categoryid=30

Also check out this one: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

回答2:

• use UDP, not TCP
• use a custom protocol, usually a single byte defining a "command", and as few subsequent bytes as possible containing the command arguments
• prediction is used to make the other players' movements appear smooth without having to get an update for every single frame

hint: prediction is used anyway to smooth the fast screen update (~60fps) since the actual game speed is usually slower (~25fps).

回答3:

The other answers haven't spelled out a couple of important misconceptions in the original post, which is that these games aren't websites and operate quite differently. In particular:

• There is no or little "data-mining" that needs to be speeded up. The fastest online games (eg. first person shooters) typically are not saving anything to disk during a match. Slower online games, such as MMOs, may use a database, primarily for storing player information, but for the most part they hold their player and world data in memory, not on disk.
• They don't use webservers. HTTP is a relatively slow protocol, and even TCP alone can be too slow for some games. Instead they have bespoke servers that are written just for that particular game. Often these servers are tuned for low latency rather than throughput, because they typically don't serve up big documents like a web server would, but many tiny messages (eg. measured in bytes rather than kilobytes).

With those two issues covered, your speed problem largely goes away. You can send a message to a server and get a reply in under 100ms and can do that several times per second.