# 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.