Première version "stable" de dunipod: v0.10.0

[Chiara07]

@Claude

C’est une question à poser maintenant plutôt qu’au moment de basculer : existe-t-il un Dunipod Ğ1 prévu, et quand ? Si la réponse est « pas avant des mois », ça change l’ordre :
autant soigner ce qui sert aussi à Squid.

Ce que je propose ensuite : le jalon 3, le modèle de coût

Trois raisons, dans l’ordre de leur poids.

Il est vérifiable. Les vecteurs normatifs existent, la formule est écrite (min(30, 1 +
max(F div 5000, W div 800) + 9 * E)). C’est du calcul qu’on peut confronter à une
référence, pas de l’interprétation. Je sais faire ça bien et le prouver.

Il conditionne les deux jalons suivants. Une requête syntaxiquement valide peut être refusée pour son coût. Écrire la pagination du jalon 4 ou les souscriptions du jalon 5 sans savoir ce qu’on a le droit de demander, c’est prendre le risque de les réécrire.

Il ne touche à rien qui fonctionne. Comme la découverte, il s’ajoute à côté sans passer par les cinq switch du chemin Squid.

L’ordre que j’en tire

1. Jalon 3, le modèle de coût et la lecture des en-têtes de quota.
2. Finir le jalon 2 : type d’endpoint, persistance, classement, endpoint imposé — avec le connecteur, d’un seul tenant, pour ne pas laisser de branches mortes.
3. Jalon 4, pagination par curseurs opaques. Il ferme #250 et #249, et le premier morceau est déjà fait dans durt!14.
4. Jalon 5, les souscriptions. Le gros morceau, une réécriture : trois flux d’événements là où nous en avons sept par entité.
5. Jalon 6, mode explicite puis bascule — qui suppose le pod Ğ1.

ce qui a ete fait :

@Claude

La découverte Dunipod est faite, et validée sur le réseau réel.

durt!15 — Making sure you're not a bot!
Ma première branche interne sur durt2, grâce à tes nouveaux droits. Indépendante de !14 :
ce service n’utilise aucun type généré, seulement HTTP et JSON.

Le point qui structure tout. otherDunipods n’annonce aucun réseau. Rien dans la réponse ne dit quelle chaîne le pod indexe — les pods de deux chaînes s’annoncent mutuellement sans distinction, et un pod de la mauvaise répond à toutes les requêtes par des données
plausibles et sans rapport. Une annonce est donc une indication d’où chercher, jamais une affirmation sur ce qui s’y trouve. Chaque candidat est interrogé sur son propre dunipodStatus et retenu seulement si chainId correspond, si la genèse est complète et s’il
se déclare prêt pour le public — parce qu’un pod qui importe encore son historique répond aussi, mais avec des trous.

Mesuré en conditions réelles. Une seule graine mène aux trois pods ĞTest, tous au bloc 4 960 278, à 2 secondes de retard, en 0.9.1-dunipod.

Et cette mesure a rattrapé un défaut que mes tests ne voyaient pas : l’horodatage porte déjà son décalage (…+00:00), et lui ajouter un Z produisait une date illisible, donc un retard toujours nul. Mon test passait parce qu’il utilisait le format que j’avais supposé.
C’est l’argument pour éprouver le contrat contre le vrai service, pas seulement contre l’idée qu’on s’en fait.

Aucun pod Ğ1 n’est connu : j’ai laissé cette liste vide plutôt que d’inventer des adresses. À signaler, ça conditionne la suite.

Ce que je n’ai pas fait, volontairement. Pas de nouveau EndpointType : il est lu par cinq switch dans trois fichiers au cœur du chemin Squid qui marche. Le câblage du registre ira avec le connecteur qui s’en servira, plutôt que cinq branches mortes en attendant. Restent donc pour finir le jalon 2 : le type d’endpoint et sa persistance, le classement par latence et échecs récents, le rafraîchissement en arrière-plan, et le comportement d’un endpoint imposé.

État des lieux : 3 MR ouvertes — gecko!169 (accents), durt!14 (codegen + dividendes), durt!15 (découverte). analyze propre partout, 326 tests durt2 et 837 Ğecko.

Outillage et historique : débloquer la génération de code, puis paginer les...

Dunipod : découvrir les pods et savoir lesquels servent notre chaîne (!15) ·...

[elois]

@Claude

otherDunipods n’annonce aucun réseau

@Chiara07 N’hésite pas à ouvrir des issues sur le dépôt de Dunipod pour demander des améliorations.

Par exemple, on pourrait ajouter l’identifiant de réseau des autres pods indiqués dans otherDunipods. Toutefois, un Dunipod n’annonce déjà dans otherDunipods que des pods du même réseau, donc l’information ferait doublon avec le réseau déjà déclaré par le pod.

Dans tous les cas, un pod malveillant ou buggé peut mentir ou se tromper, donc cela n’enlèverait pas la nécessité de vérifier le réseau indiqué par chaque nouveau pod auquel l’app se connecte.

[Chiara07]

correction

@Claude

● Correction poussée et créditée sur !15. Le contrôle ne change pas d’un iota, seule sa raison change — et la sienne est meilleure : la confiance ne se transmet pas d’un pod au suivant, parce qu’une annonce n’est pas signée. C’est plus solide que mon « les réseaux se mélangent », qui était simplement inexact.

[EDIT]

@Claude

● Jalon 2 fini et poussé dans durt!15, qui porte maintenant les jalons 2 et 3 d’un seul tenant (pas de branche empilée, pas de branche morte).

Ce qui est fait

Type d’endpoint. EndpointType.dunipod est un troisième type, pas une variante de squid. Le compilateur a listé les 5 switch non exhaustifs, tous traités :

• chargeurs d’amorces (registre, bootstrap, découverte) → config/dunipod_endpoints.json ;
• le switch du peering → const : un nœud Duniter n’annonce jamais de pod, donc rien n’en sort ;
• le testeur d’endpoint → délègue à la sonde de la découverte, au lieu d’en écrire une deuxième copie du contrat dunipodStatus.

Le piège que ça a révélé. getCustomEndpoint faisait type == rpc ? ‘customEndpoint’ :
‘customIndexer’ : ajouter dunipod lui donnait silencieusement la case de Squid. Un pod et un Squid ne parlent pas le même schéma — chaque requête serait partie au mauvais serveur, et la première adresse posée aurait disparu. Trois cases distinctes maintenant.

Classement. La fraîcheur d’abord, la latence ensuite, avec un seuil de 6 s entre les deux.
La mesure sur les trois pods gtest justifie le seuil : même bloc, 4/4/5 s de retard, mais 286 / 287 / 539 ms de latence. Sans seuil, 1 s de bruit de mesure aurait décidé à la place de 250 ms réels. Au-delà d’une demi-heure de retard le pod est refusé : il répond vite et faux.

Échecs récents. Mise de côté 30 s, doublant jusqu’à 15 min — sauf si tous les pods refroidissent en même temps, auquel cas c’est notre connexion qui est en cause et on réessaie quand même.

Pod imposé (le point que l’issue demandait de trancher) : il gagne sur un plus rapide, il n’est jamais effacé pour une panne (la sonde a pu tourner hors ligne), un autre prend le relais par défaut, et qui l’a imposé exprès peut refuser tout remplaçant. J’ai signalé dans la MR que le connecteur Squid actuel, lui, efface le réglage de l’utilisateur dans ce cas — allowFallbackFromCustom est écrit pour les deux types si poka veut aligner Squid plus tard.

Mode explicite. Durt.i.connectDunipod() existe et est atteignable, mais rien ne sélectionne un pod tant qu’on ne le demande pas : les lectures passent toujours par Squid.
C’est le jalon 6 qui bascule.

Vérifications

flutter analyze propre, 414 tests au vert dont 16 nouveaux, plus la sonde contre les trois vrais pods gtest.

Un test existant a cassé et je l’ai corrigé plutôt que contourné :
endpoint_registry_test.dart affirmait EndpointType.values.length == 2.

Reste sur #252 : la moitié du jalon 3 (en-têtes RateLimit, budget partagé, arbitrage attendre/dégrader/changer de pod), puis les jalons 4, 5, 6. Et la question ouverte pour poka tient toujours : aucun pod Dunipod Ğ1 connu, donc le jalon 6 n’a rien à viser sur la Ğ1.

QUESTION:

@Claude

Posée en questions pour @poka et @elois : des pods Ğ1 sont-ils prévus et par qui, faut-il une entrée d’amorçage dès le premier, et en attendant est-ce qu’on peut livrer le mode
Dunipod activable uniquement là où un pod répond. J’ai précisé que ça ne bloque que le jalon 6 : les jalons 1 à 5 se développent sur la ĞTest sans rien attendre.

[elois]

@Claude

des pods Ğ1 sont-ils prévus et par qui

Il y a déjà 3 pod Ğ1 en prod, un hébergé par @HugoTrentesaux et le deux autres par moi-même:

g1pod.elo.tf
g1pod2.elo.tf
dunipod.g1.gyroi.de