Avatar portability version 2

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(→‎Answer to the 1st How - XRDS)
m (Robot: Cosmetic changes)
 
(23 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
__NOTOC__
 +
{{Quicklinks}}
 +
 +
{{proposal}}
 +
 
[[User:Lulurun]]
 
[[User:Lulurun]]
  
Line 6: Line 11:
 
There are 3 problems to be considered:
 
There are 3 problems to be considered:
 
# How to enable foreign user login - [[OpenID for data portability in virtual world|Authentication]]
 
# How to enable foreign user login - [[OpenID for data portability in virtual world|Authentication]]
−
# (If a foreign user can login)How to get a foreign user's belongings(including appearance, inventory)
+
# '''(If a foreign user can login)How to get a foreign user's belongings(including appearance, inventory)'''
 
#* '''This is discussed in this page'''
 
#* '''This is discussed in this page'''
−
# [[AvatarPortability - Security]]
+
# [[security vulnerability brought by non-check inventory service|Security]]
  
 
To achieve the 1st, client side changes are needed. SO, so far, I have
 
To achieve the 1st, client side changes are needed. SO, so far, I have
−
only implemented 2nd, and would like to explan my idea:
+
only implemented the 2nd and the 3rd, and would like to explan my idea:
  
 
== Basic Idea ==
 
== Basic Idea ==
  
 
=== definition ===
 
=== definition ===
−
*User U1 resgitered at GridService G1
+
* User U1 resgitered at GridService G1
 
** U1's inventory information is stored in InventoryServer I1
 
** U1's inventory information is stored in InventoryServer I1
 
** U1's assets are stored in AssetServer As1
 
** U1's assets are stored in AssetServer As1
 
** U1's appearance information is served by AvatarService Av1
 
** U1's appearance information is served by AvatarService Av1
  
−
*RegionServer R2 serves a sim at GridService G2
+
* RegionServer R2 serves a sim at GridService G2
 
** R2 fetches assets from Assetserver As2 by default.  
 
** R2 fetches assets from Assetserver As2 by default.  
 
** R2 gets inventory information from InventoryServer I2 by default.
 
** R2 gets inventory information from InventoryServer I2 by default.
−
[[Image:avatar_portability_v2_1.PNG]]
+
[[File:avatar_portability_v2_1.PNG]]
  
 
=== avatar portability ===
 
=== avatar portability ===
  
 
AvatarPortability (or called "grid interoperability") is
 
AvatarPortability (or called "grid interoperability") is
−
*U1 login to R2
+
* U1 login to R2
−
**U1's appearance at G1 can be seen from any other client which is connecting to R2.
+
** U1's appearance at G1 can be seen from any other client which is connecting to R2.
−
**U1 can CRUD(Create/Read/Update/Delete) its inventory/appearance through R2.
+
** U1 can CRUD(Create/Read/Update/Delete) its inventory/appearance through R2.
  
 
This means, (in the fig. 2) R2 should have the ability to connect not only its default
 
This means, (in the fig. 2) R2 should have the ability to connect not only its default
 
UGAI server, but also external Inventory, Asset, Avatar service.
 
UGAI server, but also external Inventory, Asset, Avatar service.
  
−
[[Image:avatar_portability_v2_2.PNG]]
+
[[File:avatar_portability_v2_2.PNG]]
  
−
Then "AvatarPortability" can be subdivided into 2 goals
+
'''Then "AvatarPortability" can be subdivided into 2 goals:'''
−
# How to let R2 know where are U1's storage services(Inventory,Asset,Avatar,...) ?
+
# '''How to''' let R2 know where are U1's storage services(Inventory,Asset,Avatar,...) ?
−
# How to enable R2 to interact with mutilple Inventory/Asset/Avatar services ?
+
# '''How to''' enable R2 to interact with mutilple Inventory/Asset/Avatar services ?
  
−
==== Answer to the 1st How - XRDS ====
+
==== Answer to the 1st How to - XRDS ====
  
 
more information can be found at:
 
more information can be found at:
−
*http://en.wikipedia.org/wiki/Yadis
+
* http://en.wikipedia.org/wiki/Yadis
−
*http://en.wikipedia.org/wiki/XRDS
+
* http://en.wikipedia.org/wiki/XRDS
  
 
A sample XRDS for U1 can be like:
 
A sample XRDS for U1 can be like:
Line 75: Line 80:
 
   </xrds:XRDS>
 
   </xrds:XRDS>
  
−
*There are more than one way can be considered to pass U1's XRDS file to R2
+
* There are more than one way can be considered to pass U1's XRDS file to R2
−
**[[OpenID for data portability in virtual world]]
+
** [[OpenID for data portability in virtual world]]
  
 
REASONS for proposing XRDS
 
REASONS for proposing XRDS
Line 83: Line 88:
 
# '''XRDS is just a proposal''', still, we have many other choices.
 
# '''XRDS is just a proposal''', still, we have many other choices.
  
−
==== Answer to the 2nd How - ForeignAssetHashTable ====
+
==== Answer to the 2nd How to - ForeignAssetHashTable ====
  
−
=== implemetation ===
+
Why it is a problem ? The asset download process is described below:
−
 
+
* RegionServer sends user/prims' Texture UUID to the client.
−
== Avatar Portability ==
+
* Client extract the UUIDs, and sends a "RequestImagePacket" to request the actual asset data.
−
 
+
* RegionServer receives the AssetUUID and passes it to AssetServer to get the asset.
−
In "users" table, "UserInventoryURL" and "UserAssetURL" have been there for a long time, and they are not used yet. My idea starts from the 2 properties;
+
[[File:avatar_portability_v2_3-1.PNG]]
−
 
+
* Considering only 1 GridService, there is no problem, but if RegionServer knows more than 1 asset server, RegionServer has to determine which assetserver should be used.
−
=== 1 UserInventoryUrl UserAssetUrl ===
+
* Here '''ForeignAssetHashTable''' is used to solve this problem. (The detailed implementation is shown in following section.)
−
[[Image:avatar_portability_1.PNG]]
+
*# when U1 login to R2, R2 register U1's owned asset UUIDs to "ForeignAssetHashTable".
−
*U1 is an user of GridService G1, so probably, U1's "UserInventoryURL" and "UserAssetURL" are pointing to G1's default Inventory/Asset server.
+
*# Client sends a RequestImagePacket
−
*R2 is a regionserver in GridService G2, so R2 fetches assets from G2's Asset server by default.
+
*# R2 looks up into "ForeignAssetHashTable" to find the AssetServerUrl,(if not found, returns the default url)
−
----
+
*# R2 use the returned AssetServerUrl to get asset data.
−
 
+
[[File:avatar_portability_v2_3.PNG]]
−
=== 2 Fetch data from multiple Inventory/Asset Data ===
+
−
[[Image:avatar_portability_2.PNG]]
+
−
*U1 login to R2, If U1 want to also bring in its apearance, R2 should have the ability that can '''get U1's appearance from U1's "UserInventoryUrl" and get U1's assets(textures) from "UserAssetUrl"'''.
+
−
*So, in this case, because an asset request("RequestImagePacket") only sends asset UUID to R2, R2 has to '''determine which asset server provides the reuqested UUID'''.
+
−
 
+
−
----
+
−
 
+
−
=== 3 ForeginAssetHashTable ===
+
−
 
+
−
[[Image:avatar_portability_3.PNG]]
+
−
 
+
−
>R1 has to determine which asset server provides the reuqested UUID
+
−
*At the right-bottom of this picture, "ForeginAssetHashTable" is used to solve this.
+
−
*When an user login,
+
−
*#region gets its "inventoryurl", "asseturl" from its "profile"
+
−
*#region gets its appearance(UUIDs) from its "inventoryurl", and add the UUIDs into "ForeginAssetHashTable"
+
−
*#Then when client send a "RequestImage(UUID)", RegionServer can look up into "ForeginAssetHashTable" to get the proper "AssetUrl"
+
  
 
== Implementation ==
 
== Implementation ==
  
−
=== Authentication ===
+
* All the implementation described here are already finished
−
 
+
** The testing environment will be made public after solving the "[[security vulnerability brought by non-check inventory service|security]]" issues.
−
[[not prepared yet]]
+
* Just for appearance portability, asseturl and inventoryurl are enough, so temporarily just use the 2 existing properties.
−
 
+
* XRDS is not implemented
−
=== Avatar Portability ===
+
  
−
==== 1 Implementation - ForeginAssetHashTable.Add ====
+
=== 1 Implementation - ForeginAssetHashTable.Add ===
  
−
[[Image:avatar_portability_4-1.PNG]]
+
[[File:avatar_portability_4-1.PNG]]
  
−
==== 2 Implementation - ForeginAssetHashTable.Get ====
+
=== 2 Implementation - ForeginAssetHashTable.Get ===
  
−
[[Image:avatar_portability_4-2.PNG]]
+
[[File:avatar_portability_4-2.PNG]]
  
−
==== 3 Implementation - ForeginAssetHashTable.Remove ====
+
=== 3 Implementation - ForeginAssetHashTable.Remove ===
  
−
[[Image:avatar_portability_4-3.PNG]]
+
[[File:avatar_portability_4-3.PNG]]

Latest revision as of 21:43, 3 March 2012

Languages Languages: 

En.png English

48x48

This article or section is a Proposal
It does not represent the current state of OpenSim, but is an idea for future work in OpenSim. Please feel free to update this page as part of the proposal discussion.
User:Lulurun

[edit] Agenda

To enable user avatar travel from a grid service to another grid service, There are 3 problems to be considered:

  1. How to enable foreign user login - Authentication
  2. (If a foreign user can login)How to get a foreign user's belongings(including appearance, inventory)
    • This is discussed in this page
  3. Security

To achieve the 1st, client side changes are needed. SO, so far, I have only implemented the 2nd and the 3rd, and would like to explan my idea:

[edit] Basic Idea

[edit] definition

  • User U1 resgitered at GridService G1
    • U1's inventory information is stored in InventoryServer I1
    • U1's assets are stored in AssetServer As1
    • U1's appearance information is served by AvatarService Av1
  • RegionServer R2 serves a sim at GridService G2
    • R2 fetches assets from Assetserver As2 by default.
    • R2 gets inventory information from InventoryServer I2 by default.

Avatar portability v2 1.PNG

[edit] avatar portability

AvatarPortability (or called "grid interoperability") is

  • U1 login to R2
    • U1's appearance at G1 can be seen from any other client which is connecting to R2.
    • U1 can CRUD(Create/Read/Update/Delete) its inventory/appearance through R2.

This means, (in the fig. 2) R2 should have the ability to connect not only its default UGAI server, but also external Inventory, Asset, Avatar service.

Avatar portability v2 2.PNG

Then "AvatarPortability" can be subdivided into 2 goals:

  1. How to let R2 know where are U1's storage services(Inventory,Asset,Avatar,...) ?
  2. How to enable R2 to interact with mutilple Inventory/Asset/Avatar services ?

[edit] Answer to the 1st How to - XRDS

more information can be found at:

A sample XRDS for U1 can be like: 

 <?xml version="1.0" encoding="UTF-8"?>
 <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
  <XRD>
    <Service priority="0">
      <Type>http://opensim.org/profileservice/1.0</Type>
      <URI>http://osgrid.org:8002/GetUserProfile/12345678-1234-1234-1234-12345678abcd</URI>
    </Service>
    <Service priority="0">
      <Type>http://opensim.org/authservice/1.0</Type>
      <URI>http://osgrid.org:8002/session/12345678-1234-1234-1234-12345678abcd</URI>
    </Service>
    <Service priority="0">
      <Type>http://opensim.org/assetservice/1.0</Type>
      <URI>http://osgrid.org:8003</URI>
    </Service>
    <Service priority="0">
      <Type>http://opensim.org/inventoryservice/1.0</Type>
      <URI>http://osgrid.org:8004</URI>
    </Service>
    <Service priority="0">
      <Type>http://opensim.org/avatarservice/1.0</Type>
      <URI>http://osgrid.org:8005</URI>
    </Service>
  </XRD>
 </xrds:XRDS>

REASONS for proposing XRDS

  1. There are "UserAssetUrl" and "UserInventoryUrl" in "Users" table, they are cab be used to specify users' storage services, but it's lack of scalability, to think we may have "friend service", "currency service", ... we can not simply add a column for each service.
  2. XRDS is widly used, many languages has libs for discovering/parsing it. To use XRDS can increase the compatibility　with existing(web) service
  3. XRDS is just a proposal, still, we have many other choices.

[edit] Answer to the 2nd How to - ForeignAssetHashTable

Why it is a problem ? The asset download process is described below:

  • RegionServer sends user/prims' Texture UUID to the client.
  • Client extract the UUIDs, and sends a "RequestImagePacket" to request the actual asset data.
  • RegionServer receives the AssetUUID and passes it to AssetServer to get the asset.

Avatar portability v2 3-1.PNG

  • Considering only 1 GridService, there is no problem, but if RegionServer knows more than 1 asset server, RegionServer has to determine which assetserver should be used.
  • Here ForeignAssetHashTable is used to solve this problem. (The detailed implementation is shown in following section.)
    1. when U1 login to R2, R2 register U1's owned asset UUIDs to "ForeignAssetHashTable".
    2. Client sends a RequestImagePacket
    3. R2 looks up into "ForeignAssetHashTable" to find the AssetServerUrl,(if not found, returns the default url)
    4. R2 use the returned AssetServerUrl to get asset data.

Avatar portability v2 3.PNG

[edit] Implementation

  • All the implementation described here are already finished
    • The testing environment will be made public after solving the "security" issues.
  • Just for appearance portability, asseturl and inventoryurl are enough, so temporarily just use the 2 existing properties.
  • XRDS is not implemented

[edit] 1 Implementation - ForeginAssetHashTable.Add

Avatar portability 4-1.PNG

[edit] 2 Implementation - ForeginAssetHashTable.Get

Avatar portability 4-2.PNG

[edit] 3 Implementation - ForeginAssetHashTable.Remove

Avatar portability 4-3.PNG

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