Reduce reconnection backoff

[debuglevel]

trafficstars

Describe the bug When the connection is lost, BBB has an exponential(?) backoff to prevent reconnecting too fast:

• backoff n: ? seconds
• backoff n+1: 63 seconds
• backoff n+2: 98 seconds
• backoff n+3: 291 seconds [255 -> 401]

While this feature makes sense in other places (like in a microservice architecture to prevent thousands of clients to DDoS an already overloaded server), but IMHO this is not too useful in a real-time application. The user usually wants to attend the meeting as fast as possible again. At the latest, a 291 seconds delay after a few minutes really does not make sense anymore and users will probably just hit F5 - which ends in a even more unfavorable situation because now they are stuck on their browsers "sorry you are offline, but here is a cute dinosaur" screen.

I can imagine two cases when this occurs:

• Something went wrong on the client side. Probably the most common case. IMHO no need for backoff.

• Something went wrong on the server side. Should happen rarely. But I guess in this case, everything is lost after all, because BBB terminates the session soon because nobody is in the meeting anymore and it has to be started again.

• Idea 1: Just set this to e.g. 10 seconds.

• Idea 2: Send an inexpensive ping request to figure out whether we can connect to this BBB server. Do this every second. Reconnect once we are back online.

• Idea 3: Is there a browser function to get the connectivity state? https://developer.mozilla.org/en-US/docs/Web/API/Navigator/onLine sounds rather unreliable however (see also https://stackoverflow.com/questions/189430/detect-the-internet-connection-is-offline)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[debuglevel]

I just tried this again with BBB 2.7:

• i=1: 6 secs
• i=2: 9 secs
• i=3: 23 secs
• i=4: 45 secs
• i=5: 91 secs
• i=6: 220secs

While it seems that it does not increase as fast as before, it probably still increases exponentially which does not really seem to fit an end user application as it yields really big numbers after just a few retries.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[antobinary]

I believe this is quite different in BBB 3.0 but let's verify after #20485 is done.

[antobinary]

@Tainan404 is this still relevant in BBB 3.0.0-beta.1 +?

[Tainan404]

@Tainan404 is this still relevant in BBB 3.0.0-beta.1 +?

Nope, it was a feature of Meteor, now using graphql the amount of time is static (10sec I guess) and after X attempts the client stops trying and emits an error