Changements du code de la semaine

Correction de llInsertString

Commit 9132b1 : Éviter de sortir des limites de llInsertString. Merci Tampa.
Prototype de la fonction llInsertString

Function: string llInsertString( string dst, integer pos, string src );

Cette correction ajoute une vérification de la limite supérieur manquante sur l'argument d'index (integer pos).

Modification de HttpListener.cs

Commit

: Cpmmit afd5b3 : définir le mode TCP sans délai à l'intérieur de try catch.

Description

Une une ligne de code dans la section try /catch a été déplacée. Il se pouvait que tcp no delay échoue pour certaines raisons, ce qui entraînerait l'arrêt du service pour tout. Avec cette modification, cela restera silencieux et ignoré.

Statistique de grille : correction du nombre de régions

Commit aed3df : Essayer d'améliorer le comptage des régions équivalentes connectées dans les statistiques de la grille. Merci Tampa.
C'est une partie du code de Vincent Sylvester (Alias Tampa). Il corrige le problème du nombre de région dans les statistiques de la grille.
Ubit Umarov dit que ça ne marchera peut-être pas pour tout le monde.

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉

Bugs

Le serveur http tombe en panne sans qu'OpenSim ne le détecte

Historique

Évolution

L'erreur de socket s'est reproduite sur la version du 8 décembre avec la vérification de socket null d'origine. C'est la première fois depuis un mois.
Cuga Rajal n'avait pas lancé Tcpdump[1], il pensait que cela ne se reproduirait plus. Il va faire la mise à jour vers la dernière version aujourd'hui et lancer Tcpdump pendant les deux prochaines semaines.
Le Honeypot de Vincent Sylvester est toujours en marche, il a peut-être détecté quelque chose.

Journaux tcpdump lancé pendant la réunion

Problème

Dans un simulateur OpenSim, lorsque le serveur reçoit une requête qui inclut <methodName>get_server_urls</methodName>, il renvoie des données XML contenant les URL des serveurs.
Cuga Rajal pense qu'une des adresses renvoyées est inexacte. Toutes les adresses renvoyées indiquent rajal.org:9000 sauf l'URI du gatekeeper qui n'est pas correcte. De plus, cette adresse n'apparaît dans aucun des fichier ini de configuration de la standalone.
La réponse XML contient :

<member><name>SRV_GatekeeperURI</name><value><string>http://xxx.xxx.xxx.xxx:9000</string></value></member>

C'est une adresse Comcast. Cuga Rajal n'est plus chez Comcast depuis 8 ans.

C'est une réponse à une requête POST qui contenait :

  <?xml version="1.0" encoding="utf-8"? >
    <methodCall>
       <methodName>
              get_server_urls
       </methodName>
       <params>
            <param>
                  <value>
                       <struct>
                             <member>
                                  <name>
                                       userID
                                  </name>
                                  <value>
                                       <string>
                                               81b3fb03-3444-4a73-bb8b-f57558741520
                                       </string>
                                  </value>
                            </member>     
                      </struct>
                  </value>
            </param>
       </params>
   </methodCall>

Discussion

Ubit Umarov dit que la plupart des URL renvoyées sont définies dans un des fichiers de configuration du simulateur.

;;Extrait du fichier StandaloneCommon.ini
[LoginService] 
WelcomeMessage = « Bienvenue, Avatar ! » 
SRV_HomeURI = « ${Hypergrid|HomeURI} » 
SRV_InventoryServerURI = « ${Const|BaseURL}:${Const|PublicPort} »
SRV_AssetServerURI = « ${Const|BaseURL}:${Const|PublicPort} »

Cela pourrait être une requête vers une autre grille qui renvoie cela. Les utilisateurs Hypergrid peuvent afficher des URL qui peuvent sembler étranges.
Ubit Umarov pense qu'il s'agit de l'URL des serveurs des utilisateurs.
Normalement, cette adresse se trouve dans un fichier ini et pas dans la base de données. Mais, certaines peuvent être stockées sur le compte utilisateur. Les fichiers ini sont utilisés pour les utilisateurs locaux, mais en revanche quand il s'agit d'utilisateurs hypergrid, Ubit Umarov à l'air de dire que ce n'est pas très clair.

NDLR :

La suite a été discutée sur Discord. Je ne dispose pas de ces informations.

Projets en cours / Infos

Statistiques des grilles Opensim

Mises à jour des statistiques des grilles OpenSim de Vincent Sylvester. Les heures ont été ajoutées, une recherche et le code a été un peu nettoyé.
Pages des statistiques.

PrimItems : Code de Vincent Sylvester pas encore fusionné

Historique

2025-12-09 : Lecture écriture dans Primitems, bilan de la mise en production

Certains objets ne se chargent pas

Vincent Sylvester a reçu plusieurs signalements indiquant que certains objets ne se chargeaient pas.
Apparemment, Linden Lab a apporté une « correction côté serveur » pour cela, mais cela semble être lié au rendu ou au cache des objets. Cela pourrait être quelque chose du côté d'OpenSim qui n'envoie pas les données.

Problème avec la routine de liaison / déliaison des objets

Description

La routine de liaison et de déliaison ont endommagé un script. Sa nature asynchrone provoque des dysfonctionnements entre la scène et la base de données qui ne sont plus syncrhonisés.
Vincent Sylvester ne sait pas comment cela peut affecter un script. Il soupçonne que les modifications apportées à la routine de stockage des primitives ont mis en évidence ce problème et à quel point la routine de liaison est défectueuse dans OpenSim.

Observations

C'est relativement facile à reproduire. Sur une région vide, vous pouvez facilement le voir en regardant la table Prims. Rezzer un objet lié depuis l'inventaire de l'avatar. Déliez-le. Supprimez une partie. Reliez le reste. Reprenez l'objet lié dans l'inventaire de l'avatar. La scène est maintenant vide, mais la base de données affiche toujours des éléments. La prochaine fois que le cache de région est vidé, on retrouve l'objet lié ou la partie dissociée dans la région. La scène n'a pas eu le temps d'être interrogée pour détecter les changements. Ce qui est inquiétant c'est que cela n'avait jamais affecté un script.

NDLR :

Version OpenSim 0.9.3.0 Standalone vide , Mysql -- Objet : 16 cubes liés.
Chez moi, la base de données se vide quasi instantanément quand on supprime l'objet lié de la région. Peut-être que la scène n'est pas assez chargée ?

Si on ajoute un objet lié dans l'inventaire de l'avatar avant que la région ne remarque que les objets ont été liés dans la région, il est enregistrés dans la base de données de la région , mais la scène les supprime (NDLR : on ne le voit plus dans le viewer). La scène est vide, mais la base de données contient toujours l'objet. Lorsque le cache de la région est vidé, à la prochaine connexion, la scène est chargée depuis la base de données et l'objet apparaît dans la scène.

Discussion

Le problème s'est posé sur la version master d'OpenSim avec la routine pour PrimItems que Vincent Sylvester a modifiée il y a quelques semaines.
Le code de liaison des primitives ne modifie pas le contenu des primitives.
Le script aurait pu être détruit car la routine n'aurait pas trouvé le bon endroit ou le placer. Mais impossible de savoir comment l'identifiant de l'objet a pu changer.
Vincent Sylvester pense que la routine de PrimItems affecte le script mais que la cause sous-jacente est plutôt la routine de liaison des primitives asynchrone entre la liaison dans la scène et l'écriture dans la base de données.
Si une sauvegarde s'exécute après chaque action, cela ne pose pas de problème, mais si c'est la région qui écrit les données, comme elle ne le fait pas au moment où la scène est modifiée, cela peut entraîner un décalage.
Mais si la primitive et son contenu sont enregistrés, ils devraient être là. La dépendance du script à l'objet est l'UUID de l'objet, il devrait rester le même. C'est juste un symptôme plus grave du problème sous-jacent.
Ubit Umarov dit que la base de données effectue des suppressions stupides pour des raisons inconnues. Il faudra encore déboguer cela.
Vincent Sylvester se demande quel serait le résultat en termes de performances si cela était rendu synchrone, probablement assez mauvais. Ubit Umarov le confirme. Mais avec l'augmentation des performances, certains éléments asynchrones n'ont peut-être plus besoin d'être asynchrones pour être rapides. Peut-être serait-il préférable que la liaison de primitives prenne deux secondes pour s'assurer de la stabilité de la région.
La suppression dans la scène envoie aux viewers un message indiquant que l'objet lié a été supprimé afin qu'ils le suppriment aussi. Mais, il reste dans les collisions de la région jusqu'à ce que la prise dans l'inventaire se termine. Ainsi, la suppression ajoute ses propres vers aux tests lier/délier.
Les objets peuvent réapparaître dans la région si la région ne s'est pas arrêtée correctement.
Quand Ubit Umarov veut vraiment supprimer un objet, il le met simplement en temporaire.
Vincent Sylvester pense que plus d'autres éléments sont modifiés et fonctionnent plus rapidement, plus ces problèmes de synchronisation et d'asynchronisme sont mis au jour mais ils sont là depuis de longue date.
Ubit Umarov ne pense pas que la synchronisation soit en cause, il penserait plutôt qu'il existe quelques bogues qui dansent un peu partout.
Vincent Sylvester va essayer de reproduire le problème du script qui disparaît et voir si la nouvelle routine pour PrimItems est en cause. Il va rédiger un rapport de [[Réunion_du_13-01-2026&action=edit&section=21 | Mantis].

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2026-01-13