IMs and group IMs (was Re: [sldev] Frequent bugs with difficultrepros)

[Frans]

Wouldn't it be simpler and more reliable to just have. viewer -> distributed
chat module -> send member of the group. This would also allow you to keep
chatting even when you get disconnected from the sim.

-Frans

On Sun, Mar 2, 2008 at 8:37 PM, <jwolk at lindenlab.com> wrote:

> I'll chime in here with some information.  These are not excuses, just
> information.
>
> Double IMs, out of order IMs and other "strange" behaviors are bugs and
> the protocol used (UDP or TCP) does not guarantee will be successful or
> fail.  These bugs will hopefully be fixed at some point in the future, but
> these also have been happening for a long, long time even with the old
> centralized userserver and are very difficult to do in backwards
> compatible way.
>
> Synopsis:
>
> A centralized server is simpler, but in no way can scale and definitely is
> not a solution.  There are many problems with the current structure and
> the distributed chat module.  I hope to fix some design flaws in the
> distributed chat module sometime soon (TM) but some changes that would be
> needed to help group IM are very vast and none of which, much like the
> rest of SL, are easy.  Also, some of the group IM "features" that SL
> currently has (like "passively" joining group IM sessions when you log in)
> are strange and make the group IM work much harder than it really needs to
> be.
>
> Details:
>
> Now, some stuff about the userserver.  The userserver worked "better" in
> terms of group IM because it was centralized and did keep a persistent
> "connection" to all of the users logged into SL at any given moment.
> Therefore, if a group IM wanted to get delivered to someone, the
> userserver simply just sent an IM on a connection that it knew already
> existed.
>
> The code path used to be: viewer -> userserver -> (msg all members' in the
> group viewer)
>
> Unfortunately, as Kelly said, this way of keeping an active connection to
> every user probably wouldn't have made it past 6k concurrent users.
>
> Currently, only an SL region has an active connection to you and your
> viewer.  Therefore, all requests to and from your viewer *HAVE* to go
> through the region you're connected to and that region can change from
> time to time (when you region cross or teleport).
>
> Therefore, just in terms of code paths or the number of processes needed
> to send a message around, the current distributed architecture is much
> more complicated.
>
> viewer -> region -> distributed chat module -> (send to all regions which
> have a member of the group in them) -> have those region deliver to your
> viewer
>
> Therefore, if there is a problem with the region (being slow or
> overwhelmed) you're in or the regions the other members of the group are
> in there can be a problem sending the IM.  Also, if the chat module has a
> problem, there will be a problem sending the IM.  Also, the distributed
> chat module has to look up what region each of the members is in and send
> a message to them.  Basically, there are many more moving parts now than
> there were before.
>
> Now, I will be the first to say that the distributed chat module has some
> design flaws and there are some things that can be done in both the chat
> module and the general "flow" of group IMs that can be streamlined and
> fixed.  But these changes are hard, especially when being made in a
> backwardly compatible way.
>
> -Jonathan Linden
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>



-- 
Jeroen Frans
The Vesuvius Group
http://www.thevesuviusgroup.com
http://www.linkedin.com/in/mrfrans
SL: Frans Charming
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080303/04e15713/attachment.htm