Direct Service Requests/fr
From OpenSimulator
Contents |
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.
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).
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).
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.
Avantages et inconvénients
Avantages
Le traitement des demandes directement par l'intermédiaire d'un service présente les avantages suivants.
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é.
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.
