Pour palier à ces problèmes les entreprises mettent en place des architectures redondantes extrêmement onéreuses, autant à l’achat qu’a l’entretien (Par exemple la firme Google totalisera bientôt près d’un million de serveurs (d’ici a 2011), tandis que Microsoft de son côté mets des milliers de nouveaux serveurs en ligne chaque mois pour supporter ses applications).

De même, l’espace de stockage et la bande passante nécessaires sur les serveurs sont de plus en plus importants car les applications lourdes augmentent les coûts de l’infrastructure. C’est pourquoi un nombre croissant d’entreprises se tournent vers les réseaux décentralisés, pour leurs applications secondaires (mise à jour ou autre) sachant que la technologie n’est pour le moment pas bien maitrisée pour des applications exigeantes.

Plusieurs exemples de réseaux décentralisés sont utilisés par beaucoup (en le sachant ou pas) :
– Mise à jour de beaucoup de jeux en ligne
– Emule et autres logiciels de partage communautaire (DC, le défunt Kazaa,…)
– Le téléchargement de beaucoup de fichier lourd (release Linux, démo,…)
– La voix sur les jeux supportés par la plate-forme Steam (cf Valve)

Ainsi on peut prédire le meilleur pour cette technologie, qui permet de réduire grandement l’utilisation serveur, et ainsi réduire son parc serveur.

Une petite explication sur le système s’impose alors :
Dans un réseau décentralisé, la majorité des données sont échangées directement entre utilisateurs et ne transitent pas (ou peu) par le serveur. On a ainsi le plan suivant :

Comme vous pouvez le constater les interactions ne sont pas les même dans ces deux schémas. Ce c’est justement cette différence qui permet au système de réseau décentralisé de consommer 10x moins de ressources serveurs. Un exemple simple : si 100 personnes souhaitent télécharger un fichier, sur un système centralisé le serveur va lui-même redistribuer le fichier aux 100 personnes (si le fichier fait 100Mo, cette opération va consommer 10Go de bande passante et occuper le serveur pendant un bon moment (accès disque, traitement des requêtes,…)). Tandis qu’avec un système décentralisé, le serveur aurait coupé le fichier en 10 parties, qu’il aurait distribué à 10 personnes, et ces 10 personnes se seraient alors échangé les parties afin de reconstituer le fichier entier.

Donc, dans l’absolue théorie, le serveur n’aurait diffusé qu’une fois le fichier, et 100 personnes l’auraient eu (utilisation minime du disque et de la bande passante serveur, mais utilisation de la bande passante client qui est la plupart du temps inutilisé dans le sens montant/upload).

Ce système est de plus en plus efficace avec l’avènement du haut débit en France (et bientôt très haut débit), avec plus de 1Mbit/s d’upload dans la plupart des offres (soit 128 ko/s). Ce n’est pas grand-chose me direz-vous mais la force d’un réseau décentralisé est la communauté connectée, ainsi lorsque 100 utilisateurs ont acquis le fichier, la bande passante disponible est équivalente à celle d’un serveur de production.

Principal exemple (on y revient souvent pour la présentation car cela parle à de nombreuses personnes) : le réseaux eDonkey, avec ses serveurs dépassant la barre du million d’utilisateurs connectés sur un seul nœud (serveur) ce qui est impensable sans cette technologie. Dans ce cas précis le serveur ne fait que rediriger les clients les uns vers les autres en fonctions des fichiers demandés, ensuite le transfert de fichier ne passe pas par le serveur (et le flux de données est bien plus important que s’il passait par celui-ci : plusieurs TB/s).

Maintenant que l’idée générale est posée, et que celle-ci est claire (je l’espère, sinon posez vos questions en commentaire) dans l’esprit de tous nous allons voir les avantages et les inconvénients de ce système et optionnellement comment y remédier.

Le principal avantage est, comme dit précédemment, qu’il permet un fort gain de bande passante (car celle-ci n’est pas illimités, la liaison inter-atlantique à une limite fixe, et il est très onéreux de « tirer » de nouveaux câbles au travers d’un océan).
Viens ensuite le fait qu’une panne de serveur ne pénaliserait pas forcément les services hébergés (grâce à la persistance due au cache de tous les utilisateurs connectés). Les données seraient alors encore disponible le temps de repérer la panne.

Bien sur, tout n’est pas rose dans le monde merveilleux du décentralisé. La sécurité, l’intégrité des données et la validité des clients sont les principaux inconvénients/problèmes techniques que le système pose. Mais comme tout à une solution, nous verrons plus tard comment palier à ces problèmes.

Parlons maintenant applicatif (en toute théorie) afin que l’image de ce système n’en soit que plus forte dans votre esprit :

Comme vous le savez certainement, les MMOx (jeux permettant de jouer avec des milliers de joueurs simultanément) demande une infrastructure importante.
L’utilisation en bande passante serveur est titanesque, alors que les clients, eux n’utilisent que 2-5ko/s de leur bande passante montante (upload) soit moins 10%.
Le but dans cette application serait de se dire, aucune bande passante ne doit être perdue. Ainsi lorsqu’un millier de joueurs seraient connectés la bande passante disponible serait largement supérieur à ce qui est nécessaire, et les serveurs serait ainsi plus qu’allégés. (Économie de plusieurs To de bande passante).

Autre application possible, directement liée au web, faire un navigateur qui partagerai le cache des utilisateurs. Ainsi lorsqu’un serveur serait surchargé, il suffirait de demandé à la communauté qui a consulté cette page dernièrement afin qu’il nous l’envoi.

Enfin bref, passons sur toutes les possibilités (utopique ?) offerte par cette technologie, elle a un autre atout de taille : savez combien d’énergie utilise une ferme de serveur (autant pour tourner que pour refroidir ?) ? Il ne vaut mieux pas le savoir.

Donc si l’on peut réduire le parc de serveur mondial (ou continuer à développer le web sans pour autant étendre ce parc), d’énorme économie peuvent être réalisée.

Voila, c’est la fin de cette petite présentation (généraliste) de ce système.
Nous verrons les aspects plus techniques (sous plateforme .net) dans les billets qui viendront.

Si vous avez des questions n’hésitez pas !

EDIT : Merci à nouknouk pour ses critiques éclairées.

Effectivement j’ai oublié de préciser que le P2P n’est valide que pour du contenu « statique », donc pour du contenu dynamique il faut tout d’abord demander une validation sur le contenu de la page (par exemple pour un forum savoir si une discussion a évoluée).

Il m’a aussi fait remarquer à juste titre que pour les MMOx, ce système engendrait des incohérences, mais je m’expliquerais sur cela plus tard, car il y a aussi une solution.

De plus, les clients acceptants les paquets des autres clients, si un utilisateur décide de faire passer un code malicieux par le biais du logiciel, celui-ci se propagera rapidement au travers de toute la communauté.

Petit exemple : Un utilisateur de messagerie décentralisé décide de faire passer une image contenant un code malicieux de sa fabrication (non reconnu par l’antivirus), celui-ci se propagera sans aucune vérification d’intégrité de l’image. Pour contrer cet éventuel problème, de nombreuses dispositions sont à prendre lors du développement du système.

Première décision à prendre, y’aura-t-il un contrôleur maitre ?

Le Contrôleur maitre est un serveur (ou client) vérifiant les opérations importantes. Dans la suite de l’article nous allons prendre la solution la plus simple pour la sécurité, une architecture avec la présence d’un contrôleur maitre. (si vous avez des questions sur la sécurité sans l’utilisation d’un contrôleur maitre posez moi les question en commentaire).

Le contrôleur maitre vérifiera l’intégrité des paquets et tiendra à jour une liste des peers (clients) potentiellement dangereux. Quant un paquet arrivera d’un client et qu’un doute se pose sur l’intégrité de celui-ci (nous verrons le contrôle de l’intégrité dans un article prochain), il demandera simplement au contrôleur maitre de vérifier ce paquet. Ainsi, si le paquet est valide (si il respecte une architecture spéciale, que le hash est bon et que l’analyse anti-virus + malware n’a rien donné) il renverra un signal au client. Dans le cas contraire un message général sera envoyé à la totalité des peers mettant en garde contre ce client. Au bout du deuxième avertissement, ce client ne sera plus autorisé à émettre sur le réseau.

Ces petites vérifications peuvent être très utiles afin de ne pas se retrouver avec un réseau poubelle.

Dans le cadre d’une application demandant un haut niveau de sécurité toutes les transactions importantes doivent être vérifiées par des contrôleurs maitres. Dans certains cas il est possible d’assigner certains utilisateurs comme contrôleurs maîtres (afin d’éviter la location d’un serveur).
Il est aussi recommandé d’utiliser des coverts channels dans le cadre d’applications à haute sécurité (un article sur le sujet verra le jour prochainement).

Maintenant que les présentations faites, nous allons maintenant voir les fonctions d’un Contrôleur maitre (C#/.NET) et comment procéder à son intégration sur un réseau.

Suite au prochain article, publication prévue fin de semaine.

Bonne journée à tous.