Slashdot Mirror

← Back to Stories (view on slashdot.org)

Web Enabled Spacecraft

Posted by michael on from the fluffy-bunny-to-the-rescue dept.

gilgsn writes "Yahoo has an article from space.com about a satellite which will be operated by FTP over TCP/IP on the Internet! The CHIP (Cosmic Hot Interstellar Plasma Spectrometer) spacecraft will examine the stuff between stars, the so-called void of space that is actually rich with hot gas. The choice of protocol was dictated by economics. I wonder what OS it will run and if communications will be encrypted?"

16 of 236 comments (clear)

  1. I guess our company isn't too far off the mark... by los+furtive · · Score: 5, Interesting

    We were asked to come up with a fast cheap solution for getting two servers to keep in touch, and not have to change the company's firewall setup. Our solution was to use SOAP and JAXM, but our backup plan was to do everything via FTP...who knew we were in the same league as NASA?

    --

    I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.

  2. Why FTP? by drunkmonk · · Score: 5, Interesting

    Maybe it's just me, but doesn't it seem strange that it would be operated by FTP? I mean, one would think that being able to SSH to it and having a command prompt would be a lot more useful...

    Unless it's actually a cover and NASA is creating the first orbiting pr0n server :)

    1. Re:Why FTP? by Bostik · · Score: 3, Interesting

      one would think that being able to SSH to it and having a command prompt

      Did you give that thought any consideration whatsoever? SSH2, while secure and neat protocol, is not the leanest you could do. Try to think about it. We're talking about control channel to a moving, non-terrestrial body with probably not too much CPU cycles to spare.

      To establish an SSH connection, both the client and server need to exchange public keys. After that, they need to negotiate the session key(s) over public-key cryptography. This alone is slow. Then, to have any kind of real control, the latency between SSH endpoints needs to be rather small. The symmetric encryption wouldn't take that much cycles, so I'm leaving that out of the equation.

      So while FTP sounds like a really weird and unortohodox solution, it is after all a trivial protocol to transfer sets of batch commands.

      USER control
      PASS *********
      PUT batch
      QUIT

      Just a thought...

      --
      There is no such thing as good luck. There is only misfortune and its occasional absence.
    2. Re:Why FTP? by medcalf · · Score: 3, Interesting

      That would be really bad. Leaving aside the practical implications of attempting an interactive encrypted session with the kind of lag that comes from the physical distance, there is the simple matter of mistakes. You don't want someone to make a mistake typing an interactive command, which could leave the satellite useless and nonresponsive. Instead, you create and test the heck out of your control files, and once they are perfect, just transfer them.

      What actually surprises me is that they are using TCP/IP, rather than UUCP, which seems more appropriate to this kind of latency and simple file transfer need.

      --
      -- Two men say they're Jesus. One of them must be wrong. - Dire Straits
    3. Re:Why FTP? by sketerpot · · Score: 3, Interesting

      Perhaps FTP over an encrypted connection with symmetric keys exchanged before the thing goes into space? There are even special purpose chips to do such things if you want negligible CPU time expended. Check out OpenCores

    4. Re:Why FTP? by Cujo · · Score: 3, Interesting

      They don't just use FTP. That's just one port for getting data to and from the spacecraft in batches (which is usually a perfectly acceptable way to get data in and out). See their whitepaper. They can also telnet to the 750, and hve other services as well.

      --

      Helium balloons want to be free.

  3. FTP and TCP/IP???? by amithv · · Score: 4, Interesting

    Couldn't they have picked better protocols? It seems to be me for reliability and performance that isn't the best of choices. There are alot of other protocols (XTP for example) that the government could have used instead. Although TCP/IP is so commonplace I wouldn't want my 15 million dollar satellite to depend on it.

  4. PING by del_ctrl_alt · · Score: 5, Interesting

    Hope it has an IP address, It would be cool to ping something not on earth.

  5. Engineering Issues with Space Design by Effugas · · Score: 5, Interesting

    Serious kudos to these guys for the work they're doing! From what it sounds like, they're using FTP inside of either a IPSec or custom layer 2 encrypted tunnel -- once you've been wrapped by that, you're mostly OK (though FTP servers in general have had some pretty nasty growing pains).

    Some may be wondering why the use of FTP, instead of HTTP. Indeed, HTTP is a unified protocol capable of elegantly handling both (moderately) interactive command exchange and bulk data transfer. The problem is latency -- if this beast is going anywhere, there's going to be some significant (5-10 second, minimum) lag between issuing commands and receiving responses. In such an environment, you don't *want* interactive access; you want an elegant way of providing a series of commands and receiving a series of responses. FTP provides that -- among other things, while HTTP's capacity for downloading files is quite mature, anything more is asking a bit more of HTTP than it was designed.

    FTP has specific commands for machine interaction w/ the file server -- NLST provides a standard formatted directory of files, independent of the underlying implementation. By contrast, Apache dumps some HTML.

    WebDAV ("Web Folders) was meant to address complex file system operations under the rubrick of HTTP. Thus far, it hasn't been much of a success. It most likely never will be. Thus, FTP is used.

    But FTP is built on TCP, and this introduces a problem: The affects of latency upon the underlying TCP error handling protocol. TCP implementations are notoriously untuned for the case of high bandwidth, high latency. They're built to assume the lack of a response implies either congestion on the line or packets being dropped; either way, implementations tend to scale back. Significant work has been done to address this case, mostly on the behalf of Satellite systems (the ultimate in high latency, high bandwidth access). Mostly, the idea is to expand window size (the amount of data that each side is allowed to send before it must receive an acknowledgement) to match the amount of data that's literally hanging amidst space and time on its way to its receiver. But this is a very hard problem, one of the few that the architecture of TCP has quite a bit of trouble scaling to handle.

    NASA went to a bulk transfer protocol, partially because interactive performance across large distances is problematic. But the bulk transfer protocol itself is based upon an interactive error management protocol. It'd be interesting to repurpose an established protocol for error-handled bulk transfers for just this use...I'm certain one of the "reliable multicast" architectures out there would be an astonishingly elegant solution.

    That's not to say they made the wrong choice with FTP -- particularly if they tuned their stacks well, and encapsulated themselves amidst lower layer security, great job! Just that there's lots of work in this arena left to do.

    If I remember right, Vint Cerf and a couple of his colleagues were working on IP protocols suited for communication between Earth and Mars. We're talking *minutes* of latency! Now that'll be a hell of a hack :-)

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com

  6. Simplification for the general public by Goonie · · Score: 5, Interesting
    I think the point is that they're going to use TCP/IP as the basic communication protocol between the satellite and the ground. I think FTP was basically a "for-instance" they were using to describethe type of thing they would use - but, then again, there's no reason why they couldn't run an FTP server on the satellite for retrieving data (though I'd run SCP methinks...)

    Conceivably, you could even control the satellite by ssh'ing into it and running various command-line apps. If you wanted to be really cute, run a web server on the satellite and make it controllable with web forms... but that strikes me as just a little over-elaborate :)

    For security purposes, they mention using "standard commercial applications" to encrypt the link. Presumably that means they're running a VPN of some description. As an additional security measure, you'd presumably want to hide the thing behind a firewall and give it a non-global IP address (somewhere in the 192.168.*.*'s, presumably) so that it simply can't be reached from the wider internet, and then (if it was *really* necessary) set the firewall up so that the appropriate people can tunnel through.

    Actually, it would be interesting if we could get a /. interview with one of the people behind this satellite (and grill them about their security measures). Roblimo, are you listening?

    --

    Any sufficiently advanced technology is indistinguishable from a rigged demo
    --Andy Finkel (J. Klass?)
  7. Protocol choice by tigress · · Score: 5, Interesting

    Personally, I find it very intriguing that they've chosen FTP as the protocol, though it does make a lot of sense. Most of what the sattelite is intended to do will be done in a pre-determined manner. Very little will be done in real-time. As a result, most instructions will be able to be scripted, and FTP is an excellent way of uploading scripted instructions to the sattelite. TFTP would've been even better, had it not been for the lack of access controls.

    Now, that much said, when do you think we'll see the first DDoS of zombie spaceprobes? =)

  8. IP in Space by Anonymous Coward · · Score: 1, Interesting

    There is a group downstairs from me at nasa that working on their IP in space project. Part of it relates to this, developing a space standard from TCP/IP for connecting to satellites instead of all the proprietary stuff they use these days. And, BTW, they want to use linux for this.
    The second part of their project is to try to get all the components on a satellite to communicate with eachother using TCP/IP instead of all the (again) proprietary connections. It would save alot of time and testing if you could just:
    a) test a component by plugging it into network card on a computer, instead of having to develop software to deal with an IO card and the unique communications of the device

    b) be able to just plug all the components into the satellite

    Its one of those things that is interesting/scary

  9. Web-enabled vs. FTP by Peter_Pork · · Score: 2, Interesting

    Let's get this straight. The web uses the HTTP protocol, not FTP, so this web-enabled spacecraft headline is misleading. Browsers include an anonymous FTP client, so you can navigate and download from FTP servers, but that doesn't mean FTP is part of the web. The piece of news is the use of out-of-the-box Internet protocols in a spacecraft. It is great news. Save money by using solid, well-known technologies. This is part of the agenda of the new NASA, and it is basically good. You cannot reinvent the wheel in every mission. BTW, you still need a deep space antenna to contact the spacecraft, so it cannot be hacked unless the attacker breaks into a well-protected NASA site.

  10. The International Space Station Already Has This by cybrpnk2 · · Score: 5, Interesting

    The Ground Systems Department at NASA Marshall Space Flight Center has a "new" system called Telescience Resource Kit (TReK) that allows experimenters to hook personal computers in their home labs up to experiments they are running aboard the International Space Station. The main entrance page is here, but most of the links are password protected...

  11. Interesting thought... by lscotte · · Score: 2, Interesting

    I know this was meant to be funny, but it's a very interesting thought. Sort of like the off-shore hosting companies, but taken several steps further.

    Of course latency would always be an issue for something in space, but for a streaming protocol...

    --
    This post is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.
  12. Astrophysics Programming by VoidEngineer · · Score: 3, Interesting

    So, in college, I worked with some astrophysicists at the Enrico Fermi Institute, which is where they build nuclear powered satellites, and took some classes from professors at at The Laboratory for Advanced Space Research, which is responsible for building such satellites/spacecraft as Ulysses, Pioneer 10 & 11, Cassini, StarDust, and Argos.

    Anyhow, from talking with folks at the EFI and LASR, the general answer to everybody's questions is: latency and noise. Remember, this is a Cosmic Hot Interstellar Plasma Spectrometer, which means that it's going to be sent away from the earth, and eventually be millions and billions and trillions + miles away. The longer that it works, the more latency is going to build up... So, the programming needs a very non-interactive protocol. If this thing goes interstellar, it could take days and weeks for packets to travel from Earth to CHIPS and back.

    Remember, it takes 4 minutes for light from our closest neighboring star to reach earth, traveling at, well, the speed of light. In all probability, this CHIPS will be using radio frequencies which are much, much slower. (I could be wrong, but I would be surprised if they had hacked some type of interstellar laser guidance system... )

    Anyhow, they write scripts for this kind of mission, and generally operate with a big time lag, to the extent that it's sort of like typing with your computer monitor turned 'off'. That is, they'll figure out what they want the satellite to do for the next week or next month, type up a script, and 'submit' it to CHIPS. A couple of hours/days/weeks later, CHIPS will receive the script and start working. This kind of astrophysics programming generally involves being able to project into the future (temporally), and to know that in {x} days, the satellite will be past Mars, in {x+a} days, it'll be past the asteroid belt, in (x+a+b} days, past Jupiter, in {x+a+b+c} days, past Saturn, and so forth. It also requires good file keeping and record keeping, so that you know how many days {n} into the project you are, so you can calculate {n-x}, which gives you the time window for submiting an FTP control sequence.

    Other than that, yeah... they can dir things and get thing. Depends on the exact implementation, but you have the concept.