Re: [Bitobi-arch] Pré-requis, phase 1: la base.

[Aurelien DEHAY]

<quote who="Olivier Lourdais">

> Aurelien DEHAY wrote:
>
[snip]

> Quelqu'un a un protocole, un scénario ou n'importe quoi à proposer pour
> l'authentification ?

Moi :) Enfin, juste pour l'implémentation de base, un truc tout simple,
pas sécurisé. Enfin, pas sécurisé du tout quoi. Perso, je vois bien, pour
commencer les tests, une méthode "à la main". Chaque admin de noeud
calcule/génère une chaine, qu'il envoit à l'admin de l'autre machine. Le
reste, je te laisse deviner (indice: MD5 toussa). C'est basique, mais à la
limite, c'est extensible.

>
>>3) Vérification de l'heure du serveur tiers.
>>[snip]
> J'ajouterais que chaque noeud doit connaître à tout moment cet état, donc
> :
> - diffusion des messages concernant l'évolution de cet état (ce que j'ai
> appelé messages de service)
> - mise à jour de l'état au moment de la connexion

ça me paraissait logique, merci de préciser.

>
>>Pour la méthode de comm entre les propagateurs, deux écoles (Olo et moi,
>>donc :) ), se proposent:
[snip]

> Mouais, je suis pas franchement convaincu qu'une implémentation over
> HTTP soit plus facile à créer qu'une implémentation over TCP.
> Et surtout il ne faut pas oublier qu'une des raisons d'être du bitobi
> vis-à-vis d'une tribune normale est que chaque noeud ait une charge
> moins forte à supporter. Il ne faut pas non plus oublier que le mode de
> fonctionnement d'un noeud est de fournir à tous ses voisins chaque
> message qu'il produit ou qu'il reçoit, symétriquement chaque noeud
> reçoit donc chaque message depuis chacun de ses voisins. Si on utilise
> une surcouche à HTTP, chaque noeud aura à traiter un sacré paquet de
> requêtes. Je crois que là on passe un peu à côté de l'objectif initial.

PAs dans le cas d'un réseau maillé complet. Le problème, c'est que là on
discutte qu'à deux, et comme on est pas 'forcément' d'accord, ça va pas le
faire.

>
>>Je propose également de choisir des fonctions mandatoires (FOUTAISES!) et
>>des fonctions optionnelles. Dans ce qu'a proposé Olo, certaines choses
>>pourraient être implémentées, mais je ne pense pas qu'elles soient
>>nécessaires, tout du moins dans les premières phases de dev.
>>
>>
> Ma position : pas de problème pour ne prendre en compte qu'un
> sous-ensemble de fonctionnalités dans un premier temps (normal), mais il
> faut que chaque implémentation gêne le moins possible les
> implémentations qui prennent en compte plus de fonctionnalités (et donc
> normaliser ces fonctionnalités dès le début).

Pas d'accord. Si tu veux faire du XML, c'est pas dur, tu mets les tags
quand même, mais ils ne seront pas compris, donc pas traités par les
implémentations plus 'simples'. Si tu fais autre chose, pareil, faut pas
que les implémentations soient bloqué par le non traitement de ces
messages.

Autrement dit: les propagateurs ne doivent pas être tributaires de ces .
fonctionnalités
Autrement dit: la non implémentation de ces fonctionnalités ne doit pas
être bloquante en quoi que ce soit.

Pas d'accord donc pour les normaliser.

Encore une fois, pour avoir un truc qui fonctionne relativement assez
vite, faut faire simple, pas vouloir tout faire tout de suite.

>
>
>
> _______________________________________________
> Bitobi-arch mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/bitobi-arch
>
>