>If you re-invent TCP on top of UDP without a thorough prior understanding of TCP, you will get it wrong.
I don't know why this is in there twice for emphasis. The use case for a custom TCP on top of UDP is pretty rare. More likely you will not want the kind of flow control and packet ordering that TCP spends its cycles doing.
And this isn't the only article that suggests that "re-inventing TCP" is what UDP network game code does.
Yes, you need to do some of the same things that TCP does, but not all of them and the ones you do should work differently.
Connection management is similar in TCP and UDP game protocols but you also need to keep track of ping and you probably don't need a fancy three way handshake either.
Reliability and in-order reception is something you don't need in UDP game code, especially reliability through retransmission. You need only semi-reliability, ie. knowing when a packet was lost. The way to handle a lost packet is application specific, but most likely you'd like to send the most up-to-date data instead of retransmitting the state from 100ms or one second ago.
Flow control needs to make sure that no more packets are sent than can be received but the goal is to minimize latency, not maximize throughput.
The whole idea of "implementing TCP over UDP" is just silly - why would you want to do that? There are very good reasons to use UDP and you should know when that is the case.
I think the point is that most of the time what you are doing is reinventing the basic idea of a TCP connection over UDP, with a few optimizations for your environment.
Now, the implementation may be different, but basically you have to deal with connection startup, connection teardown, packet loss, packet loss detection, and so forth.
In other words, what you are doing is taking the basic idea of TCP, and reimplementing a different take on that basic idea optimized for your application. Doing this benefits from a great deal of in-depth knowledge of current solutions, starting with TCP.
In other words, the danger is that you will try to do something TCP does without a real understanding of why it solves a problem in a particular way and come up with a very bad solution.
> I think the point is that most of the time what you are doing is reinventing the basic idea of a TCP connection over UDP, with a few optimizations for your environment.
The idea of TCP is to have a reliable ordered stream of bytes over a connection. The idea of an UDP game protocol is to have a semi-reliable, out-of-order, low latency packet oriented connection. In my opinion that is not the same basic idea.
They both operate over the internet using IP and face similar issues so similarities exist.
> In other words, the danger is that you will try to do something TCP does without a real understanding of why it solves a problem in a particular way and come up with a very bad solution.
This I will have to agree with. Before choosing UDP, it does make sense to try TCP first and figure out if and why it does or does not work for you. And then fix those issues with a UDP protocol if needed.
In some situations you do, but if the game has a matchmaking server you can just go.
>connection teardown
Packets stop when the game ends, no need to do anything special.
>packet loss
You have to deal with this but you don't have to use a similar method to what TCP does.
A minimal UDP protocol to meet the requirements of a game might not do nearly anything TCP does, yet work perfectly fine. A fancier protocol might have a TCP-like channel, but that's not a guarantee. And it's not hard to use UDP and TCP at the same time.
>If you re-invent TCP on top of UDP without a thorough prior understanding of TCP, you will get it wrong.
I don't know why this is in there twice for emphasis.
Because far too many people do it? I'll admit, my net-programming-fu is very weak, but every time I've seen someone say "we'll use UDP, it will be faster!", they then start trying to make it reliable and ordered, and they end up with a stinking, unreliable slow pile of crap, when they could have just started with TCP instead and optimized later.
By all means, if you don't need the guarantees that TCP gives, don't use it. But if all you're going to do is implement the features of TCP on top of UDP, why bother? You probably won't get it right the first time, and even if you do, you will have wasted time reinventing the wheel.
You say 'faster', danielweber says 'efficiency', I guess I've just never heard such ridiculous things said about UDP. I've only seen it suggested to avoid lag from the forced-in-order delivery.
And there are scenarios where you want to reimplement TCP, after thoroughly understanding TCP. TCP assumes that all packet loss is congestion and needs slowing. This can lead to very poor behavior, especially when it exponentially backs off. With a real-time connection it's better to never stop sending data entirely, backing off less and shutting down entirely if it can't get enough bandwidth.
And there are scenarios where you want to reimplement TCP, after thoroughly understanding TCP.
Yes, precisely; thorough understanding, then have a whack at only picking pieces of TCP you want. In my (limited) experience, I've almost always seen people with less knowledge of network programming than I have (!) try to reimplement most of TCP on top of UDP once they realize UDP was not what they wanted.
It's a pretty common anecdote that someone will start out using UDP for efficiency, and then end up, over time, re-implementing all the things TCP provides at some other layer where it's more expensive.
I don't know why this is in there twice for emphasis. The use case for a custom TCP on top of UDP is pretty rare. More likely you will not want the kind of flow control and packet ordering that TCP spends its cycles doing.