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.😉

Scripts

Fonction de validation des requêtes http

Problème

Vincent Sylvester a envoyé une requête HTTP vers une adresse IP blacklistée. En l'absence de mécanisme de gestion des erreurs, le script a planté.
La nature ouverte des erreurs expose des données sensibles ou peut être simplement gênante, car elles sont diffusées à tout le monde. C'est un sujet qui fait débat depuis des années.
Actuellement, il n'existe aucun moyen de « tester » une requête HTTP pour s'assurer qu'elle ne plante pas. Le script échoue simplement avec une erreur, ce qui expose publiquement l'adresse de la requête, entre autres, ce qui n'est pas idéal. De plus, Si la requête plante, le script ne reçoit aucune information précise sur ce qui a échoué, donc on ne peut pas non plus gérer le problème.
Impossible de le gérer avec try catch non plus, car ce n'est pas une exception en tant que telle.

NDLR :

try-catch est une structure de gestion des erreurs utilisée dans la programmation pour traiter les exceptions, c'est-à-dire les situations imprévues qui peuvent survenir lors de l'exécution d'un programme.

Solutions

Vincent Sylvester a écrit une fonction de validation pour les requêtes HTTP. La fonction renvoie des entiers correspondant aux types d'échec ou true s'il n'y a pas d'échec. Cette fonction indique clairement si une connexion peut être établie à partir des paramètres de la requête. Le cas d'utilisation est la validation d'URL, de DNS, de paramètres et d'en-têtes. La fonction doit encore être testée.
Cela devrait ralentir le script. Vincent Sylvester ne recommanderait pas d'utiliser cela à chaque requête, mais peut-être comme moyen de vérifier d'abord si les paramètres fonctionnent ou si l'adresse peut être résolue.
Limiter les messages aux propriétaires des scripts pourrait être une solution, mais les propriétaires de la région et du domaine ont parfois besoin d'accéder aux erreurs de script et signaler l'erreur à tout le monde est une bonne tactique pour que les scripts soient corrigés.
Il serait théoriquement possible d'utiliser une fonction de requête HTTP pour lancer des exceptions gérables via try-catch, mais cette approche n'est pas documentée et ne suit pas les conventions habituelles de LSL.

Notecards invasives

Vincent Sylvester a remarqué cette semaine que certaines notecards ont augmenté rapidement sur la grille ZetaWorlds (10 000 par semaine pour certaines, 1 500 pour d'autres).
La crainte de perdre des données en raison des redémarrages semble pousser certaines personnes à enregistrer des fiches toutes les 5 minutes.
L'utilisation de notecards pour enregistrer des données reste un problème, car un nouvel asset est créé à chaque modification du contenu. Les notecards prennent une place inutile sur les serveurs de données.

Tests

Ramasse-miette (GC), Warp3D et fuite de mémoire

Problème

Vincent Sylvester a fait quelques tests cette semaine et il a remarqué un comportement intéressant du ramasse-miettes(GC) en ce qui concerne la génération de maptiles (carte de région/tuile de carte). L'utilisation de Warp3D pour générer les tuiles au démarrage semble faire exploser la consommation de mémoire, car ce module bloquerait le ramasse-miettes (GC), empêchant la libération de mémoire une fois les maptiles créées. Chaque nouveau simulateur augmenterait également l'utilisation de la mémoire de 25 Mo. Cependant, en créant des tuiles avec le module de base MapImageModule puis en passant ensuite à Warp3D, on observe également une augmentation de la consommation de mémoire, mais le ramasse-miettes finit par tout effacer.
Il fait ça tous les jours et il voit les pics de mémoire monter et descendre. Il doit faire des tests spécifiques. Il soupçonne qu'une partie de l'utilisation de la mémoire sert à stocker la tuile de carte dans la scène plutôt que dans les assets. Donc, il s'attendait à une utilisation plus importante de la mémoire, mais pas autant et avec ce comportement étrange.

Discussion

ubit Umarov dit qu'il n'y a pas de bug, c'est CG qui fait un peu ce qu'il veut. C'est m ieux qu'avec Mono mais, ce n'est pas encore ça. De plus Warp3D utilise beaucoup de mémoire. Le module dessine entièrement la région, donc il doit tout récupérer.
Ce qui étonne Vincent Sylvester c'est l'augmentation linéaire de la mémoire. Le premier simulateur utilise 400 Mo, le suivant 425, puis 450, etc. La même chose même pour des régions vides sans rien dedans. Le fait de démarrer les simulateurs les uns après les autres sans leur laisser le temps de se stabiliser pourrait jouer un rôle. Ce n'est probablement pas le code, c'est quelque chose dans le runtime qui ajoute de la mémoire par instance pour une raison quelconque.
.NET met en cache une tonne d'informations système et autres au démarrage d'une application, donc il y a peut-être un bug à ce niveau.
Le fait de dissocier la génération des tuiles de carte du processus de démarrage a considérablement réduit la charge. Vincent Sylvester désactive complètement cette fonction et génére les tuiles de carte plus tard. Après les appels à la base de données, c'est la fonction la plus lourde.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-07-08