[Opensim-dev] Update for group module & flotsam

[Michelle Argus]

Yes, in the long run we will need a major overhaul of the groups module 
which also should include possible security issues. It will however 
break the simiangrid grou module which is also in core. My approach was 
more to get a simple implementation which then gives us time for a full 
scale overhaul...

Anyway, my overhaul thoughts...

1)Online status

  Requesting the online status via the gridservices only is not a good 
solution, as that takes more time than sending IMs to every groupmember 
(my first approach for a quickfix). It would also require each simulator 
to request online status for each groupmember which means lots of trafic 
between group server and then lots of trafic to the gridservices. This 
also applies if someone is just viewing the groupmember were we want to 
see all groupmembers nomatter if they are online or offline.

  We thus need to keep track of the online members in the database of 
the group server. When sending a chat/notice each simulator then 
receives a short list of online members. When listing all groupmembers 
we get all online/offline status.

  The same applies for the last loggin time which needs to be saved in 
the group server database aswell. In combination with a cache one then 
could run a query on who has logged in since the last IM/notice sent. 
One then would receive a very very short list of new members to add to 
already known online agent list.


  Updating the online and last login data would best be done by the 
gridservices instead of the local simulators. No matter who updates the 
online status, it becomes tricky in open grids were some simulators have 
their own group server running instead of using the grids default. This 
would be a case were tracking the online status from the gridservices 
via the simulator would make sence.

2) Database

  I would suggest that we add a field to the osgroupmembership table 
which shows who may receive IMs and notices. This way we just need the 
osgent and osgroupmembership tables when requesting the groupmembers 
that will receive IMs/notices without to many joins. When group role 
changes are done, then these fields would need to be updated depending 
on the permissions set.

  Then we also need many more specialized quaries. I think for each 
group tag we will need other data instead of always sending everything. 
One should not limit GetGroupMembers to just IM, Notices  and 
everything, each Grouptab requires diffrent data. (list all members, 
role members, role member permissions, IM members, notice members etc.)

3) Cache

  The cache should be shareable by multiple simulators running on 1 
server. Even with a cache we should check the current online users for 
members which have come online since the last IM that was sent.

4) Security

  The group module has some security issues because it is open to 
everyone who has the ini settings. I am taking advantage of this to 
manage my entire support groups via web without running a simulator. The 
danger here is, that anyone can manage all groups, which includes adding 
members, removing members, changing role permissions etc etc.

  Here one could use the online/offline status again to make sure that 
the agent is online as these changes actualy should be done via a 
viewer. Maybe also a unique session ID should be added. If the session 
ID and online status do not match, then no  changes are made. If the 
group server receives the data from the gridservices instead of the 
simulator it would be more difficult to manipulate.

As we do love the openess of opensim, one could add an extra password to 
each group which allows external applications to gain full control over 
that specific group. This could be done by an OSSL function which 
enables setting the password by a groupowner that is online. A  external 
application would then send that password in its quary. Actually, even 
OSSL function like osInviteToGroup & osEjectFromGroup should have 
aditional security measures implemented.

  5) Other unimplemeted goodies

  If the group module gets a total overhaul, we should also have a list 
of unimplemented things which might affect any changes done or any 
changes which additionaly will have an impact.

Currebtly unimplemented are:
- Attachments in group notices
- donated Tier, eg. settable via new ossl
- pruning of Archive, could optionaly be a ossl function for group owners
- proposals
- land and money (Land could use the search module which already stores 
the neccessary parcel information)

Michelle

Am 05.10.2012 18:35, schrieb Kevin Cozens:
> On 12-10-03 12:00 PM, Michelle Argus wrote:
>> - added agents online status to flotsam
>> - added agents last login data to flotsam
>> - displaying the online/last login data in the groupmembers list 
>> viewerside
>> - added optional filter to get a memberlist of online members only 
>> instead
>> of allways receiving all groupmembers
>> - send groupchat IMs only to online members.
>>
>> The changes can be found in the 2 gits here: 
>> https://github.com/MAReantals
>
> Nice to see some missing functionality added. Sending group messages 
> to avatars that are not on line was clearly a bug that needed fixing.
>
> The proposed changes started me thinking about the groups code and 
> wondering if there were other areas of the code that could be written 
> differently to minimize chat lag. What I have seen so far makes me 
> realize there are a number of ways the overall groups code can be 
> improved. I'll start with some comments about online status in groups 
> before I get to the main areas where improvements can be made.
>
> Having an online status in the groups database raises the question as 
> to whether it might get out of sync with an avatars real online status 
> but this may not be much of a problem. A status of online could be 
> forced when an avatar opens a group chat window. Offline status could 
> be set on a failure to send a group chat message fails (and determines 
> user is offline?).
>
> The updated group code adds OnClientClosed handler to check and update 
> an avatars online status. Does OnClientClosed get called on TP to a 
> different region or on sim boundary crossings? If it is called at 
> times other than during login/logout it should check if the avatars 
> status has changed before issuing the database update call as that is 
> an "expensive" call involving an external web server to update the 
> group database.
>
> The preceeding items are minor issues. Now for the bigger issues.
>
> I was surprised (almost shocked) to find that a call is made to 
> GetGroupMembers() for *every* chat message that is to be sent. [It is 
> also called when sending group notices.]
>
> If that doesn't sound bad enough it gets worse when you realize what 
> is involved. The C# code invokes a PHP script on a webserver to query 
> a database to get the list of members. The PHP code uses a complex SQL 
> query that contains 3 JOIN's and one LEFT JOIN. To top it all off, 
> once it has the list of members the PHP code then runs another query 
> to get group permissions for each member.
>
> The SQL query with the JOIN's makes one question the design of the 
> group database tables. I think it is more likely that it is trying to 
> return more data than is required when determining which avatars 
> should receive a group chat message or notice.
>
> I think the first thing to do is create a new function to get online 
> group members that returns the minimum amount of data required to send 
> chat and notices. I don't think that should involve more than two 
> tables versus the three currently used. It could be done with one but 
> the second table is needed to see if the member is online. If there is 
> a simpler/faster way for the group .cs code to check if a user is 
> online given an avatar UUID that doesn't require an external database 
> check that would be better. The online status wouldn't be needed in 
> the groups database, the list of members could be filtered in the .cs 
> code so only online members get chat/notices.
>
> The next(?) step would be to do the SQL queries from inside the C# 
> code and eliminate the need for the use of a webserver and the PHP code.
>
> A more complex solution to reducing overhead and lag in group chat is 
> to set up a cache to hold the online group member data to avoid 
> multiple requests to an external webserver on each message.
>
> The other question to be asked is if the group code is in anyway 
> threaded? Can it handle multiple chat messages at the same time or is 
> it sequential and processing only one message at at time? Is the group 
> module a bottle neck when people are chatting in several groups at the 
> same time?
>
> One last issue remains. How do we test changes to the group chat code? 
> A test bed is needed to allow simulation of a large number of people 
> chatting in several groups at the same time.
>
> I have suggested working on the group module as a possible first 
> project for the #metaversity people. It is self-contained enough to be 
> a good first project as it doesn't need a lot of broad knowledge of 
> the overall code base, not to mention the amount of "bang for the 
> buck" as it is of benefit to anyone using group chat.
>