v0.13.13

Full Changelog: v0.13.12...v0.13.13

v0.13.12

Full Changelog: v0.13.11...v0.13.12

v0.13.11

Full Changelog: v0.13.10...v0.13.11

v0.13.10

• Tell a POST/GET streaming client at once when the relay ends its transport. When one side of a session reconnected, the Azure and Go relays aborted the other side's transport to resume both together, but a streaming client only received empty responses until its own heartbeat timed out several seconds later. By then the other side had moved on to the next relay, and the two kept missing each other until the Remote Desktop client gave up. The relays now send a close record on the client's next download, so it resumes within a fraction of a second. The Python relay already did this.
• Wait longer at the room's other relays when the session's relay cannot be reached. A side that cannot reach that relay cannot return to it, so it now waits at least 8 seconds at the other relays (12 seconds per attempt on Android), giving the other side time to give up on the session's relay and follow. Resume diagnostics now name both relays when a session moves.

Full Changelog: v0.13.9...v0.13.10

v0.13.9

• Move interrupted Android Home sessions to the room's other relays too. When the session's relay cannot be reached, the Android Home app now tries the room's relays in the configured order, as the Windows and macOS apps and the Work service do since 0.13.8. With more than one relay, each attempt allows 4 seconds plus 3 more per round (up to 15) for connecting and for the Work agent to arrive.
• Stop pairing a resume connection that a side has already abandoned. A side that gives up waiting at one relay closes that resume connection and tries the next, but the relay did not notice until it tried to pair it, which cost another full resume round. The Azure, Go, and Python relays now read waiting resume connections continuously, drop one as soon as it closes, and no longer interrupt a working session because of one.

Full Changelog: v0.13.8...v0.13.9

v0.13.8

• Move an interrupted Remote Desktop, WinRM, or SMB session to another relay of the same room when its relay cannot be reached. A resume previously retried only the relay the session started on, so when one side's path to that relay stayed down longer than the Remote Desktop client's ~16-second reconnect window, the session was lost even though the room's other relay was reachable. The Windows Home app, the Work service, and the macOS Home agent now try the room's relays in the configured order, waiting a bounded and growing time at each for the other side, and every relay rebuilds the session from the two resume attachments. The Android Home app still resumes only through the session's original relay.

Full Changelog: v0.13.7...v0.13.8

v0.13.7

• Reconnect Remote Desktop sessions sooner after the relay path recovers from a freeze. A resume attempt started while the path was frozen kept waiting for its full 8-second limit after the path came back, and failed attempts also doubled the delay before the next one, so a session could resume a fraction of a second after the Remote Desktop client had already given up. On Windows and macOS, Remote Desktop resume attempts now give up after 4 seconds, returning to 8 seconds after three consecutive timeouts in case a slow proxy needs longer. On every client, an attempt that timed out no longer increases the delay before the next one.

Full Changelog: v0.13.6...v0.13.7

v0.13.6

Full Changelog: v0.13.5...v0.13.6

v0.13.5

• Notice a frozen relay path within 8 seconds instead of 15 during Remote Desktop sessions, on Windows, macOS, and Android. The OCI relay's network briefly stops passing traffic for about 11 seconds, roughly once an hour. A side with no data awaiting acknowledgement only noticed through its 15-second heartbeat timeout, after the Remote Desktop client had already reset the connection (about 16 seconds after data stopped). It now notices at 8 seconds and keeps retrying the resume, so the session reattaches as soon as the path recovers. Other services keep the 15-second timeout.

Full Changelog: v0.13.4...v0.13.5

v0.13.4

• Resume Remote Desktop sessions within seconds after one side abandons a stalled POST/GET streaming transport. That transport is abandoned without a close message, so the relay kept treating it as alive until it expired about five minutes later, never told the other side to resume, and the Remote Desktop client gave up after about 20 seconds. The Azure, Go, and Python relays now treat a resume connection from either side as proof that its previous transport failed, and immediately coordinate both sides to resume.

Full Changelog: v0.13.3...v0.13.4