New Edge Cluster: Relay server for SRS.

[winlinvip]

The new Origin Cluster, SRS origin server with proxy, can extend the number of streams it supports. The Edge Cluster is used to expand the number of viewers supported, but the Edge Cluster only supports the RTMP protocol. You cannot use Edge Cluster for WebRTC or SRT protocol.

Currently, the Edge Cluster is built within the SRS media server, like this:

Client ---RTMP--> SRS(Edge) ---> SRS(Origin)

This architecture has some problems:

1. Complexity: Makes SRS complex and hard to maintain
2. Protocol Limitations: Needs to support at least RTMP and WebRTC protocols within the same C++ codebase
3. Scalability Issues: Adding new protocols (like SRT) requires significant C++ development
4. Maintenance Overhead: All protocol handling is embedded in the main SRS server

I think a better approach would be a Relay Cluster, like this:

Client ----> SRS(Origin) ----> Relay ---> SRS(Origin) ---> Client

Note: A simple relay can be based on Go+FFmpeg, which can support RTMP, SRT, WebRTC, and other protocols. Accordingly, the relay server can be implemented in pure Go or Rust. Like the proxy server, a relay can be implemented in Go or Rust, eliminating the need for a C++ server.

Note: As all relays are stateless client applications, a relay is very simple and stateless, and can be deployed easily and effectively. With this approach, all SRS clusters can be made stateless.

With the relay approach, SRS only needs to be an Origin server, or an Origin Cluster with a proxy server:

Client ---> Proxy --> SRS(Origin) ---> Relay ---> Proxy --> SRS(Origin) ---> Client

A relay is not a proxy server; it relies on events to relay streams. For example, when a viewer starts to request a stream from an Origin server, it will trigger the relay to deliver the stream from another origin server.

• For a very small relay cluster, it acts as a forwarder, always forwarding all streams to another origin server.
• For a small or medium relay cluster, it uses play event hooks and starts the relay only when requests are received. It also disconnects the stream by hooking the stop event of the last viewer.

This requires more events from SRS, especially the first viewer connect event and the last viewer disconnect event. These new events can be used to reduce the load for processing all events from SRS.

Latency Analysis

The Relay Cluster architecture will NOT increase latency because:

1. No Caching Layer: Relays operate without stream caching when no cache is configured
2. Pipeline Processing: Data flows through relays in a pipeline without buffering
3. Direct Forwarding: Packets are forwarded immediately without processing delays