Building a Space-Based ISP

This is very common when controlling equipment in C++.

Technically, all C++ programs control equipment. Differences include that one program may run for weeks or even years, and is mostly the only program running, or the only one on a core. This happens from microcontrollers on up to servers with a TB of RAM running, say, high-frequency trading, and in networks of hundreds of those, running weather simulations.

The program typically does all its heap allocation at startup. There is no reference-counting std::shared_ptr. You might have lots of std::vector>, std::string, the works, but they all get provisioned in the first second or two, and then just used thereafter. If anything goes wrong, you don't try to do anything clever or sophisticated; you just kill and restart, or even re-boot, and start over from scratch. That is fine if it doesn't happen too often, so you make sure it doesn't.

For communication between programs, some of the memory set up is shared, with a header containing std::atomic sequence counters that each process can watch and compare against its last copy to know when something changed. Most commonly, actual messages show up on a ring buffer, so you don't need to act on them immediately; as long as you pick them up before they get lapped, you're good. If you get lapped, you might need to reset the whole system; so you make sure not to get lapped, by making the ring buffers big enough and by picking up messages soon enough. With big enough ring buffers and careful scheduling, you can leave all the bulk data there and just use it before it gets overwritten, avoiding expensive copies.

Often, once the program starts up, it does no more system calls at all, doing all its work by reading and writing shared memory, and maybe poking at hardware registers. On Linux one usually isolates cores doing this, with "isolcpus=..." on boot, and "nohz_full=...", "rcu_nocbs=...", "rcu_nocb_poll" etc. The ring buffers tend to live in hugepages ("hugepages=50000"), often just files opened in /dev/hugepages. This is all a simpler alternative to a unikernel/parakernel/demikernel/blatherkernel.

You might also have ephemeral processes that run just long enough to do a job and then quit, running on their own pool of cores and using their own pool of memory. This is usually how you administer the system: ssh in, look around, exit.

Yes, the useful unit is light-milliseconds:

  $ units
  You have: 340 mi
  You want: light ms 
          * 1.8251859
          / 0.5478894

So, 3.6 ms round-trip. In practice, the route will be slanted, so could just exceed 5 ms.

  $ sudo apt install units

Once the constellation is mature, certain very-high-paying subscribers will get the packets forwarded from one satellite to the next via laser links, across oceans, before being downlinked, and get there a few ms before packets dawdling along on fiber links below 0.7c, to trigger securities trades ahead of the crowd acting on now-ancient information. The time by fiber from Singapore to New York is on the order of 90 ms, where Starlink ought to get them there in well under 70 ms, leaving a good 20 ms to arbitrage. In investment banking, they say "a microsecond is an eon, a millisecond is an eternity".

Even just between New York and London, they can gain a few ms headway, enough to dominate.

It would not be surprising if the US military, and maybe some others, will have access to satellite-to-satellite routing. (They have their own WGS, "Wideband Global SATCOM", but it is GEO, thus high-latency.)

AFAIK, only the polar-orbit nodes have inter-satellite laser links, thus far, so this is a phenomenon of the near future, not the present. Other things to expect in the near future are lofting them with a few TB of storage, to minimize uplink bandwidth by edge-serving Disney and Netflix blockbusters; and multicast downlinks for real-time soccer games and maybe even time-binned shows.

Why was this downvoted though?

And cheap. $99/mo for competitive data service literally anywhere is amazingly cheap.