Sorry I get lost in that kind of discussion. Artyom started a vote, quote:
*I think in this case the functionality like this is useless, it should be removed at all or improved to allow users reconnect without leaving the room. I offer to vote about this thing: +1 fix leaving rooms 0 don't change anything -1 remove reconnection functionality at all* So what does +1 mean *fix leaving the room* ... what has that to do with what you say Alexei ?! In fact I don't think that there is anything to fix with that reconnect. And whatever Artyom proposed has nothing todo with fixing an user that lost the connection. About the *reconnect when user lost connection* feature: I think in another thread I tried to explain: When the connection is lost, simply reconnecting the rtmp-connection has _no_ meaning, as you don't know how long the user was away. You need to re-sync the whiteboard, the videos list, the list of participants and the list of current screensharing sessions. So in fact you can simply clean everything and re-login the user. The same the other way round, everybody that was in the room, will have to re-initialize the user that was lost. Simply connecting the rtmp-connection will just make the situation worse as it may look like *working* but in fact nothing really *works*. So I am sorry but from my point of view you mix things together that have nothing todo with each other: Reconnecting while leaving the room VS connection lost. Sebastian 2013/6/7 Alexei Fedotov <[email protected]> > I used the following arguments: > > 1. Skype tries to re-connect when the connection is lost (though it > works awfully). Why should not we? > 2. When one re-connects (doesn't matter how, maybe after the flash > crash), she should reappear in the place where she was before the > break. This simplifies reestablishing connection. I think this is > useful behavior. > > Combining two of these arguments we get "room reconnect" feature which > can potentially improve the user experience. > > This is close to the second variant, which is called the cluster > re-connect. > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Fri, Jun 7, 2013 at 12:47 PM, [email protected] > <[email protected]> wrote: > > Hallo Artyom, > > > > *We know that reconnection works somehow* > > > > Just to be _very_ clear. There is no such feature! > > > > There is a co-incident that may _look like_ a reconnect. > > > > The *feature* is that the flash clients does try to connect 3 times to > the > > rtmpconnection. > > This initial connection try out is _never_ cleared. So if your > connections > > gets lost (and you did not have initially the bad luck of using your 3 > > tries), the rtmp connection does reconnect. > > However this is just a funny co-incident. This was never the intend to > > re-connect the rtmp connection when it gets lost while the user is > already > > in the meeting. > > > > So what other types of *reconnect* are you refering to? > > There is one reconnect when the user leaves the room, that is when he > > switches the rtmp connection URL from: > > rtmp://host:port/openmeetings/$roomId > > to > > rtmp://host:port/openmeetings/hibernate (default channel) > > > > The same *re-connect* happens when he enters the room. He has to switch > > from the default/global scope to the room scope. > > > > There is no option to remove this functionality, if the user does not > > change the rtmp-connection he can never receive any messages and connect > to > > the streams of the conference room. > > This is the concept of streaming servers: > > If you want to connect to a particular room and receive update > > notifications of events of that room => Connect/Subscribe to that URL! > > Connecting/Subscribing to that URL cannot happen without a reconnect when > > you enter or leave the room. > > > > Btw: THis functionality is actually the basis for any kind of clustering > as > > the point where somebody enters and leaves the room is when it gets > > re-directed to another server. So without that reconnect, there is no > > clustering. > > > > So those are the different version of "reconnect" that currently exist. > > > > Can you please clarify what exactly you meant with *reconnecting*? What > > kind of reconnecting? > > And did you see the impact of your proposal? > > > > Thanks, > > Sebastian > > > > > > > > > > > > > > 2013/6/7 Artyom Horuzhenko <[email protected]> > > > >> Hello collegues, > >> > >> I want to discuss reconnection again and decide what should we do with > it. > >> We know that reconnection works somehow: users leave the room after > >> reconnection. I think in this case the functionality like this is > useless, > >> it should be removed at all or improved to allow users reconnect without > >> leaving the room. I offer to vote about this thing: > >> > >> +1 fix leaving rooms > >> 0 don't change anything > >> -1 remove reconnection functionality at all > >> > >> I made some experiments and suppose that reconnection can be fixed > without > >> global changes in code, but requires deep testing. Anyway, my vote is > +1. > >> > > > > > > > > -- > > Sebastian Wagner > > https://twitter.com/#!/dead_lock > > http://www.webbase-design.de > > http://www.wagner-sebastian.com > > [email protected] > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
