Sign in to follow this  

UDP vs TCP *sigh* again

This topic is 4847 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Quote:
Original post by tok_junior
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.
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.


Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Michael Tanczos
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.


This isn't entirely true though. TCP has tons of settings, and a lot of validation to ensure it's functional on obsolete (and also never used) systems. Like i said up there, we have guaranteed ordering in our protocol, and it's still way faster than TCP.

Share this post


Link to post
Share on other sites
Probably because TCP has a handful other features like throttling and congestion control.

So, if you don't actually need what UDP offers, do everyone a favor and use TCP, to avoid any more internet congestion than neccesary. :)

If it's a turnbased game, I don't see a problem in using TCP, for example.

Share this post


Link to post
Share on other sites
Depends how fast the turns are, and how laggy players' connections are.

If the turns are happening in a human-playable time (500ms+ say), I'd say TCP. Because TCP is nice and robust, but more importantly, writing TCP code is much easier, because packets always arrive (or at least, if they don't arrive, the client must have disconnected).

You might want to tweak some socket settings to get the behaviour you want. The most common thing to do is to disable NAGLE (setsockopt(s, SO_NODELAY I think). Another thing to consider is whether a small number of badly lagged players will cause server lag - it has to be able to deal with this.

I guess your server needs to be clever enough to detect if a client has gone away (ideally BEFORE a TCP timeout) and kick it off the game, otherwise other players could be in for a long wait.

As far as efficiency of servers with a large number of sockets is concerned - there are some ways around it - but don't worry about it prematurely. Premature optimisation is evil. Worry about that once you have 10k players.

Mark

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Do TCP initially and if its fast enough for your use (which sounds like speed isnt as critical);

It will be simpler to get your guaranteed delivery and with alot less work that you can now spend on your game.

If you do need more speed, you can later take on making UDP do guaranteed delivery (I did it and it was alot of work, but I also added alot of optimization features possible with my particular App requirements).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by tok_junior
Like i said up there, we have guaranteed ordering in our protocol, and it's still way faster than TCP.


Could you give details, because this is *extremely* hard to believe?

My best guess? You weren't using TCP at full speed, either through ignorance or deliberately being cunning to make your protocol look better :D. Give me any TCP implementation and I can get it to run it at around 10% of the speed it normally goes at! It doesn't mean that something that runs 10 times as fast as *that* screwed-up TCP setup is "10 times faster than TCP", but it's enough that you would be safe to write that in adverts in the USA without getting sued...

There's even some companies claiming to have protocols that transfer data 30 times as fast as TCP (can't remember the URL, but it was on their front page :(). Those cases are marketing BS, being based on data that bares little or no relationship to real life (you could read their explanation - BS). The nearest I've seen to a protocol that is "much faster than TCP but with all the features" are some cunning stream compressors - but that's not really the same thing; it's a bit unfair to compare TCP to a compressed stream.

redmilamber

Share this post


Link to post
Share on other sites
I can, as soon as our network programmer gets back from his vacation. And he ran the benchmarks with the best settings/code for both protocols that he could think of, and considering he's been coding netcode for something like 15 years, i think he's doing it as well as anyone can possibly do it ;)

Share this post


Link to post
Share on other sites
A few years ago I wrote a TCP/IP stack for a company that ran under neath MS's stack on win NT /2000 to perform encryption/decryption/VPN/Firewall. TCP has overhead that you cannot control. TCP is a broad protocol that was designed to provide reliable data connectivity with the ability to scale for a broad number of applications. However for real-time (eg. game applications) it is not particulary suitable due to the resending of packets which are not necessary.
Look up dead-reckoning for info how you can optimise your protocol at the application level and use something like UDP for the base protocol.

edit:
EliteWarriorManTis for something like you describe which doesnt require real-time ability but is a MMORPG there is another thing you need to consider, and that is TCP connections take up resources in the OS. I do believe MS has improved their stack since I last checked and can support a much larger number of connections.
Also consider disconnects which leave resources tied up in the operating system for sometime.

Cheers

[Edited by - Jaltz on August 29, 2004 9:19:34 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
No, don't use both...it's usually a complete PITA (because you usually sooner or later have to synchronize the two separate streams, and that is nasty). There's a lot of ignorant people who advocate using both, and a few knowledgeable people - ignore the former, and listen very carefully to the precise words used by the latter: in the right situation, it's fine, but in general it's something to avoid.

As someone said, just use TCP first, and if it becomes a problem, move to eNet. If that's still not good enough (very very unlikely) then start worrying about writing a custom UDP-based system.

Share this post


Link to post
Share on other sites

This topic is 4847 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this