Allow disabling ping/pong? #312
Comments
|
@STRML if Primus doesn't pick up those connection terminations it's a bug in Primus so please report that in https://github.com/primus/primus as for the disabling of ping/pong's. I would love to see that as well. |
|
Closed due to inactivity, please reopen if needed. |
|
Maybe it makes sense to reopen as this was a feature request which I also support. |
|
PR is welcome! |
|
@darrachequesne thanks. |
|
@lpinca You're right, pings are sent by the client. But a timer is set on both the client and the server (allowing to detect any unavailability from the other side), isn't that the case with primus? |
|
Yes, but the client timer that sends the ping is delayed by the browser so the server incorrectly closes the connection. Hope it makes sense :) |
|
This is something we'll have to be prepared for in every browser - Safari
has been doing this for years, Chrome is next and I'm sure FF and IE are
not far behind. We simply can't rely on client timers being anywhere near
reliable. I've seen 130+ (!) delays in Chrome 56. Word from them is that
they will set a max, but the writing is on the wall.
…On Jan 22, 2017 3:28 PM, "Luigi Pinca" ***@***.***> wrote:
Yes, but the client timer that sends the ping is delayed by the browser so
the server incorrectly closes the connection.
Imagine that you used setTimeout(sendPing, 20000); on the client. The
sendPing callback is not actually called after 20 sec but after 40 sec.
Hope it makes sense :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#312 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABJFP9A_SydFX0hUCYKgTSZY1IZojB5Uks5rU8npgaJpZM4Dp2fJ>
.
|
The ping packets will now be sent by the server, because the timers set in the browsers are not reliable enough. We suspect that a lot of timeout problems came from timer being delayed on the client-side. Breaking change: v3.x clients will not be able to connect anymore (they will send a ping packet and timeout while waiting for a pong packet) Related: #312
The ping packets will now be sent by the server, because the timers set in the browsers are not reliable enough. We suspect that a lot of timeout problems came from timer being delayed on the client-side. Breaking change: v3.x clients will not be able to connect anymore (they will send a ping packet and timeout while waiting for a pong packet) Related: socketio/engine.io#312
The ping packets will now be sent by the server, because the timers set in the browsers are not reliable enough. We suspect that a lot of timeout problems came from timers being delayed on the client-side. Breaking change: v3.x clients will not be able to connect anymore (they will send a ping packet and timeout while waiting for a pong packet). Related: socketio/engine.io#312
The ping packets will now be sent by the server, because the timers set in the browsers are not reliable enough. We suspect that a lot of timeout problems came from timers being delayed on the client-side. Breaking change: v3.x clients will not be able to connect anymore (they will send a ping packet and timeout while waiting for a pong packet). Related: #312
|
Following up on this issue, as of commit 31ff875 it has reversed the ping-pong mechanism. So, is this issue still relevant? |
It would be nice if a
0value forpingIntervalorpingTimeoutcould disable ping/pong checking entirely.When used with an abstraction layer like Primus, the ping/pong is redundant and can sometimes cause situations where engine.io terminates the connection and Primus doesn't pick up on it. In those cases Primus might not reconnect.
The text was updated successfully, but these errors were encountered: