&timeouts=10000,100000,3000,30000,3000,5000

timeouts.md

The session.reconnectSpeed array stores various timeout and retry durations in milliseconds, critical for managing WebRTC and WebSocket connection states. Each value influences how quickly the application detects and reacts to connection issues.

session.reconnectSpeed = [10000, 100000, 3000, 30000, 3000, 5000];

You can modify these values using the &timeouts=xx,yy in the URL or by editing the index.html file and adding session.reconnectSpeed = [10000, 100000, 3000, 30000, 3000, 5000];

Examples:

&timeouts=1000,3000 (updates first two values, keeps rest)
&timeouts=,,,10 (updates only 4th value)
&timeouts= (no changes)
&timeouts=1000,abc,3000 (updates first and third, ignores invalid value)

Here's a breakdown of each value:

1. session.reconnectSpeed[0] (Value: 10000 ms)

   • Description: This value represents the timeout duration for a local peer connection (session.pcs) that has entered the disconnected state. If a peer connection remains in the disconnected state for this amount of time, the connection is considered lost, and session.closePC() is called to clean it up.
   • Impact:
     • Increasing: Provides a longer window for the connection to potentially recover from a temporary disconnection without being terminated. This can be beneficial on unstable networks but might delay the detection of a genuinely lost connection.
     • Decreasing: Leads to quicker detection and cleanup of permanently disconnected peers. This can free up resources faster but might prematurely terminate connections that could have recovered.
   • Suitable Range: 5,000 ms to 30,000 ms.
   • Pros of Adjusting:
     • Higher: More resilient to transient network issues.
     • Lower: Faster cleanup of dead connections, quicker response to permanent disconnections.
   • Cons of Adjusting:
     • Higher: Slower to react to genuinely failed connections, potentially holding onto resources longer.
     • Lower: May drop connections that could have self-healed given a bit more time.
   • Used in: session.pcs[UUID].onconnectionstatechange when connectionState is "disconnected".

2. session.reconnectSpeed[1] (Value: 100000 ms)

   • Description: This value is used as a threshold to determine if a WebRTC data channel send operation failure is due to a connection being "dead or not yet open". When session.sendPeers or session.sendMessage fails to send data, it checks if the connection's age (Date.now() - session.pcs[i].startTime) has exceeded this threshold. If startTime + session.reconnectSpeed[1] < Date.now(), a warning is logged, implying the connection has been established for a significant time and should be operational.
   • Impact:
     • Increasing: Makes the system more tolerant before logging a warning about a potentially dead connection after a send failure. It assumes that older connections might take longer to stabilize or that errors are transient for a longer period.
     • Decreasing: The system will more quickly log warnings about send failures on established connections, assuming they should be stable sooner.
   • Suitable Range: 30,000 ms to 120,000 ms.
   • Pros of Adjusting:
     • Higher: Fewer warnings for connections that might be temporarily problematic but still viable.
     • Lower: Earlier indication that an established connection might be having persistent send issues.
   • Cons of Adjusting:
     • Higher: May delay the realization that a connection has serious issues.
     • Lower: Could lead to more frequent warnings for connections that are just slow to become fully operational or experiencing brief hiccups.
   • Used in: session.sendPeers and session.sendMessage within the catch block of a sendChannel.send() attempt.

3. session.reconnectSpeed[2] (Value: 3000 ms)

   • Description: This is the timeout duration for a remote peer connection (session.rpcs) that has entered the failed state. If an RPC remains in the failed state for this period, session.closeRPC() is called.
   • Impact:
     • Increasing: Allows more time for a failed connection to potentially recover (e.g., through an ICE restart triggered by other mechanisms) before being closed.
     • Decreasing: Results in faster cleanup of connections that have definitively failed, allowing for quicker re-attempt or notification.
   • Suitable Range: 2,000 ms to 10,000 ms.
   • Pros of Adjusting:
     • Higher: Gives more opportunity for recovery if the "failed" state is transient.
     • Lower: Faster reaction to truly failed connections.
   • Cons of Adjusting:
     • Higher: Delays cleanup of permanently failed connections.
     • Lower: Might close a connection that could have recovered, especially if ICE restarts are slow.
   • Used in: session.rpcs[UUID].onconnectionstatechange when connectionState is "failed".

4. session.reconnectSpeed[3] (Value: 30000 ms)

   • Description: This timeout applies to the initial WebSocket (signaling server) connection attempt. If the WebSocket connection isn't established (onopen is not called) within this timeframe, it's considered a timeout.
   • Impact:
     • Increasing: Gives the WebSocket connection more time to establish, which can be useful on slow networks or when the server is under high load.
     • Decreasing: Provides faster feedback to the user or system if the signaling server is unreachable or very slow to respond.
   • Suitable Range: 15,000 ms to 60,000 ms.
   • Pros of Adjusting:
     • Higher: Better chance of connecting on slow or congested networks.
     • Lower: Quicker failure detection for signaling server issues.
   • Cons of Adjusting:
     • Higher: User waits longer before being notified of a connection failure.
     • Lower: May fail connections that would have eventually succeeded on a slow network.
   • Used in: session.connect for the initial WebSocket connection attempt.

5. session.reconnectSpeed[4] (Value: 3000 ms)

   • Description: This value is used as a delay (sleep) in session.offerSDP when a local peer connection (session.pcs) is being set up but its state is not yet "connected". The code waits for this duration and then re-checks the connection state. If it's still not "connected", the peer connection is closed. This is a brief pause to allow a newly created or re-negotiating peer connection to transition to a stable state before potentially closing it due to an offer request on an unstable PC.
   • Impact:
     • Increasing: Provides more time for a peer connection to stabilize before an offer is potentially aborted. This might be useful if connection establishment is generally slow.
     • Decreasing: Reduces the delay in the offerSDP process but might lead to premature closure of a PC if it's slow to connect.
   • Suitable Range: 1,000 ms to 5,000 ms.
   • Pros of Adjusting:
     • Higher: More robust against slow PC state transitions during offer creation.
     • Lower: Faster offer processing if PCs are typically quick to connect.
   • Cons of Adjusting:
     • Higher: Adds a fixed delay to the offer process if the PC isn't immediately connected.
     • Lower: Higher risk of closing a PC that is just slow to establish during offer generation.
   • Used in: session.offerSDP as await sleep(session.reconnectSpeed[4]);.

6. session.reconnectSpeed[5] (Value: 5000 ms)

   • Description: This timeout is for a remote peer connection (session.rpcs) that has entered the disconnected state. If an RPC remains disconnected for this duration, session.closeRPC() is invoked to clean it up.
   • Impact:
     • Increasing: Allows more time for a disconnected RPC to recover, useful for transient network problems.
     • Decreasing: Faster detection and cleanup of permanently disconnected RPCs.
   • Suitable Range: 3,000 ms to 20,000 ms.
   • Pros of Adjusting:
     • Higher: Greater resilience to temporary network interruptions for remote peers.
     • Lower: Quicker resource release and state update when an RPC is truly gone.
   • Cons of Adjusting:
     • Higher: Can delay the system's response to a permanently lost remote peer.
     • Lower: May prematurely terminate RPCs that could have recovered.
   • Used in: session.rpcs[UUID].onconnectionstatechange when connectionState is "disconnected".

Modifying these values requires balancing responsiveness to failures against tolerance for network instability and varying connection setup times. The "suitable ranges" are general guidelines and might need adjustment based on specific application requirements and typical network conditions of users.

Available on v27.6 of VDO.Ninja