Skip to main content

Handling long duration sessions [8+ hour]

8 hours has been found to be the optimal time for a longer duration session. Anything longer should be handled differently, using the API to instruct connections and disconnects after the 8-hour mark. Keep reading to learn the best practices for implementing such actions using pseudo code.

Issues that occur with 8+ hour sessions

The testRTC analysis engine can handle long sessions. That said, analyzing them in a timely fashion or visualizing them quickly to the user on the dashboard increases linearly with the time of the session. Our suggestion is that if many of the sessions conducted in your watchRTC account are longer than 8 hours, it might be better to split them up.
Important: Please remember that no alerts or notifications can be sent until a connection is closed and the data is analyzed. This can be problematic as issues go unnoticed during longer sessions because the file is waiting much longer to be analyzed.

Solutions and best practices

These are two alternative solutions here that we usually suggest in such cases:

  1. Keep your sessions short(er)
  2. Apply our persistent connection mechanism

We will leave the “keep session shorter” option to you to implement (you will need to close and reopen the WebRTC peer connections in your application for that). If you’d rather not take that route, then read on to see how you can use persistent connections instead.

Persistent connections for long sessions: or pseudo code

Persistent connection is a mechanism that is used by call centers to hold a single WebRTC connection while “splitting” it internally to multiple logical calls from users. The same concept can be applied by watchRTC to also split a long session into shorter ones.

Here’s how we’re going to apply this mechanism to long duration sessions:
  • Keep track of sessions
  • Connect and disconnect every 8 hours (or a different time frame of your choosing)
  • Modify roomID for each new connection
The code snippet below does it all: it uses a timer to keep track of the session duration and at the given time, closes one logical connection and opens another with a new roomId.
   let sessionsIterator = 1;
   watchRTC.persistentStart(roomId, peerId);

     () => {

       watchRTC.persistentStart(roomId + '-' + sessionsIterator, peerId);
     60000 * 60 * 8 // 8h
  1. let sessionsIterator = 1;

    This line initializes a variable sessionsIterator to 1. This variable is used to keep track of sessions.

  2. watchRTC.persistentStart(roomId, peerId);

    This function is being used to start a persistent session with the roomId and peerId parameters.

  3. setInterval(() => {...}, 60000 * 60 * 8’

    This sets up a recurring function that will execute every 8 hours (60000 milliseconds * 60 seconds * 8 hours).

    Inside this function:
    • watchRTC.persistentEnd(); This function is used to end the current persistent session.
    • sessionsIterator++; This increments the sessionsIterator variable to keep track of the number of sessions.
    • watchRTC.persistentStart(roomId + '-' + sessionsIterator, peerId); This calls persistentStart() function again, but this time with a modified roomId. It combines the current ‘roomId’ with the current ‘sessionsIterator’, separated by a hyphen to differentiate sessions.
Overall, this code sets up a persistent session with initial parameters, then at regular intervals, it ends the current session, increments the session counter, and starts a new session with updated parameters.
Important: Just to be clear - this implementation doesn’t close, reopen, reset or create WebRTC peer connections. It just tells our watchRTC server to close one logical session in a room and open up another in a newly created room for the exact same WebRTC peer connection.

Benefits of adding this pseudo code

By using pseudo code which instructs to disconnect and create a new user with an updated peer name every 8 hours, users can avoid all of the issues mentioned above.

Was this article helpful?

0 out of 0 found this helpful