Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
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: 2) by devlux on Sunday March 27 2016, @06:14PM

    by devlux (6151) on Sunday March 27 2016, @06:14PM (#323589)

    I dunno about his particular implementation. However UDP is fine as long as you don't need guarantees. Once you start needing guarantees then you begin to start re-implementing TCP. If you own the entire loop, i.e. it's a private network this might be worthwhile but as soon as you begin to expand beyond the local side of things TCP does become king. Turning Nagel off on TCP can help alot if you're mostly smallish updates and need closer to realtime performance, but most of the features of TCP are there for a reason. That reason is to make sure your data arrives at it's destination. If your data only needs to "mostly" arrive then UDP becomes superior.

    What I don't understand is why no one has ever implemented a packet multicasting option for UDP as a standard.

    This would make UDP a lot more useful since a lot of people could subscribe to a a feed and it wouldn't be limited to the the upstream of the originator.

    (For those who don't know, the reason your video conference craps out at 4 or 5 people has little to do with your downstream bandwidth. if you have 5 people in a videochat your computer is pumping out the exact same packet 5 different times, simply changing the destination IP. What I'm saying is this seems like a function the router would be better at, failing that, having multiple ip destinations in a single packet might be good although I can see the IP header space quickly swamping the data portion in a large enough conferencing app.)

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by c0lo on Sunday March 27 2016, @08:52PM

    by c0lo (156) Subscriber Badge on Sunday March 27 2016, @08:52PM (#323639)

    (For those who don't know, the reason your video conference craps out at 4 or 5 people has little to do with your downstream bandwidth. if you have 5 people in a videochat your computer is pumping out the exact same packet 5 different times, simply changing the destination IP. What I'm saying is this seems like a function the router would be better at, failing that, having multiple ip destinations in a single packet might be good although I can see the IP header space quickly swamping the data portion in a large enough conferencing app.)

    Ah, such a simple solution, how come others haven't thought of it [wikipedia.org]?

    (grin)

    • (Score: 2) by devlux on Monday March 28 2016, @03:15PM

      by devlux (6151) on Monday March 28 2016, @03:15PM (#323918)

      Thanks I guess what I meant is as part of a major working standard like WebRTC.

      • (Score: 0) by Anonymous Coward on Monday March 28 2016, @10:57PM

        by Anonymous Coward on Monday March 28 2016, @10:57PM (#324123)
        Yes, because a Web browser needs to get OS capabilities.</sarcasm>
  • (Score: 2) by Common Joe on Monday March 28 2016, @07:14AM

    by Common Joe (33) <common.joe.0101NO@SPAMgmail.com> on Monday March 28 2016, @07:14AM (#323752) Journal

    Once you start needing guarantees then you begin to start re-implementing TCP. If you own the entire loop, i.e. it's a private network this might be worthwhile but as soon as you begin to expand beyond the local side of things TCP does become king.

    My understanding is that that is the key. The network is private so they don't lose tons of packets -- just a few. It sounds like their program can handle those few losses. And you're right, if they opened up the network beyond that, the setup sounds like it would fail. Obviously, this is not a standard database setup, but it's an interesting enough idea that it could be used for other extremely specialized programs. And for all I know, other programs may use it.