I cannot reproduce the issue with latest revision anymore. Sebastian
2013/6/10 [email protected] <[email protected]> > Thanks, > > I submit something later today. > > Sebastian > Am 10.06.2013 14:58 schrieb "Maxim Solodovnik" <[email protected]>: > > I'll try to fix it after my vacation :) >> Could you please file an issue? >> >> >> On Mon, Jun 10, 2013 at 11:55 AM, [email protected] < >> [email protected]> wrote: >> >> > @Maxim: Currently it does not take you back to the list of rooms. The >> url >> > seems to be right but it does not load the rooms. >> > >> > Sebastian >> > Am 10.06.2013 14:11 schrieb "Maxim Solodovnik" <[email protected]>: >> > >> > > +1 for displaying "Connection has been lost" >> > > >> > > Additionally things are simplier in 3.0: >> > > - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1) >> > > - Room leave just removes div with embedded flash from the DOM and >> > displays >> > > main interface (use case 2) >> > > >> > > >> > > On Mon, Jun 10, 2013 at 6:55 AM, [email protected] < >> > > [email protected]> wrote: >> > > >> > > > Hi Artyom, >> > > > >> > > > Quote: *When a user looses his connection he >> > > > get 3 attempts to reconnect. * >> > > > => Which is a funny co-incident. It should not do that, the 3 times >> try >> > > are >> > > > only for when you do your initial set up. It does try 3 times rtmp >> and >> > > then >> > > > switches to rtmpt. >> > > > >> > > > *If we don't, I offer to show user an error message without >> > reconnection >> > > > attempts because unexpected leaving the room looks as a bug.* >> > > > =>I agree. It should not even try a single time. There should be >> just >> > an >> > > > error message "Your lost the connection, please reload the >> > application". >> > > > That would be the correct behaviour. Everything else is just >> confusing, >> > > > cause at the moment it looks like it does some "auto-reconnect". But >> > > there >> > > > is no such feature. >> > > > The only thing to make sure is that room-leave and >> room(-re)-entering >> > > still >> > > > works correctly: >> > > > - Room enter disconnects from rtmp://xyz/openmeetings/hibernate to >> > > > rtmp://xyz/openmeetings/$roomId (use case 1) >> > > > - Room leave disconnects from rtmp://xyz/openmeetings/$roomId to >> > > > rtmp://xyz/openmeetings/hibernate (use case 2) >> > > > - If a user has rtmpt (you can test that by chaning the rtmp port >> to >> > > some >> > > > rubbish in the config.xml and clear your cache), then room enter and >> > > leaver >> > > > should still work the same _but_ using rtmpt instead of rtmp all the >> > > time. >> > > > (use case 3 [rtmpt-enter] and 4 [rtmpt-leave]) >> > > > >> > > > You can verify if everything works correctly if you goto >> > Administration > >> > > > Connections. If the re-connect on rooms leave is correct, then >> exiting >> > > and >> > > > re-entering a room with a user in another session will just >> increment >> > the >> > > > ID of the roomClient by : >> > > > Exiting the room +1, >> > > > Renering the room +2 (one time SWF8 rtmp connection +1, one time >> SWF11 >> > > > rtmp-connection +1) >> > > > If you just close your browser it does not increment the id by +1, >> just >> > > > closing your browser will just disconnect and send appropriate >> messages >> > > to >> > > > everybody. >> > > > >> > > > Administration > Connections is quite handy for development >> purpsose. >> > On >> > > > click of an entry you can see every session attribute in the >> > RoomClient. >> > > > You currently always see 2 entries per user as soon as he is in the >> > > > conference room. Every user has two separated rtmp connections, one >> for >> > > the >> > > > SWF8 legacy code and one for the "new" SWF11 container. SWF11 does >> > handle >> > > > all the Audio/Video stuff. SWF11 does only connect when you really >> need >> > > > Audio/Video. So only in the conference room and maybe in the >> recording >> > > > section. >> > > > >> > > > Maybe part of this information is redundant for you Artyom, however >> if >> > > you >> > > > have any further questions please let me know. >> > > > >> > > > Thanks, >> > > > Sebastian >> > > > >> > > > >> > > > 2013/6/7 Artyom Horuzhenko <[email protected]> >> > > > >> > > > > Sebastian, let me explain our trouble. When a user looses his >> > > connection >> > > > he >> > > > > get 3 attempts to reconnect. If all of the attempts are failed, >> the >> > > user >> > > > > sees an error message, otherwise - the user reconnects to >> dashboard. >> > We >> > > > are >> > > > > discussing idea about reconnecting to room again instead of >> > dashboard. >> > > I >> > > > > agree with you that whiteboard, userlist etc should be reloaded, >> but >> > I >> > > > want >> > > > > to know if we really need restoring connection. If we don't, I >> offer >> > to >> > > > > show user an error message without reconnection attempts because >> > > > unexpected >> > > > > leaving the room looks as a bug. >> > > > > 07.06.2013 13:28 пользователь "[email protected]" < >> > > > > [email protected]> >> > > > > написал: >> > > > > > >> > > > > > 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] >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Sebastian Wagner >> > > > https://twitter.com/#!/dead_lock >> > > > http://www.webbase-design.de >> > > > http://www.wagner-sebastian.com >> > > > [email protected] >> > > > >> > > >> > > >> > > >> > > -- >> > > WBR >> > > Maxim aka solomax >> > > >> > >> >> >> >> -- >> WBR >> Maxim aka solomax >> > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
