Bridge sessions#

Bridge sessions provide a one-to-one channel between a desktop role and a mobile role. After the initial hello, PacketRelay forwards text frames verbatim and reports when the peer joins or leaves.

Before you start#

• Complete First bridge.
• Generate a fresh, unguessable session identifier for every new pairing.
• Configure both clients to use the same relay hostname and session identifier.

Connection order#

1. The desktop opens a WebSocket and sends desktop_hello.
2. The relay creates or reuses the bridge and returns session_ready.
3. The mobile opens a WebSocket and sends mobile_hello.
4. The relay returns session_ready to the mobile and sends peer_connected to both peers.
5. Either peer may send text frames until one disconnects.

Only one connection occupies each role. A reconnect takes over that role. The client should treat peer_connected and peer_disconnected as current-state signals and tolerate repeated network reconnections.

Forward application traffic#

Bridge payloads are opaque strings. PacketRelay does not add identity, sequence, acknowledgement, or encryption fields. If the application needs those properties, define them in its own payload and validate them at both ends.

Keep frames within the relay message-size limit. Split larger artifacts at the application layer or transfer them through a separate storage channel.

End a session#

Close both sockets. When the final role leaves, the in-memory bridge is removed. A later mobile connection with the old identifier cannot recreate it; a desktop must establish a new bridge first.

Verify#

After reconnecting either role:

1. Confirm the new socket receives session_ready.
2. Confirm the remaining peer receives the expected connection event.
3. Send a new text frame in each direction.
4. Close the new socket and confirm the survivor observes peer_disconnected.

If it does not work#

Related#

• Protocol — bridge hello and response shapes.
• Operations — connection and message limits.