You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@openmeetings.apache.org by Artyom Horuzhenko <ak...@gmail.com> on 2013/06/07 09:23:05 UTC

Leaving room after reconnection

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.

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

I cannot reproduce the issue with latest revision anymore.

Sebastian


2013/6/10 seba.wagner@gmail.com <se...@gmail.com>

> Thanks,
>
> I submit something later today.
>
> Sebastian
> Am 10.06.2013 14:58 schrieb "Maxim Solodovnik" <so...@gmail.com>:
>
> I'll try to fix it after my vacation :)
>> Could you please file an issue?
>>
>>
>> On Mon, Jun 10, 2013 at 11:55 AM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> 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" <so...@gmail.com>:
>> >
>> > > +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, seba.wagner@gmail.com <
>> > > seba.wagner@gmail.com> 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 <ak...@gmail.com>
>> > > >
>> > > > > 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 пользователь "seba.wagner@gmail.com" <
>> > > > > seba.wagner@gmail.com>
>> > > > > написал:
>> > > > > >
>> > > > > > 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 <al...@gmail.com>
>> > > > > >
>> > > > > > > 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, seba.wagner@gmail.com
>> > > > > > > <se...@gmail.com> 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 <ak...@gmail.com>
>> > > > > > > >
>> > > > > > > >> 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
>> > > > > > > > seba.wagner@gmail.com
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Sebastian Wagner
>> > > > > > https://twitter.com/#!/dead_lock
>> > > > > > http://www.webbase-design.de
>> > > > > > http://www.wagner-sebastian.com
>> > > > > > seba.wagner@gmail.com
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Sebastian Wagner
>> > > > https://twitter.com/#!/dead_lock
>> > > > http://www.webbase-design.de
>> > > > http://www.wagner-sebastian.com
>> > > > seba.wagner@gmail.com
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > 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
seba.wagner@gmail.com

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

Thanks,

I submit something later today.

Sebastian
Am 10.06.2013 14:58 schrieb "Maxim Solodovnik" <so...@gmail.com>:

> I'll try to fix it after my vacation :)
> Could you please file an issue?
>
>
> On Mon, Jun 10, 2013 at 11:55 AM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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" <so...@gmail.com>:
> >
> > > +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, seba.wagner@gmail.com <
> > > seba.wagner@gmail.com> 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 <ak...@gmail.com>
> > > >
> > > > > 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 пользователь "seba.wagner@gmail.com" <
> > > > > seba.wagner@gmail.com>
> > > > > написал:
> > > > > >
> > > > > > 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 <al...@gmail.com>
> > > > > >
> > > > > > > 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, seba.wagner@gmail.com
> > > > > > > <se...@gmail.com> 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 <ak...@gmail.com>
> > > > > > > >
> > > > > > > >> 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
> > > > > > > > seba.wagner@gmail.com
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sebastian Wagner
> > > > > > https://twitter.com/#!/dead_lock
> > > > > > http://www.webbase-design.de
> > > > > > http://www.wagner-sebastian.com
> > > > > > seba.wagner@gmail.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sebastian Wagner
> > > > https://twitter.com/#!/dead_lock
> > > > http://www.webbase-design.de
> > > > http://www.wagner-sebastian.com
> > > > seba.wagner@gmail.com
> > > >
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: Leaving room after reconnection

Posted by Maxim Solodovnik <so...@gmail.com>.

I'll try to fix it after my vacation :)
Could you please file an issue?


On Mon, Jun 10, 2013 at 11:55 AM, seba.wagner@gmail.com <
seba.wagner@gmail.com> 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" <so...@gmail.com>:
>
> > +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, seba.wagner@gmail.com <
> > seba.wagner@gmail.com> 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 <ak...@gmail.com>
> > >
> > > > 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 пользователь "seba.wagner@gmail.com" <
> > > > seba.wagner@gmail.com>
> > > > написал:
> > > > >
> > > > > 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 <al...@gmail.com>
> > > > >
> > > > > > 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, seba.wagner@gmail.com
> > > > > > <se...@gmail.com> 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 <ak...@gmail.com>
> > > > > > >
> > > > > > >> 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
> > > > > > > seba.wagner@gmail.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sebastian Wagner
> > > > > https://twitter.com/#!/dead_lock
> > > > > http://www.webbase-design.de
> > > > > http://www.wagner-sebastian.com
> > > > > seba.wagner@gmail.com
> > > >
> > >
> > >
> > >
> > > --
> > > Sebastian Wagner
> > > https://twitter.com/#!/dead_lock
> > > http://www.webbase-design.de
> > > http://www.wagner-sebastian.com
> > > seba.wagner@gmail.com
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>



-- 
WBR
Maxim aka solomax

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

@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" <so...@gmail.com>:

> +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, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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 <ak...@gmail.com>
> >
> > > 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 пользователь "seba.wagner@gmail.com" <
> > > seba.wagner@gmail.com>
> > > написал:
> > > >
> > > > 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 <al...@gmail.com>
> > > >
> > > > > 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, seba.wagner@gmail.com
> > > > > <se...@gmail.com> 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 <ak...@gmail.com>
> > > > > >
> > > > > >> 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
> > > > > > seba.wagner@gmail.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sebastian Wagner
> > > > https://twitter.com/#!/dead_lock
> > > > http://www.webbase-design.de
> > > > http://www.wagner-sebastian.com
> > > > seba.wagner@gmail.com
> > >
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: Leaving room after reconnection

Posted by Maxim Solodovnik <so...@gmail.com>.

I have added login by 2 additional parameters:
wicketsid, wicketroomid
if both specified loginWicket method is used to login the user
getRoomById is used to load the room

It was hard for me to choose which way it might me implemented, so I have
added my own mechanism to avoid conflicts.


On Mon, Jun 10, 2013 at 1:41 PM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:

> ... room enter by given SID* simply by SID will not work
> => will of course work, but what I meant was:
> It will not work without connecting to the default scope as the roomid is
> needed for the URL.
>
> Sebastian
>
>
> 2013/6/10 seba.wagner@gmail.com <se...@gmail.com>
>
> *I have added additional method*
>> What is this additional method or mechanism ?
>>
>> *What I need is: room enter by given SID* simply by SID will not work.
>> Cause the URL contains the $roomId. Otherwise the SWF has to get the ROOMId
>> by doing a RTMP call. But that would mean it has to connect to the default
>> RTMP connection first.
>> So this is not possible. Simply use the scopeRoomId parameter.
>>
>> Sebastian
>>
>>
>> 2013/6/10 Maxim Solodovnik <so...@gmail.com>
>>
>>> - room enter: Most probably you are right :( I'm not really good in all
>>> those "room enter" methods so I have added additional method
>>> I would really appreciate the help in this.
>>> What I need is: room enter by given SID and room id with exit button
>>> visible :) (so the user entered is treated as "normal" OM user, not
>>> external)
>>>
>>> - room close: I have added JS call handling removing of room from the
>>> DOM or just replacing the DOM "the room" element with room list element.
>>>
>>>
>>> On Mon, Jun 10, 2013 at 12:37 PM, seba.wagner@gmail.com <
>>> seba.wagner@gmail.com> wrote:
>>>
>>>> Quote:
>>>> *Additionally things are simplier in 3.0:
>>>> - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1)*
>>>>
>>>> => This is not true. There is such a mechanism, however currently 3.0
>>>> does not use it. So it will first connect to the scope "hibernate" and then
>>>> to the scope "$roomId".
>>>> However it could be reworked to work like you describe. There is a
>>>> param "scopeRoomId", if that is specified it will directly connect to the
>>>> scope of the room instead of going to hibernate. However there is end the
>>>> end always a check:
>>>> It will request the conference session object from the user and compare
>>>> the roomId with the scopeRoomId, if that test is OK it will directly
>>>> connect to the $roomId, if that test fails, it will connect to the scope
>>>> hibernate and use the "normal" mechanism to get the $roomId and build an
>>>> URL with it. This check is mainly for security reasons, so that by just
>>>> manipulating the URL, the user can gain access to random rooms.
>>>>
>>>> *- Room leave just removes div with embedded flash from the DOM and
>>>> displays
>>>> main interface (use case 2)*
>>>> => Again, it could be done like that but I am not sure if it currenlty
>>>> really does.
>>>>
>>>> Sebastian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2013/6/10 Maxim Solodovnik <so...@gmail.com>
>>>>
>>>>> +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, seba.wagner@gmail.com <
>>>>> seba.wagner@gmail.com> 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 <ak...@gmail.com>
>>>>> >
>>>>> > > 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 пользователь "seba.wagner@gmail.com" <
>>>>> > > seba.wagner@gmail.com>
>>>>> > > написал:
>>>>> > > >
>>>>> > > > 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 <al...@gmail.com>
>>>>> > > >
>>>>> > > > > 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, seba.wagner@gmail.com
>>>>> > > > > <se...@gmail.com> 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 <ak...@gmail.com>
>>>>> > > > > >
>>>>> > > > > >> 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
>>>>> > > > > > seba.wagner@gmail.com
>>>>> > > > >
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > --
>>>>> > > > Sebastian Wagner
>>>>> > > > https://twitter.com/#!/dead_lock
>>>>> > > > http://www.webbase-design.de
>>>>> > > > http://www.wagner-sebastian.com
>>>>> > > > seba.wagner@gmail.com
>>>>> > >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Sebastian Wagner
>>>>> > https://twitter.com/#!/dead_lock
>>>>> > http://www.webbase-design.de
>>>>> > http://www.wagner-sebastian.com
>>>>> > seba.wagner@gmail.com
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

... room enter by given SID* simply by SID will not work
=> will of course work, but what I meant was:
It will not work without connecting to the default scope as the roomid is
needed for the URL.

Sebastian


2013/6/10 seba.wagner@gmail.com <se...@gmail.com>

> *I have added additional method*
> What is this additional method or mechanism ?
>
> *What I need is: room enter by given SID* simply by SID will not work.
> Cause the URL contains the $roomId. Otherwise the SWF has to get the ROOMId
> by doing a RTMP call. But that would mean it has to connect to the default
> RTMP connection first.
> So this is not possible. Simply use the scopeRoomId parameter.
>
> Sebastian
>
>
> 2013/6/10 Maxim Solodovnik <so...@gmail.com>
>
>> - room enter: Most probably you are right :( I'm not really good in all
>> those "room enter" methods so I have added additional method
>> I would really appreciate the help in this.
>> What I need is: room enter by given SID and room id with exit button
>> visible :) (so the user entered is treated as "normal" OM user, not
>> external)
>>
>> - room close: I have added JS call handling removing of room from the DOM
>> or just replacing the DOM "the room" element with room list element.
>>
>>
>> On Mon, Jun 10, 2013 at 12:37 PM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> Quote:
>>> *Additionally things are simplier in 3.0:
>>> - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1)*
>>>
>>> => This is not true. There is such a mechanism, however currently 3.0
>>> does not use it. So it will first connect to the scope "hibernate" and then
>>> to the scope "$roomId".
>>> However it could be reworked to work like you describe. There is a param
>>> "scopeRoomId", if that is specified it will directly connect to the scope
>>> of the room instead of going to hibernate. However there is end the end
>>> always a check:
>>> It will request the conference session object from the user and compare
>>> the roomId with the scopeRoomId, if that test is OK it will directly
>>> connect to the $roomId, if that test fails, it will connect to the scope
>>> hibernate and use the "normal" mechanism to get the $roomId and build an
>>> URL with it. This check is mainly for security reasons, so that by just
>>> manipulating the URL, the user can gain access to random rooms.
>>>
>>> *- Room leave just removes div with embedded flash from the DOM and
>>> displays
>>> main interface (use case 2)*
>>> => Again, it could be done like that but I am not sure if it currenlty
>>> really does.
>>>
>>> Sebastian
>>>
>>>
>>>
>>>
>>>
>>> 2013/6/10 Maxim Solodovnik <so...@gmail.com>
>>>
>>>> +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, seba.wagner@gmail.com <
>>>> seba.wagner@gmail.com> 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 <ak...@gmail.com>
>>>> >
>>>> > > 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 пользователь "seba.wagner@gmail.com" <
>>>> > > seba.wagner@gmail.com>
>>>> > > написал:
>>>> > > >
>>>> > > > 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 <al...@gmail.com>
>>>> > > >
>>>> > > > > 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, seba.wagner@gmail.com
>>>> > > > > <se...@gmail.com> 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 <ak...@gmail.com>
>>>> > > > > >
>>>> > > > > >> 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
>>>> > > > > > seba.wagner@gmail.com
>>>> > > > >
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > --
>>>> > > > Sebastian Wagner
>>>> > > > https://twitter.com/#!/dead_lock
>>>> > > > http://www.webbase-design.de
>>>> > > > http://www.wagner-sebastian.com
>>>> > > > seba.wagner@gmail.com
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Sebastian Wagner
>>>> > https://twitter.com/#!/dead_lock
>>>> > http://www.webbase-design.de
>>>> > http://www.wagner-sebastian.com
>>>> > seba.wagner@gmail.com
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

*I have added additional method*
What is this additional method or mechanism ?

*What I need is: room enter by given SID* simply by SID will not work.
Cause the URL contains the $roomId. Otherwise the SWF has to get the ROOMId
by doing a RTMP call. But that would mean it has to connect to the default
RTMP connection first.
So this is not possible. Simply use the scopeRoomId parameter.

Sebastian


2013/6/10 Maxim Solodovnik <so...@gmail.com>

> - room enter: Most probably you are right :( I'm not really good in all
> those "room enter" methods so I have added additional method
> I would really appreciate the help in this.
> What I need is: room enter by given SID and room id with exit button
> visible :) (so the user entered is treated as "normal" OM user, not
> external)
>
> - room close: I have added JS call handling removing of room from the DOM
> or just replacing the DOM "the room" element with room list element.
>
>
> On Mon, Jun 10, 2013 at 12:37 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> wrote:
>
>> Quote:
>> *Additionally things are simplier in 3.0:
>> - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1)*
>>
>> => This is not true. There is such a mechanism, however currently 3.0
>> does not use it. So it will first connect to the scope "hibernate" and then
>> to the scope "$roomId".
>> However it could be reworked to work like you describe. There is a param
>> "scopeRoomId", if that is specified it will directly connect to the scope
>> of the room instead of going to hibernate. However there is end the end
>> always a check:
>> It will request the conference session object from the user and compare
>> the roomId with the scopeRoomId, if that test is OK it will directly
>> connect to the $roomId, if that test fails, it will connect to the scope
>> hibernate and use the "normal" mechanism to get the $roomId and build an
>> URL with it. This check is mainly for security reasons, so that by just
>> manipulating the URL, the user can gain access to random rooms.
>>
>> *- Room leave just removes div with embedded flash from the DOM and
>> displays
>> main interface (use case 2)*
>> => Again, it could be done like that but I am not sure if it currenlty
>> really does.
>>
>> Sebastian
>>
>>
>>
>>
>>
>> 2013/6/10 Maxim Solodovnik <so...@gmail.com>
>>
>>> +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, seba.wagner@gmail.com <
>>> seba.wagner@gmail.com> 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 <ak...@gmail.com>
>>> >
>>> > > 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 пользователь "seba.wagner@gmail.com" <
>>> > > seba.wagner@gmail.com>
>>> > > написал:
>>> > > >
>>> > > > 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 <al...@gmail.com>
>>> > > >
>>> > > > > 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, seba.wagner@gmail.com
>>> > > > > <se...@gmail.com> 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 <ak...@gmail.com>
>>> > > > > >
>>> > > > > >> 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
>>> > > > > > seba.wagner@gmail.com
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Sebastian Wagner
>>> > > > https://twitter.com/#!/dead_lock
>>> > > > http://www.webbase-design.de
>>> > > > http://www.wagner-sebastian.com
>>> > > > seba.wagner@gmail.com
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Sebastian Wagner
>>> > https://twitter.com/#!/dead_lock
>>> > http://www.webbase-design.de
>>> > http://www.wagner-sebastian.com
>>> > seba.wagner@gmail.com
>>> >
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: Leaving room after reconnection

Posted by Maxim Solodovnik <so...@gmail.com>.

- room enter: Most probably you are right :( I'm not really good in all
those "room enter" methods so I have added additional method
I would really appreciate the help in this.
What I need is: room enter by given SID and room id with exit button
visible :) (so the user entered is treated as "normal" OM user, not
external)

- room close: I have added JS call handling removing of room from the DOM
or just replacing the DOM "the room" element with room list element.


On Mon, Jun 10, 2013 at 12:37 PM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:

> Quote:
> *Additionally things are simplier in 3.0:
> - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1)*
>
> => This is not true. There is such a mechanism, however currently 3.0 does
> not use it. So it will first connect to the scope "hibernate" and then to
> the scope "$roomId".
> However it could be reworked to work like you describe. There is a param
> "scopeRoomId", if that is specified it will directly connect to the scope
> of the room instead of going to hibernate. However there is end the end
> always a check:
> It will request the conference session object from the user and compare
> the roomId with the scopeRoomId, if that test is OK it will directly
> connect to the $roomId, if that test fails, it will connect to the scope
> hibernate and use the "normal" mechanism to get the $roomId and build an
> URL with it. This check is mainly for security reasons, so that by just
> manipulating the URL, the user can gain access to random rooms.
>
> *- Room leave just removes div with embedded flash from the DOM and
> displays
> main interface (use case 2)*
> => Again, it could be done like that but I am not sure if it currenlty
> really does.
>
> Sebastian
>
>
>
>
>
> 2013/6/10 Maxim Solodovnik <so...@gmail.com>
>
>> +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, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> 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 <ak...@gmail.com>
>> >
>> > > 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 пользователь "seba.wagner@gmail.com" <
>> > > seba.wagner@gmail.com>
>> > > написал:
>> > > >
>> > > > 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 <al...@gmail.com>
>> > > >
>> > > > > 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, seba.wagner@gmail.com
>> > > > > <se...@gmail.com> 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 <ak...@gmail.com>
>> > > > > >
>> > > > > >> 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
>> > > > > > seba.wagner@gmail.com
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Sebastian Wagner
>> > > > https://twitter.com/#!/dead_lock
>> > > > http://www.webbase-design.de
>> > > > http://www.wagner-sebastian.com
>> > > > seba.wagner@gmail.com
>> > >
>> >
>> >
>> >
>> > --
>> > Sebastian Wagner
>> > https://twitter.com/#!/dead_lock
>> > http://www.webbase-design.de
>> > http://www.wagner-sebastian.com
>> > seba.wagner@gmail.com
>> >
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

Quote:
*Additionally things are simplier in 3.0:
- Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1)*

=> This is not true. There is such a mechanism, however currently 3.0 does
not use it. So it will first connect to the scope "hibernate" and then to
the scope "$roomId".
However it could be reworked to work like you describe. There is a param
"scopeRoomId", if that is specified it will directly connect to the scope
of the room instead of going to hibernate. However there is end the end
always a check:
It will request the conference session object from the user and compare the
roomId with the scopeRoomId, if that test is OK it will directly connect to
the $roomId, if that test fails, it will connect to the scope hibernate and
use the "normal" mechanism to get the $roomId and build an URL with it.
This check is mainly for security reasons, so that by just manipulating the
URL, the user can gain access to random rooms.

*- Room leave just removes div with embedded flash from the DOM and displays
main interface (use case 2)*
=> Again, it could be done like that but I am not sure if it currenlty
really does.

Sebastian





2013/6/10 Maxim Solodovnik <so...@gmail.com>

> +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, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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 <ak...@gmail.com>
> >
> > > 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 пользователь "seba.wagner@gmail.com" <
> > > seba.wagner@gmail.com>
> > > написал:
> > > >
> > > > 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 <al...@gmail.com>
> > > >
> > > > > 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, seba.wagner@gmail.com
> > > > > <se...@gmail.com> 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 <ak...@gmail.com>
> > > > > >
> > > > > >> 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
> > > > > > seba.wagner@gmail.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sebastian Wagner
> > > > https://twitter.com/#!/dead_lock
> > > > http://www.webbase-design.de
> > > > http://www.wagner-sebastian.com
> > > > seba.wagner@gmail.com
> > >
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: Leaving room after reconnection

Posted by Maxim Solodovnik <so...@gmail.com>.

+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, seba.wagner@gmail.com <
seba.wagner@gmail.com> 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 <ak...@gmail.com>
>
> > 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 пользователь "seba.wagner@gmail.com" <
> > seba.wagner@gmail.com>
> > написал:
> > >
> > > 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 <al...@gmail.com>
> > >
> > > > 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, seba.wagner@gmail.com
> > > > <se...@gmail.com> 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 <ak...@gmail.com>
> > > > >
> > > > >> 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
> > > > > seba.wagner@gmail.com
> > > >
> > >
> > >
> > >
> > > --
> > > Sebastian Wagner
> > > https://twitter.com/#!/dead_lock
> > > http://www.webbase-design.de
> > > http://www.wagner-sebastian.com
> > > seba.wagner@gmail.com
> >
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

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 <ak...@gmail.com>

> 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 пользователь "seba.wagner@gmail.com" <
> seba.wagner@gmail.com>
> написал:
> >
> > 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 <al...@gmail.com>
> >
> > > 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, seba.wagner@gmail.com
> > > <se...@gmail.com> 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 <ak...@gmail.com>
> > > >
> > > >> 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
> > > > seba.wagner@gmail.com
> > >
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: Leaving room after reconnection

Posted by Artyom Horuzhenko <ak...@gmail.com>.

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 пользователь "seba.wagner@gmail.com" <se...@gmail.com>
написал:
>
> 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 <al...@gmail.com>
>
> > 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, seba.wagner@gmail.com
> > <se...@gmail.com> 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 <ak...@gmail.com>
> > >
> > >> 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
> > > seba.wagner@gmail.com
> >
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

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 <al...@gmail.com>

> 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, seba.wagner@gmail.com
> <se...@gmail.com> 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 <ak...@gmail.com>
> >
> >> 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
> > seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: Leaving room after reconnection

Posted by Alexei Fedotov <al...@gmail.com>.

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, seba.wagner@gmail.com
<se...@gmail.com> 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 <ak...@gmail.com>
>
>> 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
> seba.wagner@gmail.com

Re: Leaving room after reconnection

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.

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 <ak...@gmail.com>

> 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
seba.wagner@gmail.com