Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 9 down vote favorite
5

I'm currently working on a c# online multiplayer game in real-time. The aim is to have client/server based connection using the UDP protocol. So far I've used UDP for players' movements and TCP for events (a player shooting, a player losing life) because I need to be sure such data will arrive to all players connected to the server. I know that UDP is said 'unreliable' and some packets may be lost. But I've read everywhere to never mix TCP and UDP because it can affect the connection.

The main question is how should I organize my network?

UDP is connectionless, how should I save who's is who? Should I save ip adresses of the clients in a list?

Should I use TCP for important events or use UDP? If I need to use UDP, how can I make sure that data will not be lost?

By using both TCP and UDP, I need to save for each player their IP in a list (for UDP) and the TcpClient which is connected in another list (for the UDP). How could I change that to be more effective?

share|improve this question

2 Answers

up vote 6 down vote accepted

UDP has less overhead, but at the cost of losing packets without knowing about it (part of the overhead with TCP ensures that lost packets get re-sent).

However, the big problem with using UDP is that there are many sites that block all UDP traffic (except for DNS) because many administrators believe it's a good security practice.

Also, don't assume that every one of your players will have a different IP address -- there are many situations where multiple users share the same internet connection, and if school kids get hooked on your game you can bet that they're probably going to figure out how to install and run it during class instead of doing their work (and wouldn't you rather that they be spending this precious time on your game instead of someone else's?).

Once your TCP stream is open, it's still pretty efficient. The next step is to minimize the amount of data you're sending/receiving, and this is where protocol design comes into play. If you just send a few bytes for each command (e.g., "move forward") instead of, for example, wrapping the same command in hundreds of bytes of XML code, then your overall network bandwidth consumption will be lower AND fewer CPU cycles will be required to process the information (a few bytes are easily compared versus dismantling and interpreting and syntax-checking a big chunk of XML).

You certainly can open multiple TCP streams and use them for different purposes, such as one for commands, another for graphics transfers, another for audio-based chat, etc. That way, if you're transferring a large graphic that takes 5-10 seconds to download, at least player command movements won't lag because they'll be on a different stream (and you can display a default sprite until the new sprite is finished downloading, which is always more fun than waiting).

share|improve this answer
Original question mentioned a client-server model, so "sites" that block all UDP are irrelevant; that is the client's problem, and I doubt many client's actually do block all UDP. "Using TCP is the worst possible mistake you can make when developing a networked game! To understand why, you need to see what TCP is actually doing above IP to make everything look so simple!" See gafferongames.com/networking-for-game-programmers/udp-vs-tcp – indeed005 Sep 1 '11 at 0:43
@indeed005: There are pros and cons to this -- UDP definitely does provide a performance advantage, but at the cost of reliability (which is where TCP has the advantage). As for the UDP blocking, you're absolutely right about it being the client's problem, but in many corporate and educational environments I've encountered UDP (except for port 53) being blocked by clueless admins who think UDP is a security problem, and so the option for the client to fallback to TCP can at least mean that the player can experience the game (especially if network bandwidth is fast enough). – Randolf Richardson Sep 1 '11 at 3:34
@indeed005: Also, using a mixture of UDP and TCP can be quite acceptable as well since TCP can be used for the lower-priority data transfers, while UDP can be used for the high-speed action side of things. Interesting to note also is that with IPv6 there are new options available (that aren't available with IPv4) which may cater to the real-time needs of gaming while not being connectionless in nature, but I think it will be a while before IPv6 can be utilized by games without also having to rely on IPv4 (this is unfortunate, so we make do with IPv4 as best we can for now). – Randolf Richardson Sep 1 '11 at 3:38
up vote 3 down vote

This is not a direct answer to your question, but gafferongames has some really nice articles on network games: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.