Hacker News Reader

Comment by diggan | Hacker News Reader

Something that sticks out looking at the table. How can some sites simply FAIL loading? I mean, there is something inherently wrong with our web today, where if my internet is very slow and _could_ load a page in 80 seconds if I just leave it like that, the server itself could have configured the timeout to be 60 seconds. So I can never load the page?!

The assumption is here that both points of the connection is based on earth. When we have these hard timeout limits, how will stuff even remotely work when we are a interplanetary species or even from orbit around earth?

View on HN

I chatted about just this timeout issue with an engineer from a major CDN while he was at my house enjoying the dialup. Seems like simply a matter of resource management; slow connections do use more resources. Most CDN customers don't care or don't know that a few percent of the US population is getting their web browsing broken by timeouts, so there's no push back.

(NASA has their wacky ways around the issue for ISS residents, something like VNC to a ground-based browser IIRC.)

That's pretty smart of NASA; things like a caching HTTP proxy still wouldn't work in some cases, given that sites can expect your browser to make a given AJAX request within X ms of requesting the page.

I wonder if there's still a more "API level" way to handle things, though, rather than making your computer into a dumb frame buffer client with extremely low responsiveness to typing/scrolling.

Maybe they could run a headless browser on Earth, and use a protocol like the Chromecast does to synchronize its DOM state to a "browser proxy" in space—like a higher-level, domain-specific version of the X11 protocol. That'd still have latency for JavaScript-based webapp UI, though... maybe the JS could be split and its state synchronized so that the "server" handles timer triggers, while the "client" handles input events.

> (NASA has their wacky ways around the issue for ISS residents, something like VNC to a ground-based browser IIRC.)

Wait, VNC? Won't that use oodles more bandwidth than proxying HTTP?

It's about lag, not bandwidth.

I remember astronaut Alex Gertz somewhere saying the VNC was also for security reasons. Keep in mind that most infrastructure on the ISS was installed in the middle 00s and that the Thinkpads were possible running Windows XP and IE 6 then.

I certainly bloody hope they're not running Microsoft software on the International Space Station.

They were in 2001: https://m.theregister.co.uk/2001/04/27/nt_4_0_sp7_available/

This is one of my favorite NT4 tidbits :)

I'm surprised they need anything. I get my home internet from a satellite in geosynchronous orbit and it works fine other than the latency. No human has got that far from Earth since Apollo in the 1970s, so my home internet has to be worse than anyone NASA cares give internet. (though I have no idea what bandwidth NASA has)

If they wanted to use a geosynchronous satellite from the ISS, it would be occluded by the earth half of the time and the other half of the time they'd have to track it with a satellite dish over the course of the 45 minutes (out of every 1.5 hours) they have access to it.

of course the same is true of ground stations... I'm not actually sure how they do it but they probably don't need as high-gain of an antenna to reach them.

The ISS gets connectivity via a small number of ground stations and mostly satellites. Their connectivity is not uninterrupted; there are small regular time intervals at which none of their uplinks is in line of sight.

> how will stuff even remotely work when we are a interplanetary species

IPFS or similar. Basically, make all public content content-addressed (give me the article with SHA 0xabcdef) rather than connection oriented (give me the bytestream that comes from http://news.ycombinator.com/foo/bar)

Open connections take system resources. One way to DOS a website is to open a ton of connections and just sit on them. If the server allows extra long timeouts as long as some bits come in occasionally, then the attacker can send bits occasionally. It's a tricky problem. It might work to allow long turnouts as long as you don't have an ongoing DOS attack, but that sort of thing is hard to configure and test.

After Slowloris and other attacks, this is pretty much a solved problem. Minimise per connection memory, limit connections per IP, drop connections which don't finish the request in X seconds, and separate your app server from your front proxy. And for the front proxy, don't block on reads - do minimal event loop until you can dispatch the full request.

One person's "Solved Problem" is another person's "I just built an app in rails that accomplishes what I want it to, why did it stop working?"

I heard this somewhere on HN, but websites should fail like escalators, not like elevators. Too many people design sites like elevators though.

I love this visual, but elevators have way more safety mechanisms than poorly-designed web sites. Check out the source HTML of instagram.com for a great example. /-:

Well, my point isn't about safety, it's about usability. Escalators can still be used as stairs when they fail. Elevators can't be used at all.

I see. Good point.

I'm going to steal this comparison :)

>how will stuff even remotely work when we are a interplanetary

We won't be and aliens have better internet anyway :)

read a fire upon the deep

He mentions packet loss of 10%. That's a different problem than a slow connection.

High packet loss and slow connections frequently go hand in hand (TCP over cellular modems).

This effect is exacerbated if the web site you're connecting to changes congestion control and TCP ramp up settings.

10% packet loss though typically is the threshold of "completely unusable" TCP connections. Depends of course, but 5% I generally think of "severely degraded" (e.g. ssh being almost unusable but still able to get some basic stuff done during a sev0) and 10% being "drive on-location because you aren't getting anything done" territory.

Exactly, but it's not a modern website problem.

How is it not a modern website problem, if that modern website is being viewed over wireless connections, and follows Google's lead in disabling slow start TCP?

On the TV series Stargate SG-1, they envisioned using conventional EMR (like radio and TV signals) through wormhole connections.

Later plots faced invasion attempts through the stargates (permanent, direct-dial wormhole portals), so matter shielding was employed, and signals were used to authenticate who was on the other side of the connection before lowering the shield.

how will stuff even remotely work when we are a interplanetary species

I would not expect interactive anything when latency is 20min+. Usenet and listservs should work fine tho, maybe worth some tweaks to the underlying protocols if they're too chatty.

Reply on news.ycombinator.com