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.

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.

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

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).

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

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 ;)

I guess there is noway u can use only tcp or udp for a game, if u want a fast game u shuld use both.

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.