3 ms·

Genuine question, other than NAT punchthrough what does UDP not include that you would want? It seems like unreliable packets are the foundation for anything el

Genuine question, other than NAT punchthrough what does UDP not include that you would want? It seems like unreliable packets are the foundation for anything else you'd want to build into a higher level protocol.

mikeash 10y ago
Just to clarify, UDP is a great primitive, it's about as close to how the underlying hardware works as you can reasonably get for a userland-accesible protocol, and anything that could work over the Internet in general can be built on top of UDP. I'd just like things to be a bit more "batteries included" as the Python folks would say. Consider, for example, that even TCP is unnecessary, as you could implement it on top of UDP, but we all benefit from having it built in. Anyway, I'd love to be able to pick and chose among: 1. Packets versus streams. 2. Reliable versus unreliable. 3. Immediate delivery, or delivery in the same order as data was sent. Right now, we have UDP, which is packets, unreliable, immediate, and TCP, which is streams, reliable, delivery in order of transmission. But all eight possible combinations make sense (albeit some more than others), and it's unfortunate that we have to reimplement stuff that already exists if we don't fit within the two choices we have. And if we're going beyond what TCP provides, I'd really like to see: 4. Choice of ACK versus NACK based loss notification. 5. Forward error correction. 6. Multihoming.
- vvanders 10y ago
  #1,2,3,4 are all pretty straightforward to build. I've done that more than a few times. There's a bunch of parameters that tend to increase complexity(how many ordered streams do you need, additional data associated with an endpoint, etc) that makes me think a one-size fits-all would be hard to do. #5 should really be done at the framing layer, otherwise your frame delimiters can also be corrupted. It's also very tied to physical layer and probably better off not being configured in platform agnostic software. No opinion on #6, I've not deal with it much AFAIK.
  - mikeash 10y ago
    I agree they're largely straightforward, but there would be a huge advantage in having one standardized version of each one rather than a million different buggy implementations. I also missed one, which is hard to get right: rate limiting. Especially if you want to coexist with TCP rather than drown it out (or be drowned out by it).

mikeash 10y ago

Just to clarify, UDP is a great primitive, it's about as close to how the underlying hardware works as you can reasonably get for a userland-accesible protocol, and anything that could work over the Internet in general can be built on top of UDP. I'd just like things to be a bit more "batteries included" as the Python folks would say. Consider, for example, that even TCP is unnecessary, as you could implement it on top of UDP, but we all benefit from having it built in. Anyway, I'd love to be able to pick and chose among: 1. Packets versus streams. 2. Reliable versus unreliable. 3. Immediate delivery, or delivery in the same order as data was sent. Right now, we have UDP, which is packets, unreliable, immediate, and TCP, which is streams, reliable, delivery in order of transmission. But all eight possible combinations make sense (albeit some more than others), and it's unfortunate that we have to reimplement stuff that already exists if we don't fit within the two choices we have. And if we're going beyond what TCP provides, I'd really like to see: 4. Choice of ACK versus NACK based loss notification. 5. Forward error correction. 6. Multihoming.

vvanders 10y ago
#1,2,3,4 are all pretty straightforward to build. I've done that more than a few times. There's a bunch of parameters that tend to increase complexity(how many ordered streams do you need, additional data associated with an endpoint, etc) that makes me think a one-size fits-all would be hard to do. #5 should really be done at the framing layer, otherwise your frame delimiters can also be corrupted. It's also very tied to physical layer and probably better off not being configured in platform agnostic software. No opinion on #6, I've not deal with it much AFAIK.
- mikeash 10y ago
  I agree they're largely straightforward, but there would be a huge advantage in having one standardized version of each one rather than a million different buggy implementations. I also missed one, which is hard to get right: rate limiting. Especially if you want to coexist with TCP rather than drown it out (or be drowned out by it).