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]
