FrogNet / Build / How a FrogNet discovers itself, step by step
FrogNet · discovery

Finding
the network.

The install left one node configured and alone. Discovery is how it finds everyone else — with no operator, no server, and no map handed to it.

it goes and · asks ·

Current implementation: FD&F and the network path

Local-only path.

Inspect the local discovery/merge logs, the known hosts, kernel routes and the selected application service host. The earlier videos show the recursive walk and measured routes. Those mechanisms belong to the local or broker-era path, not region-driven membership.

Region path.

Start with the participant’s own facts, then its published row in the RAM manager. Inspect the graph and the daemon’s applied plan. At startup the watch is registered before the world read. For each event, the log names the changed facts, membership and the route/host differences.

r19 does not send admission echo probes for live region members. The session supplies member aliveness, and lease pairs supply LAN adjacency. A hub route still needs handshake health.

Change one fact.

Add or remove an address, move a device between the served LAN and an outside network, end a member session, or change the forward pond. Inspect what changed and what stayed. The displayed graph is a derivation of the published facts, not another independent inventory to maintain.

Name the scope.

A PC already on a member’s LAN is on-mesh. Outside it, the PC is a leaf through the hub. Other ponds may be reached through aliases. If identity resolution has several answers, refusal is the correct observation.

STEP 01
Where we start

One node, asking

Configured, powered — and with no idea who else is out there.

  • No directory to look in
  • No server to phone
  • No map handed down

The only way to learn the network is to go and ask.

STEP 02
Phase 1

It works by asking

The node probes outward from each of its own interfaces.

  • Ask every reachable address: who are you?
  • Plain request / response — the oldest way
  • Nothing is trusted until it answers

Reachability has to be re-proven constantly — so asking is the right shape.

STEP 03
Phase 2

Just two questions

Every ask is the same short conversation.

  • Who are you? — your name and identity
  • Who do you know? — the peers you can reach

That's the whole exchange. Everything else is repeating it.

who? who else?
STEP 04
Phase 3

Then their children. Then grandchildren.

Ask the same two questions of everyone they named.

  • Same questions to each child
  • Same again to each grandchild
  • Bounded — a shallow walk, not the whole world

Two levels out is enough — every node walks at once, so even complex networks synchronize fast.

2 levels
STEP 05
Phase 4

.2 proves, .1 carries

Probe to prove the path works — then record who answered.

  • The .2 proves it: a live round-trip, not a promise
  • The reply .1 carries the peer's identity
  • Ask that peer what it knows — recurse, bounded

Reachability is measured, never asserted.

.2 .1 id
STEP 06
Phase 5

The wire decides

Every path is proven with a real round-trip — so every path has a real number.

  • More than one route? Lowest measured round-trip wins
  • Can't reach it directly? A relay vouches for it
  • No static weights — only what the wire just did
STEP 07
Phase 6

Asking is nearly free

The same questions, over and over — and usually the same answer.

  • Unchanged replies ride SAME / DIFF compression
  • A peer that hasn't moved answers in 21 bytes

You can afford to re-prove constantly because re-proving costs almost nothing.

= 16 B
STEP 08
Phase 7

Every node, its own table

From the answers, each node writes its own routing table.

  • No coordinator, no master list
  • Built from what this node reached and measured
  • A split network keeps working on both sides
STEP 09
Phase 8 · the headline

Two ponds become one

Separate networks come into range — and merge on their own.

  • Discovery finds the new neighbours
  • The mesh converges; databasehost re-elected
  • Every routing table and /etc/hosts rewritten

Nobody configured anything. Everyone can suddenly reach everyone.

STEP 10
Phase 9

A node drops. Nobody notices.

The same loop, running the other direction.

  • A node reboots or loses its link
  • Routes re-form around the gap
  • It comes back — and is re-absorbed, no manual step

Split and merge aren't special cases. They're the loop, always running.

STEP 11
The end state

One living
network.

The lone node is now part of a coherent whole.

  • Every node holds its own measured table
  • Every name resolves
  • It re-derives itself the moment anything changes

Nobody drew this map. It assembled itself.

You now have one running

The cheapest contribution is a topology that breaks it

The known ceiling is fifty-eight nodes, and as few as sixteen where one broker carries a second pond. It should be fifty-nine thousand. The build manual’s Known Limits appendix says where the number comes from and why a bigger one is not the fix.

  • No licence, no engine access, no Python
  • The simulator runs the real code, not a reimplementation
  • A topology that fails today and passes on a fix is an oracle

Better gets demonstrated, not argued — and the gate does not care who either of us is.

Run the simulator →  ·  The autonomics seam →