-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: Lost connection to server. #431
Comments
This comment was marked as outdated.
This comment was marked as outdated.
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? |
I tested it with a self-deployed peerjs server and I can confirm that setting the timeout to 70 seconds via the |
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
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. |
Intensive throttling might result in heartbeats being sent only once a minute. This change adjusts the timeout to 90 seconds. For more information, see https://developer.chrome.com/blog/timer-throttling-in-chrome-88 Thank you, @e-nikolov. Closes #431.
Intensive throttling might result in heartbeats being sent only once a minute. This change adjusts the timeout to 90 seconds. For more information, see https://developer.chrome.com/blog/timer-throttling-in-chrome-88 Thank you, @e-nikolov. Closes #431.
## [1.0.2](v1.0.1...v1.0.2) (2023-12-05) ### Bug Fixes * **deps:** update dependency @types/express to v4.17.18 ([f4bcc16](f4bcc16)) * **deps:** update dependency @types/express to v4.17.19 ([ebec5b0](ebec5b0)) * **deps:** update dependency @types/express to v4.17.20 ([a6c01fd](a6c01fd)) * **deps:** update dependency @types/express to v4.17.21 ([80df87f](80df87f)) * reduce unnecessary timeouts ([638af56](638af56)), closes [#431](#431)
🎉 This issue has been resolved in version 1.0.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
# [1.1.0-rc.1](v1.0.0...v1.1.0-rc.1) (2024-04-01) ### Bug Fixes * **deps:** update dependency @types/express to v4.17.18 ([f4bcc16](f4bcc16)) * **deps:** update dependency @types/express to v4.17.19 ([ebec5b0](ebec5b0)) * **deps:** update dependency @types/express to v4.17.20 ([a6c01fd](a6c01fd)) * **deps:** update dependency @types/express to v4.17.21 ([80df87f](80df87f)) * **deps:** update dependency express to v4.18.3 ([ff0b83a](ff0b83a)) * **deps:** update dependency express to v4.19.0 ([208f108](208f108)) * **deps:** update dependency express to v4.19.1 ([3a67b5d](3a67b5d)) * **deps:** update dependency express to v4.19.2 ([ec993f6](ec993f6)) * **deps:** update dependency node-fetch to v3.3.1 ([2275ce3](2275ce3)) * **deps:** update dependency node-fetch to v3.3.2 ([05a1833](05a1833)) * **deps:** update dependency yargs to v17.7.2 ([23b4e47](23b4e47)) * empty npm package ([f4c359a](f4c359a)), closes [#318](#318) * force new version ([26877ca](26877ca)) * import from ESM only environments ([993dee9](993dee9)) * reduce unnecessary timeouts ([638af56](638af56)), closes [#431](#431) * remove confusing version number ([f6314df](f6314df)) * the server could crash if a client sends invalid frames ([33e6d75](33e6d75)), closes [#290](#290) ### Features * build Docker image for `arm64` ([a61f103](a61f103)) ### Reverts * Revert "build: deploy to fly.io" ([c3de627](c3de627)) * Revert "chore: Configure Mend Bolt for GitHub (#349)" ([fd00aef](fd00aef)), closes [#349](#349)
🎉 This issue has been resolved in version 1.1.0-rc.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
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)
The text was updated successfully, but these errors were encountered: