search

mconf / bigbluebutton

BigBlueButton is an open source web conferencing system for distance education
www.bigbluebutton.org
40 stars 33 forks source link

Close BBB port test connection #286

Open mconf-daileon opened 8 years ago

mconf-daileon commented 8 years ago

Author Name: Pedro Beschorner Marin (Pedro Beschorner Marin) Original Redmine Issue: 1784, http://dev.mconf.org/redmine/issues/1784 Original Date: 2015-10-02 Original Assignee: Pedro Beschorner Marin

When BBB connects it establish 3 essentials connections: BBB itself, video and deskshare. There is a fourth connection that we suppose to be a port test connection that is never closed. Try closing this connection after it's completely used.

mconf-daileon commented 8 years ago

Original Redmine Comment Author Name: Rafael Petersen (Rafael Petersen) Original Date: 2015-10-06T20:12:07Z

I have tryed to close the connection that is established in "...bigbluebutton-client/src/org/bigbluebutton/main/model/" regarding the PortTest connection.

Upon reading the code I have noticed that in more than one point (i.e. PortTest.as function netStatus, PortTestProxy.as function netStatusEventHandler ...) there are calls to @close();@ this test connection that seems to be completely ignored if not skipped.

I focused my fix implementation on closing this connection either by calling a @close();@ method (that should work and even dispatch a NetStatusEvent according to http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/NetConnection.html#connected). I added the @close();@ method in several different stages of the execution, and I have only sucessfully closed it before the other connections are even opened, which leads to unfunctional software, as those other connections (bbb, video, deskshare) will never be established.

After attempting to close the Port Testing connection in different scenarios and debugging the values of the connection attributes on the existing @close();@ methods I could verify that the command does not change the status of the connection, therefore never closing it, never leading to a timeout and never dispatching a NetStatusEvent (not that our listeners could reach at least).

I would need more instructions or at least some new testing and implementation directions to follow in order to start making progress on this task. So far all my assumptions and workaround attempts failed.