The decision to build a custom one using edge-triggered epoll was driven by the need to handle many short-lived connections efficiently without the overhead of a full STUN/TURN stack for every single handshake. I'm curious if anyone here has experience scaling similar custom relay architectures in production.
cpp_enjoyer•2mo ago
I built this because I wanted to tackle two deeply annoying problems in distributed systems simultaneously: getting P2P traffic through aggressive corporate firewalls/CGNATs reliably, and guaranteeing that shared data actually expires across a mesh without central coordination.
It’s a standalone infrastructure daemon written from scratch in C++20 (no Boost, minimal dependencies).
Some technical details for those interested:
The NAT Problem: It uses standard STUN, but falls back to a custom, high-performance asynchronous relay server I built using Linux epoll and macOS kqueue edge-triggered notification. It’s designed to handle high-throughput spikes efficiently.
The Expiration Problem: It implements a modified Kademlia DHT where TTL (Time-To-Live) is a first-class constraint enforced cryptographically across the network. Nodes actively reject and purge expired records.
Security: Handshake involves a proof-of-work puzzle to mitigate Sybil attacks. Transport is encrypted using ChaCha20-Poly1305 with rotating session keys.
It’s currently v1.0.0. The docs and architecture diagram are at the link. I’d love to hear your feedback on the design choices, especially around the relay architecture.
Thanks!