Catégorie : pondération

Quantification commune de la disponibilités des relais

Les quelques entités robot que je teste sont maintenant tout à fait capable de synchroniser des liens et objets divers. Le problème est souvent de savoir ce que l’on veut synchroniser en fait.

Chaque robot essaye de télécharger un objet sur toutes les autres entités qu’il connaît. Ou plus exactement sur toutes les localisations qu’il connaît, même si ce n’est pas une entité connue. Le téléchargement est actuellement unitaire. L’objet téléchargé doit être complet, on ne prend pas un bout à un endroit et le reste ailleurs comme avec le P2P habituellement. Ce raffinement sera pour plus tard. Et l’ordre des localisations est toujours parcouru de la même façon, c’est à dire dans l’ordre des liens de ces localisations avec l’objet qui les référence.
Évidement, la vérification de l’intégrité des objets et la vérification des signatures des liens associés permet de ne pas se soucier de savoir sur quel entité relais l’objet est téléchargé.

Ce système est assez primaire mais il remplit parfaitement son rôle. Cependant, en terme de performance, on peut faire mieux…

Une des solutions peut être d’enregistrer systématiquement le débit moyen de téléchargement d’un objet sur une localisation particulière. Des statistiques vont commencer à s’accumuler avec le temps et le robot pourra ensuite privilégier certaines localisations en fonctions de leurs statistiques.
Si chaque mesure de débit moyen est lié à la localisation comme étant une statistique, l’ensemble des statistiques des entités peuvent se propager d’une entité à l’autre. Ainsi c’est l’ensemble des robots qui peuvent profiter des statistiques pour affiner le classement des localisations.
Il faut quand même ne pas tout prendre brute quoiqu’il arrive. Des statistiques anciennes n’ont que peu de valeur. De même, comment interpréter les statistiques d’une entité à l’autre bout du monde, et donc qui a des temps de latence différents ? Une moyenne non pondérée entre les statistiques de toutes les entités est-elle suffisante pour gommer des valeurs anormales de débit moyen ?

Objets privés et fonctionnement interne

Il existe des informations que l’on ne peut gérer par les liens nebule sous peine de fortement complexifier son fonctionnement, et donc la compréhension que l’on en a dans son ensemble.

Par exemple, c’est le cas pour mettre un poids à un objet. C’est à dire lui attribuer une méta information qui décrit son importance relative aux autres objets. C’est une notation en quelque sorte.
Un poids peut être fixé arbitrairement. Ce n’est pas le meilleur cas même si c’est réalisable en pratique. Le poids d’un objet a surtout de forte chance de refléter l’importance que l’on donne à cet objet. A cet objet pondéré sont liés d’autres objets. Ces autres objets, si leurs poids ne sont peut-être pas explicitement définis, vont hériter d’une moyenne des poids des objets autour. Ainsi, un objet va gagner de l’importance si il est lié à un objet jugé (donc pondéré) très important.
De ce poids peut en découler des conséquences concrètes. Par exemple si l’on permet l’oublie et l’effacement d’objets anciens de façon calculé et contrôlé, la pondération permet de conserver très longtemps un objet important.

Cette pondération des objets qu’une entité va réaliser est un travail ‘personnel’. Le fruit de ce travail peut avoir un intérêt public. Et une autre entité ayant fait le même travail ne donnera pas les mêmes pondérations.
Cependant, une partie de ce travail de pondération peut être jugé privé. Si le partage d’une pondération d’objets peut être réalisée simplement par des liens, comment protéger les pondérations privées ?

Une des possibilités est d’exploiter les objets stockants des liens.

Mémoire fini

On part souvent du principe que l’on va gérer nos données en les accumulant dans le temps de façon infinie…

Mais est-ce vrai?

C’est en partie vrai.

Les capacités de stockage évoluent assez rapidement dans le temps. Nous enregistrons de nouveaux fichiers assez régulièrement dans le temps mais pas forcément de façon continu. Ici, pour la réflexion, on ne va retenir qu’une moyenne constante d’enregistrement de données.

Que se passe-t-il si on ajoute régulièrement suffisamment de capacités de stockage, suffisamment pour ne jamais arriver à saturation?
Tout se passe bien, on ne perd rien.

Et si la capacité de stockage n’augmente pas assez vite (dans le cas extrême où elle ne peut plus être augmentée) ?
C’est dans ce cas que doit être prévu un mécanisme de nettoyage (d’oubli), et donc de pertes maîtrisées.

Le stockage de données sous la forme proposée pour nebule risque dans certains cas de générer, et donc de stocker, énormément de données. On doit prévoir ce mécanisme d’oubli nativement.

La perte d’information maîtrisée impose de permettre cette gestion à la main. Mais quelle efficacité d’une gestion à la main pour plusieurs millions de fichiers?
Des mécanismes d’assistance ou d’automatisation doivent être proposés. Ils peuvent avoir plusieurs formes.

Sur quels critères déclarer un fichier périmé?
Plusieurs critères peuvent être pris en compte, et plusieurs combinaisons complexes peuvent être calculées de critères simples :
– le temps de possession de l’objet, plus il est vieux plus il a de chance d’être périmé ;
– si le fichier dispose d’une nouvelle version, il n’est peut-être plus intéressant de le conserver ;
– l’attractivité, ou un critère d’appréciation, donne de l’importance à un fichier dans le temps et doit faciliter sa conservation ;
– l’intensité de l’appréciation peut être exploitée en absolu, un fichier qui appel un très fort sentiment positif ou négatif a des chances de devoir être conservé longtemps ;
– un fichier lié à plusieurs autre fichiers jugés importants a surement besoin d’être lui aussi conservé, il va peut-être hériter par calcul d’une note d’appréciation ;
– d’autres fichiers font références à ce fichier, il faut sûrement le conserver ;
Рmes amis ont gard̩ ce fichier, il doit ̻tre important.

Doit-on supprimer immédiatement un fichier périmé?
Celui-ci peut peut-être servir à quelqu’un d’autre? A-t-on la place de le garder en attendant? Peut-on se contenter de le supprimer lorsque l’on aura besoin de la place qu’il occupe? Doit-on les marquer périmés en attendant ou gérer une liste des objets périmés?
L’analyse des fichiers à marquer peut se faire en continu, moyennant une occupation constant et relativement importante de ressources. L’analyse peut se faire lors d’une phase de repos (activité de sommeil). Une liste peut aussi être maintenu en temps réel sans analyse, juste en classant les objets de façon croissante dans une liste et en faisant évoluer la place des objets en fonction de l’évolution de leurs paramètres.

Une fois un objet marqué comme périmé, comme propager son marquage? C’est à dire, comment vont se comporter les relais avec ces objets dits périmés?
Cette propriété de péremption doit-elle être visible des entités tierces? Ou est-elle purement interne?