4 ms·

> why bother with UDP? Perhaps one of you can give a persuasive one Pretty much all video games use UDP.

exDM69 3y ago
Video games have a very good reason to use UDP: latency and lack of head of the line blocking. This also applies to video and audio live streams. But it's not the only reason to use UDP. It can open connections faster, accept out of order packets and generally offers a low overhead datagrams for building custom protocols.
amtamt 3y ago
This is right observation but not so right reasoning. Loosing a few pixels or missing some object updates won't be noticable in high fps games, but where correctness and completeness of data is needed, UDP based applications end up implementing TCP features in application layer. These application layer implementations can be more performant (low latency and/or high throughput) with UDP, utilizing the special cases, than TCP, which needs to provide generic facilities to every application running on the same host. And then it becomes a question of available resources vs benefits. Example: DNS started as UDP and later used TCP when expectations on correctness grew. That said, We have high capacity and high quality backbones that UDP looks right choice for many cases, and should be used where it makes sense.
- alfons_foobar 3y ago
  Nit: DNS supports TCP, but most DNS traffic is still over UDP
  - kkielhofner 3y ago
    DNS supports TCP largely because of packet fragmentation issues with UDP. I don't have a lot of experience with it but from what I understand DNS attempts to switch to TCP (with varying degrees of success by implementation) when the size of the response exceeds or is expected to exceed the MTU.
    - opless 3y ago
      DNS Supports TCP due to some responses to requests being > 64Kb Initially for domain transfers, and now for DNSSec etc where you can get rather large certificates embedded. Also it's rather handy if you're tunneling over a proxy that only supports TCP ;)
    - alfons_foobar 3y ago
      Yeah. For "regular" DNS (not zone transfers), TCP is mostly used as a fallback.
kkielhofner 3y ago
I suspect video games use UDP for the same reasons bidirectional real-time communications protocols (WebRTC, VoIP, etc) use them. Generally speaking when you have an interactive session with > 1 parties (especially humans) when/if packet loss or out of order packets occur there's no reason to attempt re-transmission because the clock, people, and application continually move forward in time. Consider a VoIP call - by the time a packet is retransmitted the conversation has moved on. Most audio codecs and implementations have a default packetization interval of 20ms of audio per packet so this is pretty granular. This has been mitigated somewhat with audio codecs like Opus that have packet loss concealment and forward error correction techniques that provide relatively high robustness to this issue. Variable latency (jitter) and out-of-order packets are typically handled by dynamic jitter buffers on each receiving side that can detect when the finely-clocked streams are wobbling. They then buffer incoming frames, potentially with re-ordering, and play them out smoothly with the side-effect being slightly higher latency to perform this (that's why they're dynamic).

Video games have a very good reason to use UDP: latency and lack of head of the line blocking. This also applies to video and audio live streams. But it's not the only reason to use UDP. It can open connections faster, accept out of order packets and generally offers a low overhead datagrams for building custom protocols.

amtamt 3y ago

This is right observation but not so right reasoning. Loosing a few pixels or missing some object updates won't be noticable in high fps games, but where correctness and completeness of data is needed, UDP based applications end up implementing TCP features in application layer. These application layer implementations can be more performant (low latency and/or high throughput) with UDP, utilizing the special cases, than TCP, which needs to provide generic facilities to every application running on the same host. And then it becomes a question of available resources vs benefits. Example: DNS started as UDP and later used TCP when expectations on correctness grew. That said, We have high capacity and high quality backbones that UDP looks right choice for many cases, and should be used where it makes sense.

alfons_foobar 3y ago
Nit: DNS supports TCP, but most DNS traffic is still over UDP
- kkielhofner 3y ago
  DNS supports TCP largely because of packet fragmentation issues with UDP. I don't have a lot of experience with it but from what I understand DNS attempts to switch to TCP (with varying degrees of success by implementation) when the size of the response exceeds or is expected to exceed the MTU.
  - opless 3y ago
    DNS Supports TCP due to some responses to requests being > 64Kb Initially for domain transfers, and now for DNSSec etc where you can get rather large certificates embedded. Also it's rather handy if you're tunneling over a proxy that only supports TCP ;)
  - alfons_foobar 3y ago
    Yeah. For "regular" DNS (not zone transfers), TCP is mostly used as a fallback.

kkielhofner 3y ago

I suspect video games use UDP for the same reasons bidirectional real-time communications protocols (WebRTC, VoIP, etc) use them. Generally speaking when you have an interactive session with > 1 parties (especially humans) when/if packet loss or out of order packets occur there's no reason to attempt re-transmission because the clock, people, and application continually move forward in time. Consider a VoIP call - by the time a packet is retransmitted the conversation has moved on. Most audio codecs and implementations have a default packetization interval of 20ms of audio per packet so this is pretty granular. This has been mitigated somewhat with audio codecs like Opus that have packet loss concealment and forward error correction techniques that provide relatively high robustness to this issue. Variable latency (jitter) and out-of-order packets are typically handled by dynamic jitter buffers on each receiving side that can detect when the finely-clocked streams are wobbling. They then buffer incoming frames, potentially with re-ordering, and play them out smoothly with the side-effect being slightly higher latency to perform this (that's why they're dynamic).