<story><title>UDP vs TCP</title><url>http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/</url></story><parent_chain><item><author>mjevans</author><text>The main difference between TCP and UDP, as this programmer discovered, relates to quality of realtime service.&lt;p&gt;Times to use UDP over TCP&lt;p&gt;&lt;pre&gt;&lt;code&gt;  * When you need the lowest latency
  * When LATE data is worse than GAPS (loss of) in data.
  * When you want to implement your own form of error correction to handle late&amp;#x2F;missing&amp;#x2F;mangled data.
&lt;/code&gt;&lt;/pre&gt;
TCP is best when&lt;p&gt;&lt;pre&gt;&lt;code&gt;  * You need all of the data to arrive, period.
  * You want to automatically make a rough best estimate use of the available connection for &amp;#x2F;rate&amp;#x2F; of transfer.
&lt;/code&gt;&lt;/pre&gt;
For a videogame, having a general control channel to the co-ordination server in TCP is fine.  Having interactive asset downloads (level setup) over TCP is fine.  Interactive player movements &amp;#x2F;probably&amp;#x2F; should be UDP.  Very likely with a mix of forward error correction and major snapshot syncs for critical data (moving entity absolute location, etc).</text></item></parent_chain><comment><author>Negitivefrags</author><text>People talk like most games use UDP, but they don&amp;#x27;t.&lt;p&gt;Pretty much the only genre that does is First Person Shooters.&lt;p&gt;MMOs (like world or warcraft)
MOBAs (like Dota)
RTSs (like Starcraft)
Action RPGs (like Diablo)&lt;p&gt;All of these are action games and use TCP.&lt;p&gt;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.&lt;p&gt;Due to the large number of geographical locations you can have your servers in these days, it&amp;#x27;s common for most of your players to have pings &amp;lt;30ms. With that kind of latency and a few tweaks, it&amp;#x27;s possible for a single packet lost to be recovered very quickly with TCP.</text></comment>
<story><title>UDP vs TCP</title><url>http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/</url></story><parent_chain><item><author>mjevans</author><text>The main difference between TCP and UDP, as this programmer discovered, relates to quality of realtime service.&lt;p&gt;Times to use UDP over TCP&lt;p&gt;&lt;pre&gt;&lt;code&gt;  * When you need the lowest latency
  * When LATE data is worse than GAPS (loss of) in data.
  * When you want to implement your own form of error correction to handle late&amp;#x2F;missing&amp;#x2F;mangled data.
&lt;/code&gt;&lt;/pre&gt;
TCP is best when&lt;p&gt;&lt;pre&gt;&lt;code&gt;  * You need all of the data to arrive, period.
  * You want to automatically make a rough best estimate use of the available connection for &amp;#x2F;rate&amp;#x2F; of transfer.
&lt;/code&gt;&lt;/pre&gt;
For a videogame, having a general control channel to the co-ordination server in TCP is fine.  Having interactive asset downloads (level setup) over TCP is fine.  Interactive player movements &amp;#x2F;probably&amp;#x2F; should be UDP.  Very likely with a mix of forward error correction and major snapshot syncs for critical data (moving entity absolute location, etc).</text></item></parent_chain><comment><author>nrjdhsbsid</author><text>This isn&amp;#x27;t really true, or at least not the main reasons to choose UDP or TCP .&lt;p&gt;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&amp;#x27;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.&lt;p&gt;Sometimes, like with DNS, it&amp;#x27;s better to just resend to request than burden a massively parallel server with maintaining TCP state and checksums.&lt;p&gt;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 &amp;quot;stream&amp;quot; to the line rate automatically and play somewhat nicely with each other on large scale.&lt;p&gt;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&amp;#x27;s BITS, your main reason for using UDP is to roll your own rate limiting protocol, since otherwise you&amp;#x27;re stuck with what the OS gives you on TCP.</text></comment>