Re: [Bitobi-arch] [archi] Efficacité du ré zal par l'architecture

[Olivier Lourdais]

> > > > On a des échanges dans ces cas :
> > > > - modification de la topologie du réseau (un noeud se connecte ou se
> > > > déconnecte, ajout/suppression de connexion) -> ça fait pas des 
> > > > masses de
> > > > messages
> > > > - mise à jour des stats de latence/charge -> on n'est pas obligé dans
> > > > faire toutes les 3 secondes non plus
> > > >
> > > > Donc au final ça reste négligeable.
> > > >
> > > >
> > > >       
> > >
> > > Négligeable, mais la question que je me pose est: "A quoi ça sert"?
> > >
> > >     
> >
> > À gérer la charge du réseau : si on arrive à une configuration en
> > "étoile" (tous les noeuds sont connectés à un noeud central) le noeud
> > central devra supporter une charge forte et on a un risque
> > d'engorgement, à l'inverse si on arrive à une configuration "linéaire"
> > (par exemple A--B--C--D--E--F) il y aura une latence importante entre
> > les noeuds situés aux extrémités.
> > Si un noeud peut connaître l'état du réseau au moment de sa connexion,
> > on peut éviter ce genre de désagrément.
> >   
>
>
> Comment?
cf les messages précédents.
En gros si je choisis de me connecter aux deux noeuds qui sont les plus 
éloignés en terme de latence, je contribue à éviter ce genre de situations.

> J'avouerai que cela ne me plait pas et que j'aimerais garder un
> truc, du moins au début, le plus simple possible.
>  
À la limite si au début toutes les implémentations ne se servent pas des 
données de topologie c'est pas bien gràve, par contre il faut qu'elles 
sachent diffuser ces messages, pour ne pas gêner les implémentations qui 
s'en servent.