## 3 System Design
### Security Protection Mechanisms  
Security is a foundational consideration in the design of our system. Unlike traditional centralized streaming platforms, which aggregate all audio and video traffic through a small number of servers--creating single points of failure and attractive targets for attacks--our system employs a decentralized peer-to-peer (P2P) chain architecture. In this design, video streams are forwarded sequentially through direct, one-to-one connections between client nodes. The central server is only responsible for node registration, link scheduling, and anomaly monitoring; it does not participate in the forwarding of any audio or video data. This approach eliminates the risks associated with data aggregation, centralized server leaks, or targeted attacks, thereby decentralizing transmission channels and significantly enhancing overall system security and resilience. Each node in the chain listens on a local port instead of a remote one and only accepts connections initiated by its designated upstream node. The connection is strictly one-to-one, using the receiver's IPv6 address and port. There is no publicly exposed address that can be accessed arbitrarily. All chain connections are established in a fully controlled and authenticated manner, preventing any unauthorized access. As a result, the system is inherently secure by design. Eavesdropping or tampering with the data stream is virtually impossible, as all nodes would only establish connections with their designated upstream nodes, and the data stream has no chance of being accessed by any third-party nodes or servers. Figure 3: Chain link break recovery and fallback self-healing mechanism diagram. At the data link layer, the system fully integrates the SRT (Secure Reliable Transport) protocol as its streaming media transport standard. The SRT protocol inherently embeds advanced symmetric encryption algorithms, including AES-128 and AES-256. Users can negotiate keys during link establishment, ensuring that every segment of video data is encrypted before being transmitted over the public network. In its specific implementation, all pushing and pulling nodes are serialized through the \(\mathtt{srt}\):// protocol. The SRT protocol stack automatically encrypts and decrypts data packets during transmission and reception at each hop. Even if a malicious third party or \"Man-in-the-Middle\" (MITM) attempts to eavesdrop on or intercept data within the link, all transmitted content appears as high-strength ciphertext due to the lack of the correct session key, thereby guaranteeing the confidentiality and integrity of the content. Furthermore, because the system employs chain-based peer-to-peer forwarding, the actual data stream is not obtained directly from a server by the client. Instead, the server delivers the initial stream to the head node of the chain, which then pushes it to downstream nodes. Each level only needs to establish an SRT-encrypted connection with its direct upstream and downstream counterparts. The client's local Frmpeg decoding module only accesses and decrypts locally received stream data, eliminating the need for additional plaintext data interaction with the server. This chain-based push-pull separation significantly reduces the possibility of attackers injecting, forging, or hijacking content by impersonating servers or tampering with relay links, further enhancing the overall security protection capabilities of the system. To specifically counter Man-in-the-Middle (MITM) attacks, the SRT protocol not only relies on key exchange and data encryption but can also incorporate identity verification using passwords or keys configured locally on the client. Only authenticated nodes are permitted to participate in the chain forwarding. Should an attacker attempt to forge a link node for hijacking, they cannot access the system's actual forwarding chain without obtaining the session key or successfully completing the server's legitimate registration process.