22 ms·

The main difference between TCP and UDP, as this programmer discovered, relates to quality of realtime service. Times to use UDP over TCP * When you need th

• exDM69 10y ago
  Another article on this site addresses TCP plus UDP mix. The tl;dr is that they should not be used at the same time because TCP retransmission will interfere with UDP (and routers give TCP priority). As long as TCP happens outside of the "hot" loop, it's fine.
  • wtallis 10y ago
    > (and routers give TCP priority). What routers? Is this something that stupid routers did in the '90s and people are still worried about, or are modern routers actually behaving this way? (And if so, why?) TCP retransmission interfering with UDP sounds like something that shouldn't be a problem on any sane network, especially if the application authors are smart and use something like LEDBAT for their TCP traffic when they're also doing latency-sensitive UDP communication.
    • vvanders 10y ago
      You'd be shocked at the things home routers do. There's a reason most people don't try to implement NAT traversal and use common middleware. Since UDP isn't as common of a protocol I can certainly see some routers treating it a second class traffic when it comes to packet shaping.
      • wtallis 10y ago
        I'm well aware of how dumb home routers can be, but a general de-prioritizing of the transport protocol that DNS uses is both really dumb and pretty easy to detect. Are you aware of any router vendors that have actually shipped such a configuration? (Or for that matter, any consumer router that has shipped with any prioritization rules enabled out of the box?)
        • macintux 10y ago
          DNS strikes me as something relatively painless to deprioritize. Small packets, not all that latency-sensitive for most use cases.
          • wtallis 10y ago
            DNS isn't VoIP, but most DNS traffic is very much latency sensitive. When you click a link to a typical modern web page, you trigger multiple HTTP connections to load the page and its many resources hosted on dozens of domains. The DNS lookups are on the critical path for all of those requests.
            • macintux 10y ago
              Yes, but the HTTP requests themselves dominate the overall load time, even if DNS takes a bit longer. Plus there's caching to reduce somewhat the need for the DNS requests. (Of course, I'm pulling all of this out of my nether regions without a lot of thought, and you may well be right, the sheer volume of such requests might lead to problems.)
              • wtallis 10y ago
                It looks like on Windows a typical DNS retry timout is 1 second, with backoff if multiple retries are needed. If a DNS packet needed for loading a web page gets dropped, it's very likely to increase the overall page loading time. Re-ordering DNS to be delivered only when there's a lull in the large TCP packets would almost serialize the loading of resources from different domains. DNS caching is a good thing, but it certainly doesn't eliminate this problem. Web browsing still produces a lot of DNS requests, and any cache upstream of the bottleneck (ie. any cache operated by your ISP rather than in your own router) doesn't help against loss during congestion.
    • fulafel 10y ago
      The internet is generally built on the implicit contract of "TCP-friendly flow control". If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first. There is no general policy against non-TCP packets of course, as lots of important internet services are non-TCP. Just flows that don't respond to congestion. It's not a vendor specific thing, all the major router vendors provide ways of doing this. (Note: router != your home NAT box)
      • wtallis 10y ago
        > If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first. I think that's only if you're being less responsive to congestion signals (drops, ECN marks), and you're using more than a fair share of bandwidth or trying to use any available bandwidth. Fixed but low rate flows (eg. VoIP) shouldn't be penalized until the link is congested with so many flows that the VoIP is trying to use more than 1/N of the bandwidth.
  • placebo 10y ago
    There are quite a few "reliable UDP" implementations out there - I wonder if the same considerations would hold. Guess it might depend on the implementation of reliability using UDP.
  • jlgaddis 10y ago
    I'm a network engineer and I think this is the first time I've ever heard the claim that "routers give TCP priority" (ICMP is often de-prioritized but that's on the control plane). Exactly which routers are alleged to be doing this?
• lobster_johnson 10y ago
  I always wondered why nobody used UDP for bulk data transfer: Ship all the chunks over with a sequential number identifying each, then when you've reached the end, have the client request any lost packets, then repeat the cycle until all are transferred. After all, the client doesn't need everything in sequential order if it knows the size, and it can deal with holes as long as they're eventually repaired. This gives you (in theory, I've never tried it) better throughout, and you get the equivalent of TCP's retransmission without the window semantics, since you move all the retransmissions to the end. On the other hand, it's probably bad for everyone else, since there's no congestion control.
  • lend000 10y ago
    That sounds like a TCP congestion control mechanism, except worse! TCP leaves much to be desired in terms of performance, largely because their congestion control fails miserably on lossy links (TCP RENO). There are better backoff mechanisms that can be added on many distros, like Westwood. And then there are altogether more efficient protocols like QUIC. But designing one for general purposes from UDP is easier said than done.
  • orasis 10y ago
    Back in the day of hard drives, the random access I/O would be nasty and you'd have to be careful about creating sparse files, so you'd end up double writing the missing packets. you'd also still need congestion control so might as well just use TCP to retransmit.
  • vvanders 10y ago
    You've kinda answered your own question there, congestion control becomes a big issue(also MTU discovery to a lesser degree). Games sit in this happy space where the data rate is ~10-20kb at most so they don't need to worry about congestion control as much.
    • user5994461 10y ago
      Additional information: The source engine (valve) has been limited to 30 kb/s for more than a decade.
• dabockster 10y ago
  Isn't UDP more secure than TCP since it does not implement a sequence number (among other things)?
  • frutiger 10y ago
    Questions like "more secure" and "less secure" only make sense in some specific context with a well-defined threat model: what it is that you want to keep safe from which classes of threats. For many (if not most) threat models, the lack of a sequence number does not provide adequate security.
• problems 10y ago
  You can also use something like enet which allows for both reliable and non reliable channels.
• nrjdhsbsid 10y ago
  This isn't really true, or at least not the main reasons to choose UDP or TCP . In modern days UDP is really only used in situations where you can afford packet loss and CPU is expensive, or when you need to bypass the built-in behavior of TCP on your OS. It's not as much about latency or data loss, usually UDP is used in places where processing power is expensive or load is too extreme to justify TCP. Sometimes, like with DNS, it's better to just resend to request than burden a massively parallel server with maintaining TCP state and checksums. The main issue I have with the above comment is that UDP absolutely does not guarantee better latency or have higher priority than TCP packets. The packets usually queue in the NIC buffers and downstream identically regardless of which protocol you use. The main draw of TCP besides data and ordering guarantee (which are CPU costly) is that (depending on your operating system) it follows some kind of automatic rate limiting algorithm be it TCP Vegas(Linux, delay based) or Reno (windows, loss based). These algorithms attempt to limit your connection "stream" to the line rate automatically and play somewhat nicely with each other on large scale. In contrast, the main problem with using UDP is figuring out a smart way to rate the limit to avoid excessive packet loss. In some protocols like DNS anycast type things where only raw throughout matters, who cares if responses drop. Other times, like with LEDBAT or Microsoft's BITS, your main reason for using UDP is to roll your own rate limiting protocol, since otherwise you're stuck with what the OS gives you on TCP.
  • banachtarski 10y ago
    I'm not sure I follow your argument. Say I want to communicate from player A the position of player A to player B. The position is really only relevant for a 200 ms time frame or so (the game might support teleports, jumping, dashing, etc). In a TCP setting, even if a packet is old (>200ms), I have no choice but to send it regardless, and all new packets must queue behind it. The whole point behind using UDP for games is that I can control what the resend policy is, which determines what ends up in the buffers you are referring to in your post. TCP gives me not only little to no choice in the matter, but often does the worst thing in a critical situation, especially in a game where input latency is 6 ms and the tolerance for network latency is <50 ms.
    • 10y ago
• fulafel 10y ago
  Comparing TCP and UDP generally is nonsensical. The sensical comparison would be TCP vs whatever protocol you build or use. It might be your homegrown protocol, but if you have problems with TCP, you should probably look at other ready-made protocols first. For games, there's eg ENet. (Not to say that TCP is generally out of the question for games, eg. WoW uses it apparently successfully)
• yaur 10y ago
  IMO the rule is actually really simple. If the correct thing to do when you lose a packet is to retransmit it use TCP, if it's not use UDP.
  • 0xcde4c3db 10y ago
    I think that rule is a little too simple, because it might be correct to retransmit but not to have the retransmission block processing of later packets. I'd say one should probably use TCP when any of the following are true: 1) The correct interpretation of later packets depends on side effects of earlier packets (e.g. commands in an SSH session, OpenGL commands) 2) Raw bytes-per-second throughput is a major consideration (e.g. file transfer, streaming video) 3) The application readily tolerates high latency and jitter (e.g. email, text chat)
• user5994461 10y ago
  Damn. I disagree with all of your points. Use UDP only if you satisfy all the following conditions: * Don't care about loosing data * Don't care about receiving data out of order * Not sending stream of data but individual messages ( < 580 bytes) * Don't care about the other side of the connection being dead or terminated, and not knowing about it
  • Dylan16807 10y ago
    UDP doesn't cause things like not knowing if the other end is gone. You're being kind of ridiculous.
    • user5994461 10y ago
      UDP is connectionless, it just sends data to <somewhere>. Doesn't care if that somewhere is online, or available, or exists at all.
      • Dylan16807 10y ago
        If you don't check for returns, TCP isn't going to help either. The requirements you listed don't make sense as written. Nobody would ever use UDP.
        • user5994461 10y ago
          TCP establishes a connection when it starts and it has build-in timeouts (and various mechanisms) to detect dead connections. TCP will signal to the application if the destination is unavailable or lost. The requirements make sense and the common usages for UDP fit these requirements. It's correct that [almost] nobody ever uses UDP. It's a niche protocol for a very few specific use cases, one of which is real-time FPS/RTS/MOBA games (which fits all the criteria I listed).
          • the_mitsuhiko 10y ago
            TCP by itself does not detect dead connections.
• Negitivefrags 10y ago
  People talk like most games use UDP, but they don't. Pretty much the only genre that does is First Person Shooters. MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) All of these are action games and use TCP. In most genres people would rather have the simulation pause when there is packet loss, and then run fast to catch up rather than have unreliable data about player locations. Due to the large number of geographical locations you can have your servers in these days, it's common for most of your players to have pings <30ms. With that kind of latency and a few tweaks, it's possible for a single packet lost to be recovered very quickly with TCP.
  • chaotic-good 10y ago
    >> In most genres people would rather have the simulation pause when there is packet loss, and then run fast to catch up rather than have unreliable data about player locations. I thought that modern games use interpolation to compensate for this, because network lags are always present in WAN.
    • Negitivefrags 10y ago
      You can't use interpolation to compensate for late packets. Interpolation is generating data between two data points that you have. You are talking about extrapolation which is the prediction of future data from previous data points. Once again, First Person Shooter games will tend to do extrapolation, but few games of other genres do that kind of thing.
  • cma 10y ago
    Not doubting, I see some other sources say the same thing, but why do you need to open UDP ports for WOW? https://us.battle.net/support/en/article/firewall-proxy-router-and-port-configuration https://us.battle.net/support/en/article/firewall-proxy-rout... Is it something that changed over time and that page is out of date? Is it just doing TCP over UDP for some esoteric cases?
    • Negitivefrags 10y ago
• disiplus 10y ago
  also wherever you need real time there is mostly UDP in use, For SIP + RTP, webrtc is a little bit complicated but the real time part is based on UDP. all those have a mechanisms implemented for packet loss and how to handle it.
• skarap 10y ago
  Nobody ever mentions that UDP has one additional feature that TCP doesn't: preserving of message boundaries.
  • kmm 10y ago
    A datagram-like protocol with the reliability of TCP might be nice. I once implemented a communications protocol that worked with variable-length independent messages over TCP. It felt a little silly pushing distinct datagrams into a stream, that would be chopped up into a packets, sent to another PC, where the OS would then reassemble those packets back into a stream, only to be chopped up again in messages. Implementing the system for chopping up the stream really felt like it should have been done by a lower level as well, not in an application
    • moosingin3space 10y ago
      Seems to me that ZeroMQ basically implemented this - length-prefixed framing is part of the wire protocol.
• fosco 10y ago
  > * When you want to implement your own form of error correction to handle late/missing/mangled data. if this is a consideration -- using TCP may be best option.