System Design & Memory Budget Blueprint
RUSEON Core is engineered as a unified single binary that encapsulates ingestion, shared-memory distribution, low-latency transmuxing, and crash-resilient archiving into a tightly bounded resource model.
1. Process Memory Budget Calculation
RUSEON Core's memory consumption scales deterministically based on the number of active camera streams and concurrent viewers:
text
Total RAM = Base Runtime (~35 MB) + (N_cams × 0.7 MB) + (M_viewers × 0.1 MB) + BadgerDB MemTable (16 MB)Memory Footprint Breakdown:
| Subsystem Component | Memory Allocation | Purpose |
|---|---|---|
| Base Binary & Runtime | ~25 – 40 MB | Go runtime, Gin HTTP router, Prometheus metrics registry, SSE dispatcher |
| RingBuffer (per camera) | ~0.5 – 1.0 MB | 100-frame circular slice for GOP KeyFrame backfilling and subscriber fan-out |
| fMP4 Archiver Window | ~0.2 – 0.5 MB per stream | In-memory fragment buffer before sync_file_range and POSIX_FADV_DONTNEED flush |
| BadgerDB v4 MemTable | 16 MB (global cache) | LSM memory write table (opts.MemTableSize = 16MB, opts.NumMemtables = 1) |
| Active WebRTC Viewer | ~100 KB per peer | Pion WebRTC session state, ICE candidates, and 32-packet UDP batch buffer |
TIP
Empirical Validation: In standard benchmark tests (bench-baseline.md), 600 concurrent 1080p cameras (18,139 FPS) with 1,800 active HLS viewers and 240 WebRTC viewers consumed only 471 MB RSS memory and 140 MB Heap Alloc in total.
2. Security Boundaries & Process Isolation
- Zero Root Privilege: RUSEON Core runs as an unprivileged user (
ruseon:ruseonin Docker). If binding to privileged ports80/443, standard LinuxCAP_NET_BIND_SERVICEcapability is used. - Memory Safety: Written 100% in Go without Cgo bindings, eliminating buffer overflow, double-free, and use-after-free vulnerabilities common in legacy C/C++ media servers.
- Strict Network Sandboxing: All WebRTC UDP traffic can be multiplexed over a single listening port (
8555/UDP), eliminating dynamic port sprawl in firewalls.