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

[Estian]

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

Olivier Lourdais wrote:

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

gah, t'as raison.. depuis le début on dit qu'on connait le noeud
d'origine du post, chuis trop con. bon, vendu en ce qui me concerne

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

je sais pas.. on a déjà un authentifiant unique, donc je dirais que ce
n'est pas une pure nécessité. Si on a un moyen raisonnablement simple de
garantir une norloge unique par post, je plussoie, c'est clair que ce
serait mieux. En même temps, pifométriquement parlant, ça me semble bien
galère à gérer, et en tout cas je vois pas comment faire sans attendre
que tous le bitobi soit synchronisé pour un temps t.. Mais bon, laissons
le sujet ouvert, si quelqu'un a une idée de génie..

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

aaah.. okay, je vois ce que tu veux dire. En revanche, je ne suis
toujours qu'à moitié convaincu. y'a-t-il vraiment un avantage à diffuser
vers plus de node, plutôt que d'imaginer pour les noeuds 'passifs' un
fonctionnement à la antigone? (récupération du xml comme n'importe quel
mouling agent, et traitement spécifique). En terme de charge et de
transit réseau, à quoi ressemblerait chacune des solutions?
D'autre part, j'interprete peut-être mal ton schemas, mais il me semble
que certains noeuds passifs seraient susceptibles de faire transiter des
messages (par exemple depuis un coin² 2ème génération), et l'interface
ouaibe a aussi l'air d'être un noeud passif.. là, du moins si
j'interprète bien ton schémas, ça me gène un peu.. ça veut dire plus de
noeuds à authentifier par clef, et donc agrandir le résal de confiance,
ce qui me semble a priori pas une bonne idée, ou en tout cas être trop
compliqué pour la fonction de ces nodes passifs. Je dirais à la louche
que soit ces nodes passifs devraient utiliser le remote.xml, soit qu'ils
devraient passer par des interfaces différentes des nodes 'normaux' (et
qu'on devrait donc avoir un autre type de flèches dans ton crobard)
ça vous semble avoir un sens?

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

pas faux. en même temps, je préfererais que ce soit un cas particulier
de couche de persistance, une qui aurait 0 capabilités (on partait de
toutes façon sur des couches 'plugin' pour pouvoir persister
indifférement sur un fs, une db, une autre db, etc..). ça implique juste
que chaque plugin sache dire ce qu'il peut fournir comme service, ce qui
de toutes façons est plutôt un bon design amha
En plus, quand je parle de persistence, c'est pas nécessairement de la
persitence à long terme non plus, sauf si on veut logguer pour repérer
d'éventuels boulays.. ça peut être juste une table en mémoire, et du
coup c'est la ram de ton hébergeur que tu vas pourrir ;)
y'a encore à réfléchir du coup, je dirais.. peut-on prendre le parti de
dire que tout est en ram et laisser tomber l'idée d'un stockage en
db/fichier? pourquoi cela n'a-t-il pas été fait dans dacode et templeet?
pour coller au reste du moteur, ou parce que sinon ça écroule les machines?

|
|
| > comment peut-on vérifier qu'on a oui ou
| > non dejà reçu un message donné?
|
|
| bah y'a mon algo :)

voui, du coup ça au moins ça serait réglé

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

et cf au dessus à propos de la couche persistente

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

aucune, faut juste bien avoir les specs avant pour pas aboutir à des
implémentations incompatibles, et ça va pas forcément être simple à
gérer en cas d'évolutions. Mais aucune objection dans le principe

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

bah en plus, je dirais que tant qu'on reste dans de l'objet, les
diagrammes UML (ça aussi ça fait bien sur le CV) sont compatibles (si on
décide de partir sur UML, bien sûr.. perso, j'aime bien). En plus, je
connais bien Java, donc je pourrais filer un coup de main aussi (en
revanche, moi je suis plus chomedu, du coup j'ai pas énormément de temps)

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

papier, ou un automate à tester? Moi je suis pour l'automate, mais c'est
plus de boulot

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

voui, cf ma réponse à l'étage du dessus ;)

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

[++++] dans cette optique là, pas de problème

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

bon, donc sous-tache : définir des messages administratifs?

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

cf plus haut, pour ce qui est de considérer les noeuds passifs comme
n'importe quel noeud

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

effectivement, avec ta définition des noeuds passifs. Du coup en
revanche, faut absolument que ces noeuds passifs là au moins fassent
partie du résal de confiance, sinon c'est danjeureu

|
|

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

iD8DBQE+FiIf5didzvdbnrURAlfUAJ9rL+Gapw3dtJEkMlf6cp5lj13+kwCgp38k
BmUbIFSqLzXOiooGRKrcl3o=
=zKgF
-----END PGP SIGNATURE-----