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

[Olivier Lourdais]

Aurelien DEHAY wrote:

> Bonjour à tous.
>
> Je n'ai pas encore eu le temps commencer un document de travail sur un
> début d'archi de bitobi, mais je jette ici quelques idées, et quelques
> petites choses que nous avions déjà décidé:
>
> - bitobi doit être totalement compatible avec les coin² au niveau du backend.
>
> - Un système de sécurité boulay-proof doit être inclus.
>
> - Une norme de communication inter-bitobi serveurs doit bien sûr être
> définie.  Chaque serveur implémentera au moins les fonctionnalités
> suivantes:
>
> 1) Gestion du message (c'est quand même la base)
> 2) Authentification du serveur tiers.
Quelqu'un a un protocole, un scénario ou n'importe quoi à proposer pour 
l'authentification ?

> 3) Vérification de l'heure du serveur tiers.
>
> Un serveur devra obligatoirement effectuer au moins les actions suivantes:
>
> 1) Horodatage, nettoyage du message. Il devra par conséquent stocker DSC^W
> quelque part toutes les infos pertinentes d'un message (DTD a définir).
> 2) Transfert dudit message aux autres serveurs.
> 3) Fournir aux serveurs qui en font la demande des informations sur son
> "état" (mode bunker, liste des plonkés, des bannis au moins).
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

> Pour la méthode de comm entre les propagateurs, deux écoles (Olo et moi,
> donc :) ), se proposent:
>
> - Olo, qui vote pour une socket "fixe" et "simple" entre les propagateurs.
> Moins de ressources utilisées, communication en XML, toussa.
>
> - Moi, qui vote pour une méthode de comm HTTP. Plus de ressources, plus
> facile a coder (et on pourrait faire un serveur bitobi en PHP comme ça).
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.

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