Latest revision as of 02:53, 22 October 2024

 

Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English    Deutsch    Français

[edit] Introduction

Dans la grande majorité des cas, les demandes des viewers sont traitées par le simulateur qui interagit ensuite avec les services dorsaux (assets, inventaire, etc.) selon le cas.

Cependant, dans la configuration par défaut, certaines de ces demandes sont traitées par le viewer qui interagit directement avec un service backend. Par exemple, lors de la connexion, le service de connexion transmet au viewer une URL de carte configurée dans la section MapTileURL de [LoginService] dans Robust.ini. Lorsque le viewer a besoin d'afficher des tuiles sur la carte principale, il contacte cette URL pour les récupérer. L'URL elle-même est servie par le service ROBUST sur le port public de la grille (8002 par défaut).

Il est également possible de traiter d'autres requêtes directement. Cependant, le meilleur exemple de fonctionnement connu, détaillé ci-dessous, est celui qui traite les requêtes GetTexture directement à partir d'un service plutôt que par l'intermédiaire d'un simulateur. D'autres exemples seront ajoutés à l'avenir, bien que certains posent des problèmes de sécurité importants qu'il faut prendre en compte.

[edit] Traitement direct de la capacité GetTexture

AVERTISSEMENT : les viewers ne peuvent plus l'utiliser

GetTexture est un protocole de capacités client-viewer par lequel les clients (viewers) peuvent demander des textures via HTTP au lieu des anciens mécanismes basés sur UDP.

Normalement, OpenSimulator gère cela en fournissant un point de terminaison de capacité (une adresse spécifique) qui pointe vers le simulateur où se trouve l'avatar de l'utilisateur. Les requêtes sont reçues par le simulateur et l'asset est récupéré dans le cache ou par un appel au service backend d'assets, selon le cas.

Cependant, nous pouvons également configurer GetTexture pour qu'il soit géré directement par un service via le port public de la grille. Alors, le point de terminaison de capacité passé au viewer pointe directement vers ce service au lieu de pointer vers le simulateur, de la même manière que les tuiles de carte sont fournies directement par un service.

Cette configuration fonctionnera à la fois pour les installations non-Hypergrid et Hypergrid (puisque tous les assets nécessaires sont copiés dans le service d'assets local lorsqu'un utilisateur étranger entre dans le simulateur et lorsqu'il rezz ou transfère des objets de son inventaire).

[edit] Configuration

La première chose à faire est de configurer le service pour qu'il fournisse le connecteur de capacité GetTexture. Nous pouvons le faire avec la configuration ci-dessous.

[Startup]
 
[ServiceList]
GetTextureConnector = "8010/OpenSim.Capabilities.Handlers.dll:GetTextureServerConnector"
 
[Network]
port = 8010
 
[CapsService]
AssetService = "OpenSim.Services.AssetService.dll:AssetService"
 
[DatabaseService]
StorageProvider = "OpenSim.Data.MySQL.dll"
ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=mypassword;Old Guids=true;"
 
[AssetService]

Je suppose ici que nous exécutons le service GetTexture à l'intérieur d'une instance de service Robust entièrement séparée. Cependant, il peut être exécuté dans un shell Robust qui gère également d'autres services (par exemple, le shell par défaut de la grille qui gère tous les services). Dans ce cas, vous pouvez omettre certaines sections, comme nous le décrivons ci-dessous.

Voici une explication de chaque section.

• [Démarrage] - Cette section est vide et n'existe que parce qu'actuellement le shell du service Robust l'exige. Il se peut qu'elle ne soit plus nécessaire à l'avenir. Dans un shell de service partagé, la section [Startup] existante sera utilisée.
• [ServiceList] - Ceci déclenche l'initialisation du connecteur de capacité GetTexture. Ici, nous spécifions explicitement un port de 8010, bien qu'il puisse être omis s'il est identique au paramètre « port » par défaut dans la section Network. Il s'agit du port par lequel le viewer communiquera avec le connecteur de capacité GetTexture ; il doit donc être accessible à un viewer à travers votre pare-feu. Vous ne devez pas exécuter de services privés (par exemple, un service d'asset interne) sur ce port.
• [Network].port - OpenSimulator se plaindra toujours si ce port n'est pas présent, même si vous n'avez qu'un seul connecteur et qu'il spécifie explicitement le port que vous utilisez (comme ci-dessus). Si vous spécifiez explicitement le port de GetTextureConnector, il peut s'agir de n'importe quel port libre sur votre serveur (il ne sera pas utilisé s'il n'y a pas d'autres services). Si vous exécutez GetTextureConnector dans un shell de service partagé, n'importe quel port existant suffira.
• [CapsService].AssetService - Spécifie le service d'assets que GetTextureConnector doit initialiser pour récupérer les textures (qui sont des assets).
• [DatabaseService] - Ceci contient les paramètres pour que l'AssetService accède à la base de données. Si GetTextureConnector partage le shell Robust avec d'autres services, il est très probable qu'il existe déjà.
• [AssetService] - Cette section est vide et n'existe que pour éviter que AssetService ne se plaigne fatalement. Il est possible qu'elle disparaisse à l'avenir.

Maintenant, si vous démarrez le shell Robust qui héberge GetTextureConnector et si vous exécutez la commande « show http-handlers », vous devriez voir quelque chose comme ce qui suit (pour plus de clarté, nous montrons la sortie lorsque GetTextureConnector est la seule chose en cours d'exécution dans le shell).

R.O.B.U.S.T.# show http-handlers
Registered HTTP Handlers for server at 0.0.0.0:8010
* XMLRPC:
* HTTP:
* HTTP (poll):
* JSONRPC:
* LLSD:
* StreamHandlers (1):
  GET:/CAPS/GetTexture/

Cela montre que le point de terminaison /CAPS/GetTexture est maintenant disponible.

Nous devons maintenant configurer les simulateurs pour qu'ils fournissent aux viewers la capacité GetTexture qui pointe vers le service. Dans la section [ClientStack.LindenCaps] d'OpenSim.ini pour chaque simulateur, nous devons ajouter quelque chose comme ce qui suit.

[ClientStack.LindenCaps]
    Cap_GetTexture = "http://192.168.1.2:8010/CAPS/GetTexture/"

Cela remplace le paramètre habituel « localhost » spécifié dans bin/OpenSimDefaults.ini. Dans ce cas, l'URL pointe vers une adresse IP du réseau local (192.168.1.2). Mais pour une grille publique, il doit s'agir d'un hôte public accessible à tous les utilisateurs (par exemple, services.mygrid.com).

Maintenant, lorsqu'un observateur se connecte, il fait des requêtes GetTexture directement au service, en passant entièrement par le simulateur. Si le connecteur GetTexture est exécuté dans son propre shell, vous pouvez vérifier ce qui se passe en lançant une commande telle que "show stats httpserver.8010.HttpRequestsServed".

R.O.B.U.S.T.# show stats httpserver.8010.HTTPRequestsServed
httpserver.8010.HTTPRequestsServed : 139 requests, 0 requests/s, 0 requests/s

Dans ce cas, nous pouvons voir que le service a servi 139 requêtes. Malheureusement, il est plus difficile de vérifier cela si le shell est partagé par plusieurs services sur le même port - nous n'enregistrons pas actuellement de statistiques pour montrer les capacités (bien que cela devrait changer à l'avenir).

[edit] Configuration expérimentale

Cette configuration est extrêmement expérimentale et n'est pas encore connue pour fonctionner pleinement. Elle est laissée ici à titre de référence.

Au lieu d'instancier un AssetService pour s'occuper des requêtes GetTexture au niveau du service, nous pouvons potentiellement instancier une instance HGAssetBroker lorsque l'Hypergrid est actif. Pour l'instant, ce n'est pas nécessaire puisque les assets sont copiés dans le service d'assets local lorsque c'est nécessaire (et donc la configuration par défaut de GetTexture ci-dessus les trouvera toujours). Cependant, il pourrait y avoir de futures expérimentations qui pourraient ne plus copier ces assets à l'avance et de ne les demander/mettre en cache que sur demande. Cela nécessitera également un code supplémentaire pour transférer correctement l'objet s'il est requis de façon permanente (par exemple, parce qu'un objet est rezzé dans une région ou donné à un autre utilisateur).

La configuration ci-dessous n'est actuellement possible que dans la branche de développement « ghosts » du dépôt d'OpenSimulator, à partir du commit 0437d44 (post 0.8), bien qu'elle soit bientôt disponible dans le code de développement principal.

La configuration côté service est la suivante. La configuration côté simulateur est la même que dans le cas normal.

[Startup]
 
[ServiceList]
GetTextureConnector = "8010/OpenSim.Capabilities.Handlers.dll:GetTextureServerConnector"
 
[Network]
port = 8010
 
[CapsService]
AssetService = "OpenSim.Region.CoreModules.dll:HGAssetBroker"
 
[DatabaseService]
StorageProvider = "OpenSim.Data.MySQL.dll"
ConnectionString = "Data Source=localhost;Database=opensimmaster2;User ID=root;Password=passw0rd;Old Guids=true;"
 
[AssetService]
LocalGridAssetService = "OpenSim.Services.AssetService.dll:AssetService"
HypergridAssetService = "OpenSim.Services.Connectors.dll:HGAssetServiceConnector"
 
[Modules]
AssetServices = HGAssetBroker

Les changements par rapport à la configuration non-Hypergrid sont les suivants.

• [CapsService].AssetService instancie maintenant HGAssetBroker à partir de OpenSim.Region.CoreModules.dll plutôt que AssetService à partir de OpenSim.Services.AssetService.
• [AssetService] contient maintenant deux entrées. L'entrée LocalGridAssetService indique à HGAssetBroker quel service d'assets doit être instancié et utilisé pour les demandes d'assets de la grille d'origine. L'entrée HypergridAssetService indique à HGAssetBroker quel service d'assets doit être instancié et utilisé pour les demandes de services d'assets étrangers.
• [Modules].AssetServices entrée nécessaire pour que HGAssetBroker s'exécute après avoir été instancié. Cette entrée est nécessaire car, jusqu'à très récemment, HGAssetBroker était un module de région qui n'était jamais instancié par CapsService. Cette exigence pourrait disparaître à l'avenir.

[edit] Avantages et inconvénients

[edit] Avantages

Le traitement des demandes directement par l'intermédiaire d'un service présente les avantages suivants.

[edit] Réduction de la charge du simulateur

Le traitement des demandes directement par le service réduit la charge de traitement du simulateur lui-même. Ceci est particulièrement pertinent pour les services qui traitent un grand nombre de requêtes, comme GetTexture. Cependant, l'impact n'a pas encore été correctement mesuré.

[edit] Performances constantes

Lorsqu'une requête est traitée directement par le service, les performances pour satisfaire cette requête ne varieront pas potentiellement entre les simulateurs fonctionnant dans des conditions différentes.

[edit] Inconvénients

Cependant, il présente également les inconvénients suivants.

[edit] Les textures locales aux régions ne fonctionnent pas

Les textures dynamiques OSSL ne fonctionneront pas, par exemple

[edit] Toute la charge repose sur le service

Au lieu d'être répartie dans une certaine mesure entre les simulateurs, toute la charge des demandes de service est désormais placée sur un seul point de service (par exemple, GetTexture). Ce problème se pose particulièrement dans les grilles où le nombre d'utilisateurs et de simulateurs est élevé. Dans le cas de GetTexture et de toute demande impliquant un asset, il arrive souvent que ces assets soient servis à partir du cache local du simulateur. Toutefois, ce problème peut être résolu en répartissant les demandes entre plusieurs instances de service, étant donné que tous les services sont sans état (ne conservent pas d'informations entre les requêtes). Enfin, on pourrait également utiliser d'autres implémentations de services (par exemple SRAS pour le service d'assets) qui sont probablement beaucoup plus efficaces que les implémentations de services ROBUST intégrées. En général, il existe déjà un grand nombre de connaissances et de logiciels pour la mise à l'échelle des services.

[edit] Sécurité

Pour prendre l'exemple de GetTexture, si vous exécutez la commande "show caps list" sur le simulateur lorsqu'au moins un utilisateur est connecté, vous verrez que la capacité GetTexture est maintenant servie par une URL fixe plutôt que par une URL qui contient un composant aléatoire. Par exemple :

OpenSim (test)# show caps list
Region test:
** User f2f493c0-27d3-4cf2-be97-b44dfdad13b6:
   ObjectAdd                              /CAPS/OA/a7dd11fd-5f0c-4f5a-b70d-f558273101b5/              
   NewFileAgentInventory                  /CAPS/f608dd70-15f1-40a9-8780-8164c09627680002/             
   FetchInventory2                        /CAPS/176542be-6a06-4219-8647-cb57f8c9ec20                  
   ...                             
   GetTexture                             http://192.168.1.2:8010/CAPS/GetTexture/

En effet, il n'existe actuellement aucun mécanisme permettant de générer une URL de capacité aléatoire lorsqu'une capacité est fournie directement par un service. Dans ce cas, par exemple, toute personne connaissant l'URL fixe de GetTexture peut demander un asset si elle connaît son ID. Dans le cas de GetTexture, cela n'est pas considéré comme un problème critique puisqu'il existe de nombreuses façons d'obtenir un asset particulier si l'identifiant est connu (bien que dans le cas de grilles dont l'adhésion est restreinte, cela puisse encore être considéré comme un problème). Toutefois, dans d'autres cas, tels que la capacité FetchInventory2, il s'agit d'un problème beaucoup plus important. En fin de compte, un mécanisme permettant au simulateur d'enregistrer un point de terminaison de capacité aléatoire auprès du service hébergeant la capacité devra être mis en œuvre, ce qui augmentera la complexité du système.

[edit] Certains connecteurs ne peuvent pas gérer l'hypergrid

Actuellement, certains connecteurs de capacité ne fonctionnent pas en mode Hypergrid, bien que cela ne pose pas de problème avec GetTexture. Cette situation devrait évoluer à l'avenir.