Re: [Bitobi-arch] [archi] noeuds passifs

[Aurélien DEHAY]

Olivier Lourdais <address@hidden> writes:

> Description de l'archi à base de noeuds passifs (
> http://bitobi.olivierl.org/noeuds_passifs.png )
>
> Objectif : simplifier au maximum le fonctionnement d'un noeud et
> renforcer la modularité.
> Principe : déléguer toutes les taches qui ne relèvent pas de la
> communication entre noeuds à des noeuds dits passifs.
>
> Sur chaque machine du réseau, on trouve donc un noeud (d'amarrage) et
> un ensemble de noeuds passifs.
> Un noeud communique avec ses noeuds passifs comme avec ses noeuds voisins.
> En régime de croisière, le rôle d'un noeud se borne donc à attendre la
> réception d'un message et à le diffuser à tous les noeuds (voisins et
> passifs) authentifiés.

On arrive donc a plusieurs niveau d'authen et de secu. Pas extra.

> Chaque service (interface web/backend, log, antigone, admin, ...) est
> donc implémenté via un noeud passif distinct.

Comment se passe la comm entre le noeud passif et le node pour la
generation des backends?

> Un noeud passif ne connait qu'un seul noeud (son noeud d'amarrage) qui
> lui fournit chaque message une fois et une seule et lui permet
> d'émettre des messages, il n'a donc aucun travail de diffusion
> proprement dite à effectuer.
> Un noeud passif n'est connu d'aucun noeud du réseau à part par son
> noeud d'amarrage. Il ne fait donc pas partie intégrante du réseau (si
> ce n'est pour rajouter un service à son noeud d'amarrage).

??????

>
> Si on veut affiner un peut les connexions, on peut créer des classes
> de messages (posts, état du réseau, demande de plonk, ...), et chaque
> noeud maintient une liste d'abonnés pour chaque classe de message
> (deux noeuds voisins s'abonnent entre eux à toutes les classes, chaque
> noeud passif s'abonne à la classe (ou aux classes) qui l'intéresse).
>
> Précision : ça n'est pas directement lié à cette archi, mais pour moi
> une connexion entre deux noeuds est permanente, on ne se fait pas
> chier à ouvrir un nouveau socket, s'authentifier, tout ça ... à chaque
> fois qu'il y a un/des messages à balancer.
>
> Pour moi, les avantages de ce design sont :
> - les implémentations, pour un service donné, peuvent être effectuées
> sans s'occuper du reste (à partir du moment où on a un protocole pour
> communiquer avec le noeud d'amarrage, on est indépendant du langage,
> ...)

Donc, niveau implementation -> bitobi-dev, c'est selon moi specifique
a chaque serveur. (cf infra)

> - il est possible de choisir les services à héberger sur un site donné
> (par exemple, en cas de contraintes techniques trop fortes, il est
> possible de ne mettre aucun service lié à la persistance)

PAreil donc que ci-dessus.

> - ...

Je disais donc que c'etait selon moi specifique a
l'implementation. Explication:

Je developpe un bitobi en Ruby. Ce que tu appelle noeud passif est
pour moi un classe a part, mais elle fait parti du serveur. Si un pro
(ou un porc, a voir comment ce sera code) a envie de se taper 42
processus (42 programmes) ayant chacun une tache definie, cela n'est
pas pour moi du niveau de l'architecture. Pour moi, l'architecture du
truc, c'est avant tout de definir les principes de bases les prerequis
(backend XML, HTTP, WAP, compatibilites ascendante et descendante) et
surtout, surtout, le protocole ENTRE les noeuds. Honnetement, je pense
que le truc interne au serveur est pas lie a l'archi du truc.


Voila. Donc, je pense que le truc des noeuds passifs est pas
specifique a l'archi.

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