111–120 of 198 posts
Earlier quoted context omitted.
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 (
UDP doesn't cause things like not knowing if the other end is gone. You're being kind of ridiculous.
The entire article makes me shudder in disbelief. It's aimed at people who don't know the difference between UDP and TCP (and possibly wet string). Yet he recommends they implement their own reliably protocol over UDP, and they avoid TCP because it's better to implement your own QoS? Why not add obtaining PhD in quantum mechanics just to round it out? It wouldn't alter the odds of pulling it off overly.
For people who are not familiar with TCP and UDP, the answer should be to ALWAYS use TCP.
The only exception is some subset of games (FPS, RTS), that this article is exclusively intended for.
Even there, for the average user who just wanna make a test game project, TCP may be easier to use and program around. For simple games (e.g. Connect 4), TCP is a better option either way.
It's been a while since my networking class, but if I remember correctly with UDP you have some serious issues where you can end up clobbering your network, filling up buffers in the middle and dropping tons of packets. The lack of congestion control is a huge no-no.
For instance in the example he gives, sure you can tolerate dropped packets for player-position data, but how do you know if you can tolerate sending at 10Hz 100Hz 1000Hz? Even with TCP you can't (I think....) programmatically adapt to the size of your pipe. That's kinda abstracted away for you so that you just say "send file A to B" and it does it for you
Are you supposed to write your own congestion control in userland???? Seems like this should be a solved problem
This feels like a nice introduction. Anyone here have any experience using QUIC in any application of their own? The custom congestion control makes me wonder if it only works alongside TCP traffic - once everything goes QUIC, then what happens? I looked for a bit about the story in ancient history of some blazing fast server OS TCP implementation that broke the rules so it fell over when more than one server was on…
This feels like a nice introduction. Anyone here have any experience using QUIC in any application of their own? The custom congestion control makes me wonder if it only works alongside TCP traffic - once everything goes QUIC, then what happens? I looked for a bit about the story in ancient history of some blazing fast server OS TCP implementation that broke the rules so it fell over when more than one server was on…
Earlier quoted context omitted.
UDP doesn't cause things like not knowing if the other end is gone. You're being kind of ridiculous.
UDP is connectionless, it just sends data to . Doesn't care if that somewhere is online, or available, or exists at all.
The requirements you listed don't make sense as written. Nobody would ever use UDP.
I 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 ove…
Worked with Glenn on Freedom Force and Tribes. He knows his stuff!
Earlier quoted context omitted.
> ship all the chunks over with a sequential number Except that if you ship them too fast, they will at best simply build up in a buffer somewhere (e.g. near a bottleneck link), or more likely they will overflow causing many of your packets to be lost. So not only did the recipient not get them (and you have to figure this out and resend them later), but you also wasted a bunch of resources sending packets only to ha…
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.
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 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…
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, lik…
The 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 th…
I too was wondering how TCP and UDP can affect one another on the same interface and the explanation I read is that at the lowest level both UDP and TCP segment data into packets and place them onto the same network adapter's queue which can affect they way they are transmitted under congestion depending on the device/drivers.
UDP will drop data if there is congestion. Basically, if you care about congestion and data loss, you should not use UDP.
---
If you do UDP and TCP. The UDP transfer will loose data during congestion, while the TCP transfer will slow down and try harder.
This has some usage. For instance, videoconferences software will do TCP and UDP. The TCP is used for control data -low volume data that needs to work- (authentication/joining room/leaving/adjusting quality), the UDP is used for audio/video (some pieces may be lost during congestion, it's okay).
If you use UDP for everything, you'll randomly loose control AND audio/video. It's the worst of both worlds.
Not to be dismissive but I think the guy who gave you the advise doesn't really understand networking (or doesn't explain very well or was talking about some weird usage we don't know about).