|
|
| Line 2: |
Line 2: |
| | {{Quicklinks|Hypergrid}} | | {{Quicklinks|Hypergrid}} |
| | <br /> | | <br /> |
| − |
| |
| − | == Implementation Hypergrid ==
| |
| − |
| |
| − | === Hyperlinks et les transferts d'agent ===
| |
| − |
| |
| − | Quand vous établissez un lien entre votre opensim et un autre, un message est envoyé à cet opensim lui demandant des informations sur lui même; les informations requises incluent les informations de réseau de cette machine opensim et les coordonnées de sa première région sur sa grille locale sous la forme d'un handle de région. Par exemple, supposez que vous reliez le noeud X.com:9000 en le placant sur votre carte locale en 900,900. Qu'opensim lance une ou plusieurs régions qui ne sont pas en 900,900 sur leur propre carte; supposez que la première région de la grille est sur 1100;1100. Depuis votre point de vue, peu importe quelles sont ces coordonnées et vous n'avez pas besoin de le savoir-- ceci est la clef pour être capable de commencer à décentraliser le monde comme donné dans une carte 2D: vous voulez la placer sur votre carte à 900,900. La véritable position de ce simulateur dépend essentiellement du client LL, quand il y a des téléports entre votre monde et cet autre opensim. Ce mapping entre les systèmes de coordonnées est l'essence des hyperliens pour opensim.; cette chose simple mais critique que fait l'implémentation hypergrid. Le mapping se passe sur l'évènement TeleportFinish; à la place d'envoyer les coordonnées locales au client, l'encapsulage du téléport hypergrid envoie les coordonnées distantes.
| |
| − |
| |
| − | Quand un agent se téléporte à travers cet hyperlien, voici ce qu'il se passe. Premièrement, avant InformRegionOfChildAgent, l'opensim local informe l'opensim distant sur cet utilisateur via la méthode "expect_hg_user". Ce message envoie les adresses de tous les serveurs qu'utilise cet utilisateur, comme les serveurs d'utilisateur, d'inventaire et d'assets. L'opensim distant place une entrée pour cet utilisateur dans son cache de profil utilisateur local mais pas dans sa base de données utilisateurs; les informations de l'utilisateur étranger ne sont pas persistantes. Apres cela, le processus de téléport est exactement le même que le processus de teleport normal; la seule différence est que les region handles sont basculés entre la région distante sur la grille locale et sa position actuelle sur la grille.
| |
| − |
| |
| − | En résumant, les deux nouveaux concepts introduits par hypergrid sont le concept d'un hyperlien et le concept d'un "utilisateur local" par rapport à un "[[Banning Foreign Users in Hypergrid|utilisateur étranger]]".
| |
| − |
| |
| − | === Accès à l'inventaire ===
| |
| − |
| |
| − | L'accès à l'inventaire depuis l'extérieur est effectué en encapsulant le scene-inventory existant avec du code additionnel qui prend ou donne les assets d'inventaire depuis/vers le serveur d'assets de l'utilisateur. Quand l'inventaire est accédé, l'encapsulation hypergrid verifie si l'utilisateur est étranger et si il l'est, l'encapsulation donne simplement les assets nécessaires depuis le serveur d'assets de l'utilisateur au cache local d'assets du serveur; à partir de là, l'encapsulation passe le contrôle aux fonctions existantes d'accès à l'inventaire. Quand quelque chose est ajouté à l'inventaire, l'encapsulation hypergrid est informée par un évènement et poste les assets au serveur d'assets de l'utilisateur. Un cache des identifiants d'éléments échangés est maintenu afin qu'ils ne soient pas récupérés en boucle.
| |
| − |
| |
| − | Le résultat est que les instances hypergridées de opensim finissent par interagir avec plusieurs serveurs d'assets à la place d'un seul. Cette interaction est implémentée d'une manière france en instantiant différents objets GridAssetClient à la place d'un seul.
| |
| − |
| |
| − | === Les classes HyperGrid ===
| |
| − |
| |
| − | Actuellement, hypergrid est intégré en dehors de l'espace de nom OpenSimulator donc il y a une séparation complète entre ce qui existe et ce nouveau comportement. Il possède son propre espace de nom, HyperGrid. Il y a à l'intérieur 4 sous espaces de noms qui suivent directement l'architecture logicielle de OpenSim, respectivement :
| |
| − |
| |
| − | * '''OpenSim.Framework''':
| |
| − | ** ForeignUserProfileData étend UserProfileData en introduisant des informations sur la "home" de l'utilisateur, l'adresse de la home sous forme de nom, le port et le port distant. La "home" de l'utilisateur n'est pas le service utilisateur de cet utilisateur; c'est l'opensim que cet utilisateur a défini comme étant sa home. C'est nécessaire afin de supporter le téléport vers sa home.(Ctrl-Shift-H).
| |
| − | ** HGNetworkServersInfo suit l'esprit de NetworkServersInfo, cependant il ne l'etend pas ni le l'utilises. Actuellement, il est une classe utilitaire dont les deux fonctions principales servent à convertir les noms de domaines de serveurs vers des adresses IP et de fournir uniformément la réponse à la question bool IsLocalUser(...).
| |
| − |
| |
| − | * '''OpenSim.Region.Framework.Scenes.Hypergrid''':
| |
| − | ** HGSceneCommunicationService étend SceneCommunicationService, surchargeant RequestTeleportToLocation. Il y a deux tres petits changements mais critiques à la méthode de base: (a) sur l'évènement TeleportFinish, nous basculons les handles de région quand la région de destination est un hyperlien; (b) les connexions finales sont toujours fermées aux TPs hypergrid.
| |
| − | ** HGScene étend Scene, en surchargeant TeleportClientHome(...). Le seul changement à la méthode de base est actuellement de rester éloigné du serveur utilisateur car le service utilisateur n'est pas encore complètement encapsulé pour les utilisateurs étrangers. Une fois que le service utilisateur est proprement encapsulé, la classe devient inutile.
| |
| − | ** HGScene.Inventory est une classe partielle de HGScene, juste comme ce qu'il se passe dans le framework OpenSimulator. Cette partie de HGScene surcharge quelques méthodes d'interactions inventory-scene, donc les assets sont récupérés/postés depuis/vers le serveur d'assets de l'utilisateur. Une fois que cet échange est effectué, ces methodes passent simplement la balle aux méthodes de base.
| |
| − | ** HGAssetMapper: c'est une nouvelle classe spécifique à hypergrid qui gère la récupération et l'envoi d'assets entre régions étrangères où l'utilisateur se trouve et le serveur d'assets.
| |
| − |
| |
| − | * '''OpenSim.Region.Communications.HyperGrid''' est un mélange de OpenSim.Region.Communications.*. C'est la place où la plupart des extensions hypergrid mentent. Une des raisons à cela est que la partie des communications de hypergrid effectue une chose additionnelle: ceci rend les standalones interconnectables.
| |
| − | ** HGCommunicationsStandalone étend CommuniationsLocal. Juste à sa base, c'est un concentrateur pour les nombreux services réseau disponibles en mode standalone. La différence principale est que ces services sont des extentions de ce qui est dans OpenSimulator.
| |
| − | ** HGCommunicationsGridMode étend CommunicationsManager directement. Encore, c'est un concentrateur pour les services réseau disponibles en mode grille, ces services sont des extensions de OpenSimulator.
| |
| − | ** Les clusters HGGridServices (superclass), HGGridServicesStandalone et HGGridServicesGridMode (subclasses) implémentent les interfaces IGridServices et IInterRegionCommunications. Les 2 sous classes sont les encapsuleurs pour LocalBackEndServices et OGS1GridServices, respectivement. Il y a un pattern commun There is one common pattern tout au long de ces classes: vérifie si la région à qui parler est un hyperlink; si elle ne l'est pas, il délègue simplement le travail à LocalBackEndServices/OGS1GridServices; si elle l'est, il envoie le boulot à la classe de base HGGridServices. HGGridServices, à son tour, effectue la gestion des régions hyperliées et définit deux morceaux additionnels du protocol inter-region protocol:
| |
| − | *** region_uuid: pour lier des régions
| |
| − | *** expect_hg_user: similaire à l'interface existante expect_user, mais avec beaucoup plus d'information à propose de l'utilisateur passé aux alentours, nominément, tous les serveurs utilisateur (inventory, asset, user, home, etc.)
| |
| − | ** HGInventoryService étend LocalInventoryService et implémente ISecureInventoryService. Cette classe est le mélange le plus évident du pack, mélangeant les acces aux services locaux pour les utilisateurs standalone et les acces à l'inventaire distant pour quand les utilisateurs sont sortis et sur le point de l'être. Actuellement, il y a une bonne quantité de coper/coller sélectif afin de rester éloigné de l'arrivée affreuse de OGS1InventoryService et OGS1SecureInventoryService. HGInventoryService est toujours un ISecureInventoryService. Ses méthodes suivent toutes le même pattern: verifie si l'utilisateur est un utilisateur standalone local; si il l'est, il passe le mot à la méthode de base (dans LocalInventoryService); si il ne l'est pas, effectue un acces distant sécurisé.
| |
| − | ** HGUserServices encapsule OSG1UserServices, mais il n'est pas encore fonctionnel.
| |
| − |
| |
| − | * '''OpenSim.Region.CoreModules.HyperGrid''' est une collection de 3 modules de région:
| |
| − | ** HGWorldMapModule étend WorldMapModule. Il réutilise pratiquement tout depuis la classe de base. Le seul petit changement est dans RequestMapBlocks, où il essaie d'envoyer des offline mapblock au client.
| |
| − | ** HGStandaloneInventoryService et HGStandaloneAssetService fait ce que disent leur nom. Ce sont des modules de région qui autorisent l'acces aux asset et à l'inventaire pour les standalones. quand l'utilisateur standalone est sorti ou sur le point de l'être. Dans l'esprit, il y a beaucoup en commun entre ces modules et le plugin REST d'inventaire/asset. Infortunément, ce plugin pourrait ne pas être utilisé car il définit une interface complètement différente que celle utilisée par les serveurs d'assets et inventaire existants et l'acces à l'hypergrid doit utiliser une interface consistante.
| |
| | | | |
| | == Installing and Running == | | == Installing and Running == |
