4 ms·

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

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).
    - cestith 1y ago
      I wouldn’t say either is absolute. I’d call TCP more reliable than UDP, but not necessarily reliable exactly. I’d also call UDP unreliable compared to TCP. However, that doesn’t make it broken. Reliable ordering and delivery was not part of the design or spec. It’s fit for purpose sometimes better than TCP - when you don’t need the extra reliability or have built your own around it.
- tsimionescu 1y ago
  Note that TCP doesn't actually provide that guarantee to the application layer. There's no way to know if some bytes you sent on a TCP socket ever arrived. So, if you want a reliable packet delivery, you have to build that at the application layer yourself anyway. That's why HTTP requires the 204 No Content response code, for example - instead of relying on a TCP ACK to achieve the same. The only real guarantee that TCP provides is in-order delivery. That is, it really guarantees that if you sent two requests A and B to a server, the server will never see request B unless it saw request A first. Again looking at HTTP, this is why request pipelining theoretically works without including any request ID in the response: the client knows that if it sent reqA first and reqB second, the first response it gets from the server will be respA, and the second will be respB (if either of them ever arrives, of course). Note that the fact ACK is not shown to the application layer is not an implementation limitation, it is a fundamental part of the design of TCP. The ACK is generated by the TCP stack once the packet was received. This doesn't guarantee in any way that the application will ever see this packet: the application could crash, for example, and never receive (and thus act on) this message. The in-order guarantee works instead because the transport layer can simply avoid ever showing reqB to the application layer if it knows that there was a reqA before it that it didn't receive. So the transport can in fact ensure that it's impossible for the application to see out-of-order data, but it can't ensure that the application has actually received any data.
- threatofrain 1y ago
  For the case examples being discussed, like drones, TCP is unreliable in the sense that it may be death penalty for your app. Isn't death penalty a severe kind of unreliable? In that case UDP is much more reliable in not murdering your app.
  - cestith 1y ago
    TCP will be reliably too slow. There are situations in which it’s better to drop a packet than wait for a reordering buffer. That doesn’t mean UDP is reliable. It just means sometimes it’s the right solution anyway.
    - threatofrain 1y ago
      Too slow underplays how bad it is. It'll be unbounded backup. That is death penalty. There's no point in talking about reliability at that point.

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).
  - cestith 1y ago
    I wouldn’t say either is absolute. I’d call TCP more reliable than UDP, but not necessarily reliable exactly. I’d also call UDP unreliable compared to TCP. However, that doesn’t make it broken. Reliable ordering and delivery was not part of the design or spec. It’s fit for purpose sometimes better than TCP - when you don’t need the extra reliability or have built your own around it.
tsimionescu 1y ago
Note that TCP doesn't actually provide that guarantee to the application layer. There's no way to know if some bytes you sent on a TCP socket ever arrived. So, if you want a reliable packet delivery, you have to build that at the application layer yourself anyway. That's why HTTP requires the 204 No Content response code, for example - instead of relying on a TCP ACK to achieve the same. The only real guarantee that TCP provides is in-order delivery. That is, it really guarantees that if you sent two requests A and B to a server, the server will never see request B unless it saw request A first. Again looking at HTTP, this is why request pipelining theoretically works without including any request ID in the response: the client knows that if it sent reqA first and reqB second, the first response it gets from the server will be respA, and the second will be respB (if either of them ever arrives, of course). Note that the fact ACK is not shown to the application layer is not an implementation limitation, it is a fundamental part of the design of TCP. The ACK is generated by the TCP stack once the packet was received. This doesn't guarantee in any way that the application will ever see this packet: the application could crash, for example, and never receive (and thus act on) this message. The in-order guarantee works instead because the transport layer can simply avoid ever showing reqB to the application layer if it knows that there was a reqA before it that it didn't receive. So the transport can in fact ensure that it's impossible for the application to see out-of-order data, but it can't ensure that the application has actually received any data.
threatofrain 1y ago
For the case examples being discussed, like drones, TCP is unreliable in the sense that it may be death penalty for your app. Isn't death penalty a severe kind of unreliable? In that case UDP is much more reliable in not murdering your app.
- cestith 1y ago
  TCP will be reliably too slow. There are situations in which it’s better to drop a packet than wait for a reordering buffer. That doesn’t mean UDP is reliable. It just means sometimes it’s the right solution anyway.
  - threatofrain 1y ago
    Too slow underplays how bad it is. It'll be unbounded backup. That is death penalty. There's no point in talking about reliability at that point.