Slashdot Mirror

Correct me if I'm wrong but wasn't Iceland a geologically unstable land with an high rate of volcanoes because traversed by a fault line and thus subject to seismicity?

Right, someone could object that also some other place as well filled with important datacenters and nodes has far more seismicity or happens to be under water level in times of sea level rise, but still.

Although geografic spreading like in Akamai make a non-problem of this, at least for big data providers who can afford them: how do we confront the problem of nodes like AMS-IX and other Internet Exchange Points of NAPs potentially vulnerable, and not only to the force of nature?

Would the Net Transit survive a Big One, and then be useful as emergency service too and for communications, the reason it was initially made for, or would it miserably fail by the falling of one of its major nodes? So then does it really make sense to concentrate too many resources in the same place other than from an economic point of view?

I agree. If you can, have Akamai do it. You will save yourself a thousand man-years of headaches. They have people in Spain, BTW. Also, AFAIK Flash servers are 1) proprietary and have licensing costs, and 2) run only on Windows. Somebody would end up having to be the local FMS expert, and at least one other person would have to be competent for when the expert is not available.

If that's true it's the opposite of how every other industry works. Business rates for electricity arecheaper than for citizens. Business rates for phone service are also much cheaper (like unlimited long distance calling) than for citizens like us. It seems to me that the internet hookup for a business would follow the same routine, and be cheaper per gigabyte.

So take my 19 cent estimate, multiply by 2, and you get 38 cents which is cheaper than mailing a physical disc.

It is different than other industries because, not only is the usage ratio flipped, but business-class connections have guaranteed-uptime contracts. The higher that guaranteed uptime, the higher that price is. Of course, that's because:

• 99% uptime = max downtime of 5259.6 minutes (87.66 hours / 3.6525 days) per year
• 99.9% uptime = max downtime of 525.96 minutes (8.766 hours) per year
• 99.99% uptime = max downtime of 52.596 minutes per year
• 99.999% uptime = max downtime of 5.2596 minutes per year

with penalties for missing those guarantees.

They also have guaranteed connection speeds, while home connections usually don't (go read your ISP's fine print).

Now, having said all this, Microsoft pays Akamai for the use of their content delivery network for MSDN downloads.

Anna Nicole's death still ranked higher.

"Akamai speeds the delivery of content and applications for customers through using automatic, intermediate, and temporary information storage to make the onward transmission of that information to other recipients more efficient."

It also seems that the BBC cover themselves with iPlayer Terms and Conditions Section 12(2):

[You agree] that you are responsible for paying all expenses that you may incur in connection with your access to and use of BBC iPlayer including your internet service provider charges and any excess charges to that provider if you have a cap on downloads and/or uploads and all costs of the equipment and software you need to connect to and use BBC iPlayer. BBC is not responsible if your equipment or software is not compatible with BBC iPlayer[.]

They would see this as part of the service, so I guess unless it's tested in court we'll just have to live with it.

Martyr, anyone?

Here is one solution to that problem.

142 million visits in one day is about ~1640 visits per second. However, traffic isn't distributed evenly - typically peak is twice that of average. So they need to be provisioned to handle ~3287 visits per second.

They'll also want some headroom to ensure they can still serve in case of hardware failure, so let's imagine they provision for 4000 visits/second.

The Yahoo homepage, at least for me, triggers about 32 file loads on a cold cache, so that's a peak hits per second of about 128,000.

For comparison, Akamai globally peaks at about 6.5 million hits/second.

Easy multicast enables a whole new class of applications and mobile devices that could be very useful, but are very difficult to produce today.

Interesting. I wasn't aware that IPv6 changed anything with respect to multicasting. I Googled it and came up with this:

http://www.tcpipguide.com/free/t_IPv6MulticastandAnycastAddressing.htm

One of the most significant modifications in the general addressing model in IPv6 was a change to the basic types of addresses and how they were used. Unicast addresses are still the choice for the vast majority of communications as in IPv4, but the "bulk" addressing methods are different in IPv6. Broadcast as a specific addressing type has been eliminated. Instead, support for multicast addressing has been expanded and made a required part of the protocol, and a new type of addressing called anycast has been implemented.

Ok, having multicast a required part of the protocol means people would actually be able to use it. Right now multicast over the internet often gets filtered/ignored. Multicast makes a compelling case for content distributors - send out one copy of your stream and routers along the way will duplicate it as necessary.

All this really does is save you from having the buy more bandwidth/servers. I don't see how this enables new classes of applications; I can't think of many non-media applications that would benefit from multicast. That may just be my poor imagination. I have seen systems that use UDP multicast to deliver realtime stock quotes for traders, but that was run over a private IPv4 network.

As a workaround, content distribution networks could easily replicate streaming protocols for you without multicast; they already do it for HTTP. You set up one copy of your stream to Akamai, and they replicate it as necessary as clients connect to them. They already have distribution points scattered across the globe, close to the endpoint users.

Oh wait, they already do that. http://www.akamai.com/html/technology/products/streaming.html

No need to change the whole world over to IPv6; just shell out a few bucks. So if by "difficult" you mean "expensive" - yes. Difficult as in requiring new technology - not really.

% of Attack Traffic by Country seen by Akamai
_# 2008-Q2 2008-Q1 Country
_1 30.07 _3.56 Japan
_2 21.52 14.33 United States
_3 _8.90 16.77 China
_4 _5.56 _1.58 Germany
_5 _2.34 _0.41 Ukraine
_6 _2.25 _3.43 South Korea
_7 _2.21 11.82 Taiwan
_8 _1.89 _0.89 France
_9 _1.64 _0.93 Russia
10 _1.58 _0.83 Poland
-- 22.04 ----- OTHER

According to Akamai's quarterly "State of the Internet" report, Japan and the U.S. account for "over 50% of observed [attack] traffic in total."

You can see the executive summary and download the report here.

Full Disclosure: I work for Akamai.

For those that hate space.com:
http://mfile.akamai.com/18566/wmv/etouchsyst2.download.akamai.com/18355/wm.nasa-global/Constellation/CDT2_256.asx

See also:
http://www.nasa.gov/mission_pages/constellation/orion/pa_chute_test.html

Direct link to video.. http://mfile.akamai.com/22165/wmv/spacex.download.akamai.com/22165/F1-002-Launch-WebcastLow.asx

Why don't they just use a 3rd party distributed storage system like Akamai NetStorage? Then they don't have to worry about adding capacity, redundancy, etc. All they have to do is upload the picture there, and Akamai mirrors it all around the world.

That video that's mentioned is here. This technology still relies on wireless transmission, so who ever uses it must be in relative close proximity. So when deployed, if you notice them some how, you'll know someone is near by.

Both BitTorrent DNA and Red Swoosh have JavaScript APIs for starting, monitoring and controlling BitTorrent downloads. The actual BitTorrent client runs in a service process, which you talk to through "http://127.0.0.1:port#".

The JS libraries just rewrite the URL of the file you want to torrent so it goes through the proxy. They also allow you to monitor and control the progress of the downloads via a ReST interface to the proxy that returns json or xml.

The JS libraries both support putting links into the page that are automatically rewritten to download via BitTorrent. You can use the status monitoring interfaces to display a progress bar and give the user feedback about the download process.

Another approach is to develop an XPCOM plug-in that wraps one of the bittorrent libraries like libtorrent. That gives you a lot more direct control over the library from JavaScript. But I think it's safer to have all that complex code and volumous data running in its own separate process, and not bloating up and slowing down Firefox.

Talking to the BitTorrent client in a separate process via http makes it very easy to use from JavaScript, and that does not bloat or slow down Firefox itself.

-Don

Akamai is licensing this technology to the whole world http://www.akamai.com/html/support/esi.html , and if they choose not to license this to their competitors, but the competitor goes ahead and implements it "as-is" based on their spec, then hey, the competitor deserves to be sued.

The ESI open-standard specification is being co-authored by Akamai, ATG, BEA Systems, Circadence, Digital Island, IBM, Interwoven, Oracle, and Vignette.

Guys, I've been at Slashdot for years, and have never seen such blatant disregard for the core subject matter. You guys are all going on writing about how obvious the patent is / how bad akamai is, without even looking into the matter. I've been an Akamai customer for many years now, and no matter how much of a bloodsucking leech they are, and how exorbitantly they price their services, they do have some massive innovation going behind their products.

First, the patent isn't so obvious. The patent is for Edge Side Includes, which is in no way trivial. It is the method by which you can have a full HTML page (eg.the slashdot homepage), cached at the akamai edge servers, and have one part of personalized message (welcome USERNAME / you have X private messages / etc. etc.) load from the origin servers, taking into account all cookies etc. Doing so required inventing a whole new method of writing, interpreting, and selectively applying caching to enhanced include tags, that too across a distributed network, supporting other cool items like tiered distribution, progressive caching, server side cookies etc. etc.

Now, realize, this isn't about loading one object, like an image / flash object / javascript from a different server, but transparently loading a part of the core HTML code of a page from the origin server, with full support for cookies / post etc. while making it look like it is coming from the same physical source, so as to maintain cookie coherency. Trust me, before Akamai's founder came around and invented this, web caching static objects with personalized items was like pulling teeth. Also, Akamai is licensing this technology to the whole world http://www.akamai.com/html/support/esi.html, and if they choose not to license this to their competitors, but the competitor goes ahead and implements it "as-is" based on their spec, then hey, the competitor deserves to be sued.

And you know what? Limelight is a bunch of ex-akamai guys, who left with a boatload of trade secrets, and customer lists. I got a call from them within 15 days of their service starting, asking to switch over at half price, but their Super POP model doesn't work for dynamic content like ours.

I would assume they are talking about Edge Side Includes and not simply about the serving of images.

ESI is like Server Side Includes, except that the included part resides on the Edge servers. So your server would serve a page with only the content personalized to you specifically (like the fact that you are logged in) but a box full of news headlines that everyone sees would be included by the edge server.

Not entirely obvious, but I am not so sure it warrants patent protection in any case.

you are criticizing Rush Limbaugh because you think he insults people, and you chose to do that by... insulting him?

Hey jackhole, get a clue. When a bloated gasbag spews lies about an advocate for people with a debilitating disease, you're goddamned right he gets insulted. And when Rush mocks the disease's effects , shaking his body spastically around on camera to mimic Fox's illness, oh holy crap does he deserve to be insulted. Shakespeare didn't write enough insults for sick bastard whores like Rush Limbaugh.

But guess what? Rush was right. Fox later admitted that he purposely skips his medication before public events like this so people will see his worst case symptoms. Here is a video clip of him admitting this.

Guess what, you brain-dead moron? In that video clip Fox denies what he supposedly admitted, saying explicitly -- listen to your own video clip --

"It isn't as if I didn't take it deliberately, as some kind of theatrical thing."

Which of course pustulent corpse-raper Rush Limbaugh quotes as:

FOX: I didn't take it deliberately as some kind of theatrical thing...

Here, as usual, Rush listeners learn their facts about the world exactly backwards. It's the price you pay for giving a fat, impotent, parasitic slug-worm an invitation into your living room. Lend credence to the sneering ringmaster of a national freakshow and what happens is that you become stupid. Let me give you another example. If you'd bothered to learn something instead of lazily gulping down Limbaugh's diarrhea, you might have known that the visible tremors Rush was mocking come from the medication:

In fact, at the time he was over-medicated for his Parkinson's disease, Fox said Thursday in an exclusive interview with CBS Evening News anchor Katie Couric.

"The irony is that I was too medicated. I was dyskinesic," Fox told Couric. "Because the thing about ... being symptomatic is that it's not comfortable. No one wants to be symptomatic; it's like being hit with a hammer."

His body visibly wracked by tremors, Fox appears in a political ad touting Missouri Democratic Senate candidate Claire McCaskill's stance in favor of embryonic stem cell research. That prompted Limbaugh to speculate that Fox was "either off his medication or acting."

Fox told Couric, "At this point now, if I didn't take medication I wouldn't be able to speak."

I'm not the president of the Michael J. Fox fan club or anything. But the guy has to take his meds in order to be able to talk and move and interact with the world with some kind of normalcy. Without the medication, Parkinson's patients' muscles become rigid, their movements slow, and they even become unable to move at all. At the start of the filming day, Fox doesn't know if he's going to nail the ad in one take or is going to be there all day, so you can only imagine how carefully he plans out how much medication he's going to take and when, to ride the tightrope between his disease's wracking paralysis and the cure's tremors. Did he guess exactly right? I don't know, maybe not. Is Rush Limbaugh the biggest hate-smeared asshole the world has ever seen for second-guessing a prescription for someone he's never met, someone who is just trying to help a cause he believe

Let me get this straight- you are criticizing Rush Limbaugh because you think he insults people, and you chose to do that by... insulting him?

Its been my experience that the people that most vocally accuse Limbaugh of hate speech have not formed that opinion through their own experience of listening to the show, but rather through what other media and Limbaugh's political opponents report that he said. Is that the case with you?

Lets take the Michael J Fox story that you mentioned as an example. Mr. Limbaugh stated on-air that he thought Michael Fox had exaggerated his Parkinson's symptoms in a political ad, and that he had done so for theatric benefit. It was clearly in Fox's best interest to make his disease look as debilitating as possible, and his tremors in the ad were much more pronounced than we usually saw from him. Limbaugh said that he would be the first apologize to Fox if that wasn't the case. But guess what? Rush was right. Fox later admitted that he purposely skips his medication before public events like this so people will see his worst case symptoms. Here is a video clip of him admitting this.

So was that hate speech, or was it an attempt to inject more honesty in a charged political debate? Unfortunately, the partisans have already made their minds up on the answer to that.

Akamai is a different beast altogether -- they're not a generic computing center, but a finely-tuned cache that gets your (mostly static) data as close to the user as possible. In fact, Amazon uses Akamai (PDF press release) to host some of their content.

The difference between Sun's Grid Computing and EC2 is that EC2 is connected to the net. This doesn't mean you can't run huge batch jobs on EC2; however, there's a lot more you can put on there (read: hosting for the Web 2.0 company you've founded in your garage, mom's basement, ...). However, EC2 doesn't give you a load balancer (yet); getting the traffic from www.your-spiffy-domain.com to the EC2 instances is still your problem.

S3 is, IMHO, the more interesting of the technologies today. Buying storage capacity these days is cheap; maintaining it, however, is as expensive as ever (perhaps moreso as clients expect higher availability, geographic distribution to minimize risk, etc.). And, if I'm too small for Akamai yet need to host some static content over a fatter pipe than I have, I can even expose it to the rest of the world through the REST interface./p.

No one cares. There may be "legal" torrents, but there is absolutely no legitimate reason to distribute content using DDoSTorrent. Sorry, BitTorrent, it's just so hard to tell the difference between BitTorrent and a DDoS attack on a network.

If you want to distribute your content, then pay for it! There are hosting services that offer hosting for $10/month (or less) that will offer several terabytes of download and a gig or so of storage. There are free services out there that will allow you to upload content for users to access.

Or you could always just charge users directly for associated costs with offering torrents.

Blizzard especially should be utterly ashamed for using BitTorrent instead of hosting their patches themselves. There is no excuse for not hosting the patch themselves. If their network can't handle the load, I'm sure Akamai can help.

There's no excuse for using BitTorrent, ever. A straight FTP connection will run faster, and if you want to distribute content, you should be willing to pay for it. All BitTorrent does is DDoS people's networks, and prevent other users from accessing anything. If you think otherwise, you've never done IT on a network where BitTorrent was running.

I've killed some time on this since it's a pretty interesting idea. It turns out there are plenty outside the D and F range. It does seem to like pages with a single Flash object and not much else, so that's bad. It also makes some pretty arbitrary decisions which don't mean squat to many sites. There are some sites that get enough traffic that speed is a factor but not so much that a content delivery network is really necessary, for example.

I skipped the actual link and score on sites that are pretty much just representative of the sites around them. I wanted to include them by name, though, to show where they fall. I've stuck mostly to main index pages, and I've noted where I've gone deeper.

A: Google (99%), Altavista main page (98%), Altavista Babelfish (90%) (including upon doing a translation from English to French), Craigslist (96%), Pricewatch (93%), Slackware Linux, OpenBSD, Led Zeppelin site at Atlantic (100%), supremecommander.com, w3m web browser site (96%)

B: Apache.org (87%), the lighttpd web server (84%), Google Maps, which also got a C once (84% in most cases), Perlmonks (84%), Dragonfly BSD (85%), Butthole Surfers band page (81%), 37 Signals

C: One Laptop Per Child,, ESR's homepage, the Open Source Initiative (78%), Google News (73%), Lucid CMS (74%), Perl.org (75%), lucasfilm.com, Charred Dirt game

D: gnu.org, The Register, A9 (66%), kernel.org, Akamai (64%), kuro5hin.org, freshmeat.net, linuxcd.org, Movable Type (61%), Postnuke, blogster.com, Joel on Software (67%), Fog Creek Software, metallica.com, gaspowered.com, Scorched 3D (68%), id software (64%), ISBN.nu book search

F: MS IIS (49%), microsoft.com, msn.com, linux.com, fsf.org, discovery.com, newegg.com, rackspace.com, the Simtel archive (26%), CNet Download (29%), Adobe (58%), savvis.com, mtv.com, sun.com, pclinuxos.com, freebsd.org, phpnuke.org, use.perl.org, ruby-lang.org, python.org, java.com, Rolling Stones band page (56%), powellsbooks.com, amazon.com, barnesandnoble.com, getfirefox.com

My site for my company (96%) gets an A (no, I'm not going to get it slashdotted) which is pretty simple but has a pic and some Javascript on it. Several sites I have done or have helped design with someone else get C or D ratings.

No, bandwidth isn't an issue. We're using the Akamai Web Application Accelerator to get around the slow downs that happen normally and to ensure a good end user experience during peak (holiday) seasons.

http://www.akamai.com/html/technology/products/waa .html

From the page:

Akamai Web Application Accelerator speeds performance of dynamic, interactive Web applications without requiring additional infrastructure by taking a fundamentally different approach to application delivery, employing techniques including:

* Dynamic mapping
* Dynamic routing
* Compression
* Caching and pre-fetching
* Connection/TCP optimization
* Access control

How it Works

Requests and application responses between users and your origin server are sent over the Akamai platform. It's the world's largest fault-tolerant network, comprising 20,000 servers in 71 countries. When a user requests an application, dynamic mapping technology directs the request to the closest Akamai server. Using route optimization, we identify the fastest, most reliable path back to your server to retrieve the application content, and employ connection techniques to optimize communication between servers, improving performance and reliability of both retrieval and delivery. Access control features ensure application security is maintained throughout the process.

Why have Akamai accelerate your Web applications?

* More control over the delivery of your applications
* Optimized delivery means faster performance
* The Akamai platform handles peak usage easily
* IT burden drops - no additional hardware


Sounds like a different tier to me. The best part is that it doesn't force the end user to pick up the tab.

"think it's obvious that musicians (especially independents and small labels) will find themselves with the short end of the stick if they are asked to pay a fee to have their music streamed as fast as larger bands or even corporations." -well, the free market economy already allows this to be true, really. Content Delivery Networks like http://www.akamai.com/ provide a much higher quality of service over the public internet than just sticking it out there on a random webserver. Akamai actually powers iTunes and most big media content with big dollars behind it already. So I agree that the net itself should be free and open, but private enterprise has already created solutions to offer premium delivery for those that can afford it and have a real need.

What about Akamai's SSL encryption? http://www.akamai.com?

There are a decent number of companies (and non-profit orgs) that do exactly this sort of thing. Most of the big content distributors (iTunes, MySpace, CNN, etc) use at least one of them. The problem is that these companies work for the content distributor, not the ISP - the CDN "takes the bullet" for the content provider's main servers to offload demand, not offload capacity to the ISP. Unless the ISP sites one or more of the CDN's proxies at the customer edge of their network (which is not uncommon, but hardly ubiquitous), the ISP still has to pay to move the traffic to their customers from the proxy, and if they did have one it would be in their POP, not next to every DSLAM and cable head-end, which mean the path between the CDN proxy and the customer still has the same bandwidth requirements.

As for live TV streams, they can be cut back to near nothing, with effective caching at the ISP level (don't send hundreds of thousands of streams over seas, send one and cache/mirror locally for re-distribution).

There you go, a brand new patentable business opportunity, automatic local caching/mirroring of offshore/long range streams, to reduce bandwidth/traffic costs.

Microsoft has quite big pipe on their end

That's pipes, plural. And servers, too. A whole lot of 'em, in datacenters scattered all over the world. They use geographic redirection to get people to the closest mirror transparently, and I believe they also use Akamai for backup capacity when necesary.

We have a 100 Mbit fiber connection at work, and a recent Vista download peaked at 60 Mbps according to perfmon. I've never been able to squeeze more than 15 Mbps out of a very popular torrent (D+1 Fedora Core releases for example), no matter what client I use or how much I up the number of allowed peers. Nothing beats fat pipes and mirrors all over the world, not even BitTorrent.

This is the kind of thing that is going to strain the Internet's fabric at the seams. Up until now, your typical 1337 torrent freak was pretty uncommon among the general public, so the Internet has coped for the most part. But when the general public starts downloading several gigabytes of video every night, the whole equation will change.

Do you have any idea how many times the Internet was supposed to collapse/implode/crash/overload/burn up? I remember reading comments much like yours about streaming audio, then video games, then youtube. I remember when over 50% of the traffic on the Internet was Email. And I remember when over 50% of the Internet traffic was based around ONE SINGLE FREAKIN' BIT TORRENT SITE.

Sorry, buddy. The Internet has been around the block a few times, mmmkay? It was originally built to be a robust network, and damned if it hasn't worked out that way!

I strongly suspect you will see bit capacities on all ISPs very shortly if they don't have them already.

We solved this one a LONG time ago. It's called a proxy server

So... I don't know whether this is a positive or a negative change, but I'm guessing for a lot of peering points and a lot of overloaded switch fabrics, this is a deal breaker.

Most assuredly, Netflix is using a distributed system like Akamai to minimize peer load and overall Internet congestion. In any event, the money's on this working, so it will.

Last I recall the iTunes Store runs on Akamai's EdgeSuite infrastructure - EdgeSuite Delivery and EdgeSuie Enterprise look about right.

Last I recall the iTunes Store runs on Akamai's EdgeSuite infrastructure - EdgeSuite Delivery and EdgeSuie Enterprise look about right.

http://mfile.akamai.com/10735/wma/clearchan.downlo ad.akamai.com/10735/sx061209a.wma

Since Akamai is the delivery platform for more than 200 global online retail companies, it has a unique view into the daily Web traffic of these sites. (Full disclosure: I work for Akamai Technologies, Inc.)

So far, according to the Akamai's real-time Network Usage Retail Index, the number of visitors per minute to online retailers is up 23% more than the average day today. Its also up 9% from the 5-month peak recorded earlier this month. Not a huge increase, but significant.

Regardless of whether you think Cyber Monday was a myth or a natural occurrence in the past, now we may be in for reality imitating the media. Consumers may expect more deals on Cyber Monday and will look for them. Retailers will respond by offering more deals. And because its a regularly scheduled event, its easy to plan press releases and advertising for.

But online visits doesn't mean more profit to retailers, or even more profit. I wonder how many of those visitors are just buying the loss leaders, window shopping or checking the refund policy on the stuff they bought earlier in the week.

here is the link to the dolphins doing thei thing. Dolphin's sing "Batmaaaan"...

I agree with your points. As far as the questions go, if you download the whitepaper http://www.akamai.com/dl/reports/Site_Abandonment_ Final_Report.pdf [may require 'registration'] you will see that the questions aren't poorly written. For example, the main point of this survery, "Which of the following factors are most influential in your decision to continue shopping with an online store where you have shopped in the past? (Select all that apply.)" This question included 13 possible responses including "Site is easy to navigate", "Page loads quickly", "Personalized e-mail offers" and others. The real problem with this report is that it ignores the actual findings like the fact that navigation is most important to users and load times is down at 8.

A list of Akamai's customers. Apple is one of them.

"I believe '2' is a good number. '4' will be an interesting number for the high-end. Will we see eight cores in the client in the next two years? If someone chooses to do that, engineering-wise that is possible. But I doubt this is something the market needs."

I very strongly suspect that he's talking about 8-cores in the next two years.

Most app dev's don't know how to use 2 cores efficiently at the moment, much less 8. And for the next two years, app dev's probably don't know what to do with 8.

And look! Behold! Their 8-core plans are for post-2008!

Folks, this is nonsense. Intel has said, over and over and over again, that we're going to x100's of cores by 2015.

And they have very clear ideas for specific applications: Real-time super-resolution for cameras. Speech and Voice recognition. Recognizing who's sitting in front of the camera, quickly. Virtualization. All kinds of stuff.

There's no end to the amount of useful processing that can occur.

C:\Program Files\Mplayer>mplayer -dumpstream http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
MPlayer 1.0pre8-3.4.2 (C) 2000-2006 MPlayer Team
CPU: AMD Athlon(tm) (Family: 6, Model: 10, Stepping: 0)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled with runtime CPU detection.
Cannot load font: c:/windows/fonts/arial.ttf
Playing http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx.
STREAM_HTTP(1), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
STREAM_ASF, URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
size_confirm mismatch!: 22611 20047
Error while parsing chunk header
Failed, exiting.
STREAM_HTTP(2), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
Cache size set to 320 KBytes
Stream not seekable!
Core dumped ;)
Exiting... (End of file)

Well, so much for that... ;)

C:\Program Files\Mplayer>mplayer -dumpstream http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
MPlayer 1.0pre8-3.4.2 (C) 2000-2006 MPlayer Team
CPU: AMD Athlon(tm) (Family: 6, Model: 10, Stepping: 0)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled with runtime CPU detection.
Cannot load font: c:/windows/fonts/arial.ttf
Playing http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx.
STREAM_HTTP(1), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
STREAM_ASF, URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
size_confirm mismatch!: 22611 20047
Error while parsing chunk header
Failed, exiting.
STREAM_HTTP(2), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
Cache size set to 320 KBytes
Stream not seekable!
Core dumped ;)
Exiting... (End of file)

Well, so much for that... ;)

C:\Program Files\Mplayer>mplayer -dumpstream http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
MPlayer 1.0pre8-3.4.2 (C) 2000-2006 MPlayer Team
CPU: AMD Athlon(tm) (Family: 6, Model: 10, Stepping: 0)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled with runtime CPU detection.
Cannot load font: c:/windows/fonts/arial.ttf
Playing http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx.
STREAM_HTTP(1), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
STREAM_ASF, URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
size_confirm mismatch!: 22611 20047
Error while parsing chunk header
Failed, exiting.
STREAM_HTTP(2), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
Cache size set to 320 KBytes
Stream not seekable!
Core dumped ;)
Exiting... (End of file)

Well, so much for that... ;)

C:\Program Files\Mplayer>mplayer -dumpstream http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
MPlayer 1.0pre8-3.4.2 (C) 2000-2006 MPlayer Team
CPU: AMD Athlon(tm) (Family: 6, Model: 10, Stepping: 0)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled with runtime CPU detection.
Cannot load font: c:/windows/fonts/arial.ttf
Playing http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx.
STREAM_HTTP(1), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
STREAM_ASF, URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
size_confirm mismatch!: 22611 20047
Error while parsing chunk header
Failed, exiting.
STREAM_HTTP(2), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
Cache size set to 320 KBytes
Stream not seekable!
Core dumped ;)
Exiting... (End of file)

Well, so much for that... ;)

C:\Program Files\Mplayer>mplayer -dumpstream http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
MPlayer 1.0pre8-3.4.2 (C) 2000-2006 MPlayer Team
CPU: AMD Athlon(tm) (Family: 6, Model: 10, Stepping: 0)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled with runtime CPU detection.
Cannot load font: c:/windows/fonts/arial.ttf
Playing http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx.
STREAM_HTTP(1), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
STREAM_ASF, URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
size_confirm mismatch!: 22611 20047
Error while parsing chunk header
Failed, exiting.
STREAM_HTTP(2), URL: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx
Resolving mfile.akamai.com for AF_INET...
Connecting to server mfile.akamai.com: 80...
Cache size set to 320 KBytes
Stream not seekable!
Core dumped ;)
Exiting... (End of file)

Well, so much for that... ;)

Sorry ... its this one:
http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _forward_srb_camera.asx

Just amazing videos ... This one has a really good view of the re-entry. It's like a roller coaster ride! http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/srb_s ep.asx

...is the video looking down from the booster, showing the amazing launch and then splashdown:
http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _aft_srb_camera.asx

Just in case NASA changes the links/Web page. Right Forward SRB Camera. This one shows the space shuttle launching from the launch pad, to space, and then crashing into the water (not going underwater like the other video).

Amazing videos! If there are any more, then please share! :)

..the command would be:

mplayer -playlist http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _aft_srb_camera.asx ..hardcore console users add -vo aa

re!

Pertinent video: http://mfile.akamai.com/18566/wmv/etouchsyst2.down load.akamai.com/18355/wm.nasa-global/sts-121/right _aft_srb_camera.asx

Are you talking about that flurry of what looks like tentacles at around 7:38? I think you might have been seeing the lines from the parachute hitting the water and flowing past the camera.

Its all running a little slow now...

Anyways, if you haven't seen it yet, check out the right SRB looking-down-o-cam. Great shot of the shadow of the smoke trail, and as the main orbiter engines light off you can see the whole orbiter start to press up on the structure. Then the explosive bolts blow and the boosters rip to life. Very cool.