Device routing, reconnect, and recovery

Scroll sideways to see the whole diagram.

• Desktop watchdogINBOUND_ACTIVITY_TIMEOUT_SECS = 45

  Every 15 seconds the desktop checks the time since the last inbound frame and then sends a heartbeat, which the relay answers with a pong. A gap of more than 45 seconds ends the connection. The check runs on the 15 second tick, so the desktop gives up a dead link at most 60 seconds after its last frame.

• Reconnect backoffreconnect_backoff

  Each wait is a random time between 100 milliseconds and a cap. The cap starts at 500 milliseconds, doubles per failed attempt, and stops at 30 seconds. The connect and the registration answer each have a 10 second timeout. The failure count resets only after a connection stayed ready for 30 seconds.

• Relay watchdogCLIENT_TIMEOUT = 180 s

  Every 30 seconds the relay checks the time since the socket’s last frame and then sends a ping. More than 180 seconds of silence stops the socket, so the close comes 180 to 210 seconds after the last frame. A text, ping, or pong frame resets the clock.

• Presence graceDESKTOP_RECONNECT_GRACE_SECS = 90

  Starts when the relay closes the desktop socket. Phones see reconnecting during the grace. At its end the relay broadcasts device-status disconnected with the reason reconnect_timeout, unless the desktop registered again first.

Scroll sideways to see the whole diagram.

• Desktop requests-32011 · -32010

  Requests recorded for the closed connection get -32011, “Desktop is reconnecting”, at once, and so does every new request during the wait. After it, new requests get -32010. The relay counts a silent socket as closed only after 180 seconds.

• Reconnect waitreconnect_timeout

  It holds presence only, and phones see the desktop as reconnecting. At 90 seconds the relay marks it offline and broadcasts device-status disconnected, unless a new connection registered first.

• Phone requests(user, desktop, id)

  The record outlives the phone’s socket, so a reply that arrives after the phone registers again is delivered. A final reply that lands during the gap is dropped, and the phone’s call ends at its own timeout.

• Phone leasechat:timeline-interest

  Bound to the phone’s connection, so it ends when the socket closes and nothing from the gap is kept. The phone sends it again once the relay answers registered or resumed, pings the desktop, and loads the latest window.

Scroll sideways to see the whole diagram.

• Interest leasechat:timeline-interest { appSessionId, active }

  Sent by the phone for the session on its screen and renewed every 20 seconds. The relay stores it per phone and never forwards it. It carries no timeline content.

• Lease endTIMELINE_INTEREST_TTL = 60 s

  A lease ends 60 seconds after its last renewal, or at once when the phone sends active: false, opens another session, or its socket closes or is replaced. Queued updates for that phone go with it. The relay drops a silent socket only after 180 seconds, so the lease ends first.

• Desktop deadlinechat:timeline-interest-updated { expiresAt }

  On every lease change the relay tells the desktop per session whether a lease exists and when it ends, never which phone holds it. The desktop keeps that deadline itself and stops serializing the session’s timeline once it passes.

• Relay filterauthorizationGeneration

  Issued when a session goes from no lease to one. Every frame must carry the current value, and the relay strips it and sends the frame only to phones whose lease is still live at the final send. Nothing is kept for the others, so a returning phone loads a snapshot.

Scroll sideways to see the whole diagram.

• Desktop queueMAX_PENDING_EVENT_BYTES = 4 MiB

  One queue per connection. It holds at most 64 timeline keys, 64 other events, and 4 MiB. A key is the base session plus the thread. A newer snapshot replaces the waiting one and keeps its place in the order. An older or identical one is ignored. When space runs out, the oldest waiting snapshot is dropped.

• Send tickRELAY_EVENT_SEND_INTERVAL = 350 ms

  The socket writer takes one event from the queue per tick. Control messages are checked before every event and do not wait for the tick. Each frame send has a 10 second timeout.

• Relay bufferTIMELINE_EVENT_FLUSH_INTERVAL = 250 ms

  One buffer per phone connection with at most 16 keys and 1 MiB. A newer revision replaces the waiting one, and the oldest key is evicted when a limit is passed. The relay sends one event per flush. A frame waits 250 milliseconds, or the rest of the pause after the previous send. That pause is 250 milliseconds per started 512 KiB of the event sent.

• Oversized slot32 MiB − 16 KiB

  A snapshot above 512 KiB in the relay, or above 4 MiB on the desktop, waits alone in one extra slot outside the byte limit, and a newer oversized one replaces it. The desktop refuses an event whose frame would pass 32 MiB minus 16 KiB.

Scroll sideways to see the whole diagram.

• Process memoryDeviceConnectionManager

  Holds every connection route, pending request record, reconnect presence, and interest lease. RelaySessionStore holds the resume sessions. A second process would see none of it, which is why the relay runs as one.

• DrainrelayDraining

  One-way. From its start the process refuses registrations. It waits at most 60 seconds for routing work in progress, then clears its memory without answering open requests and closes every device socket.

• Instance IDrelayInstanceId

  A new UUID per process, sent with every registration answer. Phones ignore presence events from another instance, and the desktop clears its interest state when updates come from a different one.