Tether · 2026 · Personal project · C
Reliable Binary Transport
Continued operating at 15% packet loss and over a 9,600-baud serial link, the two conditions under which JSON-RPC/TCP failed.
15%
packet loss, still operating
9,600 baud
serial, still operating
CRC-8
per-frame integrity
Background
Context
Tether is a personal project from 2026. The question behind it: what does it take for an agent's tool calls to keep working over a link where JSON over TCP does not, such as a lossy radio hop or a slow serial line?
The design borrows from QMI, the compact, typed, binary control protocol I had spent a summer working alongside at Qualcomm.
Constraint
The hard part
JSON-RPC over TCP assumes a reliable, reasonably fast byte stream and pays for verbose text framing on every call. Over a 9,600-baud serial link, or once packet loss reaches 15%, it stops making progress.
The transport had to be small enough to implement in C for a constrained device, detect corruption cheaply, and recover from lost frames without a full TCP stack underneath.
Ownership
What I was responsible for
I designed the protocol, implemented it in C, and built the benchmark that ran it head to head against JSON-RPC/TCP under identical conditions.
System
Architecture and flow
Each tool call is packed into a compact binary frame: a QMI-style typed header, the payload, and a CRC-8 over the frame. The receiver checks the CRC, acknowledges good frames and stays silent on bad ones; the sender retries anything it has not seen acknowledged.
Frame
Acknowledgement and retry
Frame layout and the acknowledgement loop. A frame that fails its CRC or never arrives is retried by the sender.
Decisions
Key technical decisions
1
Binary, typed framing instead of text.
A QMI-inspired header carries the message type and length in a few bytes. On a 9,600-baud link, every byte of JSON punctuation is time, and typed frames also make the parser small enough to trust on a constrained device.
2
CRC-8 on every frame.
An 8-bit CRC is cheap to compute and costs one byte per frame. It catches the corruption a noisy link produces so a damaged frame is dropped and retried rather than parsed into a wrong tool call.
3
Acknowledgements and retries at the transport layer.
Rather than trusting the layer underneath to be reliable, Tether tracks which frames have been acknowledged and retries the rest. That is what lets it keep operating on links where TCP-based JSON-RPC gives up.
4
Benchmark against the incumbent, under the same conditions.
The comparison was JSON-RPC/TCP versus Tether at 15% packet loss and over 9,600-baud serial. The point was not a throughput number but the binary question: does the tool call still complete?
Failure
Reliability and failure handling
- Corrupted frames are rejected by the CRC-8 check and never reach the tool-call layer.
- Lost or rejected frames are retried after a missing acknowledgement.
- At 15% packet loss, Tether continued to operate; JSON-RPC/TCP failed.
- Over a 9,600-baud serial link, Tether continued to operate; JSON-RPC/TCP failed.
Outcome
Measured outcome
15%
packet loss: Tether operating, JSON-RPC/TCP failed
9,600 baud
serial: Tether operating, JSON-RPC/TCP failed
CRC-8
integrity check on every frame
| transport | 15% packet loss | 9,600-baud serial |
|---|---|---|
| JSON-RPC / TCP | failed | failed |
| Tether | operating | operating |
- The benchmark recorded whether each transport continued to operate under each condition. Only those two conditions were measured; no other loss rates or throughput figures are claimed.
Learned
What I took from it
Reliability is a property you choose a layer for. Putting acknowledgement and retry into the transport, rather than assuming them from TCP, is what made the protocol usable where it was needed.
Designing after a summer next to QMI made the choices obvious in a way reading about protocols never had. Compact, typed frames and explicit integrity checks are not exotic; they are what you converge on when the link is bad.