The FrogNet Living Network
Stop building a distributed system out of computers. Build a computer out of a distributed system.
A network that remembers things, so your programs don’t have to send them.
Computers on a network normally talk by sending each other messages, the way you’d text someone. FrogNet replaces that with something closer to a shared noticeboard: one program writes a value down, another reads it, and neither has to know the other exists. That one change makes a lot of hard problems stop being problems.
Somebody in New York turned on a lamp in New York — by way of Seattle.
He changed a number. The number travelled 2,400 miles to a computer in Seattle, and the lamp that came on was three feet from his hand. Four thousand eight hundred miles, to cross a room. No cloud service was involved, and nothing was ever sent to the lamp.
The part worth stopping on is not the lamp. He didn’t know he was doing anything unusual. He wasn’t picking an address to send to, or deciding what to do if the message failed, or telling anything that the number had changed. As far as his program was concerned, he set a variable. Everything else — getting it across the country, working out what actually needed to travel, dealing with the connection dropping — happened underneath, and he never wrote a line of it.
Why that’s different from how it normally works
Two programs on a normal network are like two people who can only communicate by post. Every letter has to have an address on it. If the recipient has moved, you need their new address. If the letter goes missing, somebody has to notice and send it again. If you change the shape of your letters, everyone you write to has to be told first. And if ten people want to know something, you write ten letters.
An enormous amount of the work in modern software is that post office. It is not the thing anyone set out to build; it is the tax on building the thing.
FrogNet takes it away by giving the network its own memory.
You write a value into it. Anyone who wants it reads it. Nobody addresses anybody, nobody is notified, and nothing is delivered — because nothing was ever sent.
The idea isn’t new. It was published in 1985 by two researchers at Yale, and it was impractical then for reasons that are no longer true. What’s new is that this one works across a continent, on cheap hardware, over connections that drop.
The side effect is that it barely uses any bandwidth.
If both ends of a conversation already remember what they last said to each other, then most of the time there is nothing to send. FrogNet leans on that hard: when nothing has changed, the answer is twenty-one bytes — about the length of this sentence fragment — instead of the whole thing again.
That has a consequence people find hard to believe until they watch it. A two-way video call fits in less bandwidth than a podcast. Under 150 kilobits per second, over a connection type everyone will tell you cannot carry live video.
On a normal network the cost is the cost, and it is the same every time. Here the cost is whatever changed — compressed, and different on every request. That is why the ratios below vary so widely: they are not six measurements of one thing, they are the same measurement of six different shapes of traffic.
Here is what it does to ordinary traffic. Worst case first, because a list of numbers that only shows the good ones isn’t evidence of anything.
These rows were produced by pipe_workload.py, and it ships in the download. One command, run against different payload shapes on a real machine — not six experiments assembled afterwards. So you can run the same command on your own hardware and put your numbers beside mine. That comparison is the useful part. An absolute figure from someone else’s machine tells you about their machine; the same test on both tells you something.
| What was being sent | Normally | On FrogNet | |
|---|---|---|---|
| Requests for a page that doesn’t exist — every one an error | 394.7 KB | 172.8 KB | 2.3× |
| 200 sensors, a handful changing each time | 6.6 MB | 702.3 KB | 9.6× |
| A short piece of text that never changes | 335.8 KB | 8.9 KB | 37.9× |
| A chat window, last 50 messages | 3.4 MB | 24.7 KB | 141× |
| A megabyte of data with six live fields in it | 256.3 MB | 30.0 KB | 8,741× |
The pattern is simple: the less of something actually changes, the less of it gets sent. Sensors churn constantly, so they save the least. A mostly-static file with a few live numbers in it saves almost everything.
And it is faster, not slower. Doing less work usually costs you something in exchange; here it doesn’t. The same requests, on the same machine, came back roughly twice as fast through FrogNet as without it.
Who this is actually for.
FrogNet was started to build something that keeps working where the internet doesn’t — rural land, disaster areas, ships, sites with a bad satellite link and nothing else. It turned into a way of writing software. Both halves are still true, and they suit different people.
- You need a network in a place the internet isn’t
A few cheap computers, some radios, and no service to pay for. Sites in different cities behave as though they were on the same switch. If the link between them drops, both halves keep working on their own and rejoin when it comes back — that’s a normal state here, not a failure. Not because each side kept a copy: there are no copies. Each side simply picks a machine to hold its own memory and carries on with what it can still reach. Nothing is merged when they rejoin, because nothing was duplicated to begin with.
- You want to own the thing you depend on
There is no company in the middle. No account, no subscription, nothing to be switched off, no terms that change. You have the source, and you can read every line of it.
- You’re paying for bandwidth you resent
Satellite, cellular, or a metered link. The numbers above are the whole argument.
- You write software and this sounds like it would make your life shorter
It probably would. Start with the how it works page, then the specification.
What it isn’t.
FrogNet looks a bit like several things it isn’t, and people who assume one of them end up confused later. So, plainly:
- It is not a cloud service, and there is nothing to sign up for
It runs entirely on machines you own. Nothing phones home.
- It is not a VPN
It uses one underneath, in the same way a car uses roads. Connecting the machines is the easy part and the part everyone else stops at.
- It is not a database
It holds what is true right now, in one place, and forgets the rest. It is not where you keep your records.
- It is not a compression tool
Nothing is being squeezed. The data isn’t sent because both ends already have it — and the far end genuinely checks rather than guessing, so you can’t be handed a stale answer.
- It is not finished, and the unfinished parts are written down
See below. They’re in the manual too, not buried.
What doesn’t work yet.
Every project has this list. Most don’t publish it.
- Nothing tells you when a value changes
A program that needs to know the instant something moves keeps checking. That’s cheap here — an unchanged check costs twenty-one bytes — but it isn’t the same as being told, and how often you check is how late you find out. That one is deliberate rather than unfinished: deciding which changes matter is the program’s job, and a network that knew would have to be told about every program.
- Roughly sixty machines in one network
Fewer if one rendezvous point serves more than one network. The reason is understood and the fix is a known piece of work, not a mystery.
- The rules are deliberately simple, which means some things are your problem
Last write wins. There are no permissions on individual values, no transactions, and no history.
- The test system doesn’t model everything
It doesn’t simulate a connection that loses packets, and it doesn’t run two changes at once.
Two computers and about an hour.
A Raspberry Pi 4 is enough. Two of them is a network. You download an archive, run one script, give the machine a name and an address, and finish the rest in a browser on the machine itself — no editing configuration files.
It is free software, under the GNU General Public License, version 3 or, at your option, any later version. No registration, no approval, no form. You can read it, change it, build on it, and pass it on — and anything you build on it and give to someone else carries the same licence, so it stays open for them too.
Running it inside your own company changes nothing. Use it in production, build on it, modify it, run a business on it — none of that obliges you to publish anything. The licence only asks something of you when you hand the software itself to someone outside your organisation.
Download →What you need →Watch it first →Questions →
Built by one person over about a decade. By the author’s own estimate it should have taken six months longer and one more programmer — an estimate he has fifty years of writing software behind him to make. There is a manual covering the whole system, and a second book that makes the argument in plain English if you’d rather have that than the build.