Within Tokbox there are four primary events:
connectionCreated
connectionDestroyed
streamCreated
streamDestroyed
We are monitoring these events on the client (pure JS) and using the webhooks on the server (PHP).
The connectionDestroyed event's object contains the "reason" why it was destroyed.
We have noticed that when the reason is networkDisconnected we see a delay in its response.
The other events and reasons seem to fire pretty much immediately. But, when the network connection goes down (pulling the ethernet cord or turning off wifi when testing) there seems to be a 5-20 second delay before the webhook acknowledges it.
Does anybody know if this is "typical"? Does Tokbox do this on purpose? Is it maybe giving the connection some time to reconnect so that a little network hiccup doesn't completely shut you down prematurely? Is there a way to change this delay?
If anybody has any insight into this, I would greatly appreciate it.
Thank you!
Manik here from TokBox.
When you get the connectionDestroyed event with the reason as networkDisconnected, it means that there was a network issue and the attempts to reconnect failed. The JS SDK tries to reconnect 5 times over 30 seconds when it detects a loss of connection. This is why you're seeing the delay in receiving the connectionDestroyed event.
To know if the JS SDK is trying to reconnect, you can listen for the following events:
session.on(
sessionReconnecting: () => {
//
},
sessionReconnected: () => {
//
},
sessionDisconnected: () => {
//
}
);
For more information, please see the Automatic Reconnection guide.