How do NVR (Network Video Recorder) systems let mobile apps view surveillance feeds from any network? This is a core requirement for the security industry and smart home ecosystems. This article systematically surveys three dimensions: open-source NVR projects (Frigate, go2rtc, Kerberos.io, Agent DVR, etc.), commercial surveillance vendors (Hikvision, Dahua, EZVIZ, Ubiquiti, Synology, Reolink, etc.), and third-party P2P platforms and security research (TUTK Kalay, iLnkP2P/PPPP, GB/T 28181, key CVEs).
All technical descriptions are verified against primary sources—official documentation, security advisories, and academic papers. Key statistics include citations.
Building a self-hosted P2P signaling and relay server is the core infrastructure for cross-network connectivity, remote access, and mesh VPN scenarios. This article systematically surveys the complete technology landscape across three dimensions: protocol standards (STUN/TURN/ICE/BEHAVE), mainstream products (Tailscale, Nebula, NetBird, ZeroTier, Headscale, OpenZiti, etc.), and frameworks & algorithms (libp2p, WebRTC, Kademlia DHT).
All technical descriptions are verified against primary sources—RFC originals, academic papers, and official documentation. Key statistics include citations.
BBR (Bottleneck Bandwidth and Round-trip propagation time), developed by Neal Cardwell, Yuchung Cheng, and others at Google, is one of the most advanced model-based congestion control algorithms available today. Unlike traditional loss-based algorithms (Reno, CUBIC), BBR explicitly models the network path by directly measuring bottleneck bandwidth and propagation delay, sending data at the BDP (Bandwidth-Delay Product) rate at the bottleneck point.
BBR’s core insight is that packet loss does not equal congestion. On deep-buffered (Bufferbloat) or wireless links, packet loss can be caused by channel noise or excessive buffer queuing rather than genuine link saturation. BBR actively measures bandwidth and latency to precisely control the sending rate, rather than passively waiting for loss signals.
TCP congestion control is a critical determinant of network transport performance and a cornerstone of internet stability. Whether it’s webpage loading speed in web services, smoothness of live video streaming, inter-container communication in cloud-native applications, or download efficiency in P2P transfers, all rely on TCP congestion control to coordinate bandwidth allocation. A single BitTorrent node, for example, may maintain hundreds of concurrent TCP connections, and choosing the wrong algorithm can severely degrade bandwidth utilization. Since Van Jacobson’s seminal 1988 paper at SIGCOMM, congestion control algorithms have evolved over nearly four decades — from heuristic loss-based methods to precise model-based measurement. This article covers 12 major congestion control algorithms, explaining their core ideas, strengths, weaknesses, and applicable scenarios, from Tahoe and Reno to CUBIC, BBR, and Copa.
Moving a P2P system from prototype to production involves engineering challenges across connection management, security, observability, and deployment. This article covers six critical areas with reusable code snippets and actionable guidance.
Connection Management and Resource Limits P2P nodes must maintain a large number of simultaneous connections. Without resource caps, a node can suffer OOM crashes or file descriptor exhaustion. Production environments require strict control over three dimensions.
Three-Layer Resource Control Model mermaid flowchart TD TL["Transport Limits<br/>Inbound 1024 / Outbound 512"] --> Q["Connection Queue"] Q --> SL["Stream Limits<br/>Inbound 128 / Outbound 256"] SL --> I{"Health Check<br/>Idle 30s/60s"} I -->|"Pass"| OK["Update Active Timestamp"] I -->|"Fail"| CL["Close Stream/Conn<br/>Release FD & Memory"] classDef src fill:#bbdefb,stroke:#2196F3,color:#1B5E20 classDef proc fill:#fff3e0,stroke:#FF9800,color:#BF360C classDef decision fill:#f3e5f5,stroke:#9C27B0,color:#4A148C classDef ok fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20 classDef bad fill:#ffcdd2,stroke:#f44336,color:#B71C1C class TL src class Q,SL proc class I decision class OK ok class CL bad Rust Connection Management Rust’s SwarmBuilder provides a fluent API for connection configuration:
Combining theory with practice, we’ll build a real distributed file sharing system. This system will leverage technologies introduced in previous articles — Kademlia DHT for node discovery and metadata distribution, Gossipsub for broadcasting, and a custom file transfer protocol.
System Architecture mermaid flowchart TD APP["Application<br/>CLI / REST API"] --> LOGIC["Business Logic<br/>File index / download scheduler / verify"] LOGIC --> NET["P2P Network<br/>Kad-DHT / Gossipsub / file transfer"] NET -.->|"new peer notification"| LOGIC style APP fill:#2196F3,color:#fff style LOGIC fill:#FF9800,color:#fff style NET fill:#4CAF50,color:#fff Three strictly separated layers: application faces outward, business logic handles scheduling and verification, and the P2P network layer handles peer discovery, message broadcast, and file transfer.
Go’s simple concurrency model and fast compilation make it a popular choice for P2P network development. go-libp2p is one of the most complete libp2p implementations and is widely used in large projects like IPFS (Kubo).
Environment Setup bash 1 2 3 go get github.com/libp2p/go-libp2p go get github.com/libp2p/go-libp2p-kad-dht go get github.com/libp2p/go-libp2p-pubsub go.mod configuration:
Rust’s ownership model and zero-cost abstractions make it an ideal language for implementing P2P network protocols. The Rust implementation of libp2p (rust-libp2p) provides a complete protocol stack from transport to application layer.
Environment Setup Configure dependencies in Cargo.toml:
toml 1 2 3 4 5 6 7 8 9 [dependencies] libp2p = { version = "0.53", features = [ "tokio", "tcp", "quic", "noise", "yamux", "mplex", "ping", "identify", "kad", "gossipsub", "relay", "dcutr", "macros", ] } tokio = { version = "1.0", features = ["full"] } tokio-stream = "0.1" futures = "0.3" anyhow = "1.0" Create the project:
Building on our understanding of P2P core principles and Kademlia DHT, we now dive into two production-proven P2P protocols — the libp2p protocol stack and BitTorrent. They represent two different design philosophies: a general-purpose P2P framework versus a specialized file distribution protocol.
libp2p Modular Architecture libp2p is the networking layer behind IPFS and Filecoin, providing a modular toolkit for building P2P applications. Its design philosophy is “pluggable network protocol stack for P2P applications” — developers compose transport, security, multiplexing, and application layers like building blocks.
Kademlia is one of the most influential DHT (Distributed Hash Table) protocols, proposed by Petar Maymounkov and David Mazières in 2002. It is widely used in IPFS, BitTorrent, Ethereum, and many other systems. Kademlia’s revolutionary innovation lies in using XOR (exclusive or) as its distance metric, offering elegant mathematical properties and efficient routing algorithms.
XOR Distance Metric Kademlia maps nodes and resources to the same 160-bit identifier space and defines the XOR distance function: