bitobi-arch
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bitobi-arch] [archi] noeuds passifs


From: Olivier Lourdais
Subject: [Bitobi-arch] [archi] noeuds passifs
Date: Fri, 10 Jan 2003 01:27:17 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

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. Chaque service (interface web/backend, log, antigone, admin, ...) est donc implémenté via un noeud passif distinct. 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, ...) - 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)
- ...





reply via email to

[Prev in Thread] Current Thread [Next in Thread]