Languages:

English    Français

Introduction

Cette page présente quelques détails sur le protocole utilisé pour transférer l'inventaire entre le viewer (client) et une installation d'OpenSimulator. Comme de nombreuses pages, celle-ci est en construction, aussi si vous désirez vous informer plus précisément à ce sujet, veuillez poser vos questions en anglais via la liste de diffusion opensim-dev.

Protocoles

Il existe deux protocoles OpenSimulator <-> inventaire du viewer. Le premier fonctionne uniquement avec des messages UDP. Le second utilise le protocole HTTP via les capacités pour remplacer la recherche des parties du protocole UDP.

Le portocole UDP est plus ancien et la recherche de parties a été complètement remplacée sur la grille Linden Lab par le protocole de capacités HTTP. Cependant, certains viewers peuvent encore utiliser UDP pour faire une recherche et ce protocole est encore supporté dans OpenSimulator.

D'autres opérations sur les inventaires (par exemple, la création de dossier) sont encore réalisées via UDP.

Le protocole HTTP devrait être plus performant que le protocole UDP pour les utilisateurs ayant un inventaire important. Cependant, beaucoup de viewer fournissent une option de retour vers un inventaire UDP en cas de problèmes avec le protocole HTTP. Il est aussi possibe de désactiver le protocole HTTP dans une installation OpenSimulator en désactivant les capacités.

Protocole UDP

Ci-dessous sont listés quelques messages UDP impliqués dans la manipulation de protocole. Attention: la liste est probablement incomplète et a besoin d'être complètée.

 BulkUpdateInventory
   serveur -> client
   envoyé quand un item d'inventaire est donné à un agent
   contient uniquement le/les item(s) mis à jour

 CreateInventoryItem
   client -> serveur
   reçu quand un client crée directement un nouvel item dans l'inventaire
   et pas quand le client prend un objet ou une copie d'objet depuis l'environnement.

 FetchInventory
   client -> serveur
   cherche les détails d'un item particulier

 FetchInventoryDescendents
   client -> serveur
   reçu quand un dossier d'inventaire est ouvert
   InventoryDescendents est la réponse

 FetchInventoryReplyPacket
   serveur -> client
   contient les détails d'un item de l'inventaire
   pour certaines raisons c'est la même chose que les données sur l'item envoyées dans InventoryDescendents

 InventoryDescendents
   paquet réponse pour FetchInventoryDescendents qui contient les détails d'inventaire
   contient le dossier et les données de l'item

 LinkInventoryItem
   client -> serveur
   lie un item d'inventaire à un item existant

 RemoveInventoryItem
   est invoqué par le client quand  Purge Item est sélectionné pour un item dans la corbeille.

 UpdateCreateInventoryItem
   serveur -> client
   envoyé quand 
     un item est dérezzé dans un inventaire d'avatar
     un item est glissé dans un inventaire d'avatar

 UpdateInventoryItem
   client <-> serveur
   envoie serveur -> client
     apparemment quand un dérez a réussi
   envoie client -> serveur
     quand différents yeux sont portés dans un  viewer 2
      il est possible que cela change le statut de l'objet porté

 UpdateInventoryFolder
   appelé quand le dossier est renommé.

Protocole HTTP

Le protocole HTTP fonctionne via des capacités variées. À l'heure actuelle, les capacités requises pour le transfert HTTP sont :

• FetchInventory2
• FetchInventoryDescendents2
• FetchLib2
• FetchLibDescendents2

Pour plus de précisions au sujet de leur fonctionnement, veuillez vous référer au document Linden Lab concernant les capacités d'inventaire.

Historiquement, les fonctionnalités suivantes ont été utilisées. Cependant, elles sont devenues obsolètes depuis longtemps et peuvent être négligées.

• FetchInventory
• FetchLib
• FetchLibDescendents

Si les capacités d'inventaires sont désactivées alors certains viewer (très probablement tous les viewers actuels) se rabattront sur le mécanisme UDP pour rechercher des données d'inventaire. Divers viewers peuvent proposer une option de menu pour ne pas utiliser l'inventaire HTTP. Les viewers plus anciens utiliseront uniquement le dispositif UDP. Toutefois, certains viewers ont historiquement été bogués et le retour vers UDP ne peut pas être configuré correctement.