4 ms·

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 envi

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.

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.

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.