3 ms·

UDP will always be relevant when you have head of line blocking and temporal data that expires quickly.

• bullen 8y ago
  Well, if you set the ack freq. to 0 then TCP becomes UDP. Right now it's hard coded to 2 which is just weird.
  • vvanders 8y ago
    This has nothing to do with sending. On the receiving side you can't receive newer packets when a missed packet exists with an earlier sequence ID. Ex: 4 -> 5 -> X -> 7 -> 8 -> 9 Until the client gets 6 then 7,8,9 will be held(and getting stale) until you roundtrip 6. At that point 9 may even be useless since it would be too stale and you've just added extra latency that you don't want or need. Look up how dead-reckoning is done in realtime games, this is one of many other cases where having timely data works better over UDP than TCP.
    • bullen 8y ago
      If you would be able to set ack. freq. to 0 = no ack. needed; you would not want ordering, just like UDP but over TCP. Why would you want that you might ask, because then you can choose if you want order over the same protocol precisely for games. For context I built this multiplayer platform, not that that prooves anything but I have 20 years of working with multiplayer: http://fuse.rupy.se/about.html http://fuse.rupy.se/about.html
      • vvanders 8y ago
        The reason you can't do that is because you would no longer have a stream based protocol which is one of the core requirements of TCP. Really there's no up-side to doing it that way with UDP already existing and tons of downsides in changing an existing protocol in such a fundamental way.