Earlier quoted context omitted.
Well, neither can TCP.
HTTP is built on top of TCP. Websockets are TCP connections.
So? TCP cannot be used directly in the browser by applications authors. It's an abstraction.
UDP vs TCP
171–180 of 198 posts
Re: UDP vs TCP
#172If you want to get familiar with TCP/UDP and are not gun-shy with C I would suggest the Pocket Socket Guide (now Practical Guide to TCP sockets)[1]. I have a really old edition, but it ages extremely well, and its one of the books I always use to refresh myself on network programming basics.
[1]: https://www.amazon.com/gp/product/0123745403/ref=ox_sc_act_t...
Re: UDP vs TCP
#173Earlier quoted context omitted.
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 FP…
TCP by itself does not detect dead connections.
while its technically not a timeout, it is stopping the network traffic
the TCP packets require an ACK ever n packets, as defined by the FREQ field. If the ACK isn't received, no further packets are send.
Re: UDP vs TCP
#174The 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 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/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…
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…
A lot of the internet's bulk data transfer uses UDP, torrents.
Re: UDP vs TCP
#175The 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 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/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…
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 l…
This is terrible advice. These games use TCP because they can get away with the latency and often have game designs where latency is a non-issue (300ms in WoW won't ruin your raids or quests). Latency spikes are also very noticeable in these games. Starcraft adds latency locally to your inputs so they're played on all computers simultaneously.
I'd argue that none of these games require time-critical data and often have latencies much higher than they would with UDP. None of these games have networked physics either, TCP breaks down badly in that case. I'd also argue that great network developers come in very short supply and therefore most companies are left to their own misconceptions. (Then again, most game developers grossly overestimate their own skills, nothing new here :D)
I don't know where you get that "people would rather have the simulation pause when there is packet loss, and then run fast to catch up" idea but my experience is the exact opposite.
"Unreliable data about player locations" is a myth. Its just as "unreliable" in TCP with the difference being that in TPC the protocol will arrange for the packet be resent; at which point its no longer relevant to the current frame - you've wasted CPU and bandwidth, crippling your game designers in the process, often without realizing so. You rarely ever want a reliable world state, just reliable actions.
With UDP you actually rely on unreliability to only ever use the latest game state; actions you want reliable or ordered can be implemented very easily on top of UDP or left in TCP. Client-side prediction takes care of dropped frames such that missing a datagram (and therefore that frame's player positions) isn't noticed by the player. A delayed TCP packet will do the exact same, but waste CPU/bandwidth in the process.
I've seen my share of "senior" network programmers who couldn't make a networked engine that is actually stable. I can understand why some teams look at TCP and naively claim "problem solved!" But it doesn't make TCP the best choice because you can appeal to authority with big titles using it :)
Re: UDP vs TCP
#176Earlier quoted context omitted.
Exactly. The core feature provided by TCP is not reliability, that is trivially easy. What TCP gives us is robust flow control that can detect and adapt to current network capacity.
CNN has a video transfer tool for b2b subscribers that uses multiple UDP streams to increase transfer speeds. Instead it saturated and brought down our company firewalls, which were older and our main bottleneck. All for just a potentially few more megs of speed on TB sized videos. Gotta be careful with UDP.
> a video transfer tool for b2b subscribers that uses multiple UDP streams
That sounds like FASP (http://asperasoft.com/technology/transport/fasp/)
Re: UDP vs TCP
#177Earlier quoted context omitted.
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 l…
> MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) Dota 2 definitely does not use TCP. The Starcraft games I assume can also work with TCP but I doubt that they use it as a primary choice of communication. I would love a source for this.
starcraft II uses TCP and UDP. I have verified this by reviewing my firewall, I have not gone as far to take pcaps and see what packets are doing what but I thought this was relevant enough to say.
as the parent mentioned -- UDP where time is more important than reliability. I disagree with his last comment on building your own reliability -- use TCP for that.
tcp/1119, udp/dynamic (listed app definitions for app-based firewall)
some additiona blizzard info --> https://us.battle.net/support/en/article/configuring-router-...
Re: UDP vs TCP
#178The 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 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/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…
> * 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.
Re: UDP vs TCP
#179The 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 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/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…
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.
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)
Re: UDP vs TCP
#180The 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 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/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…
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 l…
Dota 2 and Starcraft 2 both use UDP.