Every computer needs software updates, and the ones in orbit are no exception. Bugs surface, mission requirements change, and — increasingly the urgent one — vulnerabilities get disclosed against a platform that will keep flying for another decade. The patch has to get up there somehow.
On the ground this is a solved, boring problem. You download a few hundred megabytes over a connection that is always on, and if a packet drops, TCP quietly asks for it again. Nobody thinks about it.
In orbit almost none of that holds. The connection is not always on. It is on for a few minutes at a time, on a schedule set by orbital mechanics rather than convenience, at data rates that would embarrass a 1990s modem. And if the file arrives corrupted, you may not get another chance for hours.
I spent a while working on this problem — how to get a software update into space hardware when the link fights you the whole way. What follows is the shape of the problem and the class of solutions, not anybody’s results. The interesting part was never the benchmark table anyway. It was discovering which of your intuitions about networking stop being true.
The Contact Window
Radio needs line of sight. A spacecraft in low Earth orbit is moving at roughly 7.7 km/s, which means it rises above a given ground station’s horizon, arcs overhead, and sets again — and while it is below that horizon, there is no link at all. Not a slow link. No link.
The industry terms are pleasingly blunt: AOS, acquisition of signal, when the spacecraft clears the horizon; LOS, loss of signal, when it drops back below. Between AOS and LOS you have a contact window. For a typical LEO pass over a single ground station, that window is on the order of five to ten minutes, and you might get a handful of usable passes per day.
This single fact reorganizes everything downstream. Your update does not merely need to be small. It needs to fit in a window — and to survive the possibility that it won’t.
Why a Corrupted Upload Hurts So Much
Space links are noisy, so spacecraft have always leaned on forward error correction: send redundant information alongside the data so the receiver can repair damage without asking for anything back. The CCSDS standards that govern spacecraft telemetry specify a family of these, with Reed-Solomon the workhorse — it is excellent against the burst errors that radio links actually produce, and it can be concatenated with a convolutional inner code when you need more margin.
Forward error correction is wonderful, and it has a hard ceiling. A Reed-Solomon codeword can repair up to a fixed number of damaged symbols. Past that threshold it does not degrade gracefully — it fails, and the only remedy in the legacy playbook is to send the data again.
That is the expensive part. “Send it again” on a home connection costs you a shrug. On a spacecraft link, retransmitting a large file may not fit in the remaining window, which means waiting for the next pass, which may be an hour or six away. Meanwhile the vulnerability you were patching is still there, and the operations team is burning contact time it needed for telemetry and payload data.
So the question becomes obvious: when a file arrives damaged, why are we resending the whole thing? We already got most of it intact.
Send Only the Difference
This is the idea behind micropatching: rather than retransmitting a file, identify precisely which bytes are wrong and transmit only a patch that repairs them.
The concept is not exotic on the ground — rsync has done rolling-checksum delta transfer for decades, and binary diff tools like bsdiff underpin how browsers and game clients ship updates. What makes the orbital version its own problem is that the usual assumptions get inverted. On the ground you optimize for bytes because bandwidth is the scarce resource and round trips are nearly free. In orbit, as we will get to, that trade runs the other way.
There is also a security dimension that has pulled this work forward. A software update path is an attack surface — an unauthorized or tampered update to a spacecraft is close to the worst outcome available. As zero-trust architecture requirements work their way into government space acquisitions, the ability to verify and surgically repair exactly what arrived, rather than blindly accepting a bulk transfer, stops being a bandwidth optimization and starts being a security control. Axiom Space’s public work on in-space data processing has explicitly named cybersecurity as a target application for orbital edge compute.
The Part That Is Harder Than It Sounds
“Just diff the files” hides a genuinely interesting algorithmic problem, and the difficulty depends entirely on what kind of damage occurred.
If bytes were modified in place — the value at offset 4,096 is wrong, but it is still the byte at offset 4,096 — the two copies stay aligned. You can compare position by position, and finding the damage is a matter of narrowing down which regions disagree.
If bytes were inserted or deleted, alignment collapses. Insert a single byte near the front and every subsequent byte shifts by one. A position-by-position comparison now reports essentially the entire remainder of the file as corrupt, even though one byte was added. This is exactly the failure mode that classical error correction cannot address at all — Reed-Solomon is defined over fixed-length codewords and assumes the symbols line up.
That split produces two natural families of search algorithm, and the tradeoff between them is the real design decision.
A recursive search assumes alignment and subdivides: compare a region, and if it disagrees, split it and compare the halves, recursing until the damaged bytes are isolated. It is fast and needs very few exchanges, because each round eliminates a large fraction of the file. Its limitation is inherited from its assumption — it handles modifications, which is roughly the same class of damage classical error correction already covers.
A double breakpoint search does not assume alignment. Instead of comparing fixed positions, it works inward from both ends to find where the two copies stop agreeing and where they start agreeing again, bracketing the divergent region between two breakpoints. Because it locates boundaries rather than offsets, it survives insertions and deletions — the shift no longer confuses it, since the trailing agreement is discovered rather than assumed. The cost is more bookkeeping and more messages exchanged to converge.
So one algorithm is cheap and narrow; the other is more expensive and can repair damage that forward error correction fundamentally cannot touch. Which you want depends on what went wrong, and you often don’t know that in advance.
The Catch: Elegant Algorithms Are Chatty
Here is the part that I think is genuinely counterintuitive, and it is where ground-network instincts betray you.
Full retransmission is a one-way operation. You blast the file up and you are done. It is dumb, it wastes bytes, and it requires exactly one trip across the link.
Micropatching is a conversation. One side must ask which regions differ; the other must answer; the first narrows the search and asks again; eventually a patch goes up and gets confirmed. Every one of those turns is a round trip through a link with high latency and low bandwidth — and unlike the byte count, the number of round trips does not shrink just because the damage was small.
The consequence is a crossover. Below some file size, the patch conversation’s round trips cost more wall-clock time than simply blasting the file up would have, and the clever algorithm loses to the dumb one. Above that size, the byte savings dominate and micropatching pulls decisively ahead. Latency does not slow both approaches equally — a two-way protocol pays it on every turn, a one-way transfer pays it once.
This is a good lesson to carry out of the domain entirely: an algorithm’s complexity analysis is written in the wrong units if it counts the wrong scarce resource. Bytes are the obvious cost. On a link like this, turns are the real one.
Testing It Where It Actually Breaks
You can simulate all of this. You can stand up hardware matching the flight configuration, throttle the link to orbital data rates, inject latency, and corrupt files on purpose. That benchmarking is genuinely necessary — it is how you find the crossover point and characterize each algorithm before you spend precious orbital time.
But a lab replica models the link you expect. It does not model the link you get.
This is why in-orbit demonstration matters, and it is now possible in ways it wasn’t a decade ago, because commercial edge-compute hardware has flown. An AWS Snowcone has been operating aboard the ISS since 2022 through a partnership with Axiom Space, remotely operated from the ground and used for exactly this kind of demonstration — a general-purpose computer in orbit that researchers can actually talk to. Put the patch service on hardware like that, put its counterpart on a ground terminal, and you are no longer testing against your assumptions about the link. You are testing against the link.
What the real environment adds, above all, is AOS/LOS cycles that arrive on orbital mechanics’ schedule rather than yours — mid-transfer, mid-negotiation, without warning.
What LOS Does to a Conversation
Now recall that micropatching is stateful. The two sides are partway through a negotiation: certain regions have been ruled out, certain candidates are still open, a patch is half-delivered. That state lives on both ends and only makes sense as a pair.
Then the spacecraft goes below the horizon.
A brief dropout is survivable — the sockets stall, the session state is still valid on both sides, and when the link returns the conversation picks up where it left off. But as the outage lengthens, this stops working. Connections time out. Session state on one side may be discarded while the other still believes the negotiation is live. The two ends can come back with incompatible ideas about what has already been agreed, which is worse than having no state at all. And this is precisely where the one-way approach’s stupidity becomes a virtue: a blind retransmission has no conversational state to lose. It either arrived or it didn’t.
So the real engineering problem is not “which search algorithm is fastest.” It is how do you make a stateful protocol survive an adversary that severs the link at unpredictable intervals for unpredictable durations? That pushes you toward checkpointing progress durably on both ends, making every exchange idempotent and resumable, designing the session to be reconstructible from what each side already knows, and treating an outage as an expected state transition rather than an error. Robustness across LOS is the hard requirement. Algorithm efficiency is the easy part sitting on top of it.
Why This Is Getting More Urgent
Spacecraft used to be substantially fixed function. They are increasingly software-defined, which means their capability — and their vulnerability surface — is defined by code that will need to change while the vehicle is on orbit. At the same time, constellations have gone from a handful of expensive assets to hundreds or thousands of small ones, which multiplies the number of vehicles needing updates while each still gets only its own narrow slice of contact time.
Layer on the security requirement. When a disclosed vulnerability affects an entire constellation, “we’ll push the patch over the next few weeks as passes allow” is a genuinely uncomfortable sentence. The efficiency of your update path becomes a measure of how quickly you can respond to a threat — which is why this sits inside the zero-trust conversation now rather than in a networking-optimization backlog.
The Takeaway
Getting software into a spacecraft is a good reminder that engineering intuitions are local to their environment. On the ground, bandwidth is scarce and round trips are free, so you optimize bytes and reach for the cleverest diff you can find. Move the same problem into orbit and the scarcity flips: round trips become the expensive resource, connection state becomes a liability rather than an asset, and below a certain file size the sophisticated approach is simply worse than shouting the whole file again and hoping.
The constraint that dominates is not bandwidth. It is that you are talking through a keyhole that closes on a schedule you don’t control — and every design decision is really an answer to the question of what happens when it closes mid-sentence.