views:

140

answers:

4

I'm thinking like the methods games like Counter Sstrike, WoW etc uses. In CS you often have just like 50 ping, is there any way to send information to an online MySQL database at that speed?

Currently I'm using an online PHP script which my program requests, but this is really slow, because the program first has to send headers and post-information to it, and then retrieve the result as an ordinary webpage.

There really have to be any easier, faster way of doing this? I've heard about TCP/IP, is this what I should use here? Is it possible for it to connect to the database in a faster way than indirectly via the PHP script?

A: 

Most systems out there keep a connection between the server and the client open at all times. HTTP is actually a pretty fast protocol. If you are breaking down and restarting a connection every time you want to send a packet, you are spending a lot of time doing that.

You want to set thing up so that you can efficiently add information to the stream without having to wait for the response and without having to reconnect frequently. There are some buss services that will connect clients and servers, HTTP with maintained connections with keep alive can also help.

I would recommend hunting down some good books on the subject though. There are tons of tools and libraries out there.

Good luck. Jacob

TheJacobTaylor
+3  A: 

TCP/IP is made up of three protocols:

  1. TCP
  2. UDP
  3. ICMP

ICMP is what you are using when you ping another computer on a network.

Games, like CounterStrike, don't care about what you previously did. So there's no requirement for completeness, to be able to reconstruct what you did (which is why competitors have to tape what they are doing). This is what UDP is used for - there's no guarantee that data is delivered or received. Which is why lag can be such a problem - you're already dead, you just didn't know it.

TCP guarantees that data is sent and received. Slower than UDP.

There are numerous things to be aware of to have a fast connection - less hops, etc.

OMG Ponies
+1 Nicely put - I know that UDP is "connectionless" and that there is no guarantee of delivery.... but I've never considered the potential for performance gain.... Excellent! (+1 for you too kyoryu)
NTDLS
Typically, games will build a reliability layer on top of UDP for messages which *do* need to be received, and do not 'expire'. So movement updates will be sent unreliably, while things like death messages or chat will be sent reliably.
kyoryu
+2  A: 

Most games like the ones you cite use UDP for this (one of the TCP/IP suite of protocols.) UDP is chosen over TCP for this application since it's lighter weight allowing for better performance and TCP's reliability features aren't necessary.

Keep in mind though, those games have standalone clients and servers usually written in C or C++. If your application is browser-based and you're trying to do this over HTTP then use a long-lived connection and strip back the headers as much as possible, including cookies. The Tornado framework may be of interest to you there. You may also want to look into HTML5 WebSockets however widespread support is still a fair way off.

If you are targeting a browser-based plugin like Flash, Java, SilverLight then you may be able to use UDP but I don't know enough about those platforms to confirm.

Edit:

Also worth mentioning: once your networking code and protocol is sufficiently optimized there are still things you can do to improve the experience for players with high pings.

oops
+3  A: 

Client-to-server for latency-critical stuff? Use non-blocking UDP.

For reliable stuff that can be a little slower, if you use TCP make sure you do so in a non-blocking fashion (select(), non-blocking send, etc.).

The big reason to use UDP is if you have time-sensitive data - if the position of a critter gets dropped, you're better off ignoring it and sending the next position packet rather than re-sending the last one.

And I don't think any high-performance game has each and every call resolve to a call to the database. It's more common to (if a database is even used) persist data occasionally, or at important events.

You're not going to implement Counterstrike or anything similar on top of http.

kyoryu