openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Solodovnik <solomax...@gmail.com>
Subject Re: Leaving room after reconnection
Date Mon, 10 Jun 2013 10:24:40 GMT
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 <seba.wagner@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 <solomax666@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 <solomax666@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 <akhor666@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 <alexei.fedotov@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
>>>>> > > > > <seba.wagner@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 <akhor666@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message