UDP vs TCP *sigh* again
Author
I've just joined the community, but I've started reading Multiplayer section from the very beggining. I saw that mostly you recomended UDP for multiplayer games in real time. What if I'd like to create MMORPG, but with battles that take place in turns (a trading card MMO game for example). Is TCP fast enough for this?
TIA for answering
probably. bascally the general caveat with UDP v. TCP is if the packet doesn't absolutely need to get there then UDP is a good choice, if it does absolutely need to get there then TCP is required (or some mechanism of guaranteed UDP delivery that you write yourself which will really just be TCP). so things like frame by frame position updates -> UDP, but things like player spawn -> TCP.
-me
-me
I'm no networking expert, but I'd say a definite TCP on this one. The data that you would send needs to be received. TCP guarantees this. If you used UDP, then you would have to implement your own methods of guaranteeing that the data got received. This implementation would probably at best be equivalent to TCP, probably not better. So just use TCP, and let it do all the work for you. I believe the reason UDP is used in realtime games is because if the data doesn't arrive one second, newer data will the next, and it doesn't really matter if not every single piece of data is received. But in turn based stuff, all data needs to be successfully received. So TCP is the logical choice, in my opinion.
I would concur.TCP assure you that what you send is recived.It's very simple to use.
UDP is used where sending a large amount of packets per second an where all packets are, not absoulutely neccesary to be recived
Turn Based stuff like card games will work better when you use TCP than UDP since one persons move can(should) never be missed.
UDP is used where sending a large amount of packets per second an where all packets are, not absoulutely neccesary to be recived
Turn Based stuff like card games will work better when you use TCP than UDP since one persons move can(should) never be missed.
Actually, our protocol is built on UDP, with optional guaranteed delivery and guaranteed ordering. But with both options enabled, it's still heaps faster than TCP.
So use UDP, but build a decent protocol on top of it :)
So use UDP, but build a decent protocol on top of it :)
Quote:Original post by tok_juniorReally? I'll remember that when I get involved with networking heavily (and feel like I have time to put into doing all the extra work that I could avoid by being lazy and going with TCP).
Actually, our protocol is built on UDP, with optional guaranteed delivery and guaranteed ordering. But with both options enabled, it's still heaps faster than TCP.
Quote:Original post by Agony
Really? I'll remember that when I get involved with networking heavily (and feel like I have time to put into doing all the extra work that I could avoid by being lazy and going with TCP).
Yup, and this is with the extra overhead of IOCP aswell. The networking-engine and it's protocol is meant for our MMO-engine.
Unless you need IOCP, you'll be able to slice of some extra latency by removing that functionality.
If you have a turn-based game, then I'd do things in this order:
1) Use TCP, because it's everywhere, well understood, and realiable. However, TCP cannot do NAT punch-through if you're peer-to-peer.
2) Use Enet (on top of UDP) if you need to do peer-to-peer. Enet has optional guaranteed delivery functionality.
3) Only if neither of these work for some reason would I code my own, on top of UDP.
Edit: with "Enet" I really mean any already-developed, already-tested library. The Torque Network Library may also qualify, for example.
1) Use TCP, because it's everywhere, well understood, and realiable. However, TCP cannot do NAT punch-through if you're peer-to-peer.
2) Use Enet (on top of UDP) if you need to do peer-to-peer. Enet has optional guaranteed delivery functionality.
3) Only if neither of these work for some reason would I code my own, on top of UDP.
Edit: with "Enet" I really mean any already-developed, already-tested library. The Torque Network Library may also qualify, for example.
There are several reasons why udp is a better choice here. For example, you can send data which is unreliable really fast, for example position updates.
When it comes to reliable data, it can be divided into categories, for instance, chat packets dosn't have anything to do with player state updates, so if a player state update is lost, there is no need for a chat message to sit around and wait in the incomming queue for the player state message to be resent. It can be dealt with immediatly. This cannot be done with TCP unless you open new connections, with your own reliable protocol on top of udp, it is trivial.
The next part i am not 100% sure of but it is what i imagine is true.
When it comes to mmorpgs, performance of the server is very important. With TCP, each client need its own socket filedescriptor. Lets say you are doing a multiplatform server so you want to use select() (or poll() on *nix, i dont know if iocp fits well in such an architecture), i imagine that for select to scan trough alot of sockets takes alot more time that to scan just one for i/o readiness, especially if we are talking thousands of connections.
When it comes to reliable data, it can be divided into categories, for instance, chat packets dosn't have anything to do with player state updates, so if a player state update is lost, there is no need for a chat message to sit around and wait in the incomming queue for the player state message to be resent. It can be dealt with immediatly. This cannot be done with TCP unless you open new connections, with your own reliable protocol on top of udp, it is trivial.
The next part i am not 100% sure of but it is what i imagine is true.
When it comes to mmorpgs, performance of the server is very important. With TCP, each client need its own socket filedescriptor. Lets say you are doing a multiplatform server so you want to use select() (or poll() on *nix, i dont know if iocp fits well in such an architecture), i imagine that for select to scan trough alot of sockets takes alot more time that to scan just one for i/o readiness, especially if we are talking thousands of connections.
The only difference between UDP and TCP is that TCP guarantees delivery by sequencing packets. Essentially each packet is given a number in sequence (SEQ) and it is up to the protocol stack to acknowledge (ACK) the number of the packet it expects next. TCP doesn't operate by a send one packet, acknowledge one packet scenario but instead relies on a concept known as sliding windows. A "window" is a number of bytes, or conceptually a number of packets that can be sent before an acknowledgement is expected. This will vary in conjunction with the connection speed to make optimal use of the available bandwidth. The TCP protocol *will* reassemble all packets into the right order before allowing you to access them through application interfaces.
Bottom line, using UDP is excellent for realtime games in many cases because packets can sometimes be dropped without many side effects if your game has some level of predictive capabilities.
So it is not a matter of which is faster.. UDP is only faster by virtue of not having the overhead necessary to guarantee packets will be received in order.
For your case (a turn-based game), TCP is absolutely what you want for the transmission of game logic information unless you plan on reinventing TCP on the application level through UDP (which would be a waste of your time). Skipping turns is really not an option.
---
Michael Tanczos
Bottom line, using UDP is excellent for realtime games in many cases because packets can sometimes be dropped without many side effects if your game has some level of predictive capabilities.
So it is not a matter of which is faster.. UDP is only faster by virtue of not having the overhead necessary to guarantee packets will be received in order.
For your case (a turn-based game), TCP is absolutely what you want for the transmission of game logic information unless you plan on reinventing TCP on the application level through UDP (which would be a waste of your time). Skipping turns is really not an option.
---
Michael Tanczos
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
