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]
