Explore ways to reduce the occurrences of disconnects on wireless networks

[GoogleCodeExporter]

Currently, if BigBlueButton detects its network connection has dropped, it 
immediately disconnects the user and closes the session.  This ensures the user 
does not believe the client is still connected when, in fact, it's no longer 
receiving updates from the server.

The initial disconnect occurs from the red5 server after it fails to get a 
response from a heartbeat check for the client.  If not response (with a given 
threshold) is received, red5 disconnects the client, which triggers the client 
to close.

Explore if it's possible to adjust the thresholds and lower the frequency of 
disconnects on a wireless network without introducing performance (or delays) 
into the connection logic.

Original issue reported on code.google.com by ffdixon@gmail.com on 13 Feb 2014 at 1:46

[GoogleCodeExporter]

We are getting a lot of user complaints about this.  Could we have a "You are 
experiencing local network issues, please wait whilst we try to reconnect you"

Original comment by B...@speakserve.com on 20 Mar 2014 at 1:56

[GoogleCodeExporter]

Users of skype are familiar with the disconnect and reconnecting.  We'd love to 
have this feature in BigBlueButton as well.

There are four connections that the BigBlueButton client makes to red5

  1.  bbb-apps
  2.  bbb-sip
  3.  bbb-video
  4.  bbb-deskshare

There will always be a connection for the above (i.e. desktop stream waits for 
a message to display the desktop).

The BigBlueButton client is listening for disconnect events.  When Flash 
determines, within it's code, one of the connections has gone down, it raises a 
disconnect event *and* disconnects that connection from red5.  There are no 
finer-grain hooks to prevent flash from disconnecting the stream.

There are a number of ways for a disconnect event to occur

 1. 'end' meeting API request came in
 2. The user clicks 'logout'
 3. Network configuration change on the client
 4. red5 does not receive a reply to its ping (heartbeat)

Given additional logic in the client, we could detect (1), (2), and (3) -- the 
question then is what to do with the disconnect event. 

The challenge is to recover from the event in a way that let's the user quickly 
resume collaboration *and* leaves the client in a correct state going forward.

At the moment, if bbb-apps closes, we notify the user that a disconnect event 
has occurred and close all four connections.  The client has logged out.  The 
user, at this point, can click the browser's refresh button and join anew.  

If bbb-sip, bbb-video, or bbb-deskshare connection closes, the client does 
continue with some notification to the user.  For bbb-sip, the headset icon 
will pop-up.  For bbb-video or bbb-deskshare, since there is no user operation 
to subscribe to the stream, the video (webcam or desktop) freezes.  

Lots of moving pieces with definitely more work needed.

Original comment by ffdixon@gmail.com on 20 Mar 2014 at 2:52

[GoogleCodeExporter]

Pings are often blocked. How can disconnects then be prevented?

Original comment by d.vanrossum on 14 Apr 2015 at 10:27

[GoogleCodeExporter]

We can't prevent disconnects at the operating system level.  The best approach 
is to modify BigBlueButton so that when the wireless network does disconnect, 
the client should attempt to automatically reconnect.

Also, there is a difference in the behaviour between FireFox and Chrome.  If 
the user is connected to both a wired network (primary interface) and wireless 
network, and if the wireless network changes state, Chrome will disconnect 
BigBlueButton but FireFox will not.

We recommend a wired connection with BigBlueButton.  If a user is experiencing 
frequent disconnects because another network adaptor is changing state, FireFox 
will be more stable.

Original comment by ffdixon@gmail.com on 14 Apr 2015 at 11:54