Using Outlook From Orbit
Pigskin-Referee writes with this excerpt from Office Watch: "On the Space Shuttle and the International Space Station they use Microsoft Outlook 2003, but not quite in the same way that us earthbound Earthlings do. The space shuttle Atlantis is orbiting the earth right now and the crew exchange emails with the ground a few times each day. Bandwidth is a constraint and you don't want the busy crewmembers bothered with spam or unnecessary messages so NASA has a special system in place. The crew use fairly standard laptops running Microsoft Outlook (currently Outlook 2003) with Exchange Server as the email host, but they don't link to the server using any of the standard methods."
It's too bad the article didn't address the architecture behind all this. I would be curious to hear what kind of network they use, and what sort of relays (satellite?). If it is satellites, why is the bandwidth so low? (Hmmm... maybe they really should have made that ethernet cable just a little longer after all...)
"Before God we are all equally wise - and equally foolish"
Albert Einstein
mail server on the ground, mail server on the shuttle.
The mail queues up and you open up the connection between them certain times of day. Queue empties.
GZIP the link and your gold.
UUCP worked quite nicely in the days when links were ephemeral, slow, or generally unreliable. This seems like a lot of effort to solve a problem that existed 30 years ago, solved, and even adapted for RFC821 and its successors. There's a reason that Sendmail knows how to rewrite addresses!
-Scott Hutton
So, once a day they bundle a bunch of emails into a single .OST file and upload it to the shuttle. The astronauts then open that .OST file in their local copy of Outlook. And they have to shut down Outlook while the upload is in progress because of Outlook file locking.
If a 'Loss of Signal' can interrupt a POP session, wouldn't it also interrupt a file upload? Couldn't they just POP into the server on Earth once a day to grab their emails to be stored in a simple mbox or some such? Wouldn't this also eliminate the file locking issue as mboxes and Maildirs are pretty old and stable solutions that don't have this problem? This just sounds like someone wanted to use Microsoft Outlook no matter what and hacked together a procedure to use it even though there are way better approaches. And isn't the whole point of Outlook that it has a built in calendar and meeting request system and network folders? They're not even using those more advanced parts of it, they just need email.
We always knew Comcast was corrupt, here's the proof: http://tech.slashdot.org/comments.pl?sid=1909890&cid=34545432
They're doing it to save bandwidth. Yet they probably spend more on bandwidth dealing with human error issues in the process than they would if the system was engineered properly in the first place.
You don't see an issue because you aren't an engineer trying to save every drop of energy/bandwidth/processing time possible.
Basically, you're a java or C# developer when then need C and assembly developers with a clue.
Custom hacks when there are already systems (even build into EXCHANGE!) to do EXACTLY what they need to do are beyond stupid. Its one thing to use a custom hack so you don't get tied into a vendor, but their hack is entirely tied to their vendors so that rules that reason out.
Next you do it because you have a requirement that no existing solution fills in properly, which is certainly not the case here. As I already said, even Exchange will be happy to do store and forward batching on a schedule. A tiny exchange server (or a more efficient/less resource intensive alternative) on the space station could be designed to consume pretty much no energy unless it was actually in use.
In short, this is clearly something thrown together by engineers who knew nothing about the tools they were working with. Not their fault (probably), some douche bag manager probably didn't ask the IT guys.
The problem is, they went through effort and resources to make a system that is clearly less efficient than any of the possibly alternatives I can come up with.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager