SoylentNews is people
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.
Fascinating is a word I use for the unexpected.
-- Spock, "The Squire of Gothos", stardate 2124.5
(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.