mirror of
https://github.com/zerotier/ZeroTierOne.git
synced 2026-09-22 15:29:03 -07:00
Grant Limberg
2e6fe413b6
The Jul 21-22 incident: a commit thread wedged inside the change-notification fan-out while holding _changeListeners_l/_dbs_l, every other commit thread piled up behind it, and the PubSub listeners kept acking member/network changes into a queue nothing drained -- silently losing them (CV1 authorize never applied). - Lock hygiene: snapshot-then-call in DB::_memberChanged/_networkChanged, DBMirrorSet fan-out, and ENC onNetworkUpdate/onNetworkMemberUpdate/ onNetworkMemberDeauthorize; no listener callback runs under notification locks - Liveness watchdog in heartbeat(): warn when a commit thread makes no progress for 60s, abort the process at 5min so the orchestrator restarts a zombie - Ack gating: PubSub listeners nack (redeliver) instead of acking when the commit pipeline is stalled or the queue is over depth - libpq connect_timeout/keepalives/tcp_user_timeout/statement_timeout on pooled connections so a dead DB peer throws instead of blocking a thread forever - Name controller threads (wchan/stack dumps become readable); commit queue depth and enqueue-to-commit latency gauges
ZeroTier Network Hypervisor Core
This directory contains the real ZeroTier: a completely OS-independent global virtual Ethernet switch engine. This is where the magic happens.
Give it wire packets and it gives you Ethernet packets, and vice versa. The core contains absolutely no actual I/O, port configuration, or other OS-specific code (except Utils::getSecureRandom()). It provides a simple C API via /include/ZeroTierOne.h. It's designed to be small and maximally portable for future use on small embedded and special purpose systems.
Code in here follows these guidelines:
- Keep it minimal, especially in terms of code footprint and memory use.
- There should be no OS-dependent code here unless absolutely necessary (e.g. getSecureRandom).
- If it's not part of the core virtual Ethernet switch it does not belong here.
- No C++11 or C++14 since older and embedded compilers don't support it yet and this should be maximally portable.
- Minimize the use of complex C++ features since at some point we might end up "minus-minus'ing" this code if doing so proves necessary to port to tiny embedded systems.