Web Enabled Spacecraft 236
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?"
Pity about no www server (Score:5, Funny)
Re:Pity about no www server (Score:5, Funny)
but they do have ssh on it (Score:3, Funny)
Don't worry... (Score:3, Funny)
did you say FTP? (Score:5, Funny)
Interesting thought... (Score:2, Interesting)
Of course latency would always be an issue for something in space, but for a streaming protocol...
Windows... (Score:2, Funny)
Microsoft announces... (Score:5, Funny)
In other news, a satellite was taken over by a 5 year old...
Re:Microsoft announces... (Score:2, Funny)
Whats the betting that Windows SPACE will adopt a standard StarTrek orbit that decays 12 hours after power failure?
you wonder what OS and if it will be encrypted? (Score:2, Funny)
FTP? (Score:2, Funny)
Surely they could've hacked together something better than that? If that's a question of economy, their budget must be extremely small.
I didn't read the article btw.
An additional craft (Score:2, Funny)
Wacky brit! (Score:2)
Re:Wacky brit! (Score:3, Informative)
~~
By the way, this story is a dupe, and I don't think anyone else has called on it yet. It was posted several months ago under a topic of something like '.mars is coming.' and talked about how satellites around Mars would use TCP/IP.. just like, er, this article.
I guess our company isn't too far off the mark... (Score:5, Interesting)
OS (Score:2)
MS is working hard on the C_CHIP ActiveX control. Once that's done, for NASA it's just a matter of a simple drag&drop and 3 lines of VB code.
Who said space exploration was difficult ?
Why FTP? (Score:5, Interesting)
Unless it's actually a cover and NASA is creating the first orbiting pr0n server
Re:Why FTP? (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.
Just a thought...
Re:Why FTP? (Score:2, Funny)
That would be TFTP.. Hence the T
Re:Why FTP? (Score:3, Interesting)
Re:Why FTP? (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 [spacedev.com]. They can also telnet to the 750, and hve other services as well.
Re:Why FTP? (Score:2, Insightful)
Re:Why FTP? (Score:2)
So out of all the "standard" protocols out there, ftp would be the most flexible while still being very light weight.
Re:Why FTP? (Score:2)
Re:Why FTP? (Score:2)
According to Airplane II (Score:3, Funny)
Re:Why FTP? (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.
Re:Why FTP? (Score:2)
FTP? (Score:5, Funny)
It wont take long for someone to crack the satellite. They will download images thinking to collect nice data about deep space but instead will find that some h@X0R has redirected their satellite to take a good close look at Natalie Portman.
Or...the first DDoS initiated from space will soon be in the headlines.
FTP? C'mon!
Re:FTP? (Score:2)
FTP is perfectly secure if you run it over IPSec.
I doubt they're actually using IPSec here, but I'm sure they have some form of encryption built into the lower protocol layers.
Re:FTP? (Score:2)
Yeah, well...it would seem easier just to use ssh instead of dinking with ftp.
FTP!? (Score:5, Insightful)
And I wonder how this control works, do you CD into a spesifc cordinate of space to examine? Can you DIR the stars it can see to find which ones to look more closely at, and then GET the acual data?
Hrm, actualy that would be kind of cool.
Re:FTP!? (Score:3, Informative)
FTP is used as a control protocol in plenty of environments. It's really quite simple. You upload one or more files with instructions in it. Then you upload a semaphore file to say your message is complete. The receiving end reads the directory every 10 seconds or so and starts processing when it sees the last file. I imagine that the satellite would return data instead of instructions, and then the process would repeat. The FTP protocol per se has nothing to do with controlling the satellite; it's all about using files as messages.
I've seen credit card authorizations go through this way. UNIX and mainframe machines often exchange data this way when turn-around time is not important. I would assume NASA doesn't need to control the satellite second-by-second.
Re:FTP!? (Score:2)
I thought using FTP on the satellite sounded dumb, but this would be far worse.
Re:FTP!? (Score:3, Funny)
When I worked in the MIT AI lab, the coke machine used FTP as a `control protocol'.
You'd ftp to the machine, log in (you had to have a coke account), and type:
get coke
The thing is, most people just use a normal FTP client, and the above command will actually transfer a file called `coke,' so I suppose it's better to type "get coke -".
But I always forgot about that, and as it happens, I usually drank Dr. Pepper, so to this day, in random directories on that system, I'll find little files called `drpepper'...
Re:FTP!? (Score:2)
Having implemented FTP and HTTP I find the choice bizare but not suprising. There are a lot of people who incorrectly belive that FTP is more efficient than HTTP. If you do an actual packet trace there are practically no circumstances in which FTP is more efficient, and all the cases where FTP wins are contrived (padding out the headers etc.)
HTTP is simply a bunch of RFC822 headers on top of a raw TCP socket. FTP has two channels, a control channel layered on telnet - if you don't believe me go read the specs. Data has a separate channel. That means that you have two sets of stream setup and maintenance. If you have a large file the control channel acks continuously to keep itself alive.
I would not be worried so much by the inefficiency here as the unnecessary fragility over a lossy channel. Twice as many moving parts means twice the chance of failure.
Reusing FTP because it is twenty five years old does not seem to me to be a good strategy. FTP has not progressed in the time since. It was never designed to serve this use.
Astrophysics Programming (Score:3, Interesting)
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.
Re:Astrophysics Programming (Score:2)
You know, I could almost believe your comment about the Enrico Fermi institute, until I read this. I guess nobody's ever told you about 299,792,458m/s.
It's not just a good idea, it's the law.
Re:Astrophysics Programming (Score:2)
Please enlighten myself and other slashdot readers about 299,792,458m/s. Have I erred in saying that CHIPS will be using radio frequencies? Have I erred in regards to the time it takes for light from the next star over to reach earth?
Be more specific, if you're going to critique. I would like to know your opinion regarding this matter, and what about 299,792,458m/s do I apparently not know.
Addendum: Astrophysics Programming (Score:2)
Sorry for replying to my own post, however, I stand corrected. I was describing 'Radio Waves' in terms of accustic sound waves; which, in this case, does not apply. Ignore this comment regarding radiowaves being slower...
Sattelite with web protocols... (Score:2)
FTP and TCP/IP???? (Score:4, Interesting)
comonplace == bad? (Score:2)
Re:FTP and TCP/IP???? (Score:5, Informative)
It is called "Interplanetary Internet SIG":
http://www.ipnsig.org/home.htm
So... they do not use the common TCP/IP things, but their networking principle is closely related to IP.
Re:FTP and TCP/IP???? (Score:3, Insightful)
And what, specifically, do you think is wrong with TCP/IP? It's pretty minimal and simple.
Although TCP/IP is so commonplace I wouldn't want my 15 million dollar satellite to depend on it.
Even if TCP/IP had some technical drawbacks relative to some alternative protocol, software implementation errors and engineering mistakes are likely much bigger risks than some theoretical limitations of the protocol.
In different words, I'd much rather bet $15 million on a proven, debugged, mature TCP/IP implementation than on some implementation nobody has ever used for a protocol nobody has ever heard of.
Got r00t? (Score:5, Funny)
J. |_337 H4x0r: D00d$$$ I took control of da satelite man! See hoe |337 I am!!!
J. |_3373r H4x0r: L00se, sux0r! I can make her spin round! Wheee! Wheeee!
J. |_337 H4x0r: What are you doing idiot you're taking her down!!!
J. |_3373r H4x0r: No way man. I'm much to |337 for that!! DAMMIT Windows crashed again! sux0rzzz!!!###
[Sattelite falls down to Earth]
"Web Enabled"? (Score:2, Insightful)
MOD PARENT UP!! (Score:2)
Seriously, just because modern web browsers can issue a limited subset of the commands defined in the FTP protocol doesn't mean that FTP is part of "the web". I was using FTP long before there was ever a "Web". If you upload anything via FTP on a regular basis, the difference is readily apparent.
Windows (Score:3, Funny)
Ok, now I've gotten all the blindingly predictable jokes out of the way, can we move to something more interesting?
You missed a few... (Score:3, Funny)
On the Unix side -
That "No route to host" error becomes more meaningful.
"Uptime" will relate to orbit, not system.
Web != internet. (Score:2)
Satalite and Internet (Score:2)
What ftpd? (Score:2)
PING (Score:5, Interesting)
Re:PING (Score:2, Funny)
Re:PING (Score:2)
You could watch the latency gradually shrink and grow as it constantly changed distances from its receiver. If you could ping it directly, pinging it from 4 different non-planar sources would allow you to quadrangualte its exact position at any time.
Re:PING (Score:5, Informative)
I have "pinged" the dove sattelite at least 20 times in my life, Pinged and sent email to MIR, had a kind-of IRC chat with 2 different Space shuttle missions and have listened to my ping come back from the moon.
ham radio, you get to do things that other only wish they could do.
all of this was done at 144-148mhz with standard radio equipment and radio modem called a TNC. MIR was the easiest to contact.... moonbounce requires a friend with no wife and lots of money.
Engineering Issues with Space Design (Score:5, Interesting)
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
Re:Engineering Issues with Space Design (Score:2)
Re:Engineering Issues with Space Design (Score:2)
You mentioned multicast UDP for commands. I can see this for something like, "Everyone, point their dishes at this quadrant of space"...but managing error control and responses must not be fun.
Thanks!
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
--Dan
Command Verification (Score:2)
Re:Command Verification (Score:2)
Are sats constantly dumping their buffers and status to RF?
--Dan
Re:Command Verification (Score:2)
Re:Engineering Issues with Space Design (Score:2)
A couple people have used sleight of hand to create effects that, as a whole, do move faster than the speed of light. But there's nothing actually moving, you see. They're the physical equivalent of the disconnection between the rate of individual cars in traffic and the rate at which traffic dissapates. Imagine an accident's cleared, and traffic suddenly has an open path. Does it disappear immediately? No -- the first guy has to get off his brake and accelerate, then the second guy needs to see the first guy go, then the third guy needs to see the second guy, etc. So even though everyone could start accelerating immediately, this "wave", not composed of anything but the awareness that motion is possible, slowly eats away at the traffic jam.
Now, flip the situation -- imagine everyone's car had a computer that received a message saying, "traffic jam has been cleared; in 60 seconds, everyone start accelerating at the standard rate." No individual car is going to travel much faster than the speed limit -- but that pulse is going to go backwards at tens of thousands, maybe even hundreds of thousands of miles per hour. Theoretically, the "pulse" could go faster than light -- the timing information was deployed by radio, at the speed of light, but that was the past. It is now; no information needs to be exchanged to move, so there's no limit to the speed at which the "motion pulse" could occur.
But no information is moving. Just a pulse, only visible from afar.
Electricity moves as somewhere between half and two thirds the speed of light. It's slower, but still quite speedy (until you get into the scale of microchips, at which point you actually need to start taking into account signal propogation delay as you try to move from one side of the chip to the other).
There does appear to be some theory that gravity is instantaneous; my personal suspicion is that even if it was, the speed of which a sensor could react to it would be directly tied to the distance from the gravitational object (i.e. sure, the message might get sent, but it wouldn't have enough energy to be detectable until the requisite amount of light time had passed). Nature tends to be annoying in that way
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Re:Engineering Issues with Space Design (Score:2)
Quantum Entanglement is much more proof of a quantum scale PRNG than people are willing to admit.
I suspect eventually the inherent conflict between Quantum Entanglement(subatomic particles may have their "random" states synchronized) and Quantum Cryptography(subatomic particles are perfect unique tokens because their random states may never be duplicated) will lead to a break in one or the other. They will likely mutually annihilate.
*WONDER CRANK POWERS BACK IN THE CELLAR*
But that's just what *I* think.
--Dan
Re:You're got FTP and HTTP reversed there. (Score:2)
But latency at the protocol layer is not what they're trying to solve (indeed, they'd be using TCP either way, so they're having protocol issues with latency no matter what). They're trying to solve latency from the perception of the operator, by batching all of his requests into a job file. And it's standardized access to a remote file system that FTP addresses well. While HTTP does all you claim, it does an undeniably poor job of standardizing the presentation of remote files. NASA's centralized all their custom programmatic work -- both in the encoding of batched commands, and the decoding of batched results -- into a tarball. (At least, that's what I'm assuming -- I've done the same thing in the past.)
Once you have these batches, everything is utterly standard. Yes, HTTP lets you download multiple files at a time. From which URLs? Ah, you must download the HTML, pick out all the links, create an index, from those links, and start pipelining a number of requests. How many requests? How deep can the pipe go? And dear god, uploading data into a HTTP system is an utter pain in the ass.
You can build things with wget and curl. But should you?
Sure, you can twist a web server into doing all this. But it's not what it was designed for. HTTP may offer significantly fewer round trips, but its presentation of a remote file system is immature at best and a horrifying fault of HTTP at worst. How many people do you know who FTP their updated web pages into the servers? Is there even a lightweight text editor with *HTTP* support?
FTP's all about centralizing the difficulty into the file format. HTTP ends up screaming at you(a human) to use a web browser to click some icons and fill out some forms.
A simple example: wget a directory served by apache. Notice all the files with weird names, like =AQ and whatnot? Those are alternate directory indexes. Grab the same directory of files over FTP, still using wget. This works right.
Funny -- the latency win is from serializing i/o to individual files. HTTP's so bad at file management, that its use would actually threaten the viability of using files...the protocol issues, both TCP and Layer 7 just get lost in the backwash compared to that.
--Dan
P.S. Yes, I looked into doing this over SSH...you could do something like:
ssh user@satellite "scan_here -o scan1; scan_there -o scan2; tar czvf - scan1 scan2" | tar xzvf -
or even:
$ cat > test.sh
scan_here -o scan1;
scan_there -o scan2;
tar czf - scan1 scan2;
ssh user@host "`cat test.sh`" | tar xzf -
This also works, and with bigger scripts, but I haven't fixed a bug with it not exiting when it's done (it's with the tar on the client side):
cat test.sh | ssh user@host | tar xzf -
I threw 20K commmands into test.sh and it worked perfect.
--Dan
Re:Engineering Issues with Space Design (Score:2)
--Dan
ipinspace (Score:2, Informative)
Web-enabled? Nope. (Score:2, Informative)
Pedantic, I know, but FTP != web. HTTP == web. I know a lot of people don't grasp the difference between the internet and the world-wide-web, but you'd have thought someone writing web content might have got it right.
Also, ethernet != internet (the program manager for the project got that one wrong).
Simplification for the general public (Score:5, Interesting)
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?
Protocol choice (Score:5, Interesting)
Now, that much said, when do you think we'll see the first DDoS of zombie spaceprobes? =)
TFTP would be a bad choice (Score:2)
A TCP-based protocol is exactly the right thing for this application. The only thing they have to watch out for is that they need to increase timeouts and other parameters that have been adjusted downwards in consumer machines for "performance reasons". FTP's use of separate control and data connections also makes it a little more attractive than alternatives.
I doubt authentication was a consideration--FTP is insecure anyway. They probably use firewalls.
Oh no! (Score:2)
"Calling Seven-Mary-Three and Four"
Ask Slashdot? (Score:2, Informative)
From the tcp_timer.c source... (Score:2, Funny)
Remember this infamous bit of commenting?
in linux/net/ipv4/tcp_timer.cAll your satellite are belong to us (Score:2)
FTP, eh? Commercial software, eh? Low budget, eh? This is gonna be so easy.
TCP/IP is TERRIBLE in space (Score:3, Insightful)
And, this isn't the first satellite to use TCP/IP, by the way. TCP/IP has been run over satellite links numerous times, most often to demonstrate TCP's shortcomings in relation to better methods.
note: that's not to say that TCP/IP isn't a fine protocol -- it's a perfectly reasonable way to do things on a low BER, low latency network (i.e., the majority of networks we commonly use). I'd have the same criticisms of someone trying to run, for example, SCPS on a terrestrial network. It's the wrong tool for the wrong job.
Re:TCP/IP is TERRIBLE in space (Score:2, Informative)
No, it's not. However it IS the first satellite to ONLY use TCP/IP to communicate.
From the spacedev website [spacedev.com]:
"The Cosmic Hot Interstellar Plasma Spectrometer Satellite (CHIPSat) will be the first mission to use end-to-end satellite operations with TCP/IP and FTP. This concept has been analyzed and demonstrated by the NASA OMNI team via UoSAT-12; however, CHIPSat will be the first to implement the concept as the primary means of satellite communication."
Re:TCP/IP is TERRIBLE in space (Score:2)
Nah, a default TTL of 60 is perfect for sending packets through space...
CHiPs? (Score:2)
Untouchable MP3 Distribution? (Score:2, Funny)
Re:Untouchable MP3 Distribution? (Score:2)
--
Benjamin Coates
Web-enabled vs. FTP (Score:2, Interesting)
MIPS computer with several OSs (Score:2, Informative)
They are using VxWorks, PSOS, OS-9, and Linux. Looks like VxWorks is what will be running on the satellite, with less than 20 lines of code in the actual communication routines...
LR
Re:MIPS computer with several OSs (Score:3, Informative)
LR
The International Space Station Already Has This (Score:5, Interesting)
Here's the web address for the satellite! (Score:2)
RickTheWizKid
Lightening Slashdot users' days since 2001!
Woot! (Score:2, Funny)
Satellite CPAN Mirror (Score:2)
FTP? (Score:2)
Sounds like some clueness reporter pulled a TLA out of a hat or something...
Unless the FTP is being used as a sort of batch command transmission vehicle... A little like the IPN [slashdot.org] protocol specifies. A sort of connectionless command line over a connected protocol.
Phew (Score:2, Funny)
SpaceDev and other useful links (Score:2, Informative)
Spacedev is (duh)
www.spacedev.com [spacedev.com]
CHIPSat can be found under Missions.
Spacedev's stock price can be found at:
finance.yahoo.com [yahoo.com]
The Space Sciences Laboratory at UC Berkeley
chips.ssl.berkeley.edu [berkeley.edu]
Ground Controll Crew (Score:2, Funny)
Bad choice. (Score:2)
Hacking together a special use protocol with a push stream with ton of error corrections is not a big deal.
Or, what they are talking about is a connection up to the uplink station?
oh dear... (Score:2, Funny)
'WEP enabled spacecraft '
I can imagine loads of script kiddies aiming Pringles cans into the sky....
CHIPSat Launch Delayed due to Rocket Problems (Score:2)
The announcement is reproduced below:
eAnnouncement
CHIPSat Launch Delayed
December 19, 2002
Due to circumstances beyond our control, the CHIPSat launch scheduled for Thursday, December 19, 2002 on a Delta II rocket from Vandenberg Air Force Base has been delayed and is now targeted for January 8, 2003.
The launch was delayed due to a technical glitch in the Boeing-manufactured launch vehicle. The technical problem is associated with the signal the ordnance box provides for launch vehicle devices to unlatch and separate the payload fairing. NASA is expecting the replacement of this unit to take approximately two weeks.
SpaceDev designed and built the CHIPS (Cosmic Hot Interstellar Plasma Spectrometer) spacecraft and associated subsystem products (e.g. Miniature Flight Computer) for the University of California, Berkeley under a NASA-funded contract. The CHIPS mission is designed to study the formation of stars, and will have a life span of about one year.
CHIPSat will be the first mission ever to use end-to-end satellite operations over the Internet with TCP/IP and FTP. This concept was analyzed and demonstrated by the OMNI team via UoSat-12; however, SpaceDev will be the first to implement the concept as the only means of satellite communication.
SpaceDev has overall responsibility for the design of the mission, the design, assembly, integration and testing of the microsatellite, and mission control and operations from Spacedev's Mission Control Center.
If there are any further delays, we will send out an update immediately.
Re:Bad ping times (Score:2, Insightful)
But I imagine ftp access wouldn't be too fussed about ping times, unless your trying to ftp into something like Pioneer 10 or something.
Re:Bad ping times (Score:3, Informative)
OTOH, doesn't TCP use alot of SYN, ACK etc. to establish/close a connection? This could be a problem because it multiplies the round trip time which could have been avoided by using a special purpose protocol.
I'm also wondering if there would be a high error rate because of atmospheric disturbances and such. If so, TCP would be really useful because you get error correction for free.
Re:What OS? (Score:2)
Re:I wonder what the firewall rules will be? (Score:3, Funny)
Don't be silly. You can't run Cat5 into space, it's too long of a run. This is definitely a job for single-mode fiber