SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 13 submissions in the queue.
SoylentNews
posted by
martyb
on Sunday March 27 2016, @12:27PM
from the could-this-site-run-without-both-of-them? dept.
from the could-this-site-run-without-both-of-them? dept.
Discussion on the advantages of TCP vs UDP (and vice versa) has a history which is almost as long as the eternal Linux-vs-Windows debate. As I have long been a supporter of the point of view that both UDP and TCP have their own niches (see, for example, [NoBugs15]), here are my two cents on this subject.
Note for those who already know the basics of IP and TCP: please skip to the 'Closing the Gap: Improving TCP Interactivity' section, as you still may be able to find a thing or two of interest.
It's a primer, or a refresher, or a skip. We have all kinds here. Enjoy, or don't.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
The Golden Rule of Arts and Sciences:
He who has the gold makes the rules.
(Score: 5, Informative) by Rosco P. Coltrane on Sunday March 27 2016, @01:14PM
TCP and UDP are two different protocols, designed for two different purposes. Those who think they are in competition have skipped OSI 101.
(Score: 0, Flamebait) by patrick on Sunday March 27 2016, @02:17PM
And that's another similarity to the Linux-vs-Windows debate.
(Score: 2, Touché) by Francis on Sunday March 27 2016, @02:45PM
Not really, the only thing that Windows does better than Linux with any consistency is attract developer support.
But, whether that's worth being spied on and the generally crappy experience that's come to characterize Windows, I don't really know. That's up to the individual to decide.
(Score: 0) by Anonymous Coward on Monday March 28 2016, @10:43AM
Windows also does a better job of trampling on the user's freedoms.
(Score: 0) by Anonymous Coward on Sunday March 27 2016, @08:29PM
Less so these days, but back in the 90s a lot of the Windows vs. Linux debate centered around up-time.
Linux people were server oriented. If you were on "that other site", and you defended Windows in any way,
they automatically assumed you were defending NT Servers. Nope. I was defending the *desktop* where
4 hour up-time was "good enough" because you were probably going to go to lunch anyway. Networking and
security was an afterthought on Windows just as a responsive user-friendly GUI was an afterthought on Linux.
People just couldn't get it. It's become better over the years; but I'm sure those people are still around.
Of course these days, the debate is now totally different, with Windows now having more up-time than
I can use; but becoming a surveillance/ad platform...
(Score: 2) by bitstream on Monday March 28 2016, @08:25AM
Having a reboot etc when you have 10s of terminals and stuff up right in debugging is royal pain. So operating systems that can't stay stable will not be acceptable. It's also a stress to keep saving all the time because.. maybe.. ¤%¤%.
(Score: 2) by RamiK on Sunday March 27 2016, @05:13PM
Well, yes and no. Games and web apps have mixed needs. Some things need low latency (coordinating GUI elements) while other things can wait in line (loading files). Often, developers will customize their own UDP protocol under these circumstances to handle everything efficiently. But, even the best designed protocol will still crush and burn in the face of the ISP's infrastructure down-prioritizing anything not VOIP. Your awesome custom protocol might even lose out to BitTorrent or Windows 10 P2P Update protocol since you're not one of the cool kids that get Cisco to override your header by default... So, the "stupid" solution of using UDP for the GUI while opening a second TCP connection for loading files will often be the smartest and best thing to do, even if it means more client side complexity coordinating it all.
So, yeah... They're designed for two different purposes. But things get messy in real life.
compiling...
(Score: 2) by bitstream on Monday March 28 2016, @08:29AM
Fake your packets to come from one of the "cool kids" ..?
Robotics control over VoIP.. why not?
Dunno what your specific application you have in mind.
(Score: 2, Insightful) by Anonymous Coward on Sunday March 27 2016, @06:20PM
I want to be able to control the things TCP mandates I must have, but that I don't neccesarily need. I need a reliable channel that can be "reset" cheaply according to application events: The fullscreen application has changed, no need to ensure packets containing the old data still in transit reach the endpoint -- and I want the new data stream to replace the old stream in the TCP packet window.
This is not a UDP need. This is me needing TCP to be more flexible. However, the designers gave us the inflexible TCP and said: If your use case is not exactly the way we built TCP to handle, fuck you. There are no application level configuration options, eat shit and go re-invent the fucking wheel using UDP, or otherwise suffer with kludgey workarounds like opening multiple TCP connections between the endpoints (placing an exponential resource load on the server for no fucking reason other than lack of config options).
It's like the devs who hardcode the game controls to WASD, and say: Fuck all you people without QWERTY Keyboards; US Latin 1, or death! It's assinine and amazingly simple to have a config that says: Press the key you want for forward. Press the key you want for left, etc. TCP should have done that. It didn't. Therefore I have implemented (a slightly modified) TCP on top of UDP, and so has Google and a shit load of other people.
It's like saying: It works for me! There is a TCP / UDP debate. The debate is whether TCP should be changed to be a bit more like UDP to improve everyone's experience by overcoming the short sightedness of the original design. And people like Google and myself are actually furthering the debate. Idiots like yourself who say "there is no debate" are the enemies of progress.
Jump in a tar pit gramps, you're hindering the herd.
(Score: 3, Informative) by maxwell demon on Sunday March 27 2016, @06:50PM
FTFA:
There's no way to tell the routers in between to drop the already-sent packets because the routers forget each packet as soon as it is sent to the next router. You don't even have the guarantee that all your packets go the same way; how would a router on route 1 know that a cancellation message was delivered using route 2?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Geotti on Monday March 28 2016, @01:33AM
Don't you get it? "you're hindering the herd"
These "progressive" kids are just chasing the wrong kind of efficiency. Let them make their own internet and let's continue to use ours, unless they start to impose their shit on us like that Poettering dude.
(Score: 2) by isostatic on Monday March 28 2016, @10:27AM
TCP and UDP are two different protocols, designed for two different purposes. Those who think they are in competition have skipped OSI 101.
So I'm building a new application which requires a new communication protocol. I can use something based on a high level protocol like SOAP or a message broker, I could use something based on something lowerdown like http, or I could base it on UDP or TCP. Going down to raw IP datagrams becomes problematic. TCP comes with advantages, but also drawbacks, but the same can be said about SOAP, or Corba, or http, or snmp.
They aren't as different as a hammer and screwdriver, more like a screw vs a nail, they're both designed for the same purpose (fixing things together // communicating over a network), but they do it in different ways with different advantages and disadvantages.
If I wanted to send messages to many clients, I could use a message broker running on tcp to ensure the message gets there. On the other hand if I'm sending a broadcast message saying "new information, update now rather than wait 10 seconds for the poll), why wouldn't I just fire out a broadcast udp?
Packet loss is a bit of a red herring. At any one time I'm streaming 250mbit around the world on the internet, and I see packet loss post-RTP-reconstruction and minimal buffering in the 1-in-1,000 - 1-in-10,000 level.
(Score: 2) by driverless on Wednesday March 30 2016, @06:26AM
We have all kinds here.
Oh, we got both kinds, we got TCP and UDP.