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

[Estian]

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

Olivier Lourdais wrote:

| > pløp! à tous
|
|
| plop
|
| 0)
|
| > Déjà,je pense qu'il faut arrêtre de modifier les pages du wiki pour
| > discuter.. [...] Des objections?
|
|
| nope
|
| 1)
|
| > Sur le boitakonnage, et la proposition de garder un historique des
| > noeuds par lesquel un message est passé : est-ce nécessaire?
|
|
|
| j'avais compris qu'il pouvais y'avoir plusieurs types de noeuds : des
| noeuds de confiance et d'autres. Et que seuls les noeuds de confiance
| pouvaient s'échanger la liste des utilisateurs/cookies. Si je me suis
| trompé, effectivement çà sert à rien de garder l'historique.

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?

|
|
| 2)
|
| > Pour la 'fin de la propagation'
| > Nan, t'es pas clair ;)
|
|
|
| bon je reprends avec un exemple alors :
| j'envoie deux messages, "plop" à 42:42:42 et "pika" à 42:42:43 en
| passant par le noeud 127.0.0.1
| scénario sur un autre noeud :
| * réception de "plop" :
| - j'ai pas reçu de message plus récent depuis 127.0.0.1
| - last_message{127.0.0.1} := 42:42:42
| - traitement/propagation du message
| * réception de "pika"
| - j'ai pas reçu de message plus récent depuis 127.0.0.1 (42:42:43 >
| last_message{127.0.0.1})
| - last_message{127.0.0.1} := 42:42:43
| - traitement/propagation du message
| * réception de "plop" (depuis un autre noeud) :
| - 42:42:42 < last_message{127.0.0.1} donc ignorationage du message
| * réception de "pika"
| - 42:42:43 == last_message{127.0.0.1} donc ignorationage du message
|
| c'est mieux là non ? :)
| et çà coûte pas trop cher en mémoire vu qu'on a un nombre limité de noeuds
|
| en fait, je me base sur cette propriété :
| "Lemme (j'ai jamais trop su ce que ça voulait dire exactement, mais çà
| fait classe de le classe, non ?) :
| 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 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?
|
|
|
| Honêtement, je pense que ma solution est quand même plus légère :
| vérifier qu'un id est dans la liste, çà fait beaucoup de comparaisons
| (bon, en fait en prenant une structure de donnée kivabien (table de
| hash/hashset avec chaînage des éléments pour retrouver le plus vieil id
| pour le virer) pas tant que çà, mais quand même, çà me parait pas
| élégant ;-p )

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

|
|
| 3)
|
| > 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, ..
|
|
|
| bon, je prends un exemple :
| j'ai trois messages : "pika" envoyé à 42:42:42.000 depuis le noeud A,
| "plop" envoyé à 42:42:42.001 depuis le noeud B et "coin" envoyé à
| 42:42:42.002 depuis le noeud A
| j'ai mon coin coin ou mon browser sur le noeud C
| scénario :
| * le noeud C reçoit les messages du noeud A, mon coincoin affiche :
| [1]
| 42:42:42 : pika
| 42:42:42(-2) : coin
| * je réponds (via le noeud C) au second message : 42:43:00 :
| 42:42:42-2 pan
| * après un laps de temps nécessaire, tous les coincoins affichent :
| [3]
| 42:42:42 : pika
| 42:42:42(-2) : plop
| 42:42:42(-3) : coin
| 42:43:00 : 42:42:42-2 pan
|
| çà risque de faire "désordre"
| une solution pourrait être de demander au noeud qui reçoit un message en
| premier de parser les horloges et de rajouter les infos nécessaires pour
| être sûr de retrouver les liens de "causalité" entre les messages plus
| tard
| par exemple, pour le message de 42:43:00, le noeud C ajoute [42:42:42-2
| --> 42/42/2042-42:42:42.002-0/A]
| comme çà le coincoin peut se rendre compte que le post de 42:43:00 fait
| en fait référence au post de 42:42:42(-3) et activer la surbrillance,
| ... correctement
| éventuellement il peut même se permettre un s/42:42:42-2/42:42:42-3/
| dans le corps du post de 42:43:00 (mais là il faut que le match des
| horloges soit plus strict qu'actuellement avec les c² (pour éviter de
| remplacer des horloges qui n'en seraient pas) et aussi que les
| utilisateurs en respectent la syntaxe)
|
| il reste quand même une source d'incohérences : si l'état de mon noeud
| (C) est [1] quand je commence à écrire ma réponse ("pan") mais est passé
| dans l'état [2], composé des 3 premières lignes de [3] quand il reçoit
| et traite ma réponse, il ne va pas interpréter mon horloge correctement
| et associera à mon post le lien [42:42:42-2 -->
| 42/42/2042-42:42:42.001-0/B] !
| --> solution possible : pour les messages datés de la même seconde (en
| arrondissant), ils sont insérés dans le backend/html dans l'ordre dans
| lequel ils arrivent sur le noeud
| quand je poste ma réponse, le noeud (enfin l'interface web/coincoin) est
| donc dans l'état
| [2']
| 42:42:42 : pika
| 42:42:42(-2) : coin
| 42:42:42(-3) : plop
| et donc l'horloge de mon post est bien interprétée
|
| bon au final çà peut paraitre beaucoup de bordel pour pas grand chose,
| mais je pense que c'est un mal nécessaire

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

|
|
| 4)
|
| > 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?
|
|
|
| 10 pairs connus, ça me parait énorme, moi je limiterais à 2 ou 3 (en
| laissant la possibilité de monter jusqu'à 5-6 si d'autres pairs le
| demandent), au moins pour les noeuds sur une connexion adsl (mais on
| peut quand même envisager des noeuds plus gros)
| bon malheureusement j'ai rien trouvé dans mes cours d'algo distribuée (à
| chaque fois on fait l'hypothèse que le nombre de noeuds est constant et
| connu dès le départ, ce qui n'est pas vraiment le cas ici) (par contre
| j'ai trouvé un algo intéressant dans mes cours d'algo des graphes, mais
| je vais y revenir)

Je disais 10, à la louche hein.. je suis plus ennuyé par le risque de
'split', avec un algo simple comme ça..


[snip plein de truc intéressants]
(je snip, parce que c'est pas du tout mon domaine, va falloir que je
lise beaucoup plus attentivement avant d'avoir un avis). à 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 ;)

|
|
| 6)
| Proposition d'architecture
|
| - les noeuds ne savent communiquer qu'avec les noeuds

[+], les mouling agents (coin², brouteurs) se contentent du xml/html je
pense

|
| - une catégorie particulière de noeuds : les noeuds passifs : ils savent
| parler aux noeuds mais ils ne propagent pas les posts

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?

|
| - chaque site a un noeud et (a priori) une interface web/coincoin qui
| est un noeud passif

L'interface ne pourrait-elle pas être comprise dans le noeud? et aller
chercher les posts à afficher directement dans la couche persistente, ou
à defaut la recevoir 'programatiquement', plutôt que comme un message de
noeud à noeud?

|
| - on peut imaginer des coincoins de seconde génération (cc2g) qui serait
| des noeuds passifs et qui ne passeraient plus par une interface --> plus
| besoin d'ouvrir une connexion toutes les 30 secondes, et les posts
| arrivent en direct

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

|
|
| et après on peut ajouter des antigones (noeuds passifs "muets") et plein
| de jouets dans ce genre

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?

|
| penser aussi à une interface d'admin (noeud passif "sourd") pour les
| plonks, passages en mode bunker, ...

ouais, clairement, à priori une interface ouaibe je dirais

|
| 7)
| Signature des posts
|
| Je pense qu'il pourrait être intéressant de rajouter une signature GPG
| sur les posts :
| - vérification par les noeuds de confiance que la signature est bonne
| (si elle est présente) pour les utilisateurs enregistrés (non anonymes)
| - en mode bunker, seuls les posts signés sont autorisés
|
| la signature est effectuée :
| - par le coincoin avec la clé de l'utilisateur
| - par l'interface html (noeud de confiance) avec sa propre clé pour les
| utilisateurs enregistrés qu'elle connait
|
| même remarque que pour le 1)
| mais après tout, il vaut peut-être mieux penser à blinder le système dès
| le début ?

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'

|
|
| 8)
| vrac
|
| tous les possesseurs de noeuds signés peuvent plonker/passer en mode
| bunker/... qui ils veulent ou il vaut mieux imaginer un système de vote ?

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

|
|
| bon, je crois que c'est tout ce que j'avais en tête
| merci d'avoir lu ce mail jusqu'à la fin :)
| désolé si j'ai écrit quelques énormités, mais j'ai commencé à écrire ce
| mail il y a une quinzaine d'heures et j'en ai repris la rédaction après
| une nuit blanche et quelques boissons alcoolisées, donc j'ai ptet pas
| les idées très fraiches ;)
|
| je serais aussi probablement offline toute la semaine ou presque, donc
| d'avance joyeux réveillon, tout çà, tout çà (pas "bonne année" : çà se
| fête en début d'année si je ne m'abuse)
|
| @+
| olo
|
joyeux plein de trucs à toi aussi

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

iD8DBQE+Dz7h5didzvdbnrURAgEGAJ4mWQULIU2BCASVJIK1TLs+HgKeYgCeIYiD
boAruTwCe8gfhvpfjLK8wmc=
=YCld
-----END PGP SIGNATURE-----