Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses

[Estian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Lourdais wrote:

| Bonne année à tous.

Bonne année!

|
|
| Bon je fais une réponse groupée à vos commentaires.
|
| Parenthèse pour commencer : dans le scénario du point 2) de mon mail,
| l'id du noeud était vraiment mal choisi, donc s/127.0.0.1/A/g par exemple.
|
|
| estian>
|
| > Il me semble que les noeuds 'pas de confiance' ne devraient avoir que
| >  des rôles passifs, et donc ne pas être capable de relayer des
| >  messages, donc ne devraient jamais apparaitre dans la liste des
| >  propagateurs.. des opinions divergentes?
|
|
| zedek>
|
| > Tout à fait d'accord. Si on commence à donner des pouvoirs à des noeuds
| > 'non vérifiés' (pas de confiance) la gestion va devenir des plus
| > difficiles.
|
|
|
| ok (celà dit, imho cette gestion coûterait plus cher mais ne serait pas
| forcément plus difficle, mais bon...)
|
| estian>
|
| > hmm.. va falloir que j'y réflechisse à tête reposée, mais il me semble
| > que ton algo ne marche bien que si les messages viennent bien du même
| > node, or a priori le chemin des messages ne sera pas déterministe..
|
|
| Bon je vais être obligé de démontrer le lemme ("Si je reçoit un message
| daté d1 depuis le noeud h, je suis sûr d'avoir déjà reçu tous les
| messages datés d B reçoit plusieurs
| séquences entrelacées contenant chacune les messages de A dans le bon
| ordre => pour chaque message de A, B est sûr d'avoir reçu les précédents
| depuis le même voisin (chacun d'entre eux ayant pû être ignoré si et
| seulement si il a été précédemment délivré par un autre voisin), càd
| lemme vérifié à l'étape n
| - donc lemme vérifié \o/
|
| estian>
|
| > En
| > particulier, quid du scénario suivant :
| >
| > post 'pika' sur 10.0.0.1 à 42:42:42
| > post 'plop' sur 10.0.0.2 à 42:42:43
| > le noeud 10.0.0.3 se trouve recevoir ses posts en ce moment de 10.0.0.2
| > il reçoit immédiatement 'plop', mettons à 42:42:43 (le réseau est
| > rapide). à 42:42:44, 10.0.0.2 reçoit 'pika' de 10.0.0.1, et propage vers
| > 10.0.0.3 (on suppose que la connectivité du réseau est telle que les
| > messages arriveront le plus rapidement en suivant le chemin que je
| > décris). à 42:42:45, 10.0.0.3 reçoit 'pika' de 10.0.0.2, mais horodaté à
| > 42:42:42 (par 10.0.0.1, le noeud de départ), et drop donc le message.
| > J'oublie quelque chose, ou il y aurait effectivement un problème?
|
|
| nan, pas de pb, c'est bien çà (je m'attendais à une tentative de
| contre-exemple :)

Euh.. le contre-exemple c'est que dans mon scénario, 10.0.0.3 n'ajoute
jamais 'pika' à sa liste de posts, donc c'est Mal.. peut-on être sûr
qu'il le recevra d'un autre node? (quid si ils sont que ces 3 là?
peut-on garantir que ce scénario ne peut pas se répéter sur chacun des
nodes susceptible de propager vers 10.0.0.3?)

|
|
|
| zedek>
|
| > Oula va falloir que je branche mon cerveau là parce que effectivement
| > l'algo d'Olivier n'est pas si évident que ça à suivre ;-)
|
|
| héhé, mais le principe me parait assez simple à la base ;)
|
| estian>
|
| > Je pense que tu as raison, mais euh.. on n'a pas non plus des mouling
| > agents trans-luminiques.. il me semble (amha et tout) que le cas serait
| > très rare, faudrait que le coin² rafraichisse pile-poil au mauvais
| > moment et tout.. du coup, est-ce vraiment la peine de compliquer, ou
| > peut-on accepter le risque comme 'raisonnable et non bloquant'? à voir,
| > en tout cas
|
|
| Pas vraiment d'accord.
| C'est une sorte de race condition, il ne faut _jamais_ les négliger.
| Surtout qu'il est très difficile d'en estimer la proba et les
| conséquences à l'usage.
|
|
| zedek>
|
| > Ah non pas d'accord. Bitobi doit être gruik, c'es entendu mais doit
| > être blindé pour ça AMHA.
|
|
| [+]
|
| estian>
|  > Alors, remarque : le distinguo entre posts de même horodatage est une
|  > feature coin²-only, c'est pas prévu dans la version html de la tribune.
|  > en fait, c'est géré dans wmc², mais je sais pas pour les autres mouling
|  > agents, en fait. soyons donc bien conscient que si on essaie de blinder
|  > l'ordre des messages, c'est une modification fonctionnelle à la
| tribune.
|
| pas du tout, efface
| le suivi visuel avec les horloges (avec mise en exergue) est une feature
| indispensable à un mouling agent, il doit être dispo dans tous les coin²
| (au moins wmc² et pyc²), il y a aussi une surbrillance avec les pdfm,
| donc a priori çà doit être implémentable dans une interface html.
| et même en l'absence de surlignage, les horloges ont le même rôle (même
| si çà demande plus d'efforts)

Je dis pas que c'est pas possible en html, je dis simplement que
aujourd'hui ça n'existe pas dans les bouchots, et en particulier le cas
décrit ou un post change de sous-numéro ça m'est déjà arrivé (rarement,
mais au moins 2 fois) avec le coin² actuel. Alors on peut tout à fait
travailler pour trouver un moyen de garantir une norloge unique à chaque
post, mais ça sera une nouveauté, la tribune jusqu'à présent
garantissait un *ID* unique par post, pas une *norloge* unique (du
reste, les petits exposants sont rajoutés à la tentacule par le mouling
agent)

|
|
| estian>
|  > ~ Et plus j'y réfléchi, plus le seul moyen de garantir qu'on fait bien
|  > référence au même post, c'est d'utiliser l'id plutôt que la norloge, et
|  > ça ça puxorerait grave pour les moules-broutteur.
|
| ouaip, çà serait le truc le plus facile à implémenter, mais c'est
| carrément pas fonctionnel (et pas seulement pour l'interface html : je
| vois pas trop comment un coincoin pourrait s'y retrouver facilement avec
| çà)
|
| estian>
|  > Alors si quelqu'un a
|  > une autre idée.. (en fait, on pourrait imaginer une sorte de
| buffer, qui
|  > permettrait de limiter les risques.. genre, au temps t=42 on n'inclue
|  > dans le backend que les posts jusqu'à t=41, pour laisser le temps à
|  > d'éventuels retardataires.. et ensuite on classe les posts
|  > arbitrairement en fonction de l'id.. mais ça me parait plus gruik
|  > qu'autre chose.
|
| effectivement c'est gruick ;-)
| et comment s'assurer que le delta-t est suffisant ? (on ne peut pas
| faire d'hypothèses fiables sur le moment de l'arrivée de chaque post)
| de plus, la bufferisation augmenterait la latence apparente

ouais, c'est clair que c'est pas optimisé comme idée

|
|
| estian>
|
| > à la louche, je
| > dirais : demandons-nous d'abord si il est nécessaire d'avoir une
| > connaissance plus complexe du bitobi que 'tel noeud est up, tel noeud
| > est down'. Si oui, alors faut trouver un bon algo, et là je vous laisse
| > oeuvrer ;)
|
|
| Si on veut assurer le meilleur fonctionnement possible (minimiser le
| temps de propagation d'un message, ne pas concentrer la charge sur
| quelques noeuds, ...), il faut fournir à tout noeud qui veut se
| connecter les informations nécessaires, et donc connaître en permanence
| l'état approximatif (mais néanmoins détaillé) du réseau (ce qui peut
| aussi amener des noeuds à modifier leurs connexions)
| Et je pense qu'on peut y inclure un max d'infos dès le début (tant que
| çà coûte pas trop cher), étant donné que les algos qui utiliseront ces
| donnés seront non normatifs et à la discretion des implémentations (de
| noeud et de mouling agent).

mouais, je suis pas trop d'accord avec le "non-normatif".. si on se
casse à définir un jeu d'information que les nodes mettent à disposition
de leurs pairs en vu d'optimiser la répartition de charge et tout, ou
d'optimiser la propagation des messages, etc.. l'interface en question
devrait être vachement normative, et faire partie de standard 'bitobi'

|
|
| estian>
|
| > qu'entends-tu par "passifs"? il me semble qu'on était parti sur une
| > archi en 'push' : chaque node informe ses copains qu'il a une info.. un
| > noeud passif devrait donc être inscrit dans la liste de pairs, ça
| > implique de prévoir deux types de noeuds au moins dans les tables.. pas
| > impossible, mais est-ce nécessaire? les noeuds 'passifs' ne
| > pourraient-ils pas se contenter du xml/html comme les mouling agents?
|
|
| un noeud passif est vu comme n'importe quel noeud par les autres noeuds,
| il est connecté à un seul noeud, le noeud auquel il est connecté lui
| fournit tous les messages reçus et diffuse aux autres noeuds tous les
| messages qu'il lui envoie, a priori la seule différence est la façon
| dont ils sont traités dans les stat réseau
| La distinction noeuds/noeuds passifs apporte imho une simplification en
| ce sens :
| - les noeuds n'ont pas d'autre traitement à effectuer que la diffusion
| des messages (indifféremment à leurs voisins ou à leurs noeuds passifs)
| - les noeuds passifs reçoivent chaque message une fois et une seule et
| peuvent se concentrer sur une tâche (ex : maintient d'un backend/page
| html, ...)

mouais, faut voir.. le début de ta définition me plait bien, ça
ressemble à des relais, j'imagine que ça peut aider à la propagation..
en revanche, après tu dis que ces noeuds passifs sont susceptibles de
maintenir un backend (pourquoi pas), et/ou une page html.. et là ça me
parait pas bon. page html => interface de postage. Le noeud n'est plus
passif, je pense, ou alors il y a quelque chose qui m'échappe dans ta
définition

|
|
| estian>
|
| > L'interface ne pourrait-elle pas être comprise dans le noeud? et aller
| > chercher les posts à afficher directement dans la couche persistente,
|
|
| çà oblige à avoir une couche de persistance (avec l'archi que je
| propose, çà pourrait juste être un noeud passif muet facultatif)

Hmm.. sans couche de persistence, comment garde-t-on le logs d'éventuels
boulays pour envoyer à abuse? comment peut-on vérifier qu'on a oui ou
non dejà reçu un message donné? le XML pourrait servir à lui tout seul
de stockage, probablement, mais moi en tout cas je suis en faveur de
prévoir une vrai couche persistente, qui serve à générer le backend
etc.. D'autres avis?

|
|
| estian>
|
| > ou
| > à defaut la recevoir 'programatiquement', plutôt que comme un message de
| > noeud à noeud?
|
|
| çà serait à mon avis plus lourd : çà oblige le noeud à savoir parler à
| l'interface

oui, ça me parait pas optimal à moi non plus

|
| les noeuds passifs correspondent en fait à des couches de plus haut
| niveau (-> meilleure séparation des couches)
| et là on aurait l'avantage d'avoir le même protocole pour les
| correspondances :
| - noeud <-> noeud voisin
| - noeud <-> couches hautes
| ce protocole permet aussi d'implémenter les noeuds passifs dans
| n'importe quel langage

alors tout d'abord, bitobi serait une spécification, avec une
implémentation de référence. On part dans l'optique que des nodes
pourront tourner avec d'autres implémentation (charge aux admin de
vérifier que le node en question est bon avant de signer la clef.
faudrait envisager un test de conformité au standard, peut-être)
En revanche, je ne comprends toujours pas en quoi un node qui est
susceptible de recevoir des posts de moules peut être qualifié de
'passif'. Plus précisément, je ne vois pas la différence avec les autres
nodes, va falloir m'expliquer doucement ;)

|
|
| estian>
|
| > ça en revanche ce serait mignon, et justifierai le principe de noeuds
| > passifs, mais demanderai une évolution significative du coin². En plus,
| > le coin² devrait ouvrir une socket en écoute, ce qui, derrière un
| > firewall, deviendrait problèmatique. çe me gène un peu, je dois dire.
|
|
| si on a une connexion permanente initiée par le client, çà devrait être
| bon pour le firewall
| pour feinter un éventuel proxy, on pourrait placer des en-têtes http
| dans la requête (demande de connexion) et la réponse (envoi des posts)
| pour les radios sur le net (au moins pour certaines), çà doit se passer
| comme çà, nan ? et çà doit bien passer les proxies j'imagine ?
| par contre, avec un proxy, je ne pense pas que les envois de posts
| peuvent se faire avec le même socket (j'imagine qu'une fois que la
| requête est terminée, le proxy refuse tout envoi de nouvelles données,
| quelqu'un confirme/infirme ?), donc là il faudrait utiliser la même
| technique qu'actuellement.

ouais.. à creuser, mais à mon avis ça devrait être une option/évolution.
ça me parait toujours intéressant à avoir, mais je pense pas que ça
doive être notre priorité, et en tout cas pas le seul mode de fonctionnement

|
|
| estian>
|
| > Je
| > pencherai plus, comme évolution, vers un système d'évaluation de charge
| > des noeuds, et une redirection automatique des coin² vers les noeuds les
| > moins chargés..
|
|
| toutafé, le graphe de l'état du réseau peut servir à çà

Ouais.. Du coup effectivement, une connaissance de l'état du réseau plus
précise que up, down risque d'être nécessaire.. va falloir une
représentation ad-hoc du réseau, alors..

|
|
| estian>
|
| > cf supra, il me semble que ceux-là pourraient utiliser le xml.. en même
| > temps, d'un point de vue réseau ce serait mieux qu'ils s'abonnent pour
| > recevoir les nouveautés que de refresher tous les X.. c'est peut-être là
| > que les noeuds 'passifs' seraient une bonne idée.. je pense cependant
| > qu'on peut prévoir ça dans une seconde phase, ça ne me parait pas
| > prioritaire pour le moment, si?
|
|
| encore une fois, l'utilisation de noeuds passifs permet de se passer de
| couche de persistance
| antigone, nan çà n'est pas prioritaire
| pour les noeuds passifs, là c'est clairement un choix architectural à
| faire rapidement (d'autant plus que çà n'aurait pas forcément tendance à
| augmenter la charge de travail, donc y'a pas de raison de remettre çà à
| plus tard)

faut définitivement m'expliquer comment on reconnait un noeud passif
d'un noeud normal, pasque là y'a quelque chose qui m'échappe grave

|
|
| estian>
|
| > ouais, clairement, à priori une interface ouaibe je dirais
|
|
| faudrait aussi en prévoir une en ligne de commande (l'utilisation de
| noeuds passifs permet cette abstraction)

Va pour la CLI aussi.. en revanche euh.. que vient faire le noeud passif
là-dedans? il est susceptible de transmettre des commandes au bitobi aussi??

|
|
| estian>
|
| > alors, quand je parlais de signer les posts, je pensais aux noeuds, pas
| > aux agents.. à mon sens, l'authentification par cookie est suffisante,
| > on n'a pas eu, à ma connaissance, de cas de vol de cookie.. et attention
| > ~ à l'overhead que ça entraine pour des posts courts en particulier. Je
| > pense qu'il est plus simple que les noeuds s'authentifient lorsqu'ils
| > démarrent auprès de leurs pairs, et qu'ensuite on n'accepte de messages
| > que depuis des pairs connus, charge à eux d'authentifier les
| > utilisateurs postant depuis leur interface, et de n'accepter que les
| > authentifiés en mode 'bunker'
|
|
| ok, j'ai pas vraiment d'avis tranché sur ce point
|
| zedek>
|
| > Enfin une chose est
| > sûre, signer chaque post me parait être un chouïa excessif et comme le
| > dit Estian, cela introduit un overhead bien inutile notamment comme le
| > dit aussi Estian, sur les messages courts. Imagine qu'on signe tous les
| > "plop", "kikoo" et autres moulitudes :)
|
|
|
| ouaip
|
| estian>
|  > Ensuite, y'a un autre concept : les posts anonymes, ou 'signés', et ça
|  > c'est très différent : une moule non-authentifiée ne peu bien sûr
| poster
|  > que anonymement, vu qu'on sait pas qui c'est. Une moule
| authentifiée, en
|  > revanche, a le choix. Soit de poster 'signé', et je ne parle pas de
|  > signature gpg là, hein, auquel cas son post apparaitra dans le backend
|  > avec son login, comme c'est le cas aujourd'hui sur le bouchot; soit de
|  > poster anonymement, auxquel cas le premier node, après avoir vérifier
|  > que le post était 'légal', par exemple authentifié en cas de mode
|  > 'bunker', va 'oublier' le login de la moule. On retrouve donc le
|  > fonctionnement du bouchot anteboulayien, mais avec la sécurité des
|  > gateaux. le choix se ferait soit avec une préférence attachée au gatal,
|
| je pense que c'est une mauvaise approche : il faut pouvoir passer d'un
| mode à l'autre très facilement, au moment où on poste
|
| estian>
|  > soit avec un champs dans le formulaire de post, un truc comme ça..
|
| ouaip, çà c'est mieux, une case à cocher "post anonyme", un textfield
| pour éditer l'ua, et çà roulaize
|
| estian>
|
| > ah, ça.. je dirais, vu qu'on pense partir sur un relativement petit
| > nombre de nodes de confiance, que chaque admin pourra plonker un
| > utilisateur/un node. on peut imaginer que ces commandes soient signées
| > avec la clef de l'admin (ou celle du node qu'il admin du reste), et que
| > chaque node aie une liste des clefs autorisées à l'administrer, pour
| > donner plus de choix aux différents admin. Dans l'idéal, c'est vrai
| > qu'un système de vote serait plus mieux, mais à mon avis très (trop?)
| > lourd à mettre en place, sans parler de l'algo à trouver pour déterminer
| > le résultat du vote.. peut-être à ranger dans la catégorie 'évolutions'?
|
|
| la première idée qui m'est venue est une règle du style "il y a plonk si
| au minimum 3 admin demandent un même plonk en 10 minutes max"
| le problème est que çà laisserait la porte ouverte aux flooders
| nocturnes : pas assez d'admin en ligne
|
| en fait je proposerais un plonkage à deux niveaux : temporaire ou
| définitif :
| * le plonkage temporaire a pour objectif d'être assez réactif et est
| public (il utilise des posts sur la tribune)
|  soit n le nombre de posteurs authentifiés distincts qui ont posté dans
| les 10 dernières minutes (càd considérés comme présents sur la tribune)
|  soit n'=min(n/3, 5)
|  il faut au moins n' votants (pour/contre/blanc) en 10 minutes avec :
|  - au moins un admin vote 'pour'
|  - le vote d'un admin compte triple
|  s'il y a plus de 'pour' que de 'contre' (les 'blanc' comptent justent
| pour le taux de participation) 10 minutes après le 1er vote,
| l'utilisateur est plonké pour une semaine

compliqué, et en cas de flood d'un boulay, y'a plus moyen d'avoir un
vote positif (demonstrartion inverse?)

|
| * le plonkage définitif
|  il se fait via une interface d'admin et utilise des messages de service
|  il faut qu'au moins 50% des admins (des noeuds ("de confiance")
| actuellement up) votent
|  au moins 50% de 'pour' dans les votes exprimés
|
| (valeurs à titre indicatif)
| dans chaque cas on peut imaginer un déplonkage avec une procédure
| similaire
| on peut aussi utiliser un système similaire pour le passage en mode bunker
| quand un noeud se connecte, il récupère la liste des plonks et l'état
| des votes en cours
| !!! un admin peut ne pas jouer le jeu : le protocole ne garantit pas
| l'intégrité du système (mais c'est un défaut acceptable, vu que le
| bitobi est basé sur la confiance)
|
| zedek>
|
| > Hmmm. Je suis pas tout à fait d'accord avec ça. Le fait que les noeuds
| > 'admin' seront en nombre restreint me fait craindre qu'une sorte
| > d'élite sorte et fasse un peu tout et n'importe quoi. Je suis pour le
| > plonkage par les noeuds 'admin' mais que si une majorité l'a décidé. Le
| > plonkage devrait faire l'objet au préalable d'une sorte de plébiscite
| > et que au moins un certains nombres de noeuds 'admin' en ai fait la
| > requête.
| >
| > Qu'est-ce que vous pensez de ça ? Euh je sais ça fait un peu politique
| > mais enfin qui a dit que les bouchots ne devaient pas être
| > 'démocratiques' ?
| > Par exemple imaginons un cercle de noeuds admins N=6, on part du
| > principe que au moins 3/4 des noeuds 'admin' ont demandé à plonké tel
| > node.
| > Ainsi on s'affanchit d'une éventuelle dérive et que les plonks ne se
| > fassent de façon systématique 'a la tête du client'. Souvenez-vous par
| > exemple des nombreux conflits entre personne. X n'aime pas Y qui
| > voudrait qu'il dégage, etc....
|
|
| toutafé
|
| deux petites choses pour finir :
|
| on peut envisager d'appliquer une compression gzip sur toutes les
| connexions (sauf les connexions locales noeud<->noeud passif) pour
| limiter la bande passante (çà doit pas coûter trop cher en cpu)
| il faut que ce soit facultatif, donc penser à des en-têtes (style http)

[+] ça mange pas de pain si c'est facultatif

|
| et à une négocation à l'établissement d'une connexion
| je sais pas trop, mais il pourrait peut être y avoir un problème avec le
| flush : si je demande de flusher alors que le texte que j'ai demandé
| d'envoyer jusque là ne tient pas sur un nombre entier d'octets une fois
| compressé, qu'est ce qui va se passer ? (j'imagine que le flush va
| ajouter des données "vides" pour permettre l'alignement et que du coup
| il se comporte comme on l'attend, quelqu'un en sait plus là dessus ?)
|
| sinon, je crois que çà n'a pas encore été évoqué, mais je pense que les
| connexions entre deux noeuds doivent être permanentes (et pas
| ouvertes/fermées à chaque fois qu'il y a un post/paquet de posts à
| envoyer)
| - c'est plus simple a priori
| - les ouvertures/fermetures récurrentes de sockets n'augmentent-elles
| pas l'overhead ?
| - un noeud est prévenu aussitôt (à la fermeture du socket) quand un de
| ses voisins tombe sans envoyer un message de service annonçant sa
| déconnexion
|
| voila
| @+
| olo
|
pløp!

|
|
| ------------------------------------------------------------------------
|
| _______________________________________________
| Bitobi-arch mailing list
| address@hidden
| http://mail.nongnu.org/mailman/listinfo/bitobi-arch


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+E+RF5didzvdbnrURAnYyAKCdnuhiRH1NDtF5Ao7N4JTqXZiT4gCfSV5q
GD8KRlBkBaVMUQrN6HyE4YE=
=+r5x
-----END PGP SIGNATURE-----