ebf8b712c9
Reorganize the SRS (Simple Realtime Server) repository to follow a conventional Go project structure, setting the stage for a progressive transition from a C++ project to a Go project. The proxy, which was once contained within its own `proxy/` subdirectory, will now be converted into the initial Go module located at the root of the repository, serving as a template for subsequent Go modules. - **Go module at repo root:** `go.mod` moved to repo root, module renamed from `proxy` to `srsx`. The repo is now a proper Go project with `cmd/` and `internal/` at the top level. - **Elevation of Proxy Code:** Move the proxy code from `proxy/cmd/proxy-go/` to `cmd/proxy/`, and from `proxy/internal/` to `internal/`. The proxy serves as the inaugural application; subsequent modules (for instance, `cmd/origin`) will mimic this arrangement. - **Documentation Restructured:** Transfer the documentation from `proxy/docs/` to `docs/proxy/`, revise the main README to endorse OpenClaw as the preferred AI tool, and update `proxy/README.md` to point to the new documentation locations. - **Build and config:** `Makefile` moved to root, `PROXY_STATIC_FILES` default path corrected for the new layout, `.gitignore` consolidated. - **Cleanup:** removed standalone `proxy/LICENSE` (repo-level license applies), all internal imports updated to `srsx/internal/...`. - **OpenClaw workspace:** added community bot info, git workflow conventions, and support group behavior guidance. This restructuring was performed by OpenClaw orchestrating Claude Code and Codex via ACP. --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: chatgpt-codex-connector[bot] <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>
2.8 KiB
Design
Overview
proxy is a stateless media streaming proxy with built-in load balancing that enables building scalable origin clusters. The proxy itself acts as the load balancer, routing streams from clients to backend origin servers.
Client → Proxy (with Load Balancer) → Backend Origin Servers
Since the proxy is stateless, you can deploy multiple proxies behind a load balancer (like AWS NLB) for horizontal scaling:
Client → AWS NLB → Proxy Servers → Backend Origin Servers
Deployment Modes
Single Proxy Mode
Use case: Moderate amount of streams requiring multiple origin servers (each stream has few viewers). The total stream count is manageable by a single proxy server. Uses memory-based load balancing (no Redis needed).
Architecture:
+--------------------+
+-------+ Origin Server A +
+ +--------------------+
+
+-----------------------+ + +--------------------+
+ Proxy Server +------+-------+ Origin Server B +
+ (Memory LB) + + +--------------------+
+-----------------------+ +
+ +--------------------+
+-------+ Origin Server C +
+--------------------+
Multi-Proxy Mode (Scalable)
Use case: When a single proxy becomes a bottleneck. Supports a large number of streams across many origin servers, with limited viewers per stream. Redis is required for state synchronization between proxies.
Architecture:
+-----------------------+
+---+ Proxy Server A +------+
+-----------------+ | +-----------+-----------+ +
| AWS NLB +--+ | +
+-----------------+ | (Redis Sync) + Origin Servers
| +-----------+-----------+ +
+---+ Proxy Server B +------+
+-----------------------+
Complete Cluster (Edge + Proxy + Origins)
Use case: Very large deployments with both numerous streams AND numerous viewers. Edge servers aggregate upstream connections - fetching one stream from upstream to serve multiple viewers, dramatically reducing load on proxy and origin servers.
Architecture:
Edge Servers → Proxy Servers → Origin Servers
(Proxy + Cache) (Proxy) (SRS/Media)
Note: Future edge servers will be implemented as proxy servers with caching enabled, creating a unified architecture where the same codebase serves both proxy and edge roles. The edge cache aggregates viewer connections, so thousands of viewers can watch the same stream while only requesting it once from upstream.