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]
