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]
