Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday March 27 2016, @12:27PM   Printer-friendly
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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Informative) by Rosco P. Coltrane on Sunday March 27 2016, @01:14PM

    by Rosco P. Coltrane (4757) on Sunday March 27 2016, @01:14PM (#323529)

    TCP and UDP are two different protocols, designed for two different purposes. Those who think they are in competition have skipped OSI 101.

    Starting Score:    1  point
    Moderation   +4  
       Insightful=2, Informative=2, Total=4
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 0, Flamebait) by patrick on Sunday March 27 2016, @02:17PM

    by patrick (3990) on Sunday March 27 2016, @02:17PM (#323538)

    And that's another similarity to the Linux-vs-Windows debate.

    • (Score: 2, Touché) by Francis on Sunday March 27 2016, @02:45PM

      by Francis (5544) on Sunday March 27 2016, @02:45PM (#323546)

      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

        by Anonymous Coward on Monday March 28 2016, @10:43AM (#323809)

        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

      by Anonymous Coward on Sunday March 27 2016, @08:29PM (#323627)

      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

        by bitstream (6144) on Monday March 28 2016, @08:25AM (#323774) Journal

        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

    by RamiK (1813) on Sunday March 27 2016, @05:13PM (#323573)

    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

      by bitstream (6144) on Monday March 28 2016, @08:29AM (#323775) Journal

      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

    by Anonymous Coward on Sunday March 27 2016, @06:20PM (#323591)

    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

      by maxwell demon (1608) Subscriber Badge on Sunday March 27 2016, @06:50PM (#323604) Journal

      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.

      FTFA:

      TCP OOB (Out-of-Band Data) is a mechanism which is intended to break the stream and deliver some data with a higher priority. […]

      One scenario when MSG_OOB works pretty well (and which is used in protocols such as FTP), is to send an ‘abort’ command during a long file transfer; on receiving OOB ‘abort’, the receiving side simply reads all the data from the stream, discarding it without processing, until the OOB marker (the place in the TCP stream where send(…,MSG_OOB) has been called on sending side) is reached. This way, all the TCP buffers are effectively discarded, and the communication can be resumed without dropping the TCP connection and re-establishing a new one.

      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

        by Geotti (1146) on Monday March 28 2016, @01:33AM (#323686) Journal

        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

    by isostatic (365) on Monday March 28 2016, @10:27AM (#323806) Journal

    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

    by driverless (4770) on Wednesday March 30 2016, @06:26AM (#324704)

    We have all kinds here.

    Oh, we got both kinds, we got TCP and UDP.