Error: Lost connection to server.

[surjiht]

Hi,
I am receiving the below log after connecting. I couldnt figure out what was the reason behind it.
Please help me through it. thank you
Error: Lost connection to server.
at Peer.emitError (peerjs.js:9965)
at Socket. (peerjs.js:9635)
at Socket.emit (peerjs.js:6853)
at WebSocket._socket.onclose (peerjs.js:7399)
at WebSocket.wrapFn (zone-evergreen.js:1218)
at ZoneDelegate.invokeTask (zone-evergreen.js:399)
at Object.onInvokeTask (core.js:41632)
at ZoneDelegate.invokeTask (zone-evergreen.js:398)
at Zone.runTask (zone-evergreen.js:167)
at ZoneTask.invokeTask [as invoke] (zone-evergreen.js:480)

[jonasgloning]

Most "Lost connection to server" errors are caused by the browser suspending the tab when in the background. There's nothing one can do except handling in gracefully and reconnecting.

[e-nikolov]

@jonasgloning

I am also experiencing this error and have to reconnect to the peerjs server every minute if chrome considers the tab as inactive.

According to this blog post from the chrome developers, when intensive throttling activates, timers set via setTimeout() and setInterval() get batched and executed once a minute.

I noticed that by default peerjs clients send HEARTBEAT messages to the peerjs server over the WebSocket once every 5 seconds. When the tab is throttled, this becomes once a minute.

Does the peerjs server close the connection if it has not received any HEARTBEATs for a minute?
Perhaps this issue can be solved by increasing that timeout by 30 seconds to account for the throttling?

[e-nikolov]

I tested it with a self-deployed peerjs server and I can confirm that setting the timeout to 70 seconds via the --alive_timeout flag, fixes the disconnection issues for "intensively throttled" tabs.

[jonasgloning]

Thank you for the link to the blog post!

I increased the timout of the public instance to 90s. Some early results:

SELECT 
    (filter(count(*), WHERE duration >= 85 AND duration <= 95) * 100) / filter(count(*), WHERE transactionType = 'Other') 
    AS 'Percentage of Requests in 85-95s Range'
FROM 
    Transaction 
WHERE 
    entityGuid = '....' 
    AND transactionType = 'Other' 
SINCE 
    1 day ago

Interval	60s Timout	90s Timout
55s-65s	14.3%	4.55%
85s-95s	1.55%	7.53%

Approximately 12.75% (14.3% - 1.55%) of connections were terminated due to the timeout, while only 2.98% (7.53% - 4.55%) of these were actually dead.

Posively suprised! I will change the default setting in the next release.

[github-actions]

🎉 This issue has been resolved in version 1.0.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release
• v1.0.2

Your semantic-release bot 📦🚀