3

I'm working on a distributed application for a graduate class I'm taking. There has been much discussion around implementing a way to maintain peer connection health statuses. Think Gossip. One of the primary themes for this project has been how we should rely on UDP communication to overcome the "excessive" bandwidth usage of TCP (wrt maintaining these lists of connection status between peers).

I don't know that I agree with this stance though. To me, the primary advantage of TCP isn't the reliability of the connection, but instead the congestion control it offers. It seems more likely that TCP connections between hosts is actually lighterweight than UDP because you get reliability, congestion control, and built-in connection failure notifications.

One potential scenario that could make adequate use of UDP packets is a backup mechanism for detecting link failures (which is what I've started to implement, though I'm not positive this is the right approach). The idea being that our primary connection to peers is via a TCP socket, whith built-in failure detection, but if we were to miss the disconnect message from this link, we could fall back on a gossipy-stle peer list we received via UDP from other hosts.

Am I looking at this all wrong? Keep in mind that this question is specific to handling peer connections and failures in a distributed application, across multiple nodes.

closed as too broad by gnat, GlenH7, Ixrec, user22815, user40980 Oct 1 '15 at 13:18

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

3

Once upon a time, there was a great war being waged between two mighty armies, the CISCites and the RISCites. The men of RISC believed that their forces were mightier, for their instruction sets were simpler. The lumbering CISCs, they said, had to have a heavy translation layer in between the instruction set and the actual execution, in which instructions were reduced from CISC form to a much simpler RISC-like form anyway, so simply going with RISC to begin with would eliminate this overhead and result in a much more performant system.

The CISCites countered that their system was simpler to use, because their instructions were semantically more powerful.

Both of these claims were objectively true. But in the end, something interesting happened: the world kept turning, and so did Moore's Law. The cost of the CISC-translation overhead was a fixed cost, which became smaller and smaller with each iteration of faster hardware. Meanwhile, RISC did not become any easier to use. Today, CISC has essentially taken over the world.

A wise man should be able to see how a parallel to the UDP/TCP situation quite easily presents itself...

  • Ha, very intriguing analogy :) – ctote Sep 30 '15 at 21:03
  • 4
    It had to be mentionned that CISC did NOT overtake the world. Ever heard of ARM ? It's a RISC controller manufacturer that has a huge part of smartphones and other embedded device market... – Arthur Havlicek Sep 30 '15 at 21:03
  • I remember the history differently. Part of the promise of RISC was that it should be easier to iterate through Moore's law because the CPU design was so much simpler. However the CISC vendors (particularly Intel) had insane resources to throw at the problem. It turned out that resources mattered - Intel was able to iterate faster than competitors. For example this is how Transmeta failed. If they had iterated faster than Intel, we would all be using Transmeta chips. Instead Intel iterated faster so each generation of Transmeta was relatively slower until they died. – btilly Sep 30 '15 at 21:08
  • 1
    @ArthurHavlicek: Much of this is first-mover advantage. It's likely that things will be quite different in the years to come, now that Intel has gotten into the mobile CPU market. (See sealedabstract.com/rants/why-mobile-web-apps-are-slow for the reasons why. Search for "The hardware angle" if you don't have the patience to read through the whole thing--it's very long--but you should read through the whole thing anyway, for context.) – Mason Wheeler Sep 30 '15 at 21:11
  • @btilly: IIRC Transmeta failed because at its core, it was essentially an emulator of a third-party system, and emulators have a lot more technical challenges to overcome in addition to the overhead imposed by emulation, particularly when they're a third-party system that you don't have the specs to. In CISC-to-RISC translation, on the other hand, the same engineers are designing both sides of it and they can leverage that. – Mason Wheeler Sep 30 '15 at 21:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.