Skip to content

five-on-it / apps/server/src/rtc-transport

apps/server/src/rtc-transport ​

The server's side of the WebRTC data channel: withRtc wraps a client's WebSocket connection (ws-transport.ts) in a transport whose unreliable frames (the snapshots) go over a data channel while one is open, and everything else over the WebSocket.

  • Setting it up. The client's signalling frames (@foi/protocol's rtc.ts) never reach the game: an offer opens a peer in the RTC worker (rtc-host.ts), whose answer and candidates go back over the WebSocket, and the client's candidates go to the peer. Once the channel opens the transport is RtcConnection.lossy: the frames sent on it may be lost or come out of order. Frames that come on the channel reach the game like those on the WebSocket, whichever way they came.
  • Falling back. Everything goes over the WebSocket again (lossy false) when the peer fails or closes (it timed out, its connection failed, the worker was full or stopped: the client is told close), when the client says close (it fell back on its side), when WS_FRAMES_FALLBACK binary frames in a row come over the WebSocket while the channel is open (the client fell back without a word: it is told), when the debug command rtcDrop drops the server's side (RtcConnection.dropRtc: the client is not told, its own watch has to find out), or when the WebSocket closes. Each fall back is counted by the host, by its reason. The client may offer again later.
  • The game server reads lossy when it sends, and hears of each change through RtcConnection.onLossyChange (a snapshot stream that relied on an ordered connection starts again from a keyframe there, for instance).

Interfaces ​

Variables ​

Functions ​