Relay 2.7.0
Four defects on the path every byte takes, found by reading it end to end and
then measuring it — plus benchmarks that now run on every change, so the next
regression here is visible instead of silent.
Your downloads no longer die after five minutes
Relay set a timer when a connection opened and called it an idle timeout. It
wasn't one: it fired five minutes later no matter how busy the connection was.
Large downloads, video calls, SSH sessions and anything long-lived all broke at
the same mark — which looks exactly like a flaky network, and was reported as
one.
The timer now moves with your traffic, and it belongs to the connection as a
whole rather than to each direction. That second part matters: a download sends
almost nothing upstream from start to finish, so timing each direction
separately would have killed the very transfers the timer exists to protect.
Leak protection no longer breaks localhost
Blocking IPv6 blocked all of it, including the loopback address your own
machine uses to talk to itself. Windows tries ::1 before 127.0.0.1, so while
Relay was connected, anything using localhost — a development server, a
database client, an app talking to its own helper — failed or stalled first.
That was unrelated software breaking and Relay getting the blame, and it made
"turn leak protection off" look like the fix for a slow machine. Loopback is now
allowed. This cannot leak anything: loopback traffic never reaches a network
adapter, so there is nowhere for it to escape to.
The phone does less work for the same traffic
For every packet in either direction, Relay borrowed a buffer from the network
stack's memory pool and never returned it. The pool never got to reuse anything
and the garbage collector cleaned up the difference — continuously, on the phone,
on the one processor that has repeatedly turned out to be the limit.
That path is now 3.3× faster and allocates 57% less memory. A redundant
queue and a thread hand-off per packet went with it, which also restores the
buffering to the size it was meant to be — it had quietly been double, which is
what makes a tunnel feel sluggish while a transfer is running.
Being straight about this: it does not make downloads faster. Speed through
the tunnel is limited by encryption, and measured the same before and after.
What you get is lower latency while something is downloading, and a phone that
uses less battery and memory doing it.
Fewer resources held for nothing
Every DNS lookup opens a short-lived flow, and each one was holding two threads,
a socket and a 64 KB buffer for five minutes after it finished. A browsing
session piled up hundreds. Now released after a minute.
You are told when the tunnel is not protected
If Relay cannot install the filters, it still connects — a leak is bad, but an
app that refuses to work is worse. Until now the only record of that was a log
nobody reads, while the switch still said "on". You had been told you were
protected and would act on it. It now says so on screen instead.
Windows updates itself from here; nothing to do. On Android, take arm64-v8a
unless it says the app is not compatible, then take universal. Windows will
warn on first run because the installer is not code-signed yet — More info →
Run anyway.