3 ms·
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
by exDM69 13y ago
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.
- einhverfr 13y agoI 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.
- exDM69 13y ago> 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.
- Dylan16807 13y ago>connection startup 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.
- einhverfr 13y ago> You have to deal with this but you don't have to use a similar method to what TCP does. Particularly if you are not using the similar methods, a thorough understanding of TCP is helpful. Otherwise you run into the possibility of reinventing TCP badly.