[Bitobi-arch] commentaires sur http://reziztanzia.free.fr/wiki/index.php?pagename=b2bScenarPostPropag

[Estian]

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

pløp! à tous

Déjà,je pense qu'il faut arrêtre de modifier les pages du wiki pour
discuter.. ça devient difficilement gérable amha vu le nombre croissant
de moules venant donner un coup de coquille au projet.. Je propose
d'utiliser le wiki pour donner une image du consensus du moment des ML,
ce sera moins confusant je pense. Des objections?

Bon, sur ce quelques remarques sur
http://reziztanzia.free.fr/wiki/index.php?pagename=b2bScenarPostPropag

Sur le boitakonnage, et la proposition de garder un historique des
noeuds par lesquel un message est passé : est-ce nécessaire?
normalement, un message provenant d'un pair plonké ne sera jamais
propagé au delà de cette machine, donc je pense que le chemin pris par
le poste est une information dont on se fustige globalement le
cristallin (d'autant que le chemin peut varier d'un node à un autre).
Si le danger auquel ce système voulait parer était la présence d'un pair
'pirate' ou compromis, je rappelle qu'un node, pour pouvoir participer
au bitobi, doit avoir été reconnu 'de confiance' par au moins un admin
de node du bitobi. Et le premier qui signe la clef de dodolf, je lui
présente mon cubitus de mammouth. Donc c'est safe ;)
Sinon effectivement, l'overhead par post commencerait à devenir un peu
trop gros, je pense. (surtout si on post 'plop!'). Pour l'ordre
chronologique, on s'en tape un peu, en fait. Le premier node à recevoir
le post l'horodate, les nodes sont tous 'synchronisés' sur un même ntp,
et c'est marre. Comme dit plus bas, l'id unique de chaque post est (est
dérivé?) d'un hash quelconque, par exemple de l'horodatage + l'id du
node d'origine, comme ça on retrouve quelque chose de presque
chronologique, et le cas (rare) de 2 posts à la même miliseconde ne
posera 'problème' que s'ils se produisent sur le même serveur (sinon le
hash sera déjà différent). et là, ben on rajoute un suffixe genre 00,
01, ..

Pour la 'fin de la propagation'
Nan, t'es pas clair ;)
Enfin je pense que t'es surtout trop compliqué pour ce dont on a besoin,
là.. je dirais, perso, qu'on garde les ID des messages reçus genre ces
10 dernières minutes (et les plus vieux vont dans /dev/null de toutes
façons, un message ne devrait jamais mettre 10mn à arriver). Et si on
reçoit un message qu'on a déjà reçu (dont l'id est dans la liste) et ben
on le propage pas (vu qu'on l'a déjà propagé). Vous voyez un problème
avec ce système, ou qqch de plus simple?

Pour les problème de grande connectivité :
Bon, déjà gardons en tête que, à priori, on prévoit un nombre limité de
nodes dans le bitobi, on refait pas gnutella non plus, hein..
Sinon effectivement, trop de communications pourrait être embêtant. Je
propose de garder une table des pairs connu, mais de ne causer qu'au 10
premiers de la liste, par exemple. En revanche, il me semble qu'avec un
système comme ça on pourrait se retrouver avec un 'bitobi-split', et le
réseau se scinder en deux sous-réseaux imperméables.. Quelqu'un s'y
connait en maillage pour nous sortir quelque chose de mieux?

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

iD8DBQE+Dhou5didzvdbnrURAgUmAJ9WzVk17tExCsKT3NG+eSOMJXAG4QCfeH9x
gJQt2cLk8wcK2jZ2F/knp3E=
=tf0a
-----END PGP SIGNATURE-----