5 ms·

UDP is used when it's designed by network engineers. That's why we have VOIP and video streaming - all are served UDP. dont get me started on the lack of multi

by nubb 11y ago

UDP is used when it's designed by network engineers. That's why we have VOIP and video streaming - all are served UDP. dont get me started on the lack of multicast out there. imagine game servers running multicast. one day.

chetanahuja 11y ago
Well... those are examples of designing custom protocols on top of UDP. These network engineers, who I assume are specially trained in some secret govt. facility for network commando training, actually have to understand the problem at hand and design something specifically for the problem. Calling these protocols just "UDP" is like saying something like "I use wheels to commute from home to office everyday"
- efaref 11y ago
  I would hardly call protocols like [SIP](https://www.ietf.org/rfc/rfc3261.txt https://www.ietf.org/rfc/rfc3261.txt) and [RTP](https://www.ietf.org/rfc/rfc3550.txt https://www.ietf.org/rfc/rfc3550.txt) "custom". There are many more standard protocols out there than just TCP and UDP. There's even a "better TCP" in the form of [SCTP](https://tools.ietf.org/rfc/rfc4960.txt https://tools.ietf.org/rfc/rfc4960.txt). The fact is that TCP was the MVP for reliable streams of data on the 1970s internet, and is woefully inadequate for modern usage, but we're stuck with it (including its oft-disabled parts like Nagle's Algorithm) because it's what's available everywhere. Game network protocols are pretty easy in comparison with some of the protocols I've encountered in my day job, especially once you've learned the lessons of people like the author of that article.
  - chetanahuja 11y ago
    'I would hardly call protocols like [SIP]... and [RTP]... "custom".' The meaning of "custom" in this context was to distinguish it from a full TCP or raw UDP. Not to imply that there's no standard definitions for VOIP protocols. Quite the contrary in fact. The point being made is that UDP is just a substrate to create other protocols that also need to be designed for a purpose. And just calling all these protocols "UDP" is a mistake. Btw, not to be argue from authority, but to back my words with some context, I'm responsible for at least one such "custom" protocol myself. https://packetzoom.com/blog/ https://packetzoom.com/blog/
deleted 11y ago
[deleted]
- samplonius 11y ago
  I debate whether multicast has any use case in gaming. When online gaming started, it was fairly common to send the entire world state to all clients. Multicast helps when you are sending the same data to everyone. but online gaming started, worlds were small (think Quake I level). However, this type of model does not scale as the world size increases, and eventually the world is too big to send everything to every client. Plus, cheating. Sending the entire world state to every client, opens up cheating vectors. The trend has been for the game server to send only state that the particular client can actually see or needs. This limits the damage of what a compromised client can do. Plus, it allows the world size to scale up.
  - Dylan16807 11y ago
    Sending a fraction of the entire world state is still enormous for most non-FPS game types. It would benefit from multicast. Also, map-hack-style cheating will always be common because of games that take the efficient rout, sending only inputs.
  - kbenson 11y ago
    There's nothing preventing you from sharding the world state into multiple multicast streams which clients could access/subscribe to as needed. You would still get the benefit of not sending massively duplicated data, and additionally clients wouldn't be downloading large portions of world state that are either useless, an exploit vector (even if it just exploits the game), or both.
  - derefr 11y ago
    Don't picture a single multicast connection socket for all clients. Picture a multicast pub/sub topic model: each client would have a regular unicast socket to send to the server, but to receive, each client would subscribe to a set of server-multicast channels, one listener-socket per channel. For each event, the server would find (or create) a multicast-socket channel that has only the correct subscribers, and push the message once over that multicast socket. The network would then do the job of making that message arrive on every client. And, of course, you can separately encrypt each multicast channel[1], handing out keys over a regular 1:1 TCP+TLS "control" socket to the clients. (This would usually be merged with the client's unicast "send" socket.) Guess what design I have just coincidentally described? Cable set-top-box pay-per-view! (The original kind, not the "over-the-top" access-on-demand kind which is effectively equivalent to Netflix.) In legacy STB PPV, each movie stream chunk is an "event" as described above; each stream is separately encrypted; and each set-top-box gets a low-bandwidth TCP-like duplex control channel to the head office to request and receive keys for streams. People requesting the same movie at the same time get put into a queue and then bucketed on ~15min intervals; each bucket gets temporarily allocated a UHF band; and then a stream is broadcast over that band to everywhere that head-office reaches, injected on the line similarly to a local public-access cable TV channel, but only existing for two hours. --- [1] If your clients are okay with their bandwidth being wasted, you can be a bit sloppier and get away with fewer (or even just one) multicast socket(s). Imagine a multiplayer game like Starcraft: you could push every player's update events to all players... encrypted with keys in a keybag whose owners are the people the event should be visible to. Clearing fog-of-war would literally involve the client performing an action that the server responds to by sending a key to decrypt previously-received opaque event data. This matches the model of how, say, collaboration software treats group ACLs: being granted access to a new group means being given the key to decrypt the object-change-events within the global event stream that were relevant to that group.
samplonius 11y ago
Most video streaming today is not served by UDP, but by TCP. Only live video uses UDP. Stored video (ex. Netflix) is all sent via TCP.
- nacs 11y ago
  > Only live video uses UDP Not necessarily. One of the largest live video streaming services, Twitch.tv, uses TCP for streaming.
  - gafferongames 11y ago
    Twitch is not interactive so it can just buffer for a few seconds more and handle the typical worst case of TCP. It'd probably still be better over UDP but I'm not qualified to say that for sure. I'm sure the twitch.tv guys could chime in on their choice and inform us of the pros and cons for their situation. The correct choice is application specific.
perlgeek 11y ago
> UDP is used when it's designed by network engineers. UDP is used when low latency and low jitter is more important than complete information. For telefony it's better to lose a few packets than to wait a second or two for a retransmit. Some for game state, I believe. And I do believe that TCP was also designed by network engineers :-)
- Retric 11y ago
  I really depends on the game, if your writing a chess game then TCP is a much better choice than UDP. Though for anything really complex your probably going to want to use both.
- jorangreef 11y ago
  UDP is a lower level protocol than TCP so it's not an either/or as in "use UDP when low latency etc." is important and TCP when not. Rather, you'd want to use a protocol built on UDP whenever you want something faster, better, more reliable than TCP.
jamesblonde 11y ago
A lot more traffic than you can imagine comes over UDP. Most Bittorrent traffic (used to be a majority of traffic on the Internet!) comes over LEDBAT, which runs over UDP, https://tools.ietf.org/html/rfc6817 https://tools.ietf.org/html/rfc6817. WebRTC by Google is now using UDP for most things, because NAT traversal is not really possible over TCP (due to the 3-way handshake, and the SYN-SYN connection setup not being widely supported by OSes).
__d 11y ago
UDP multicast is widely used by financial trading networks to distribute state-of-the-market updates. Getting those networks to work reliably (ie. right groups distributed to right places with minimal packet loss, reordering, latency and jitter) is orders of magnitude more difficult than getting unicast traffic working. I don't think it's going to happen. Our current networks can't even do unicast well (eg. bufferbloat, general ISP randomness). But I'd be keen to read the OP's rants if someone tried ...
jwatte 11y ago
Multicast at global scales is fundamentally broken. Every router on the internet would have to know about every potential peer wanting to join a multicast group.
- fanf2 11y ago
  Wide-area multicast is usually one-way, which is much easier: each router only needs to know each which streams are to be fanned out to which of its nearest downstream neighbours, and where to forward upstream multicast group join requests.
jwatte 11y ago
Multicast at global scales is fundamentally broken. Every router on the internet would have to know about every potential peer wanting to join a multicast group.

by nubb 11y ago

chetanahuja 11y ago

Well... those are examples of designing custom protocols on top of UDP. These network engineers, who I assume are specially trained in some secret govt. facility for network commando training, actually have to understand the problem at hand and design something specifically for the problem. Calling these protocols just "UDP" is like saying something like "I use wheels to commute from home to office everyday"

efaref 11y ago
I would hardly call protocols like [SIP](https://www.ietf.org/rfc/rfc3261.txt https://www.ietf.org/rfc/rfc3261.txt) and [RTP](https://www.ietf.org/rfc/rfc3550.txt https://www.ietf.org/rfc/rfc3550.txt) "custom". There are many more standard protocols out there than just TCP and UDP. There's even a "better TCP" in the form of [SCTP](https://tools.ietf.org/rfc/rfc4960.txt https://tools.ietf.org/rfc/rfc4960.txt). The fact is that TCP was the MVP for reliable streams of data on the 1970s internet, and is woefully inadequate for modern usage, but we're stuck with it (including its oft-disabled parts like Nagle's Algorithm) because it's what's available everywhere. Game network protocols are pretty easy in comparison with some of the protocols I've encountered in my day job, especially once you've learned the lessons of people like the author of that article.
- chetanahuja 11y ago
  'I would hardly call protocols like [SIP]... and [RTP]... "custom".' The meaning of "custom" in this context was to distinguish it from a full TCP or raw UDP. Not to imply that there's no standard definitions for VOIP protocols. Quite the contrary in fact. The point being made is that UDP is just a substrate to create other protocols that also need to be designed for a purpose. And just calling all these protocols "UDP" is a mistake. Btw, not to be argue from authority, but to back my words with some context, I'm responsible for at least one such "custom" protocol myself. https://packetzoom.com/blog/ https://packetzoom.com/blog/

deleted 11y ago

[deleted]

samplonius 11y ago
I debate whether multicast has any use case in gaming. When online gaming started, it was fairly common to send the entire world state to all clients. Multicast helps when you are sending the same data to everyone. but online gaming started, worlds were small (think Quake I level). However, this type of model does not scale as the world size increases, and eventually the world is too big to send everything to every client. Plus, cheating. Sending the entire world state to every client, opens up cheating vectors. The trend has been for the game server to send only state that the particular client can actually see or needs. This limits the damage of what a compromised client can do. Plus, it allows the world size to scale up.
- Dylan16807 11y ago
  Sending a fraction of the entire world state is still enormous for most non-FPS game types. It would benefit from multicast. Also, map-hack-style cheating will always be common because of games that take the efficient rout, sending only inputs.
- kbenson 11y ago
  There's nothing preventing you from sharding the world state into multiple multicast streams which clients could access/subscribe to as needed. You would still get the benefit of not sending massively duplicated data, and additionally clients wouldn't be downloading large portions of world state that are either useless, an exploit vector (even if it just exploits the game), or both.
- derefr 11y ago
  Don't picture a single multicast connection socket for all clients. Picture a multicast pub/sub topic model: each client would have a regular unicast socket to send to the server, but to receive, each client would subscribe to a set of server-multicast channels, one listener-socket per channel. For each event, the server would find (or create) a multicast-socket channel that has only the correct subscribers, and push the message once over that multicast socket. The network would then do the job of making that message arrive on every client. And, of course, you can separately encrypt each multicast channel[1], handing out keys over a regular 1:1 TCP+TLS "control" socket to the clients. (This would usually be merged with the client's unicast "send" socket.) Guess what design I have just coincidentally described? Cable set-top-box pay-per-view! (The original kind, not the "over-the-top" access-on-demand kind which is effectively equivalent to Netflix.) In legacy STB PPV, each movie stream chunk is an "event" as described above; each stream is separately encrypted; and each set-top-box gets a low-bandwidth TCP-like duplex control channel to the head office to request and receive keys for streams. People requesting the same movie at the same time get put into a queue and then bucketed on ~15min intervals; each bucket gets temporarily allocated a UHF band; and then a stream is broadcast over that band to everywhere that head-office reaches, injected on the line similarly to a local public-access cable TV channel, but only existing for two hours. --- [1] If your clients are okay with their bandwidth being wasted, you can be a bit sloppier and get away with fewer (or even just one) multicast socket(s). Imagine a multiplayer game like Starcraft: you could push every player's update events to all players... encrypted with keys in a keybag whose owners are the people the event should be visible to. Clearing fog-of-war would literally involve the client performing an action that the server responds to by sending a key to decrypt previously-received opaque event data. This matches the model of how, say, collaboration software treats group ACLs: being granted access to a new group means being given the key to decrypt the object-change-events within the global event stream that were relevant to that group.

samplonius 11y ago

Most video streaming today is not served by UDP, but by TCP. Only live video uses UDP. Stored video (ex. Netflix) is all sent via TCP.

nacs 11y ago
> Only live video uses UDP Not necessarily. One of the largest live video streaming services, Twitch.tv, uses TCP for streaming.
- gafferongames 11y ago
  Twitch is not interactive so it can just buffer for a few seconds more and handle the typical worst case of TCP. It'd probably still be better over UDP but I'm not qualified to say that for sure. I'm sure the twitch.tv guys could chime in on their choice and inform us of the pros and cons for their situation. The correct choice is application specific.

perlgeek 11y ago

> UDP is used when it's designed by network engineers. UDP is used when low latency and low jitter is more important than complete information. For telefony it's better to lose a few packets than to wait a second or two for a retransmit. Some for game state, I believe. And I do believe that TCP was also designed by network engineers :-)

Retric 11y ago
I really depends on the game, if your writing a chess game then TCP is a much better choice than UDP. Though for anything really complex your probably going to want to use both.
jorangreef 11y ago
UDP is a lower level protocol than TCP so it's not an either/or as in "use UDP when low latency etc." is important and TCP when not. Rather, you'd want to use a protocol built on UDP whenever you want something faster, better, more reliable than TCP.

jamesblonde 11y ago

A lot more traffic than you can imagine comes over UDP. Most Bittorrent traffic (used to be a majority of traffic on the Internet!) comes over LEDBAT, which runs over UDP, https://tools.ietf.org/html/rfc6817 https://tools.ietf.org/html/rfc6817. WebRTC by Google is now using UDP for most things, because NAT traversal is not really possible over TCP (due to the 3-way handshake, and the SYN-SYN connection setup not being widely supported by OSes).

__d 11y ago

UDP multicast is widely used by financial trading networks to distribute state-of-the-market updates. Getting those networks to work reliably (ie. right groups distributed to right places with minimal packet loss, reordering, latency and jitter) is orders of magnitude more difficult than getting unicast traffic working. I don't think it's going to happen. Our current networks can't even do unicast well (eg. bufferbloat, general ISP randomness). But I'd be keen to read the OP's rants if someone tried ...

jwatte 11y ago

Multicast at global scales is fundamentally broken. Every router on the internet would have to know about every potential peer wanting to join a multicast group.

fanf2 11y ago
Wide-area multicast is usually one-way, which is much easier: each router only needs to know each which streams are to be fanned out to which of its nearest downstream neighbours, and where to forward upstream multicast group join requests.

jwatte 11y ago

Multicast at global scales is fundamentally broken. Every router on the internet would have to know about every potential peer wanting to join a multicast group.