4 ms·

The point of the article is that calling a protocol reliable doesn't make sense. You can (and should) use UDP if you don't care about (or you have a special way

The point of the article is that calling a protocol reliable doesn't make sense. You can (and should) use UDP if you don't care about (or you have a special way of handling) packet loss, and instead need to receive the latest packet as soon as possible. In the context of multiplayer FPS games and remote controlling drones -- it is actually more reliable.

eptcyka 1y ago
The protocol is reliable in the sense that the protocol provides guarantees where either party can know that the other party received something. UDP provides no such guarantees. I'm a fan of using UDP where applicable, I loathe TCP-in-TCP, not at all a fan of head of line blocking, but I don't need to call UDP reliable just because it is a great protocol with it's own usecases.
- Kiboneu 1y ago
  TCP does not guarantee delivery, and there are cases where getting confirmation of receipt actually makes the /channel/ less reliable. Again, the point is not to call UDP reliable, it's that it doesn't make sense for the reasons I stated above. If you choose the wrong tool for a usecase then the communication channel will be unreliable in either case. There's a lot of confusion about this -- it is valid to call a communication channel unreliable for the system to respond accordingly, not the protocol itself.
  - eptcyka 1y ago
    TCP does not guarantee delivery, but it guarantees that if you receive an ACK, then the acknowledged bytes were received. UDP provides no such guarantee. Yes, it is OK to call it unreliable, because you can't rely on it to reliably deliver packets - the sender will never know if the packets it sent were ever delivered without any external validation. Game servers and clients work around this by being fault-tolerant. QUIC runs on UDP but the way it achieves reliability is by implementing reliability of TCP in the application layer. You cannot expect to receive all UDP packets you send to yourself on localhost, I think that it is reasonable to call such a network protocol unreliable, in the sense that one cannot reliably know if sent packets have ever been delivered within the confines of the protocol itself.
    - Kiboneu 1y ago
      (I don't know if you've seen my edit. I re-read your response to answer more relevantly to your point about ACK. But to be honest I still don't think it's correct.)
      - eptcyka 1y ago
        I see, and I still believe that as far as network protocols go, UDP allows for unreliable communication and TCP allows for reliable communication, at least at a naive first glance. I don't see anything wrong with UDP being labeled as unreliable. Is there a particular reason you believe it is reliable? Say if UDP was a reliable network protocol, what would be an unreliable network protocol?
        Kiboneu 1y ago
        > Is there a particular reason you believe it is reliable? I don't, nor do I think it is unreliable. Protocols exist in an abstract space, but they are instantiated in a system that works within physical /constraints/ (noise, faults, oxidation, etc.). These constraints vary because different systems work in different environments. The systems we make also have to provide utility for the /purposes/ that it's made. Reliability is necessary to trust the utility of a system. If I'm playing a multiplayer FPS game and due to backoff I see players snapping back to the position of a lost packet once it is received, I will not think that the game is reliable (and I will be especially sad since this is known issue with known improvements). If I don't care about old packets and only care about the latest packet, I don't work with old information -- but the information is incomplete. Latency will still be noticeable on a noisy connection, but my brain can at least anticipate -- guess where to look next -- once the last packet is received. That incomplete information can be used to extrapolate movements. So the final step is to use a model to predict movements in (short) moments when a packet is not received. You can't do this when the information isn't relevant anymore. When that's done, I -- the player -- will feel like that game is more reliable than the first TCP case. (Games, and real-time interfaces in general, have some interesting aspects that I think is well covered in Game Feel by Steve Swink).
        1y ago
jeroenhd 1y ago
The article willfully misinterprets the way "reliable" is used to talk about the protocol, as if people use the word to insult UDP. Either that or it's slop that somehow made it to the front page.
cestith 1y ago
We use UDP a lot. I mean, a whole lot. Sometimes it’s bare UDP within a site. Some of that is unicast and some is multicast. Sometimes it’s UDP with a bunch of custom protocol logic around it between sites, handling buffering, reordering, retransmission, and more. I never said UDP wasn’t sometimes fit for purpose. I said it’s unreliable compared to TCP. Those are not the same statement. Sometimes reliability isn’t part of the spec, so you do without that or build your own reliability around it if the less reliable option is still a better fit. This is common in the industry, actually. The ‘I’ in RAID stands for inexpensive, because it’s a redundant array. We scale horizontally these days where we can because more cheaper servers can sometimes scale further and more reliably than fewer more premium servers. Heck, a paper cup is unreliable compared to ceramic or stainless steel, but Starbucks and Tim Horton’s move a lot of product in them.

eptcyka 1y ago

The protocol is reliable in the sense that the protocol provides guarantees where either party can know that the other party received something. UDP provides no such guarantees. I'm a fan of using UDP where applicable, I loathe TCP-in-TCP, not at all a fan of head of line blocking, but I don't need to call UDP reliable just because it is a great protocol with it's own usecases.

Kiboneu 1y ago
TCP does not guarantee delivery, and there are cases where getting confirmation of receipt actually makes the /channel/ less reliable. Again, the point is not to call UDP reliable, it's that it doesn't make sense for the reasons I stated above. If you choose the wrong tool for a usecase then the communication channel will be unreliable in either case. There's a lot of confusion about this -- it is valid to call a communication channel unreliable for the system to respond accordingly, not the protocol itself.
- eptcyka 1y ago
  TCP does not guarantee delivery, but it guarantees that if you receive an ACK, then the acknowledged bytes were received. UDP provides no such guarantee. Yes, it is OK to call it unreliable, because you can't rely on it to reliably deliver packets - the sender will never know if the packets it sent were ever delivered without any external validation. Game servers and clients work around this by being fault-tolerant. QUIC runs on UDP but the way it achieves reliability is by implementing reliability of TCP in the application layer. You cannot expect to receive all UDP packets you send to yourself on localhost, I think that it is reasonable to call such a network protocol unreliable, in the sense that one cannot reliably know if sent packets have ever been delivered within the confines of the protocol itself.
  - Kiboneu 1y ago
    (I don't know if you've seen my edit. I re-read your response to answer more relevantly to your point about ACK. But to be honest I still don't think it's correct.)
    - eptcyka 1y ago
      I see, and I still believe that as far as network protocols go, UDP allows for unreliable communication and TCP allows for reliable communication, at least at a naive first glance. I don't see anything wrong with UDP being labeled as unreliable. Is there a particular reason you believe it is reliable? Say if UDP was a reliable network protocol, what would be an unreliable network protocol?
      - Kiboneu 1y ago
        > Is there a particular reason you believe it is reliable? I don't, nor do I think it is unreliable. Protocols exist in an abstract space, but they are instantiated in a system that works within physical /constraints/ (noise, faults, oxidation, etc.). These constraints vary because different systems work in different environments. The systems we make also have to provide utility for the /purposes/ that it's made. Reliability is necessary to trust the utility of a system. If I'm playing a multiplayer FPS game and due to backoff I see players snapping back to the position of a lost packet once it is received, I will not think that the game is reliable (and I will be especially sad since this is known issue with known improvements). If I don't care about old packets and only care about the latest packet, I don't work with old information -- but the information is incomplete. Latency will still be noticeable on a noisy connection, but my brain can at least anticipate -- guess where to look next -- once the last packet is received. That incomplete information can be used to extrapolate movements. So the final step is to use a model to predict movements in (short) moments when a packet is not received. You can't do this when the information isn't relevant anymore. When that's done, I -- the player -- will feel like that game is more reliable than the first TCP case. (Games, and real-time interfaces in general, have some interesting aspects that I think is well covered in Game Feel by Steve Swink).
      - 1y ago

jeroenhd 1y ago

The article willfully misinterprets the way "reliable" is used to talk about the protocol, as if people use the word to insult UDP. Either that or it's slop that somehow made it to the front page.

cestith 1y ago

We use UDP a lot. I mean, a whole lot. Sometimes it’s bare UDP within a site. Some of that is unicast and some is multicast. Sometimes it’s UDP with a bunch of custom protocol logic around it between sites, handling buffering, reordering, retransmission, and more. I never said UDP wasn’t sometimes fit for purpose. I said it’s unreliable compared to TCP. Those are not the same statement. Sometimes reliability isn’t part of the spec, so you do without that or build your own reliability around it if the less reliable option is still a better fit. This is common in the industry, actually. The ‘I’ in RAID stands for inexpensive, because it’s a redundant array. We scale horizontally these days where we can because more cheaper servers can sometimes scale further and more reliably than fewer more premium servers. Heck, a paper cup is unreliable compared to ceramic or stainless steel, but Starbucks and Tim Horton’s move a lot of product in them.