openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: Leaving room after reconnection
Date Mon, 10 Jun 2013 06:41:29 GMT
... 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

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