3 ms·

I'm not sure I follow your argument. Say I want to communicate from player A the position of player A to player B. The position is really only relevant for a 20

I'm not sure I follow your argument. Say I want to communicate from player A the position of player A to player B. The position is really only relevant for a 200 ms time frame or so (the game might support teleports, jumping, dashing, etc). In a TCP setting, even if a packet is old (>200ms), I have no choice but to send it regardless, and all new packets must queue behind it. The whole point behind using UDP for games is that I can control what the resend policy is, which determines what ends up in the buffers you are referring to in your post. TCP gives me not only little to no choice in the matter, but often does the worst thing in a critical situation, especially in a game where input latency is 6 ms and the tolerance for network latency is <50 ms.

nrjdhsbsid 10y ago
You're right in that UDP will let you send the most updated data without requiring everything to be sent. My main issue was that UDP does not give you lower latency. TCP algorithms are extremely aggressive to the point I doubt you could get more recent packets on the wire with UDP. The problem is, the OS throws everything into the same buffer, and unless you're clairvoyant you won't be able to skip sending old packets into the buffer until it's too late. Basically by the time you know the data is outdated it's already on the way to the NIC buffer and you can't stop it, making TCP and UDP equal in this regard
- the_mitsuhiko 10y ago
  TCP does head of line blocking so your entire argument is just wrong. TCP by design cannot give you the latency guarantees that UDP can.
- Dylan16807 10y ago
  You're only considering the case when no packets are lost. Once TCP drops a packet, data sits in the receiving buffer getting older and older instead of being delivered to the program.
  - nrjdhsbsid 10y ago
    It's way more rediculous than you think. OS network stacks try to do the reasonable thing in most cases if possible. In the case of Linux TCP Vegas is very unlikely to drop any packet since the main algorithm is RTT based not drop. Red and hopefully codel can combat buffer bloat to some point but in the end all packets go to the same place
    - zurn 10y ago
      I think he meant the situation where the network drops a TCP segment, leading to head-of-line blocking.
    - barrkel 10y ago
      I see packet loss and spurious resends (lost acks) all the time on WiFi in certain locales. You are massively underplaying packet loss imo.
    - deleted 10y ago
      [deleted]
- hueving 10y ago
  Waiting for retransmission of a lost segment in front of you in the queue is massive latency.

nrjdhsbsid 10y ago

You're right in that UDP will let you send the most updated data without requiring everything to be sent. My main issue was that UDP does not give you lower latency. TCP algorithms are extremely aggressive to the point I doubt you could get more recent packets on the wire with UDP. The problem is, the OS throws everything into the same buffer, and unless you're clairvoyant you won't be able to skip sending old packets into the buffer until it's too late. Basically by the time you know the data is outdated it's already on the way to the NIC buffer and you can't stop it, making TCP and UDP equal in this regard

the_mitsuhiko 10y ago
TCP does head of line blocking so your entire argument is just wrong. TCP by design cannot give you the latency guarantees that UDP can.
Dylan16807 10y ago
You're only considering the case when no packets are lost. Once TCP drops a packet, data sits in the receiving buffer getting older and older instead of being delivered to the program.
- nrjdhsbsid 10y ago
  It's way more rediculous than you think. OS network stacks try to do the reasonable thing in most cases if possible. In the case of Linux TCP Vegas is very unlikely to drop any packet since the main algorithm is RTT based not drop. Red and hopefully codel can combat buffer bloat to some point but in the end all packets go to the same place
  - zurn 10y ago
    I think he meant the situation where the network drops a TCP segment, leading to head-of-line blocking.
  - barrkel 10y ago
    I see packet loss and spurious resends (lost acks) all the time on WiFi in certain locales. You are massively underplaying packet loss imo.
  - deleted 10y ago
    [deleted]
hueving 10y ago
Waiting for retransmission of a lost segment in front of you in the queue is massive latency.