Slash Boxes

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: 0) by Anonymous Coward on Sunday March 27 2016, @02:12PM

    by Anonymous Coward on Sunday March 27 2016, @02:12PM (#323537)

    Hey guys, please stop disabling my algorithm, OK? I'm here to help!

  • (Score: 2) by isostatic on Sunday March 27 2016, @02:57PM

    by isostatic (365) on Sunday March 27 2016, @02:57PM (#323551) Journal

    But I can sell suits snakeoil promising to transfer your 1000mbit file over your 100mbit connection in 9 seconds, where under fcp it takes 32 years

    (You find their demos have disabled tcp window scaling and they transfer easily compressible video files like dvc with silent audio in an mxf wrapper and compare with a protocol that doesn't have built in compression)

    But it's enough that idiotic "architects" buy the product, refuse to run in house tests because "they've already bought it", and then insist you use it rather than a nice simple sftp despite it being slower.

    • (Score: 0) by Anonymous Coward on Sunday March 27 2016, @03:15PM

      by Anonymous Coward on Sunday March 27 2016, @03:15PM (#323555)

      While I agree overall, the problem comes when it's time to send lots of small amounts of data very fast. Market data applications generally want updates as fast as they can, not as efficiently as they can. When dealing with differential updates, you only maybe have a couple bytes per symbol that change per update, and might not have many of those at a time, but the expectation is that you better be able to receive them before they get sent sometimes.

      Admittedly a niche situation, but kind of a deal breaker when comparing two software products that do the same thing and one consistently outperforms the other by ~1-5 ms. I've seen that one happen first hand both in a clean environment and at client sites. ITG comes to mind WRT some of their Reuters systems that fed (what I suspect was) their algo trading systems. They wouldn't ever let me get even a hint of what they were consuming data with, but it was home-grown and very protected. Kind of a bitch when trying to diagnose issues.

      Posting AC because, well, the name drop, and I don't really like being associated with that kind of work. I guess it's not killing people for a living, but it's really not a whole lot better. I don't do that anymore.

  • (Score: 0) by Anonymous Coward on Sunday March 27 2016, @06:38PM

    by Anonymous Coward on Sunday March 27 2016, @06:38PM (#323601)
    Your algorithm + TCP delayed ack is more of a problem than a solution nowadays compared to many decades ago*. Who the heck wants to wait hundreds of milliseconds to send small packets when you have >Mbps connections and GHz processors/ASICs on network devices and hosts.

    * Even not that long ago it seemed more of a stupid hack than a real solution. When your "solution" shows up as a top cause for many TCP performance problems, you should admit you've screwed up.