3 ms·

Then UDP won't work for your requirements, right?

• tyingq 11y ago
  UDP, without some layer on top of it for ack or retry, or ordering, isn't useful for many requirements. Maybe things like displaying stock quotes, where stale data doesn't matter after a few seconds? I think the point is just to say that the article shouldn't tout plain UDP as a fix for TCP being hard in certain languages without calling out the downside.
  • klodolph 11y ago
    TCP and UDP are different solutions for different problems. You also shouldn't tout TCP as a fix for UDP being hard without calling out the downside--TCP doesn't let you drop packets and can suffer from bad latency problems.
    • tyingq 11y ago
      Yep. When suggesting a change from one to the other, it might be a good idea to explain the benefits and tradeoffs. I didn't suggest otherwise. That said, most protocol implementations that I'm aware of over UDP have one or more of "retry/order checking/etc" on top of them. Like NFS, Bootp, tftp, etc.
      • exDM69 11y ago
        > That said, most protocol implementations that I'm aware of over UDP have one or more of "retry/order checking/etc" on top of them. But it's a common false belief that it would be "reimplementing TCP". Some guarantees of reliability are required for most practical applications but TCP's "in-order stream of bytes" isn't suitable for everything. For any kind of real time data, when packet loss occurs, TCP will re-send data that may already be outdated, and causing later packets to arrive even later. In real time uses, TCP makes any networking problems worse. It's also worth noting that under ideal conditions (ie. no packet loss), TCP and UDP behave almost identically (after startup, that is). The issues only appear when you're working in less than ideal conditions and are worse the longer the physical distances are.