Stumble It!
This is agile at work. Using existing UDP/IP or SMTP (store and download like email) for the communications protocols for space missions. Duh! Why create a whole new comm networks for each mission when you can by a TCP/IP stack on any cellphone.
This is my agile argument for me:
After reinventing this wheel at least four times by the early 1990s, Hogie came to understand the power of the Internet Protocol. IP is the lingua franca for data communications. It's not just the way bits are packaged for transmission on the Internet but also how they are routed from machine to machine. As happens all the time on the Internet, two computer systems using wildly different hardware a Hewlett-Packard PDA and an IBM mainframe, say can pass the data back and forth, so long as they both speak IP.
To prove how powerful this concept of using IP in space could be, the Goddard team set up a log-in accounta user name and a password for some colleagues at the Marshall Space Flight Center, in Huntsville, Ala., so they, too, could access the ill-fated shuttle's computer. Without a standard TCP/IP connection, Marshall might have had to commission someone like Hogie to write the software that would make the connections to give access to its engineers. But with TCP/IP, accessing the shuttle was as easy as using an AOL account. Once logged on, technicians could upload or download files, check the logs to see how the onboard server was running, or do anything else the staff at Goddard could do.
This is what agile (and common sense) can do for you.
Remembereber, the best solution is sometimes the hardest, but it is never the stupidest. (you can quote me on that :)
Thanks to Nasawatch.com and Keith Cowling for pointing out this article...
4 comments:
Ed: Due to my error including Holoscan into Space Pragmatism, these to comments got lost. So I am posting them both here now. -- djs
The interesting thing about the article is that for some strange reason both groups (Goddard and JPL) are described as advocating a single solution, theirs.
Why not combine the solutions? Use IP for short distances (like the Earth-Moon-Lagrange sytem). Add application-level proxies that sit both on the IP network and the DTN network for long distance situations.
With good tools, you can pretty much automate a significant amount of development of the application proxy. Shameless plug: I'll be happy to have that contract
What am I missing?
Ben Reytblat | Homepage | 08.23.05 - 11:39 am | #Gravatar
Ed: Due to my error including Holoscan into Space Pragmatism, these to comments got lost. So I am posting them both here now. -- djs
Well that isn't that different from what happens on the ground. You use TCP/IP over LANs, but really big pipes (OC-3 and such) use HDLC and X.25 protocols. So they just wrap the IP in a X.25 frame and unpack it on the other end.
Dan Schrimpsher | Homepage | 08.23.05 - 12:11 pm | #
I may be out of my depth here, but here goes:
I'm not sure this will work. AFAIK, TCP requires an end-to-end ACK. If the ACK takes too long, the protocol stack times out. When you simply wrap IP in another protocol, as you described, you still need to get to the ultimate destination machine to generate and ACK.
I think what Vint is saying is that you can't make the timeout be long enough and still maintain any semblance of sanity at the higher levels of the stack for a large percentage of circumstances on a long-haul network (think 10 light seconds and further).
My proposal says that the ACK comes from the application-level proxy running on a gateway between the IP-net and the DTN. This way the ACK comes back to the originator relatively quickly.
The trick, of course, is to write the app proxy (a reverse app proxy, to be more precise) carefully.
I suspect, although I haven't tried it, that after someone writes a few of them by hand, we'll be able to generalize the code enough to be able to generate a significant portion of it for further iterations.
Sorry about saying TCP/IP. It is habit. I would never use TCP over any kind of slow link. Neither would anyone else. The Military uses UDP (no ack) over Sat Comm and lets the Application level do the acking (which is much more flexible). I think this would work with the acking being between long-haul points.
Post a Comment