Disconnection state to triggered in 2.1.4 ? about pusher-js HOT 8 CLOSED

Hi,

Yes, this behavior has changed as it was incorrect before. However, documentation is inconsistent and I haven't noticed that. If you look a bit above that state transitions, the disconnected state was described as:

The Pusher connection was previously connected and has now intentionally been closed.

In your case, losing connectivity is not an intentional disconnect and the connection should not enter the disconnected state. I'd rather check if the state is connected.

Sorry about that, I'll update the documentation.

from pusher-js.

Okay clear.

And what about the delay before the state-change callback gets called?

from pusher-js.

It has also changed, as described in the changelog. We basically dropped support for browser online detection, as it was unreliable and was giving false negatives. There's only one algorithm that uses online detection - if a client is not connected and the browser emits an online event, pusher-js will try reconnecting immediately, to speed up the reconnection process.

Currently, only ping/pong messages are used to check if the connection is working. The default timeout before ping is sent is 120s and there's another 30s waiting for the response, before disconnecting.

from pusher-js.

Okay, I must have missed it in the changelog.

Currently, only ping/pong messages are used to check if the connection is working. The default timeout before ping is sent is 120s and there's another 30s waiting for the response, before disconnecting.

Okay. False negatives are bad but this means that it now always takes somewhere between 0 and 150 sec before a disconnection is known to the client right? On the other hand: does this also solve the problem of false positives (Other members in a presence channel not leaving the channel when the browser is closed), or is that something Pusher (not the js. lib) should solve?

Thanks for your quick reply.

from pusher-js.

Sorry I lost track of this thread. Yes, it will take between 0 and 150s to detect disconnection. If you really depend on connection state, you can alternatively lower the activity timeout slightly (I would advice around 30s, not less) and it will decrease the delay (to 30s in this example).

Generally, closing the browser window should close the TCP connection and it should be detected on the server side. Otherwise, servers should remove disconnected clients from presence channel automatically. The algorithm for detection is pretty much the same - ping after X seconds of inactivity, wait Y second for response and close the connection if no messages are received.

from pusher-js.

From 2.1.6 when a browser emits the offline event, the client will send a ping message immediately and if doesn't get a response after pong timeout (30s by default) it will try reconnecting, so you don't need to wait 120s for the ping. Can we close this issue?

from pusher-js.

Closing, because the default disconnection detection lag has been reduced significantly (150s -> 30s) and there's no more activity in this issue.

from pusher-js.

Cool!

from pusher-js.