In July of 1969, the US was in a race for the moon. Astronauts Michael Collins, Buzz Aldrin and Neil Armstrong were entrusted with the Apollo 11 mission, taking the first shot at the momentous achievement. Last night, I caught a great documentary on this mission, waking through the many planning details and challenges involved in going where no man had gone before. In fact, knowing the technology of the time, I am still amazed that we were able to pull this off on the first attempt. These men were truly brave, trusting their lives to such new and really untested technologies.

<IMAGE MISSING>

One thing that caught my attention was how meticulous Mission Control was, as they faced a number of “go/no go” decisions from the launchpad to the moon and back. As Buzz Aldrin and Neil Armstrong undocked the lunar module and began their decent to the moon’s surface, they were faced with almost impossible odds. There were so many calculations that had to be made in a split second, with no prior experiences to draw from. Gene Kranz, NASA’s Flight Director at Mission Control, was faced with a number of tough decisions as the lunar module approached the surface of the moon.

They did not know exactly when they would touch down, or how much fuel they would burn in the process, but they did have a good idea of how much they would need to relaunch and connect back up with the command module for the return trip to Earth. With every second, fuel consumption was being calculated and measured to insure this was not a one-way trip. About 30 seconds after beginning their final approach, Neil Armstrong calls out “1201 program alarm”. This was a computer error code that simply meant there that the computer was unable to complete all of the calculations it was attempting and had to move on. Timing was critical, and the programmers of the flight computers knew that should this condition occur, it was more important to simply note that some data was lost and move on. I can imagine the concern this caused, both in Mission Control and cramped lunar module. This is where the many eyes and ears monitoring the situation at Mission Control had to step up and insure that the important information was not dropped.

As I watched this, I noticed much this is similar to how PCoIP handles data (you knew this had to have a virtualization tie in, right?). PCoIP uses UDP. UDP is stateless, it will drop data packets. At the most basic level of the solution, the networking layer, packets can be lost the data does not stop flowing. UDP is like the flight computers on-board the Apollo 11 lunar module. At the application layer, PCoIP becomes Gene Kranz and Mission Control. It is looking to determine what may have been lost and how that can impact the overall mission. Calculating the 100 feet in front of the lunar module was infinitely more important than continuing calculations for the 100 feet behind it. With PCoIP, the goal is an efficient and pleasant user experience. To achieve that, with a myriad of unknown factors that can come into play, UDP is recognizing that not all data is critical to the end goal. Instead, PCoIP is the watchful eye that makes the “go/no go” decisions. For USB communications, data input and other critical data, it will request a retransmit of the data to insure accuracy reliable delivery of information. For audio or video packets, where it would inflict more harm to pause communications and attempt retransmits of the lost packets, it simply makes the decision to move on.

Protocols build on top of TCP, like RDP or ICA/HDX, cannot provide this intelligent decision-making. TCP guarantees delivery of packets from the network layer, so the application has no option but to pause while waiting for the delivery of data. Sometimes, you really need to allow the software protocol to apply some intelligence to that decision.

As the Apollo 11 lunar module was rapidly approaching the surface of the moon, with nearly zero tolerance for errors, NASA knew that some data loss was acceptable. In fact, it was preferable to the penalty that could have been incurred by stopping the pending functions to complete previous ones. Had the Apollo 11 flight computers actually stopped measuring fuel consumption and distance to the moon for a few seconds to finish whatever computation triggered that 1201 program alarm, the event of July 20, 1969, may have ended very differently.