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 ?

Priorité des liens à date identique

Comment doivent être interprétés des liens différents et dont la date est identique. Ce peut être le cas d’un lien de type u ayant strictement la même date qu’un lien identique mais de type x.

Est-ce qu’il y a un ordre préférentiel de lecture, et donc inversement de prise en compte ?
Le lien de type x est-il plus important que le lien de type u ou f par exemple?

Aujourd’hui, les implémentations de références doivent traiter les liens dans l’ordre tel que définit dans la documentation de référence. Donc le lien x devient implicitement, par ce que étant le dernier appliqué, celui qui a le plus de poids.

Référence des librairies en bash

L’entité bachue commence sont rôle de diffusion de logiciels signés.

Le tout premier est logiquement la librairie nebule en bash puisque c’est l’implémentation la plus avancée à ce jour.

Déploiement

Un objet dédié contenant « nebule/bachue/reference/bash », de hash 2d0468b3153a1a43861ada08cc0a209df138f581df61b8ebc4cf022ee3d83aef, permet de suivre l’évolution des version successives de la librairie. Pour cela, un lien de type f est fait entre cet objet et les objets successifs contenants les différentes versions de la librairie.
Un autre lien de type u est fait directement entre deux versions successives de la librairie.

Annulation

Si une version de la librairie doit être annulée, il y a plusieurs méthodes possibles qui aboutissent à ce résultat :

  1. La première méthode est de déployer une nouvelle version de la librairie et de faire un lien de type u entre la version à annuler et la nouvelle version. Normalement, toutes les entités devraient ainsi mettre à jour leur copie de la librairie avec la nouvelle version, ce depuis la version à annuler ou depuis une version antérieur.
  2. La seconde méthode est d’annuler le lien de mise à jour (type u) avec un lien de type x. Dans ce cas, toutes les entités avec la version de librairie à annuler devraient ainsi mettre à jour leur copie de la librairie vers la version précédente en attendant une nouvelle version. Les entités avec une version antérieur de la librairie s’arrêteront naturellement à la version précédent la version à annuler, en attendant aussi une nouvelle version.
  3. Une troisième solution pourrait être d’ajouter un lien de type u en sens inverse, c’est à dire entre la version de la librairie à annuler et la version précédente. Cependant, cela crée une boucle dans les liens de mises à jour d’un objet avec tous les risques de boucles infinies à gérer que cela entraîne. C’est une solution similaire à la deuxième solution.

dans tous les cas, par sécurité on peut demander la suppression de l’objet contenant la librairie à annuler avec un lien de type d.

La seconde méthode me paraît plus hasardeuse dans le sens où elle nécessite une régression dans la mise en application des versions de la librairie. Cependant elle à le mérite de pouvoir répondre immédiatement à un problème sans attendre la mise en place rapide d’une nouvelle version.

Attention, la version actuelle de la librairie ne tient pas encore compte des liens de type u, x et d. Ce développement devrait arriver assez rapidement pour couvrir ce besoin de gestion des références de logiciels.

Ralentissement des échanges à débit constant

Je commence à voir ressortir un problème que je ne pensais pas avoir à régler si tôt.

Le nombre d’objets augmente, et avec, les liens associés aussi. Or lorsqu’un robot par exemple synchronise les liens d’un objet pivot, que l’on peut plutôt appeler un nÅ“ud, il télécharge systématiquement l’intégralité des liens… et vérifie leurs signatures.
Tant qu’il n’y en avait pas beaucoup, ça ne se sentait pas trop sur le temps de synchronisation. Mais ça commence à se voir aujourd’hui sur certains objets.

Une des solutions serait de voir si le lien est déjà connu. Cela oblige à parcourir l’intégralité des liens d’un objet qui justement peut en contenir beaucoup. On va gagner à court terme sur le traitement des liens. Mais on continue à télécharger des liens inutilement.
Et que ce passera-t-il lorsque la recherche de la présence du lien sera plus longue que la vérification de sa signature?
Bref, cela ne fait que reporter le problème à plus tard…

Il faut résoudre ce problème de façon plus élégante. Cela peut être fait en demandant les liens après un lien particulier, le dernier que l’on connaît déjà.
Cela oblige à implémenter la fonction côté entité, mais aussi côté serveur. Or la façon dont les serveurs web délivrent les liens et objets ne se pas prête à ça. Il faut leur ajouter un peu plus d’intelligence.

D’un autre côté, la vérification si le lien est déjà présent est réalisée juste avant de l’ajouter à un objet… On aura aussi un problème à résoudre à cette étape là…

Auto-vérification automatique périodique – 2

Suite à la mise en application automatique de la vérification des objets et liens, il y avait eu des pertes.

Je n’ai pas essayé de restaurer les objets qui n’ont pas d’importance ici. Mais j’ai restauré les liens depuis une autre entité. La restauration répare en grande partie les liens.

Le résultat est visible :

Auto-vérification automatique périodique

Une des expériences en cours est la vérification automatisée et à intervalle régulier de tous les objets et de tous les liens des objets.

Les objets sont faciles à vérifier, on calcule leur empreinte et on vérifie qu’elle correspond à leur nom. Si elle diffère, on le supprime. Si l’objet n’a pas de liens, il est jugé comme une pièce rapportée, on le supprime aussi.

Les liens sont assez faciles à vérifier aussi. Il faut procéder objet par objet, prendre les liens un par un et vérifier que la signature est valide pour l’entité qui l’a générée. Si la signature diffère, on supprime le lien. Si l’entité est inconnue, la signature ne pourra être vérifiée, le lien est donc supprimé aussi.

Ce petit bout de script reste assez simple et doit être testé soigneusement pour éviter des dommages collatéraux. Il m’avait semblé l’avoir testé suffisamment… mais visiblement il y a eu des dégâts pour certaines entités.

Voici notamment le résultat sur les sauvegardes de la machine zulu (à comparer à ce graphe ci) :

On peut encore allez plus loin. Non dans les dégâts collatéraux mais dans une forme plus poussée d’immunisation. L’entité peut entretenir une liste d’objets jugés dangereux, et donc à supprimer. Elle peut et surtout doit aussi se référencer à une entité dédiée au marquage d’objets dangereux, c’est le rôle justement de cerberus

Continuer la lecture de Auto-vérification automatique périodique

Chiffrement fonctionnel vers une entité tierce

Le chiffrement est fonctionnel vers une entité tierce. Toujours sans pré-compression des données.

Cela donne ce type de graphe pour le chiffrement de multiples objets vers une entité :

CF :
Chiffrement fonctionnel
Chiffrement et type mime
Chiffrement et vecteur initial
Chiffrement et compression
Introduction à la cryptographie