iroh 1.0.2: Live Relay Rate-Limiting and Proto Hardening

The headline: a live rate-limit knob

The operational headline of 1.0.2 is that a relay's per-client rate limit can be updated live. On a relay, the rate limit is the control that bounds how much throughput a given client can consume through the relay. Before this release, changing that bound was a restart event: you edited the limit, you restarted, and the new bound applied. In 1.0.2 the bound is a live value, so an operator can raise or lower a client's budget in response to observed load, without disconnecting that client or any other.

The practical value is in load management. If one client on a shared relay is consuming too much, an operator can dial that client's limit down immediately, watch the effect, and dial it back up, all without a restart. That turns rate limiting from a static policy into an active control, which is a real difference on a relay that serves more than one party.

Relay fairness and the counter fix

The transport-lane fairness counter fix is quieter but it is about the same theme: keeping a multi-client relay fair. The relay processes traffic across lanes, and a fairness counter is what keeps the distribution even. When that counter is wrong, the distribution skews, and some lanes or clients get more than their share. The fix restores the intended counting, so the relay's bandwidth and processing are distributed as designed.

For an operator, the symptom of a broken fairness counter is not usually an error; it is a client that is faster or slower than it should be. If you see uneven throughput across clients on a relay that should treat them equally, this fix is worth testing, because it addresses exactly that class of skew.

Protocol hardening and invalid messages

The relay protocol work in 1.0.2 is about robustness under untrusted input. The release improves the property tests for the relay protocol and makes the relay handle invalid messages properly. A relay that sees traffic from many peers, some of which may be misbehaving or simply buggy, needs to reject malformed messages cleanly rather than act on them in an unspecified way. Proper handling means the relay stays in a known state regardless of what a peer sends.

This is the standard reliability argument for any network relay: the peers on the other side are not under your control, so the relay has to be correct about the messages it receives, not just the ones it sends. The 1.0.2 change is the relay getting more correct on that axis, which shows up as fewer weird states under unusual traffic rather than as any visible feature.

Testing and platform regressions

1.0.2 also adds a regression test for transient Windows receive errors, which is the kind of test that encodes a bug that was found and fixed so it does not return. The fact that it is a Windows-specific transient receive error tells you something about the transport layer: receive paths can fail transiently in platform-specific ways, and the test pins the behavior so a future change that re-introduces the failure is caught.

There is also a DNS write benchmark measurement added in this release, which is infrastructure for understanding the performance of the DNS write path. Benchmarks do not change behavior, but they are how a project can show that a change made the DNS path faster or slower, which matters over a series of releases.

What to verify on upgrade

The verification is straightforward and relay-focused. If you run a relay, test that a per-client rate limit can be changed live and that the new bound takes effect without a restart and without dropping the affected client's connection. Confirm that throughput across clients is even, which exercises the fairness fix. And run a burst of unusual or malformed traffic against the relay to confirm it stays in a healthy state, which exercises the protocol hardening. For a non-relay deployment, the change is largely transparent, and a representative connection is enough to confirm the transport still forms paths.

Limitations

• A release note is not a deployment audit. It does not inspect your operating system, network policy, credentials, storage, backups, or administrative process.
• Version numbers and documentation change. Pin the exact artifacts you test, record the date, and re-check upstream material before a production change.
• A feature that exists in a package or command does not automatically fit your threat model. Authentication, authorization, logging, patching, recovery, and abuse controls remain operator responsibilities.
• This article contains no benchmark, uptime promise, adoption statistic, cost saving, or client result. Measure those claims in your environment; the release record can only describe what shipped.

Related infrastructure context

For the physical layer around a systems deployment, TismTek provides fiber and network infrastructure work near Aurora. The team also documents on-premises compute and private AI systems. For a site discussion, call (720) 694-1976. See the iroh peer-to-peer networking explained for recovery planning and the private AI systems overview for the broader on-premises context.