UDP vs TCP
gafferongames.com
UDP vs TCP
1–10 of 198 posts
Re: UDP vs TCP
#2I thought that it was somebody who has recently discovered the existence of
UDP protocol and brags about that to the world, but from skimming the article,
it actually has some non-trivial remarks about UDP and TCP.
BTW, the article's view angle is multiplayer game programming.
Re: UDP vs TCP
#3I thought that it was somebody who has recently discovered the existence of UDP protocol and brags about that to the world, but from skimming the article, it actually has some non-trivial remarks about UDP and TCP. BTW, the article's view angle is multiplayer game programming.
This guy (Glenn Gaffer) has been writing network protocols for games for years and shipped popular titles.
On his site you can also find an irate rant about people with no experience dismissing his claims as "reimplementing TCP". It has good points but it's a frustrated rant (reader beware). But it addresses a lot of the commonly believed fallacies.
His latest project is an open source library for game networking over UDP: https://github.com/networkprotocol/libyojimbo
And he is correct, for "real time" games you must use UDP or you will be in trouble in real world networking conditions. When everything runs smoothly, TCP and UDP work almost identically but when packet loss occurs, TCP will make things worse.
Re: UDP vs TCP
#4I appreciate the first user comment on this article:
"I didn’t care for this article 7 months ago. I regret it. My whole game is useless now. I should have go with udp."
Re: UDP vs TCP
#5Another important difference: UDP can't be used in the browser =(
Re: UDP vs TCP
#6The 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.
* You need all of the data to arrive, period.
* You want to automatically make a rough best estimate use of the available connection for /rate/ of transfer.
Re: UDP vs TCP
#7The recommendation to avoid TCP altogether is surprising to me. Having encountered a number of video-conferencing systems which are in a similar space, it seems pretty standard to have separate real-time and control sockets on UDP and TCP respectively. I skimmed the linked paper and didn't find it conclusive; can someone summarize how it is that having a TCP socket can affect UDP traffic on the same interface?
All that said, I certainly see the argument for an all-UDP protocol in terms of defining your own retransmission approach, or attempting to avoid it altogether with forward error correction or whatever.
Re: UDP vs TCP
#8The 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…
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.
Re: UDP vs TCP
#9Another important difference: UDP can't be used in the browser =(
With the exception of the QUIC protocol.
* TLS over 443/udp
Re: UDP vs TCP
#10Another important difference: UDP can't be used in the browser =(
WebRTC is UDP. It's not easy, but it's there!