These 14 streaming technologies don’t operate in the same layer. A complete live streaming pipeline typically follows:
Camera/Encoder → Ingest (RTMP / SRT / RIST / WebRTC-WHIP / WebTransport) → Transcode → Delivery (HLS / LL-HLS / DASH / LL-DASH / HESP / HTTP-FLV) → Viewers
Start by identifying which segment of the pipeline you’re working on, not by asking “which is better.”
mermaid flowchart TD A["Camera/Encoder"] --> B["Ingest Layer<br/>RTMP · SRT · RIST<br/>WebRTC · WebTransport"] B --> C["Transcode/Packaging<br/>CMAF · ABR · Multi-bitrate"] C --> D["Delivery Layer<br/>HLS · LL-HLS · DASH<br/>HTTP-FLV · WebRTC · HESP"] D --> E["Viewer End"] style A fill:#2196F3,color:#fff style B fill:#FF9800,color:#fff style C fill:#9C27B0,color:#fff style D fill:#4CAF50,color:#fff style E fill:#2196F3,color:#fff The diagram above shows a five-segment structure for a standard live streaming pipeline. The ingest layer moves signals from cameras to the platform, while the delivery layer distributes processed streams to viewers. RTSP (camera control) and NDI (LAN production) operate outside the main pipeline, each working independently.
In the MiBee NVR surveillance-dashboard project, should the frontend pull H.264 or H.265 from all 16 cameras? A seemingly simple question that gets deeper the more you dig. H.265 needs only half the bitrate of H.264 at the same quality, saving both bandwidth and storage. But plenty of online sources still claim “H.265 browser support is poor, Firefox doesn’t support it, you need to install extensions.” Which of these claims still hold?
In the P2P transport-stack space, libp2p has long been the default — but its protocol stack is large and its configuration surface wide; every new project ends up choosing combinations from a long list of features (tcp/quic/webrtc/noise/yamux/identify/kad/relay/dcutr). iroh is the Rust library that takes the other road: it does only QUIC + dial-by-public-key + NAT traversal, collapses the transport layer into something small, and layers three optional modules on top (blobs/gossip/docs). On June 15, 2026, n0 released iroh 1.0 with the slogan “Dial Keys, not IPs” — the first stable release after 4 years of development and 65 pre-release versions.
In network security, fingerprinting is the foundational step for asset discovery and attack surface management. However, a single fingerprint library often has limited coverage—Nmap excels at network-layer service detection but falls short on web technology stacks; Wappalyzer is strong at frontend framework detection but cannot sense underlying protocols; WhatWeb identifies CMS accurately but lacks port scanning capabilities. In practice, a single target may involve network devices, web applications, cloud services, and other asset types simultaneously, so relying on just one fingerprint library inevitably leads to significant omissions.
Nmap is the gold standard of network scanning, and its fingerprint databases (nmap-os-db, nmap-service-probes) represent over two decades of accumulated knowledge. However, since Nmap 7.90 (2021), Nmap’s license was changed from GPLv2 to NPSL (Nmap Public Source License), adding many restrictions beyond standard GPL terms.
This means: even open-source projects that read or embed Nmap’s fingerprint data files may constitute derivative works of Nmap and must be released under an NPSL-compatible license. For closed-source commercial products, the compliance risk is even more severe—either open-source the entire project under NPSL, or pay a one-time OEM license fee of $59,980~$119,980.
Nmap has the world’s most comprehensive network fingerprint database — over 6,000 service probe signatures and 5,000+ OS fingerprints. But its fingerprint engine is implemented in C++, tightly coupled to PCRE2 regex and nsock async I/O. Reusing it directly means accepting Nmap’s entire architectural constraints.
Building a custom fingerprint loading tool is valuable when you need to embed the fingerprint database into a standalone binary for offline scanning, integrate fingerprint matching into an automated pipeline, bypass Nmap’s licensing constraints for customized scan strategies, or use it as a foundational component in a security product.
Nmap (Network Mapper) is the most widely used open-source network scanning and security auditing tool in the world. Its core identification capabilities rely on seven built-in fingerprint databases that cover operating systems, service versions, protocols, ports, MAC vendors, RPC programs, and NSE script extensions. As of the latest release Nmap 7.99 (March 26, 2026), these databases have evolved into one of the most comprehensive and active fingerprint identification ecosystems in the cybersecurity field.
The previous four articles in this series built a complete knowledge foundation—from Epidemic propagation theory in Gossip, to the SWIM membership protocol, to P2P implementations in Rust and Go, and finally to production best practices. Now it is time to apply this knowledge to real distributed systems.
This article examines six representative systems and how they adapt Gossip protocols to different scenarios: from Gossipsub parameter tuning to Raft membership changes, from Redis Cluster PING/PONG to Cassandra’s GossipDigest protocol, and the hidden Gossip routing mechanisms inside message queues.
In the previous article, we explored the core principles of the Gossip protocol in depth—Epidemic propagation models, the distinction between Anti-Entropy and Rumor-Mongering, and the mathematical foundation of the Phi Accrual failure detector. Gossip provides a general mechanism for information dissemination, but to build a complete distributed cluster, information dissemination alone is not enough: every node needs to know who else is in the cluster—who is online, who has left, and who has just joined.
In P2P networks, every node needs to learn the global cluster state—which peers are online, where data is stored, and whether new nodes have joined or old ones left—without relying on any central server. The essence of this problem is: how can information be disseminated efficiently and reliably across an unpredictable, dynamic network?
Gossip protocol (also called Epidemic protocol) offers a decentralized solution: mimic the spread pattern of infectious diseases. Each node randomly selects several neighbors and exchanges the information it knows. The message spreads like a virus, eventually reaching all nodes with high probability. It requires no centralized coordinator and has natural tolerance for network partitions and node failures.