SpaceX actually intends to compete with terrestrial systems on latency; many routes will have significantly lower latency than any feasible terrestrial system.
I would like to see a framework, where the backend of a cloud system can migrate opposite to the direction of orbit, so the same virtual cloud server could remain (by 'hops' where it serializes a copy of itself, then fails over to the copy) more or less geostationary. Such migrations would happen as seldom as once per 10 minutes.
My game server cluster isn't too far away from having such a capability. (I was planning a variety of capabilities, such as using cheap GCP "ephemeral" instances by quickly failing over to such copies.)
Why would you need to do this? The constellation still needs downlinks - and the downlink nearest the physical location of the user should always be where that traffic pops back onto the Internet.
For a game server cluster, I would be running a game loop implemented as a series of pure function functor-like objects, located "very near" a spatial database. In that case, I would be migrating to provide the very lowest latency, as if the system were running on a "geostationary" server just a few hundred miles overhead. (Which has to pause for a quarter second, once every several minutes.)
That sounds like a terrible experience. You want to avoid latency spikes at all costs. People might not like latencies as high as 100ms to 200ms but it definitively is possible to enjoy a laggy game like that. Suddenly getting a 500ms latency every minute will cause a lot of weird and unfair situations that can basically ruin the entire game.
The usual latency should be on the order of 30-40ms round trip.
Suddenly getting a 500ms latency every minute
No one said anything about that. The client should have some form of dead reckoning, and there should be an edge server that maintains connections. With the right kind of game mechanics, no one notices the server disappearing then reappearing behind the scenes. I cite 250ms as a worst case. It should be possible to get the impact as low as the server skipping one frame every few minutes. The clients don't need to skip any frames.
I agree, jitter bigger than a synchronization time is worse than high latency. When player have high latency (and I was in top3 on NA Solo ladder in League of Legends while playing from Urals with 220ms), he could only predict the moves of the opponent because what you see is far behind the server state, but with stable latency he knows the exact delay between an input and registering it on the server which puts less pressure to mind to deal with desynchronization between the picture on a display and the actual state.
I agree, jitter bigger than a synchronization time is worse than high latency.
I'll always grant that fast twitch FPS will always have a problem with this. That's not the genre I'm interested in creating games for, and it's not what my server framework is designed to support. (It is real-time action, but the pacing is more akin to RTS than FPS.)
I didn't say that high latency isn't frustrating. But you can effectively shoot the air on the route of the opponent where you'd think he would be by the time server would have your input.
A bit off topic but what does the word 'constellation' mean? A quick Google didn't yield much, and I'm not entirely sure what field it's from. My guess is "a set of connected satellites"? Or is it more specific than that?
That's quite cool. I'm doing my feature at more of an API level. That said, many applications still need to be architected to do this sort of migration well. The turnkey version just guarantees a demo version. (As technology develops, the turnkey capability will increase, but people's demands on the technology will also increase.)
Wait, what? Are you planning to put your game server in orbit? Because otherwise I don't understand what you're asking - a server on the ground will always be "geostationary" - it's the satellites it talks to that will change.
I would like to see a framework, where the backend of a cloud system can migrate opposite to the direction of orbit, so the same virtual cloud server could remain (by 'hops' where it serializes a copy of itself, then fails over to the copy) more or less geostationary. Such migrations would happen as seldom as once per 10 minutes.
My game server cluster isn't too far away from having such a capability. (I was planning a variety of capabilities, such as using cheap GCP "ephemeral" instances by quickly failing over to such copies.)