Feature Proposals/Improve Groups Service

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(→‎Alternatives)
(→‎Status)
 
(26 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
October 2012
 
October 2012
  
−
= Status (draft, in progress, done or abandoned) =
+
= Status =
  
 
In progress
 
In progress
Line 16: Line 16:
 
This may encompass many improvements to groups, but the first is to cache login information in groups to improve group IM, such that an IM isn't sent to every single user, even those offline.
 
This may encompass many improvements to groups, but the first is to cache login information in groups to improve group IM, such that an IM isn't sent to every single user, even those offline.
  
−
= Proposal =
+
= A) Proposal - Simulator tells group service about user login/logout =
  
−
Please see mailing-list e-mails [1] and [2].  The changes for OpenSimulator and XmlRpcGroups are in [3] and [4].
+
Please see mailing-list e-mails [1], [2] and [5].  The changes for OpenSimulator and XmlRpcGroups are in [3] and [4].
  
 
These changes send login status information and time to the groups service from the simulator.  This allows an extra 'offline' parameter to be passed to GetGroupMembers to control whether all or only online members of a group are returned.
 
These changes send login status information and time to the groups service from the simulator.  This allows an extra 'offline' parameter to be passed to GetGroupMembers to control whether all or only online members of a group are returned.
  
−
'''PROS''': Only a single network call (which may be cached for a period) required on each group IM.  Reasonably simple.  May allow messaging across multiple OpenSimulator installations.
+
'''PROS''':  
  
−
'''CONS''': Extra calls to groups service on each login/logout.  Groups service has to cache extra information.  Cached information not reuseable by other services.
+
* Only a single network call (which may be cached for a period) required on each group IM.   
 +
* Reasonably simple.   
 +
* May allow messaging across multiple OpenSimulator installations.
  
−
== Alternatives ==
+
'''CONS''':
  
−
One alternative is for the simulator itself to call GridUserService.LoggedIn for each member of the group on each IM.  However this has a very high overhead with large groups.
+
* Extra calls to groups service on each login/logout.   
 +
* Groups service has to cache extra information. 
 +
* Cached information not reuseable by other services.
 +
* Accuracy of login status is dependant on groupsettings of each simulator within a grid (multiple groups possible in open grids like OSGrid).
  
−
It may be possible to improve this by adding a new GridUserService call that accepts a list of UUIDs and only returns information for those which are logged in.  However, this would need to be called for each group IM, unless this was cached for short periods of time.
+
= Alternatives =
  
−
'''PROS''': Services don't need to their own login caching.  Other services can also use the same simulator-side code and data. 
+
== B) Simulator queries presence service on IM ==
  
−
'''CONS''': Every group IM still requires an extra network call to GridUser services, though possibly the results could be cached for a short period of time (e.g. 1 min).  Comparatively complex.
+
One alternative is for the simulator to fetch group information and then query which group members are online when an IM is sent to a group.
  
−
== References ==
+
'''This is current implemented as an experimental option (see status section below).'''
 +
 
 +
'''PROS''':
 +
 
 +
* Groups service doesn't need to handle online status.
 +
* One source of online status truth that cannot become inconsistent with information cached in the groups service. 
 +
* Other services can also use the same simulator-side group users online caching, though this may not be a big factor.
 +
* Groups service data can be backed up without any possible worries about inconsistent online status if it needs to be restored.
 +
 
 +
'''CONS''':
 +
 
 +
* Every group IM still requires an extra network call to GridUser services via the simulator, though this would be mitigated by short-term caching. 
 +
* Comparatively complex. 
 +
* If code external to OpenSimulator wanted to know online users for a group, it would have to call Presence service (and possibly cache information) itself rather than just being able to query the groups service.
 +
* Inconsistency between presence service and groups service online information may not be important - possibly the worst that could happen is some users do not receive group members until they relog.
 +
 
 +
== C) Groups services queries presence service on members online request ==
 +
 
 +
Similar to Alternative B, the group service requests the login status of the members from the gridservices instead of the simulator.  Like the original proposal, this requires modifications to the groups service interface to add a "request users online only" bool.
 +
 
 +
'''PROS''':
 +
 
 +
* Simulator doesn't need to handle online status.
 +
* One source of online status truth that cannot become inconsistent with information cached in the groups service. 
 +
* Groups service data can be backed up without any possible worries about inconsistent online status if it needs to be restored.
 +
* Fast data connection between grid and group server
 +
* All group related services can use the login data
 +
 
 +
'''CONS''':
 +
 
 +
* Every group IM still requires an extra network call to GridUser services via the group service, though the results could be cached for a short period of time (e.g. 20 seconds). 
 +
* Comparatively complex. 
 +
* Inconsistency between presence service and groups service online information may not be important - possibly the worst that could happen is some users do not receive group members until they relog.
 +
 
 +
== D) Groups service distributes IM ==
 +
 
 +
Instead of distributing the message itself, the simulator passes the group IM data on to the groups service.  The groups service handles message distribution to group members.
 +
 
 +
The login status could be handled by the simulator, grid services or group service (see A, B and C).
 +
 
 +
'''PROS''':
 +
 
 +
* Central service, which makes for easier management.
 +
* Only one request is sent to the group service - ''How is this a pro?  We are already sending only one request to the groups service on each IM with the other options [[User:Justincc|Justincc]] 03:14, 8 November 2012 (UTC)'' ''The Simulator request currently requests the members, then it requests online status and then it sends the IMs. We currently have atleast 3 request. If the IM is passed on, then the simulator makes only 1 request, while the IM service handles the other requests [[User:Michelle Argus|Michelle Argus]] 15 November 2012''
 +
* Message sending load is removed from the simulator.
 +
* The group server can be ajusted better as its sole purpose is to manage the grouprelated work ''Could you elaborate? [[User:Justincc|Justincc]] 03:15, 8 November 2012 (UTC)'' ''A Simulator has to deal with many things eg. physics, scriptengine etc and thus the server has a more general setup sothat everything works. The less funktions a simulator has to run, the better one can fine tune the server setup for each of those funktion. Same also aplies for a IM service[[User:Michelle Argus|Michelle Argus]]''
 +
* Spam and illegal activity can be filtered gridwide.
 +
 
 +
'''CONS''':
 +
 
 +
* Load on the group service is significantly increased as the load of group IM sending is now concentrated at the service rather than distributed among simulators.
 +
* Laws governing data protection and data security could be abused by grid management.  ''Not sure this is a strong reason, as this could already be captured at simulator level.  However, privacy concerns are worth mentioning. [[User:Justincc|Justincc]] 03:17, 8 November 2012 (UTC)'' ''In open grids the grid management has no control over what module is used/modded by the simulator hoster. [[User:Justincc|Michelle Argus]] 15 November 2012''
 +
* The group service requires client data to send the message to each groupmember. ''Well, this is only true if you try to start sending directly to viewers.  At the moment, messages are sent on to the simulator they occupy for forwarding.  The data would be fetched by the same mechanisms that the simulator's currently use to distribute group IMs. [[User:Justincc|Justincc]] 03:19, 8 November 2012 (UTC)'' ''In the case of D the IM service the IMs are not sent by a simulator and communication between simulator and IM service should be kept at its absolute minimum to prevent any possible lag that could be caused simulatorside, eg. slow requests [[User:Michelle Argus|Michelle Argus]] 15 November 2012''
 +
 
 +
== E) Separate group IM relay service ==
 +
 
 +
The login status could be handled by the grid services or group service (see B and C). The group messages can optionaly be sent by the simulator or via a "relay" service which send the message to the members. The relay service receives the group member list from the central group service. The relay service can additionaly cache data
 +
 
 +
'''PROS''':
 +
 
 +
* Multiple relay service could be in use worldwide and minimize slow requests
 +
* Requests to the group service is minimized due to cache of each relay service.
 +
* Hosters of multiple regions can optimize their own relay service to their needs within their datacenter
 +
* The simulator does not need to send messages and saves resources on the simulator side(optional). 
 +
* Each relay can offer filters for spam and illigal activity which meet local laws.
 +
* POC for other services such as assets, presence, inventory, friendslist and many more.
 +
 
 +
'''CONS''':
 +
 
 +
* The relay service requires client data to send the message to each groupmember
 +
* Requires trustworthy relay hoster.
 +
 
 +
 
 +
NB: The simulator could automaticaly receive the settings of the nearest trusted relay station from the grid service on simulator startup to minimize request to the central group service.
 +
 
 +
= Status =
 +
 
 +
The alternative approach B) is present in OpenSimulator git master as of git master 1937e5f on 2012-10-20.  It can be enabled by setting
 +
 
 +
<pre>
 +
[Groups]
 +
MessageOnlineUsersOnly = true
 +
</pre>
 +
 
 +
in OpenSim.ini (all the other groups config params need to be set and configured correctly).  More details on the parameter are in the [Groups] section of OpenSimDefaults.ini.  This is currently considered experimental and defaults to false.  This approach implements the temporary response caching mentioned in approach B.
 +
 
 +
= References =
  
 
[1] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011421.html
 
[1] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011421.html
Line 45: Line 136:
  
 
[4] https://github.com/MAReantals/flotsam
 
[4] https://github.com/MAReantals/flotsam
 +
 +
[5] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011434.html

Latest revision as of 12:35, 29 January 2013

Contents

[edit] Date

October 2012

[edit] Status

In progress

[edit] Proposers

  • Michelle Argus
  • Justin Clark-Casey (justincc)

[edit] Introduction

This may encompass many improvements to groups, but the first is to cache login information in groups to improve group IM, such that an IM isn't sent to every single user, even those offline.

[edit] A) Proposal - Simulator tells group service about user login/logout

Please see mailing-list e-mails [1], [2] and [5]. The changes for OpenSimulator and XmlRpcGroups are in [3] and [4].

These changes send login status information and time to the groups service from the simulator. This allows an extra 'offline' parameter to be passed to GetGroupMembers to control whether all or only online members of a group are returned.

PROS:

  • Only a single network call (which may be cached for a period) required on each group IM.
  • Reasonably simple.
  • May allow messaging across multiple OpenSimulator installations.

CONS:

  • Extra calls to groups service on each login/logout.
  • Groups service has to cache extra information.
  • Cached information not reuseable by other services.
  • Accuracy of login status is dependant on groupsettings of each simulator within a grid (multiple groups possible in open grids like OSGrid).

[edit] Alternatives

[edit] B) Simulator queries presence service on IM

One alternative is for the simulator to fetch group information and then query which group members are online when an IM is sent to a group.

This is current implemented as an experimental option (see status section below).

PROS:

  • Groups service doesn't need to handle online status.
  • One source of online status truth that cannot become inconsistent with information cached in the groups service.
  • Other services can also use the same simulator-side group users online caching, though this may not be a big factor.
  • Groups service data can be backed up without any possible worries about inconsistent online status if it needs to be restored.

CONS:

  • Every group IM still requires an extra network call to GridUser services via the simulator, though this would be mitigated by short-term caching.
  • Comparatively complex.
  • If code external to OpenSimulator wanted to know online users for a group, it would have to call Presence service (and possibly cache information) itself rather than just being able to query the groups service.
  • Inconsistency between presence service and groups service online information may not be important - possibly the worst that could happen is some users do not receive group members until they relog.

[edit] C) Groups services queries presence service on members online request

Similar to Alternative B, the group service requests the login status of the members from the gridservices instead of the simulator. Like the original proposal, this requires modifications to the groups service interface to add a "request users online only" bool.

PROS:

  • Simulator doesn't need to handle online status.
  • One source of online status truth that cannot become inconsistent with information cached in the groups service.
  • Groups service data can be backed up without any possible worries about inconsistent online status if it needs to be restored.
  • Fast data connection between grid and group server
  • All group related services can use the login data

CONS:

  • Every group IM still requires an extra network call to GridUser services via the group service, though the results could be cached for a short period of time (e.g. 20 seconds).
  • Comparatively complex.
  • Inconsistency between presence service and groups service online information may not be important - possibly the worst that could happen is some users do not receive group members until they relog.

[edit] D) Groups service distributes IM

Instead of distributing the message itself, the simulator passes the group IM data on to the groups service. The groups service handles message distribution to group members.

The login status could be handled by the simulator, grid services or group service (see A, B and C).

PROS:

  • Central service, which makes for easier management.
  • Only one request is sent to the group service - How is this a pro? We are already sending only one request to the groups service on each IM with the other options Justincc 03:14, 8 November 2012 (UTC) The Simulator request currently requests the members, then it requests online status and then it sends the IMs. We currently have atleast 3 request. If the IM is passed on, then the simulator makes only 1 request, while the IM service handles the other requests Michelle Argus 15 November 2012
  • Message sending load is removed from the simulator.
  • The group server can be ajusted better as its sole purpose is to manage the grouprelated work Could you elaborate? Justincc 03:15, 8 November 2012 (UTC) A Simulator has to deal with many things eg. physics, scriptengine etc and thus the server has a more general setup sothat everything works. The less funktions a simulator has to run, the better one can fine tune the server setup for each of those funktion. Same also aplies for a IM serviceMichelle Argus
  • Spam and illegal activity can be filtered gridwide.

CONS:

  • Load on the group service is significantly increased as the load of group IM sending is now concentrated at the service rather than distributed among simulators.
  • Laws governing data protection and data security could be abused by grid management. Not sure this is a strong reason, as this could already be captured at simulator level. However, privacy concerns are worth mentioning. Justincc 03:17, 8 November 2012 (UTC) In open grids the grid management has no control over what module is used/modded by the simulator hoster. Michelle Argus 15 November 2012
  • The group service requires client data to send the message to each groupmember. Well, this is only true if you try to start sending directly to viewers. At the moment, messages are sent on to the simulator they occupy for forwarding. The data would be fetched by the same mechanisms that the simulator's currently use to distribute group IMs. Justincc 03:19, 8 November 2012 (UTC) In the case of D the IM service the IMs are not sent by a simulator and communication between simulator and IM service should be kept at its absolute minimum to prevent any possible lag that could be caused simulatorside, eg. slow requests Michelle Argus 15 November 2012

[edit] E) Separate group IM relay service

The login status could be handled by the grid services or group service (see B and C). The group messages can optionaly be sent by the simulator or via a "relay" service which send the message to the members. The relay service receives the group member list from the central group service. The relay service can additionaly cache data

PROS:

  • Multiple relay service could be in use worldwide and minimize slow requests
  • Requests to the group service is minimized due to cache of each relay service.
  • Hosters of multiple regions can optimize their own relay service to their needs within their datacenter
  • The simulator does not need to send messages and saves resources on the simulator side(optional).
  • Each relay can offer filters for spam and illigal activity which meet local laws.
  • POC for other services such as assets, presence, inventory, friendslist and many more.

CONS:

  • The relay service requires client data to send the message to each groupmember
  • Requires trustworthy relay hoster.


NB: The simulator could automaticaly receive the settings of the nearest trusted relay station from the grid service on simulator startup to minimize request to the central group service.

[edit] Status

The alternative approach B) is present in OpenSimulator git master as of git master 1937e5f on 2012-10-20. It can be enabled by setting 

[Groups]
MessageOnlineUsersOnly = true

in OpenSim.ini (all the other groups config params need to be set and configured correctly). More details on the parameter are in the [Groups] section of OpenSimDefaults.ini. This is currently considered experimental and defaults to false. This approach implements the temporary response caching mentioned in approach B.

[edit] References

[1] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011421.html

[2] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011431.html

[3] https://github.com/MAReantals/opensim

[4] https://github.com/MAReantals/flotsam

[5] http://lists.berlios.de/pipermail/opensim-dev/2012-October/011434.html

Retrieved from "http://opensimulator.org/index.php?title=Feature_Proposals/Improve_Groups_Service&oldid=31690"
Personal tools
General
About This Wiki