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

[Olivier Lourdais]

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


euh moi j'arrive pas au même résultat :
42:42:42 : post 'pika' sur 10.0.0.1, qui le diffuse vers 10.0.0.2 et 
10.0.0.3 (*)
42:42:43 : post 'plop' sur 10.0.0.2, qui le diffuse vers 10.0.0.1 et 
10.0.0.3 (*)
  (*) si j'ai bien compris ton exemple, il y a une connexion 
(bidirectionnelle) entre chaque noeud
42:42:43 : 10.0.0.3 reçoit 'plop' (aka ...42:42:43.../10.0.0.2) depuis 
10.0.0.2 et le diffuse vers 10.0.0.1 [ (10.0.0.3).dernier_reçu{10.0.0.2} 
:= 42:42:43 ]
42:42:44 : 10.0.0.2 reçoit 'pika' (aka ...42:42:42.../10.0.0.1) depuis 
10.0.0.1 et le diffuse vers 10.0.0.3 [ (10.0.0.2).dernier_reçu{10.0.0.1} 
:= 42:42:42 ]
42:42:45 : 10.0.0.3 reçoit 'pika' (aka ...42:42:42.../10.0.0.1) depuis 
10.0.0.2
bon la première fois j'avais mal lu ton exemple ;)
quand 10.0.0.3 reçoit 'pika', il vérifie qu'il n'a pas reçu de post plus 
vieux depuis 10.0.0.1 (le noeud qui a horodaté le post) et pas 10.0.0.2 
(le noeud qui lui a délivré le post)
donc on a pas "((10.0.0.3).dernier_reçu{10.0.0.2} == 42:42:43 >= 
42:42:42) -> drop"
mais plutôt "((10.0.0.3).dernier_reçu{10.0.0.1} < 42:42:42) -> 
traitement du post"

çà ta va ?

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

au temps pour moi
le changement de sous numéro j'ai déjà vu çà avec wmc² effectivement, 
mais jamais avec pyc² par contre.
je vois pas trop d'où çà peut venir avec le fonctionnement actuel ! 
c'est peut-être une gruikerie de pouaite< ?
en tous cas, garantir une norloge unique ne me semble pas dénué de sens

> 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

voila à quoi çà ressemble pour moi : 
http://moules.olivierl.org/bitobi/noeuds_passifs.png
pour moi "passif" signifie qu'il ne diffuse pas les messages (vu qu'un 
noeud passif est destiné à n'être connecté qu'à un seul noeud à la fois)
donc la connexion entre un noeud passif et son noeud d'amarrage est 
identique à la connexion entre deux noeuds voisins => bidirectionnelle
pour des usages bien précis, on pourrait imaginer des noeuds passifs 
"muets" (ie qui écoutent les posts mais ne postent pas eux mêmes, ex : 
antigone), mais le noeud d'amarrage n'a pas besoin de le savoir (donc 
pas la peine de prévoir un cas particulier)
il pourrait aussi y avoir des noeuds passifs "sourds" (ie qui postent 
mais n'écoutent pas les posts, je suis pas trop sûr mais çà doit pouvoir 
être utile, pour une interface d'admin en mode texte par exemple) et là 
deux solutions : le noeud passif sourd reçoit les posts et les ignore ou 
alors il faut s'abonner explicitement pour recevoir les posts au moment 
de la connexion et tout le monde le fait sauf les noeuds passifs sourds

> Hmm.. sans couche de persistence, comment garde-t-on le logs d'éventuels
> boulays pour envoyer à abuse?

c'est ptet pas la peine de conserver l'historique sur chaque noeud
en fait le conserver sur un noeud permanent devrait suffire 
(éventuellement 2 ou 3, pour prévenir une défaillance)
et imaginons que j'ai trouvé un hébergeur avec une très bonne bande 
passante mais que je n'ai pas accès au fs ou à une bd (ou que j'ai des 
quotas trop strict, ...), là je suis content si je peux me passer de la 
persistance

> comment peut-on vérifier qu'on a oui ou
> non dejà reçu un message donné?

bah y'a mon algo :)

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

oué, qu'en pensent les zotres ?

> alors tout d'abord, bitobi serait une spécification, avec une
> implémentation de référence.

euh, j'avais demandé, on m'avait dit qu'on pouvait partir sur plusieurs 
implémentations de réf (en veillant à ne pas trop se disperser non plus)
des oppositions ?
perso, je partirais bien sur une implémentation en java : je suis au 
chômage et çà me sera plus utile sur mon cv :(, et je prototyperais bien 
quelques trucs que j'ai évoqué ici (pour voir si c'est implémentable, 
...) et là je sais que j'irais plus vite en java. maintenant çà ne 
m'empêchera pas de participer à l'implémentation ruby

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

[+] pour les tests de conformité

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

j'ai mieux expliqué plus haut ?

> 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

toutafé, le seul mode sur lequel on doit se concentrer au début, c'est 
le mode de compatibilité (ou presque) avec les coincoins actuels
faut juste pas fermer de portes trop tôt :)

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

sur chaque noeud çà peut se modéliser par un graphe valué, qui peut se 
sérialiser facilement en xml (ensemble de sommets + enemble d'arcs) pour 
le transmettre à un noeud qui vient de se connecter
pour les messages de services qui feront évolué le graphe de chaque 
noeud, on peut avoir des messages du genre :
- A: je viens de me connecter à B
- A: je vais me déconnecter
- A: je viens de perdre ma connexion avec B sans qu'il annonce sa 
déconnexion (chaque noeud regarde si B a encore une connexion active 
avec un autre noeud, si çà n'est pas le cas, B est considéré comme down)
- A: je viens d'évaluer ma connexion avec B, la latence est actuellement 
de x ms
- A: voici mes stats de charge : x req/sec depuis les coincoins 
traditionnels, avec n utilisateurs authentifiés distincts ces 10 
dernières minutes, ...
- A: voici les quotas que j'aimerais bien respecter vis à vis de la 
charge : x req/sec max, ...

> 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

le noeud passif le sait, son noeud d'amarrage le considère comme 
n'importe quel noeud (sauf pour le graphe d'état du réseau, on peut 
aussi imaginer des règles du genre "je n'accepte telle ou telle commande 
d'admin que depuis un noeud connecté depuis 127.0.0.1" dans la config 
d'un noeud, qui concerneront en fait (probablement) des noeuds passifs)

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

why not ?