234 kbps per player, and the bug the first real match found

• The number
• The bug
• What was ruled out, by measurement
• What changed

On 10 September a friend in Germany and I played Fofighter, a rollback fighting game built in Floptle, over the managed relay in Ashburn. Two players at 92 ms and 46 ms, from 20:08 to 20:19 UTC. It was the first time the product had ever carried a real game between two strangers' home connections.

The number#

The relay counted 35.1 MB in and 35.1 MB out for the session, which works out to 234 kbps of upstream per player. That is the figure every capacity number on the pricing page derives from.

A relay multiplies, so the useful unit is not "Mbps per player". One packet into an eight-player lobby leaves seven times. At 234 kbps per client the link carries roughly 1,640 players in two-player lobbies and roughly 235 in eight-player ones, seven times worse for the same people. Both clear the free tier's 100 with the required margin, which is why that number is on the page.

The finding nobody was looking for: 234 kbps is 487 bytes per frame at 60 Hz, and a rollback fighter is supposed to be sending inputs, which are a handful of bytes. Even generous redundancy does not reach five hundred. The engine's author traced it the next day: a rollback session was putting every rollback node's transform into every snapshot, and the receiving side was throwing all of it away. About 43 bytes per node per frame, and the game's eleven nodes were very nearly the whole number. Nothing broke, nothing desynced, no log line was wrong. A sender and a receiver that disagree about what is needed fail silently in the direction of waste. It shipped fixed in the next engine release, which means every capacity figure above is a floor, not a ceiling.

The bug#

For the player who joined, every asset in the world vanished a few minutes into a fight. The skybox and the HUD stayed; everything else went. The host saw nothing wrong.

"Everything except the skybox and the UI" identifies the cause, because those are the only two things a client draws that are not replicated. What disappeared was exactly the set of things that arrive over the network. The renderer and the assets were never involved.

The relay's journal had the mechanism. It logs lobby counts only on change, and the host's lobby was created and destroyed three times in one ten-minute match: up at 20:08:22, gone after 21 seconds, up again at 20:11:36, gone mid-fight at 20:15:58, up again at 20:16:16. The 20:15 teardown happened while about 1 Mbps was flowing, so it was not an idle timeout, and forwarding went to zero for about fifty seconds. The five-minute bucket for 20:15 took in 16,528,953 bytes and sent out 16,510,494. Every other bucket in the product's history has in equal to out to the byte. When the lobby came back it was a new lobby with a new code, so the joiner could not be reunited with the host even in principle.

What was ruled out, by measurement#

The relay never restarted. It logged zero warnings, errors, drops, timeouts or reconnects. Its memory peaked at 4.9 MB of a 256 MB cap on a 954 MB box. It carried 0.5 Mbps on a 480 Mbps link. There was no resource pressure of any kind, and latency does not despawn entities. The box and the distance were not the problem.

What changed#

The engine gained a grace window so a lobby that drops can be rejoined, and the control plane took ownership of lobby codes so a code survives a restart on either side. The root cause of the teardown stayed open on the engine side with the evidence above attached. And the snapshot bug, found by division rather than by instrumentation, is the cheapest bandwidth bug detector there is: a per-frame byte count that does not match what the game is conceptually sending.