[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses
From: |
Olivier Lourdais |
Subject: |
Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses |
Date: |
Thu, 02 Jan 2003 16:05:48 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 |
| > 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 ?
- Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses, Olivier Lourdais, 2003/01/01
- Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses, Estian, 2003/01/02
- Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses,
Olivier Lourdais <=
- Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses, Estian, 2003/01/03
- Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses, Olivier Lourdais, 2003/01/07
- Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses, Olivier Lourdais, 2003/01/07
- Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses, Pierrot, 2003/01/02