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: 3, Informative) by maxwell demon on Sunday March 27 2016, @06:50PM

    by maxwell demon (1608) 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.
    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (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.