3 ms·

(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 corre

(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.

(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.