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

[Olivier Lourdais]

Bonne année à tous.

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<d1 en provenance de h.") alors (z'êtes durs ;)
Concentrons nous sur les messages émis par le noeud A.
Domontration par récurrence :
- étape 0 : le lemme est vérifié sur le noeud A (trivialement, il traite 
ses propres messages dans le bon ordre)
- supposons que le lemme est vérifié à l'étape n-1 : les voisins du site 
B qui le précèdent dans la diffusion des messages de A les reçoivent 
dans l'ordre et chacun les propage dans l'ordre => 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 :)


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)

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

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

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, ...)

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)

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

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.

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 à çà

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)

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)

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
* 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) 
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