Hypergrid/fr

L' Hypergrid OpenSim
Voir aussi Grider; Virtual World Model; HyperGrid Team

Qu'est ce que l' hypergrid?
L'hypergrid est une extension d'opensim qui vous autorise à relier votre opensim à d'autres opensims sur l'internet et qui supporte les transfert d'agents entre ces opensims. Il peut etre utilisé aussi bien en mode standalone que grid. Hypergrid supporte effectivement l'emergence d'un reseau de mondes virtuels.

L'idée de base pour hypergrid est que l'administration des regions/grille peut placer des liens hyperlinks sur leur carte pointant vers des régions hypergridées exécutées par d'autres. Une fois que ces hyperliens sont établis, les utilisateurs interagissent avec ces régions exactement de la même manière qu'avec des régions locales. Plus précisément, les utilisateurs peuvent choisir de se téléporter là bas. Une fois que l'utilisateur atteint la région derrière l'hyperlien, il interagit automatiquement avec un monde virtuel différent sans avoir à se déconnecter du monde depuis lequel il vient, tout en ayant encore acces à son inventaire.

Hypergrid a commencé en tant que projet sur la forge, mais il est actuellement inclus dans la distribution standard de opensim. Pour lancer votre instance opensim en mode hypergrid, reportez vous à cette page : Install et lancer.

Hyperliens de mondes virtuels


Nous sommes tous familiers avec les liens hypertext sur le web. Mais qu'est ce qu'un hyperlien de monde virtuel ?

Dans le modèle de l'hypergrid, nous considérons que la carte en 2D d'un monde virtuel est l'équivalent d'une page web. D'autant plus qu'un hyperlien est simplement une région sur la carte.

Le modèle par défaut des mondes virtuels basés sur opensim supportent déjà ce concept d'hyperliens. Quand vous vous téléportez d'une région vers une autre sur la carte, il y a des chances que vous migriez votre agent vers un serveur opensim différent. Cette migration est un transfert d'agent qui existe aussi dans une forme rudimentaire sur le web quand un lien hypertexte est suivi. Le modèle par défaut, cependant, impose deux fortes contraintes sur ces hyperliens :
 * 1) La carte complète des régions est controllée par un service central connu en tant que la grille, dont le boulot est de fournir une vue univorme d'une monde à toutes ses régions.
 * 2) Les seuls agents qui peuvent être transférés sont ceux appartenant aux utilisateurs connus d'un autre service central, le service d'utilisateurs; si l'utilisateur arrivant n'est pas dans la base de données de ce service, le transfert d'agent ne se fera pas.

Hypergrid retire simplement ces deux conditions.

Premièrement, il autorise des instances individuelles de opensim à être des "voisins" sur leur carte locale, en passant le contrôle de la carte depuis le serveur de grille vers les instances opensim (bien que les hyperliens peuvent être fournis par les serveurs de grille si l'admin de la grille le désire). En faisant cela, le monde devient beaucoup plus intéressant et varié. La carte que vous voyez sur une instance opensim peut être complètement différente de la carte que vous voyez apres votre téléport par un hyperlien. En tant qu'administrateur, vous êtes libre de définir quels autres opensim vous voulez voir sur votre carte.

Deuxiemement, il autorise le transfert d'agents concernant les utilisateurs étrangers comme les utilisateurs enregistrés autre part. A la place de tenir compte d'un service central d'utilisateur, hypergrid tient compte d'un grand nombre de ces services tout autour du monde. En tant que tel, quand les agents sont transférés à travers des opensim hypergridés, beaucoup d'information est passée sur l'utilisateur correspondant. Cette information inclus la collection de serveurs dont l'utilisateur transféré a besoin.

Scénarios d'utilisation
Les cas suivants sont des scénarios d'utilisation. Il n'y a pas de séparation claire entre ces scénarios, il y a de nombreux points communs entre eux. Ce n'est également pas une liste exhaustive. La proposition de ces descriptions est de vous donner quelques idées de départ sur comment utiliser hypergrid dans la pratique. N'hésitez pas à proposer de nouveaux scénarios intéréssants dans cette liste.

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 "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 OpenSim 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 OpenSim. 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 OpenSim.
 * HGCommunicationsGridMode étend CommunicationsManager directement. Encore, c'est un concentrateur pour les services réseau disponibles en mode grille, ces services sont des extensions de OpenSim.
 * 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
Voir cette page Installing and Running Hypergrid

Hypergrid et la Sécurité
Voir cette page Hypergrid Security

Bannir des utilisateurs étrangers
Voir cette page Banning Foreign Users in Hypergrid

Noeuds Publics Hypergrid
Voir cette page Public Hypergrid Nodes.

Listes Hypergrid
Voir cette page Hypergrid Lists.

Development Meetings
Hypergrid Meetings