niom-signaling/docs/architecture/runtime_loop.md

Runtime Loop & Message Flow

Überblick

• Server basiert auf actix-web und actix-ws.
• Jeder WebSocket-Client erhält eine Session über actix_ws::handle.
• broadcast::channel (Tokio) fungiert als zentrales Publish/Subscribe-Relay.

Ablauf Heute

1. Handshake: /ws Route akzeptiert WebSocket-Requests.
2. Incoming Task: Liest Nachrichten vom Client, deserialisiert SignalingMessage und sendet sie in den Broadcast-Kanal.
3. Outgoing Task: Abonniert Broadcast (rx.recv()) und schreibt jede Nachricht zurück in die Session.
4. Routing: Aktuell kein Filter – alle Clients erhalten jede Nachricht.

Erweiterungsplan

• Channel/Room Map: HashMap<RoomId, Sender> oder dedizierter Actor für jede Session.
• Presence Tracking: Join/Leave Events, Heartbeats.
• Message Typen: Offer/Answer/Candidate/Text/Broadcast – sollen im Proto beschrieben werden.
• Persistente Logs: Structured Logging via tracing mit Session-ID.