Feature Proposals/Improve Groups Service
From OpenSimulator
(→Proposal) |
|||
| 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 = |
Please see mailing-list e-mails [1], [2] and [5]. 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]. | ||
| Line 33: | Line 33: | ||
* Groups service has to cache extra information. | * Groups service has to cache extra information. | ||
* Cached information not reuseable by other services. | * 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). | ||
| − | == Alternatives == | + | == B) Alternatives == |
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. | 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. | ||
| Line 49: | Line 50: | ||
'''CONS''': | '''CONS''': | ||
| − | * Every group IM still requires an extra network call to GridUser services, though the results could be cached for a short period of time (e.g. 20 seconds). | + | * Every group IM still requires an extra network call to GridUser services via the simulator, though the results could be cached for a short period of time (e.g. 20 seconds). |
* Comparatively complex. | * 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. | * 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. | * 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) Alternatives == |
| + | |||
| + | Similar to Alternative B, the group service requests the login status of the members from the gridservices instead of the simulator. The group service could cache members login status for a short time to reduce requests made. | ||
| + | |||
| + | '''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 grouprelated 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. | ||
| + | * Other services could reuse | ||
| + | |||
| + | == D) Alternatives == | ||
| + | |||
| + | 4. alternative is, that the simulator only passes on the group message itself to the group server. The group server then sends the IM to all online group members. | ||
| + | |||
| + | The login status could be handled by the simulator, grid services or group service (see A, B and C). | ||
| + | |||
| + | '''PROS''': | ||
| + | |||
| + | * Central service | ||
| + | * Only one request is sent to the group service. | ||
| + | * The simulator does not need to send messages and saves resources on the simulator side. | ||
| + | * The group server can be ajusted better as its sole purpose is to manage the grouprelated work. | ||
| + | * Spam and illigal activity can be filtered gridwide. | ||
| + | |||
| + | '''CONS''': | ||
| + | |||
| + | * The grid management has to maintain the group server. | ||
| + | * Laws governing data protection and data security could be abused by gridmanagement. | ||
| + | * The group service requires client data to send the message to each groupmember | ||
| + | |||
| + | == E) Alternatives == | ||
| + | |||
| + | 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 is present in OpenSimulator git master as of git master 1937e5f on 2012-10-20. It can be enabled by setting | The alternative approach is present in OpenSimulator git master as of git master 1937e5f on 2012-10-20. It can be enabled by setting | ||
| Line 65: | Line 126: | ||
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. | 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. | ||
| − | + | = 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 | ||
Revision as of 13:30, 28 October 2012
Contents |
Date
October 2012
Status
In progress
Proposers
- Michelle Argus
- Justin Clark-Casey (justincc)
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.
A) Proposal
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).
B) Alternatives
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.
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.
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 the results could be cached for a short period of time (e.g. 20 seconds).
- 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) Alternatives
Similar to Alternative B, the group service requests the login status of the members from the gridservices instead of the simulator. The group service could cache members login status for a short time to reduce requests made.
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 grouprelated 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.
- Other services could reuse
D) Alternatives
4. alternative is, that the simulator only passes on the group message itself to the group server. The group server then sends the IM to all online group members.
The login status could be handled by the simulator, grid services or group service (see A, B and C).
PROS:
- Central service
- Only one request is sent to the group service.
- The simulator does not need to send messages and saves resources on the simulator side.
- The group server can be ajusted better as its sole purpose is to manage the grouprelated work.
- Spam and illigal activity can be filtered gridwide.
CONS:
- The grid management has to maintain the group server.
- Laws governing data protection and data security could be abused by gridmanagement.
- The group service requires client data to send the message to each groupmember
E) Alternatives
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 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.
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
