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

[Xavier MAILLARD]

On Sun, 29 Dec 2002, address@hidden uttered the following:

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?

Tout à fait d'accord. Si on commence à donner des pouvoirs à des noeuds
'non vérifiés' (pas de confiance) la gestion va devenir des plus
difficiles.

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

Oula va falloir que je branche mon cerveau là parce que effectivement
l'algo d'Olivier n'est pas si évident que ça à suivre ;-)
  
> |
> |
> | 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

Ah non pas d'accord. Bitobi doit être gruik, c'es entendu mais doit
être blindé pour ça AMHA.  
> |
> |
> | 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'
>  

Euh je sais pas si j'ai tout compris mais les anonymes ne pourront pas
exister ou je fais fausse route ?? 
Concernant la signature, je pense qu'effectivement le couple
authentification du noeud auprès des pères + user authentifié est un
bon compromis entre sécurité et souplesse d'utilisation. Reste à voir
si dans la réalité cela ne créera pas une faille. Enfin une chose est
sûre, signer chaque post me parait être un chouïa excessif et comme le
dit Estian, cela introduit un overhead bien inutile notamment comme le
dit aussi Estian, sur les messages courts. Imagine qu'on signe tous les
"plop", "kikoo" et autres moulitudes :)

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

Hmmm. Je suis pas tout à fait d'accord avec ça. Le fait que les noeuds
'admin' seront en nombre restreint me fait craindre qu'une sorte
d'élite sorte et fasse un peu tout et n'importe quoi. Je suis pour le
plonkage par les noeuds 'admin' mais que si une majorité l'a décidé. Le
plonkage devrait faire l'objet au préalable d'une sorte de plébiscite
et que au moins un certains nombres de noeuds 'admin' en ai fait la
requête.

Qu'est-ce que vous pensez de ça ? Euh je sais ça fait un peu politique
mais enfin qui a dit que les bouchots ne devaient pas être
'démocratiques' ? 

Par exemple imaginons un cercle de noeuds admins N=6, on part du
principe que au moins 3/4 des noeuds 'admin' ont demandé à plonké tel
node.
Ainsi on s'affanchit d'une éventuelle dérive et que les plonks ne se
fassent de façon systématique 'a la tête du client'. Souvenez-vous par
exemple des nombreux conflits entre personne. X n'aime pas Y qui
voudrait qu'il dégage, etc....
 
> |
> |
> | 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

Noyeux réveillon et bonne marée à toutes les moules :-)
  
zeDek