FR2824930A1

FR2824930A1 - Procede de communication et/ou de partage de ressources machines, au sein d'un reseau de communication, entre une pluralite de membres d'une communaute

Info

Publication number: FR2824930A1
Application number: FR0106410A
Authority: FR
Inventors: Quentin Gallet; Lannic Pierre Le
Original assignee: DEUXIEME TETE
Current assignee: DEUXIEME TETE
Priority date: 2001-05-15
Filing date: 2001-05-15
Publication date: 2002-11-22
Anticipated expiration: 2021-05-15
Also published as: EP1388058A1; FR2824930B1; WO2002093373A1; US20050138181A1

Abstract

L'invention concerne un procédé de communication et/ ou de partage de ressources machines, au sein d'un réseau de communication, entre une pluralité de membres d'une communauté. Chaque membre est qualifié d'actif ou de passif selon qu'il est connecté ou non à la communauté. Selon l'invention, le procédé comprend une étape de gestion, par au moins un serveur central, du graphe des connexions entre les membres actifs. Cette étape de gestion comprend elle-même une étape telle que, lorsque l'un des membres passifs (dit futur membre actif) souhaite se connecter à la communauté, il établit une connexion temporaire avec le serveur central, de façon que ce dernier fournisse des directives de connexion au futur membre actif et au (x) membre (s) actif (s) au (x) quel (s) celui-ci doit se connecter. Puis, le futur membre actif établit une connexion permanente, d'égal à égal ( " peer-to-peer " ), avec chaque membre actif indiqué par le serveur central. La technique selon l'invention peut donc être qualifiée de " peer-to-peer hybride ", puisqu'elle combine une centralisation de la gestion du graphe des connexions entre membres actifs, avec une décentralisation des échanges entre membres actifs.

Description

1 2824930

Procédé de communication et/ou de partage de ressources machines, au sein d'un réseau de communication, entre une pluralité de membres d'une communauté. Le domaine de l' invention est celui des réscaux de communication, notamment, mais non exclusivement, de type IP (réseaux de type Internet). Plus précisément, l'invention concerne la communication et/ou le partage de ressources machines, au sein d'un tel réseau de communication, entre une pluralité de

membres d'une communauté.

Par "communication entre membres", on entend la possibilité donnée aux membres d'une communauté de communiquer entre eux, suivant différentes modalités (à

deux ou à plusieurs, en temps rcel ou en temps différé,...).

Le concept de "partage de ressources machines entre membres" recouvre la mise en commun de ressources de stockage disque et/ou de ressources de calcul des machines

dont disposent les membres.

Par "communauté" (ou "tribu"), on entend une structure permettant la mise en relation d'un ensemble de personnes (appelées "membres" ou "adhérents") ayant au moins un centre d'intérêt commun et/ou un point commun. En d'autres termes, pour former une communauté, des utilisateurs se fédèrent par affinité, par âge, par lieu d'habitation, par société,... Une communauté peut aussi être un groupe de travail. Au sein d'une communauté, on distingue les membres connectés, dits membres actifs (ou "résidents"), et les membres non connoctés, dits membres passifs. Un membre actif (re) devenant un membre pas sif dès qu ' il se déconnocte de la communauté. Inversement,

un membre passif (re)devient un membre actif dès qu'il se connecte à la communauté.

Dans un seul souci de simplification, dans la suite de la description, on entend

par "membre de la communauté" non seulement la personne physique, mais aussi le matériel dont celle-ci dispose, à savoir une machine (typiquement un micro-ordinateur) et un logiciel (dit logiciel client) exécutée par cette machine. Le logiciel client permet la connexion d'un membre à au moins un autre membre actif de la communauté (à l'instar

du logiciel "Internet Explorer" (marque déposée) pour naviguer sur le Web) .

On connâît, dans l'état de la technique, différentes techniques de réalisation d'une communauté au sens précité, permettant à ses membres de communiquer entre eux

et/ou de se partager des ressources machines (unités de stockage et/ou unités de calcul).

On présente maintenant successivement trois familles de techniques connues de S l'art antérieur. Chaque technique connue est brièvement résumée, puis ses inconvénients

en termes fonctionnels et/ou technologiques sont exposés.

1. Techniques connues basées sur le modèle client/serveur Une première famille de techniques connues est basce sur le modèle client/serveur. L'architecture matérielle simplifée liée à ce modèle est telle que chaque équipement d'utilisateur est connocté uniquement à un serveur. Le serveur est par

ailleurs connocté en outre à une base de données.

1.1 Les sites Web communautaires Les sites Web communautaires sont caractérisés par la volonté de faire de l'ensemble de leurs utilisateurs une vraie communauté. Les exemples les plus connus sont "www.geocities. com", "www.respublica.fr" et "www.multimania.fr". Ils mettent à la disposition des utilisateurs certains services, notamment: - les "chats" (pour "Conversational Hypertext Access by Telecommunications" en anglais, c'est-à-dire "accès hypertexte interactif par télécommunications") et forums, pour la communication, - l'hébergement de "sites personnels", ces derniers étant indirectement un moyen d'échanger du contenu. Un utilisateur peut en effet utiliser ce moyen pour mettre en partage ses créations multimédia (images, musiques, vidéo...) ou donner des liens vers

d'autres sites.

Les inconvénients des sites Web communautaires résident dans le fait même qu'il s'agit d'une solution totalement centralisée. Les coûts en matériels (serveurs) et en bande pass ante sont importants pour héberger de telles communautés. Par ailleurs, le principe d'échange de fichiers à base de "uploadldownload" (c'est-à-dire chargement, d'un premier utilisateur vers le serveur, et téléchargement, du serveur vers un second utilisateur), est contraignant pour les utilisateurs et ne permet pas d'échanges en temps réel. 1.2 Les sites Web professionnels

3 2824930

On peut citer, à titre d'exemple de site Web professionnel, le site "www. rescarcha.com", qui est la "communauté pour les professionnels de l'information". Il s'agit d'un site qui met en relation vendeurs et chercheurs d'informations de tous domaines et toutes nationalités, en leur proposant notamment de mettre à disposition leur C.V. sur le site. Le site permet de plus à ses utilisateurs de charger dans la base de données des liens vers des sites jugés intéressants pour les autres, toujours dans le domaine de l' information. D'un point de vue technique, il n'y a là aucune originalité puisque les vrais échanges, autres que les simples

"upload/download" de C.V., ne peuvent se faire, a priori, que par courrier électronique.

Cependant, c'est un bon exemple de communauté virtuelle de gens ayant les mêmes

centres d'intérét.

Les sites Web professionnels présentent les mêmes inconvénients que les sites Web communautaires. On notera que le "uploabldownload" de C.V. peut convenir car ce

sont en général des fichiers de petite taille.

1.3 Les sites Web commerciaux Les sites Web commerciaux permettent à leurs utilisateurs de mettre en vente des fichiers (docoments, présentations, tutoriaux, musique, vidéo...). Cela implique que les utilisateurs aient au préalable chargé ("upload") ces fichiers dans le serveur gérant le site. Les visiteurs du site peuvent ensuite télécharger ("download"), contre paiement, les

fichiers qui les intéressent. On pourra citer comme exemple "www. creavente.com".

Il est cependant difficile de considérer que l' on a à faire à des communautés. Le problème avec ces sites tient plus au modèle économique lui-même. Les échanges restent somme toute peu nombreux, donc la solution technique adoptée ne pose pas de

problème de dimensionnement des sites.

1.4 L'IRC ("Internet Relay Chat"! L'IRC (voir par exemple le site "www. mirc.com") est un réseau mondial multi serveurs dédié au "chat". Les utilisateurs se retrouvent au sein de canaux pour discuter en temps-réel. L'IRC utilise une version évoluée du protocole "Talk". Il existe en fait plusieurs "gros" réseaux indépendants (plus de 50 000 utilisateurs simultanés), tels que "Efnet", "Undernet", "IRCnet" et "DALnet" (marques déposoes), qui diffèrent par leur ancienneté et leur répartition géographique. Il existe en outre un certain nombre de réscaux plus petits, ainsi que des réscaux entièrement dédiés à un sujet (enfants, informatique...). Techniquement parlant, la communication dans un canal repose sur la centralisation des échanges. Le cheminement d'un message émanant d'un membre d'un canal est le suivant: ce message est d'abord routé vers les autres serveurs du réseau de

serveurs (par exemple "IRCnet") qui sont impliqués dans l'hébergement du canal.

Chacun d'eux redirige ensuite le message vers les autres utilisateurs. Les fonctionnalités d'IRC ne se limitent pas au simple "chat". Il permet aux utilisateurs de faire de

l'échange de fichiers grâce à un autre protocole, le CTCP ("Client To Client Protocol").

lO Ce dernier permet l'envoi d'un fichier spécifique à l'interlocuteur, ainsi que la navigation dans le dossier mis en partage par l'utilisateur distant et le téléchargement

éventuel d'un nombre limité de fichiers à partir de ce dossier.

Son ancienneté et le nombre de ses utilisateurs ont fait de l'IRC un standard. Il est à noter cependant le nombre impressionnant de serveurs, qui est dû au fait que les échanges véritablement "pecr-to-peer" (point-àpoint d'égal à égal) restent marginaux par rapport au "chat" traditionnel. Par ailleurs, il y a peu d'entreprises commerciales assurant l'hébergement de serveur. La présence de ces serveurs dépend donc principalement du bon vouloir des universités et autres organismes publics qui les hébergent. D' un point de vue plus fonctionnel, l' utilisation des fonctionnalités

d'échange de fichier est très difficile pour un utilisateur lambda.

2. Techniques connues basées sur un principe de "peer-to-peer" centralisé Une seconde famille de techniques connues est basce sur le principe de "peer-to peer" (point-à-point, d'égal à égal) centralisé. Parler de "peerto-peer" centralisé peut sembler a priori antinomique. Cependant, il existe plusieurs exemples de sites utilisant cette technique. "Napster" (marque déposée) en est sans conteste l'exemple le plus connu. 2.1 Napster (www.napster.com! Napster est un réscau multi-serveurs qui permet à ses utilisateurs d'échanger des fichiers au format "mp3". Lorsqu'ils se connoctent au réscau, les utilisateurs de Napster envoient la liste des fichiers mp3 qu'ils acceptent de partager, vers un serveur qui stocke cette liste sur une base de données. C'est de là que vient l'aspect centralisé: la liste de s tous les fichiers mp3, ainsi que les profils des utilisateurs connectés, sont disponibles sur les serveurs Napster. En d'autres termes, le contenu est réparti chez les utilisateurs, tandis que l'indexation de ce contenu est centralisée sur les serveurs, dans une base de donnces associée. Une recherche de contenu n'est qu'une consultation de cette base de données. Une fois le fichier désiré trouvé, les deux intervenants (utilisateurs) de la "transaction" sont mis en relation de façon temporaire. Le transfert s'effectue en vrai "peer-to- pecr", c'est-à-dire sans transiter par le serveur. Pour ce qui est de la communication, Napster intègre un "chat". La structure du réseau Napster est telle que les serveurs ne sont pas connoctés entre eux. On assiste donc à l'apparition d'une

partition du réscau en sous-ensembles indépendants.

Comme toutes les solutions nécessitant une centralisation de l'information (dans le cas présent, centralisation de l'indexation du contenu réparti chez les utilisateurs), Napster doit posséder de nombreux serveurs pour faire face aux demandes des utilisateurs. Le problème se pose particulièrement en termes de capacités de stockage et de gestion des requêtes. A l'inverse d'IRCnet (voir ci-dessus), par exemple, o les serveurs sont reliés entre eux, les serveurs Napster sont indépendants. Un utilisateur qui pense se connecter au réseau Napster ne fait en fait que se connecter à un sous ensemble. Cela va quelque peu à l'encontre du discours traditionnel de la marque qui s'appuie sur le concept de communauté à l'échelle mondiale. De part sa structure en étoile, le graphe du réseau Napster permet difficilement la création de sous communautés. I1 est par essence mono-communauté. Un sous-réseau Napster est entièrement dépendant de son serveur. Il n'aucune capacité d'autonomie en cas de panne de celui-ci. On pourra aussi citer le manque de moyens techniques réellement efficaces

pour éviter le partage de fichiers protogés par droit d'auteur (ou "copyright").

2.2 Les "similaires à Napster" L'exemple de Napster a été suivi par d'autres sociétés qui ont développé des sites et produits similaires. C'est le cas de la société Scour (voir "www.scour.com"), qui a développé un outil, "Scour Exchange" (marque déposée), assez proche de Napster avec cependant la différence notable suivante: il permet d'échanger tout type de fichiers multimédia, et non pas seulement les fichiers mp3. De méme, la société GlobalSCAPE ("www.cutemx.com/cutemx/") a développé un outil, "CuteMX" (marque déposée"), lui i aussi proche de Napster dans ses fonctionnalités et dans les techniques utilisées. A l' inverse de Napster et Scour, il n'y a aucune restriction sur les types de fichiers échangés. Les techniques précitées des société Scour et GlobalSCAPE sont très proches

de celle utilisée par Napster. Leurs inconvénients sont donc à peu près les mêmes.

3. Techniques connues basées sur un principe de "peer-to-peer" décentralisé Une troisième famille de techniques connues est basce sur le principe de "peer to-pecr" décentralisé. A l' inverse des solutions précédemment citées, celles-ci ne requièrent pas l'utilisation de serveurs, que ce soit pour leur maintien ni pour leur construction. L'utilisateur doit cependant télécharger, à partir d'un site dédié, un logiciel client lui permettant de se connocter directement au réseau "peer-to-peer". En fait, à travers ce logiciel client, ce site dédié fournit à l'utilisateur (nouvel arrivant) une liste de membres (sans précision sur le fait que ceux-ci sont actifs ou passifs, c'est-à-dire connectés ou non à la communauté). Pour se connecter à la communauté, le nouvel arrivant est invité à tenter d'établir une connexion avec un ou plusieurs utilisateurs de la liste précitée. On notera que le site dédié n'est en aucune façon informé des connexions effectivement réalisces entre utilisateurs, ni a fortiori des déconnexions intervenant entre ces utilisateurs. En outre, il est bien sûr impossible pour le site dédié d'effectuer un

quelconque contrôle sur le contenu échangé entre utilisateurs.

3.1 Gnutella (www.gnutella.wego.com! L'exemple le plus probant de ce type de logiciel client est Gnutella (marque déposée), qui permet la création d' un réseau d' utilisateurs (au sens " communauté"), le "Gnet". Les membres de ce réseau s'appellent les "servents" (contraction de serveur et client). On distingue 4 types de messages qui circulent sur le Gnet (c'est-à-dire qui sont routés par les servents): "Ping" (message émis par un nouvel arrivant pour signaler sa présence), "Pong" (réponse à un "Ping", signifiant "je suis déjà sur les Gnet, je partage N fichiers soit M Ko"), "Requête" ("je recherche un fichier dont le nom contient la chaîne de caractères suivante "XXX"") et "Réponse" (réponse à une requête, signifiant "je possède tel fichier, vous pouvez venir le télécharger"). L'utilisateur peut ensuite décider

à loisir de télécharger le fichier directement chez l'utilisateur distant qui lui a répondu.

Le problème principal de Gnutella est que cela ne fonctionne pas vraiment. Le "Gnet" est véritablement surchargé. La visibilité par les utilisateurs de l'ensemble du :t réseau est très limitée. Les solutions mises en _uvre pour y remédier pourront réduire ces effets, mais pas les éliminer. Les différents logiciels clients qui ont été développés essaient d'intogrer des fonctionnalités plus évoluées, mais c'est véritablement le principe technique sousjacent qui n'est pas adapté à une communauté aussi importante. Pour l'utilisateur, réussir à télécharger un fichier se révèle très aléatoire et en tout cas très long. Par ailleurs, une fois en place, le "Gnet", parce qu'il est entièrement décentralisé, ne peut plus être soumis à un contrôle quelconque. I1 n'y a donc pas d'optimisation possible du graphe des connexions, pour résoudre les problèmes liés à la présence de

résidents équipés d'un modem.

3.2 Freenet (www.frcenet.sourceforege.net! Frcenet est un réseau "peer-topeer" décentralisé, visant à garantir l'anonymat de ses membres ainsi que leur liberté d' expression. Freenet met en _uvre une politique répartie de gestion du contenu qu'il héberge. Le contenu présent sur le réseau Freenet ne réside pas forcément sur l'ordinateur de celui qui l'a introduit; il est répliqué continuellement de poste à poste. De manière dynamique, les fichiers les plus utilisés ou consultés sont donc répliqués le plus souvent. Cela permet de garantir le caractère accessible des fichiers, d'augmenter leur persistance (c'est-à-dire leur résistance à tout

organisme de censure).

La politique de gestion du contenu présent sur Freenet pose quelques problèmes.

L' anonymat qui protoge ses membres n'en fait pas un garant de la liberté d' expression mais plus un véhicule privilogié du contenu à caractère pornographique, de propagande pour l'utilisation des drogues. Par ailleurs, l' interface homme/machine est difficile à utiliser. 3.3 The Mojo Nation (www.mojonation.net) The Mojo Nation est un réscau "peer-topeer" inspiré de Freenet. Sa vocation première est de résoudre les problèmes de Gnutella et Napster concernant le partage des fichiers multimédia riches, telles les vidéos peu comprimées. A cet effet, il permet de fractionner ces fichiers de grandes tailles et de disséminer les fragments obtenus chez plusieurs utilisateurs. Le téléchargement d'un fichier consiste donc à récupérer la liste des fragments, de les importer un à un et enfin de reconstituer le fichier original. Cette

technique a pour effet de mieux répartir la charge réseau sur tous ses membres.

8 2824930

Le fait de fragmenter le contenu requiert énormément de redondance pour pallier l' absence éventuelle d'un utilisateur. En effet, la perte d'un fragment peut rendre complètement inutilisable le fichier entier. Part ailleurs, de même que pour Freenet, l' installation et l'utilisation du logiciel client Mojo Nation sont réservoes à des utilisateurs avertis. L' invention a notamment pour objectif de pallier ces différents inconvénients de

l'état de la technique.

Plus précisément, l'un des objectifs de la présente invention est de fournir un procédé de communication et/ou de partage de ressources machines entre une pluralité de membres d'une communauté (au sens précité) , qui permette une gestion optimisoe du

graphe des connexions entre les membres actifs.

Un autre objectif de l' invention est de fournir un tel procédé permettant aux membres de la communauté de communiquer entre eux en temps réel, et/ou de se

partager des ressources machines en temps réel.

1 5 Encore un autre obj ectif de l' invention est de fournir un tel procédé ne

nécessitant pas de centralisation des échanges entre membres actifs.

L' invention a également pour objectif de fournir un tel procédé permettant de garantir à la fois les intérêts des "hétergeurs" (aussi appelés FAC, pour "fournisseurs

d'accès aux communautés") et les intérêts des membres de la communauté (utilisateurs).

Pour les "fournisseurs d'accès aux communautés", il convient de garantir notamment: la qualification des membres actifs (ou résidents), le contrôle des accès à la communauté et la surveillance du contenu échangé entre membres de la communauté. Pour les membres de la communauté, les intérêts à garantir sont notamment: la sécurité des échanges, la

sécurité des données et la qualité de service.

Ces différents objectifs, ainsi que d'autres qui apparâîtront par la suite, sont atteints selon l'invention à l' aide d'un procédé de communication etlou de partage de ressources machines, au sein d'un réscau de communication, entre une pluralité de membres d'une communauté, chacun desdits membres étant dit membre actif ou membre passif selon qu'il est connecté ou non à la communauté. Selon l'invention, ledit procédé comprend une étape de gestion, par au moins un serveur central, du graphe des connexions entre les membres actifs de la communauté. Cette de gestion comprend elle même les étapes suivantes, lorsque l'un des membres passifs, dit futur membre actif, souhaite se connocter à la communauté: - le futur membre actif établit une connexion temporaire avec le serveur central, de façon à l'informer de son souhait de se connecter à la communauté; - le serveur central calcule, et/ou fait calculer, à quel(s) membre(s) actif(s) le futur membre actif doit se connocter, et génère des directives de connexions correspondantes; - via ladite connexion temporaire, le serveur central fournit des directives de connexion au futur membre actif; - le serveur central établit une connexion temporaire avec chaque membre actif avec lequel le futur membre actif doit se connocter, afin de lui fournir des directives de connexion; - le futur membre actif établit une connexion permanente, d'égal à égal, avec

chaque membre actif que lui a indiqué le serveur central.

Le principe général de l'invention consiste donc à combiner une centralisation de la gestion du graphe des connexions entre membres actifs, avec une décentralisation des échanges entre membres actifs (connexions "pecr-to-pecr" entre membres actifs). La

technique selon la présente invention peut donc être qualifiée de "peerto-peer hybride".

Elle permet de cumuler les avantages liés à la centralisation, et ceux liés à la

décentralisation, tout en évitant leurs inconvénients respectifs.

Dans le cas présent, l'aspect centralisé permet la gestion du graphe des connexions des membres actifs de la communauté. Ainsi, les connexions entre les membres actifs de la communauté sont permanentes (contrairement à la solution Napster, o elles sont temporaires) et organisées de manière intelligente (contrairement à

la solution Gnutella, o elles sont totalement libres).

Comme discuté en détail par la suite, l'aspect centralisé permet aussi, éventuellement, la gestion de la sécurité de la communauté, le contrôle du contenu des échanges entre membres, l'établissement de comptes-rendus (statistiques par exemple) sur l'activité des membres actifs, l'authentification des membres passifs souhaitant se connocter à la communauté, etc.

2824930

L'aspect décentralisé, différence fondamentale avec le modèle client/serveur, permet quant à lui la diminution de la charge induite sur les serveurs centraux, l'amélioration des capacités d'autonomie des communautés, le stockage réparti du "contenu" de la communauté (c'est-àdire des fichiers que les membres de la communauté peuvent s'échanger), le fonctionnement en temps réel, etc. Préférentiellement, ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre les étapes suivantes, lorsque l'un des membres actifs est déconnocté de la communauté: - le serveur central est informé de cette déconnexion, par le membre redevenu passif et/ou par au moins un des membres actifs, et détermine l'(es) éventuel(s) membre(s) actif(s) qui se trouve(nt) détaché(s) de la communauté du fait de cette déconnexion; - le serveur central calcule, et/ou fait calculer, à quel(s) membre(s) actif(s) chaque membre actif détaché de la communauté doit se connocter, et génère des directives de connexions correspondantes; - le serveur central établit une connexion temporaire avec chaque membre actif détaché de la communauté et avec chaque membre actif auquel celui-ci doit se connecter, de façon à leur fournir des directives de connexion; - chaque membre actif détaché de la communauté établit une connexion permanente, d'égal à égal, avec chaque membre actif que lui a indiqué le serveur central. De façon avantageuse, ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre l'étape suivante: - à au moins un instant, le serveur central calcule, et/ou fait calculer, une réorganisation au moins partielle dudit graphe des connexions, touchant au moins certains membres actifs, et génère des directives de déconnexion/reconnexion correspondantes; - le serveur central établit une connexion temporaire avec chacun des membres actifs touchés par la réorganisation, afin de lui fournir des directives de déconnexion/reconnexion; - les membres actifs touchés par la réorganisation établissent entre eux des

connexions permanentes, d'égal à égal, selon les indications du serveur central.

En effet, le graphe des connexions résulte d'une succession d'ajouts de nouveaux membres actifs ou de suppression de membres actifs qui se déconnoctent. Une roorganisation partielle ou totale du graphe des connexions peut donc parfois être nécessaire. Avantageusement, les directives de connexion et/ou les directives de déconnexion/reconnexion sont calculées selon au moins un algorithme prenant en compte au moins un critère d'optimisation du graphe des connexions entre les membres

actifs de la communauté.

D'une façon générale, il s'agit notamment d'augmenter la qualité de service sur les échanges de données entre les membres actifs de la communauté (en évitant les phénomènes de goulets d'étranglement), ainsi que le maintien du caractère connexe du graphe des connexi ons (en évitant l' app arition, au sein du graphe, de sou s -ens embl e s

1 5 indépendants).

Préférentiellement, ledit au moins un critère d'optimisation du graphe des connexions appartient au groupe comprenant: - la réduction de la redondance des messages échangés entre membres actifs; - la limitation du temps de transfert d'un message d'un membre actif à un autre; l'optimisation de la répartition géographique des membres actifs; l'augmentation de la robustesse de la structure vis-à-vis de la déconnexion de l'un des membres actifs; - la limitation du nombre moyen de membres actifs auxquels un membre actif est

directement connecté.

Dans un premier mode de réalisation avantageux de l'invention, les directives de connexion et/ou les directives de déconnexion/reconnexion sont calculées, de façon

centralisée, dans le serveur central.

Dans un second mode de réalisation avantageux de l'invention, les directives de connexion et/ou les directives de déconnexion/reconnexion sont calculées, de façon

décentralisée, par les membres actifs de la communauté.

12 2824930

De façon préférentielle, chaque connexion d'égal à égal entre deux membres actifs supporte un trafic de donnces permettant de réaliser au moins une des fonctionnalités suivantes: - transmission de messages point- à-point; - transmission de messages de diffusion, point-multipoint; - recherche spécifique de contenu, au sein de ressources de stockage disque mises en commun par l'un des deux membres actifs; - exploration directe, au sein de ressources de stockage disque mises en commun par l'un des deux membres actifs;

- téléchargement de fichiers.

Dans un mode de réalisation particulier de l' invention, le réseau de communication est de type IP. Il est clair cependant que la présente invention n'est pas

limitée aux réseaux de type internet.

Préférentiellement, pour la transmission de données au sein de la communauté,

chaque membre actif utilise un protocole d'échange propriétaire.

De cette façon, la connaissance de ce protocole d'échange propriétaire présente une valeur importante, puisqu'elle permet d'être mâître de ce qui peut transiter entre

membres actifs de la communauté.

Avantageusement, pour la transmission de donnces au sein de la communauté, chaque membre actif utilise un protocole d'échange paramétré par une clé. Ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre l'étape suivante: à au moins un instant, le serveur central invite chaque membre actif à modifier sa clé de p aramétrage du protocole d' échange, de faç on

que ledit protocole d'échange soit au moins partiellement modifié.

Ainsi, l'invention propose une défense dynamique, en cas d'attaque, par une modification évolutive du protocole d'échange entre membres actifs. On peut parler de

"protocole mutant".

De façon préférentielle, ledit au moins un serveur central comprend au moins un module de gestion du graphe des connexions et, éventuellement, au moins un module

réalisant au moins une fonctionnalité particulière.

13 2824930

En d'autres termes, on développe une architecture bas niveau, au-dessus delaquelle on positionne un ensemble de modules (ainsi que des composants, comme expliqué en détails ci-après). Enrichir le serveur central d'une nouvelle fonctionnalité revient à lui ajouter un nouveau module. Ainsi, il est possible d'améliorer un module

S existant sans modifier les autres modules.

I1 convient de noter que dans la présente description, il existe une distinction

sémantique entre le module, qui se trouve sur le serveur central, et le composant, qui se trouve dans le logiciel client d'un des membres. Hormis cette distinction, le module et le composant désignent tous les deux une partie de programme isolable et réalisant une

fonctionnalité particulière.

Av antageu sement, ledit au moins un module réal is ant au moi ns une fonctionnalité particulière appartient au groupe comprenant: - des modules d' authentification des membres pas sifs souhaitant se connecter à la communauté; 1 S - des modules de gestion de la sécurité de la communauté; - des modules d'établissement de comptes-rendus sur l'activité des membres actifs;

- des modules de contrôle du contenu échangé entre membres actifs.

- des modules de partage de ressources d'unités de calcul; - des modules de partage de ressources d'unités de stockage; - des modules de communication en mode texte (chat, forum); - des modules de communication en mode vidéo (visioconférence); - des modules de création multimédia;

- des modules de jeux et/ou d'interactivité entre membres actifs.

De façon avantageuse, ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre l'étape suivante: chaque type de module est dupliqué en un nombre d'exemplaire fonction de sa charge, relative aux

connexions temporaires des membres actifs et/ou des futurs membres actifs.

Cette caractéristique de duplication vise principalement le cas d'une variation lente de la charge. En effet, elle permet au serveur central de conserver, pour une fonctionnalité centralisée donnée, une même qualité de service aux membres actifs de la communauté, lors d'une lente montée en charge du module concerné par cette

14 2824930

fonctionnalité centralisce. Des répartiteurs de charge ("load balancers") compris dans le serveur central permettent alors de répartir la charge entre les différents modules résultant de la duplication du module initial. Inversement, quand la charge tend à baisser lentement, l' opération cons iste à effacer les modules i nutiles et/ou à regrouper au maximum les modules sur le serveur. Dans le cas d'une augmentation rapide de la charge, la duplication de module semble plus difficilement envisageable et il parâît donc difficile de conserver la même qualité de service sur la communauté. Côté membre (logiciel client), la dégradation du service peut consister à arbitrairement refuser de router certain s me s s ages jugés d'importance moindre. Côté serveur central, cette dogradation intervient de manière évolutive, notamment au sein du module de gestion du graphe des connexions. Ce dernier peut être amené à respecter de manière moins rigoureuse les critères qui déterminent normalement le graphe. Cela permet une diminution du temps de calcul lors des connexions et des réorganisations. Dans ce cas, seul est conservé le souci d'assurer à tout prix la connexité de la communauté. De manière générale, on constate alors une perte de qualité sur les fonctionnalités centralisces. Inversement, dans le cas d'une baisse rapide de charge, le module de gestion du graphe des connexions revient naturellement à

son fonctionnement optimal.

De façon préférentielle, chaque membre de la communauté comprend un logiciel client comprenant lui-même: - un composant de connexion temporaire avec le serveur central, en vue d'une connexion à la communauté des membres actifs; - éventuellement, au moins un composant réalisant au moins une fonctionnalité particulière. De même que les modules du serveur central, les composants des logiciels clients participe de l'architecture bas niveau précitée propre à l'invention. Enrichir le

logiciel client d'une nouvelle fonctionnalité revient à lui ajouter un nouveau composant.

I1 est possible de proposer à l'utilisateur une gamme de logiciels clients, comprenant par exemple une version de base gratuite ainsi que des versions évoluces payantes.

2824930

Avantageusement, ledit au moins un composant réalisant au moins une fonctionnalité particulière appartient au groupe comprenant: - des composants de partage de ressources d'unités de calcul; - des composants de partage de ressources d'unités de stockage; S - des composants de communication en mode texte (chat, forum); - des composants de communication en mode vidéo (visioconférence); - des composants de messagerie instantance; - des composants de messagerie différée; - des composants de création multimédia;

- des composants de jeux ettou d'interactivité entre membres actifs.

I1 convient de noter que certaines fonctionnalités peuvent être centralisées (c'est à-dire hébergées par un module du serveur central) ettou décentralisées (c'est-à-dire

hébergées par un composant du logiciel client du membre de la communauté).

Dans un mode de réalisation particulier de l' invention, ledit au moins un serveur central est mutualisé, de façon à pouvoir assurer la gestion d'au moins deux communautés. I1 est à noter qu'un même utilisateur peut être membre de plusieurs communautés

à la fois.

Préférentiellement, ledit procédé comprend en outre une étape de contrôle, par le

serveur central, du contenu échangé entre membres actifs.

I1 existe une synergie entre cette fonctionnalité de contrôle du contenu échangé et la fonctionnalité précitée de gestion du graphe des connexions. On notera que c'est

l'aspect centralisé qui permet de réaliser ces deux fonctionnalités.

Cette fonctionnalité de contrôle du contenu échangé permet notamment de respecter la jurisprudence en matière de Propriété Intellectuelle (notamment le respect des _uvres originales protégées par Droit d'Auteur). C'est par exemple le fournisseur d'accès à la communauté qui décide de la façon précise dont il entend effectuer le

contrôle de contenu.

De façon avantageuse, ladite étape de contrôle du contenu échangé entre membres actifs comprend les étapes suivantes:

16 2824930

- au moins un module espion, hébergé par ledit au moins un serveur central et se comportant comme un membre actif, se connocte à au moins un membre actif de la communauté; - au moins un module de traitement et/ou de décision, hébergé par ledit au moins un serveur central, reçoit dudit au moins un module espion des informations relatives à au moins certaines des données échangées entre membres actifs de la communauté. Ainsi, par l'intermédiaire du module espion, le serveur central fait lui-même indirectement partie de la communauté. En d'autres termes, il peut "voir la communauté

de l'intérieur".

Avantageusement, lesdites informations relatives à au moins certaines des données échangées entre membres actifs de la communauté appartiennent au groupe comprenant: - des donnces brutes échangées entre membres actifs de la communauté; - des données résultant d'un pré-traitement, effectué par au moins un des membres actifs et/ou ledit au moins un module espion, de données brutes échangées entre

membres actifs de la communauté.

De façon préférentielle, ledit procédé comprend en outre une étape de gestion de la liste des membres de la communauté, et ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre l'étape suivante: authentification, par le serveur central, du futur membre actif souhaitant se connecter à la communauté, ladite authentification consistant à vérifier que le futur

membre actif appartient à ladite liste des membres de la communauté.

La gestion de la liste des membres de la communauté peut être effectuce par le serveur central ou par un équipement distant de celui-ci (par exemple un site Web

spécifique, dédié à l'inscription des nouveaux membres).

L'invention concerne également un programme d'ordinateur comprenant des séquences d' instructions adaptées à la mise en _uvre du procédé décrit ci-dessus,

lorsque ledit programme est exécuté sur un ordinateur.

L'invention concerne aussi un serveur central comprenant des moyens de gestion du graphe des connexions entre les membres actifs de la communauté, lesdits moyens de gestion comprenant eux-mêmes les moyens suivants: - des moyens d'établissement d'une connexion temporaire avec un des membres passifs, dit futur membre actif, qui souhaite l'informer de son souhait de se connecter à la communauté; - des moyens de calcul, de façon à déterminer à quel(s) membre(s) actif(s) le futur membre actif doit se connecter; - des moyens de génération de directives de connexions correspondantes; - des moyens de fourniture desdites directives de connexion, via ladite connexion temporaire, au futur membre actif; - des moyens d'établissement d'une connexion temporaire avec chaque membre actif avec lequel le futur membre actif doit se connocter, afin de lui fournir des directives de connexion; de façon que le futur membre actif établisse une connexion permanente, d'égal à égal,

avec chaque membre actif que lui a indiqué le serveur central.

D'autres caractéristiques et avantages de l'invention apparâtront à la lecture de

la description suivante d'un mode de réalisation préférentiel de l' invention, donné à titre

d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels: - la figure 1 illustre le principe général du procédé selon l'invention, de communication et/ou de partage de ressources machines entre les membres d'une communauté; - la figure 2 présente un exemple de structure possible pour le graphe des connexion entre les membres actifs d'une communauté; - la figure 3 illustre le mécanisme de contrôle de contenu dans un mode de réalisation particulier du procédé selon l'invention; - la figure 4 présente le positionnement d'un exemple de protocole d'échange utilisé par les membres actifs pour la transmission de données; - la figure 5 présente un schéma simplifié d'un mode de réalisation particulier d'un serveur central selon la présente invention; et

18 2824930

- la figure 6 présente un schéma simplifié d'un mode de réalisation particulier d'un membre de la communauté selon la présente invention, ledit membre étant entendu comme la combinaison de l'utilisateur personne physique et de sa

machine qui exécute un logiciel client.

L'invention concerne donc un procédé de communication et/ou de partage de ressources machines, au sein d'un réseau de communication, entre une pluralité de

membres d'une communauté.

Dans la suite de la description, on suppose que le réseau de communication est

de type IP, c'est-à-dire basé sur le protocole Internet. I1 est clair que l' invention n 'est pas

limitée à ce type particulier de réscau de communication.

On présente maintenant de façon détaillée, en relation avec la figure 1, le principe général du procédé selon l'invention, qui consiste à combiner une centralisation de la gestion du graphe des connexions entre membres actifs, avec une décentralisation

des échanges entre membres actifs ("pecr-to-peer hybride").

Dans la suite de la description, on suppose que la centralisation précitée est mise

en _uvre par un unique serveur central 1. I1 est clair cependant que l'invention couvre également le cas o cette centralisation est réalisée par plusieurs serveurs centraux

coopérant entre eux.

Dans un souci de simplification, on entend par "membre de la communauté" 2 non seulement la personne physique 23, mais aussi le matériel dont celle-ci dispose, à

savoir une machine 21 exécutant un logiciel client 22 (voir figure 6).

Dans l'exemple illustratif de la figure 1, on suppose que l'on se situe à un instant t

o la communauté comprend six membres actifs, 2, à 26, et cinq membres passifs 3, à 35.

Les six membres actifs, 2, à 26 sont connectés entre eux par huit connexions "pecr-to

peer" (point-à-point, d'égal à égal) C1 à C8.

Le procédé selon l'invention propose une gestion intelligente du graphe des connexions entre les membres actifs, lorsque l'un des membres passifs souhaite se

connecter à la communauté (et donc lui-même devenir un membre actif).

Par exemple, si l'on suppose que le membre passif référencé 3, (appelé ciaprès "futur membre actif") souhaite se connocter à la communauté, le procédé selon la

19 2824930

présente invention consiste alors, comme illustré sur la figure 1, à effectuer les étapes suivantes: - le futur membre actif 3, établit une connexion temporaire avec le serveur central 1, afin de l'informer de son souhait de se connocter à la communauté (flèche référencée a);

- le serveur central 1 calcule (etlou fait calculer, voir description détaillée ci-après

du module de gestion du graphe des connexions) à quels membres actifs (ceux référencés 2 et 26 dans cet exemple) le futur membre actif 3, doit se connecter, et génère des directives de connexions correspondantes; via la connexion temporaire, le serveur central 1 fournit des directives de connexion au futur membre actif 3, (flèche référencée b); - le serveur central 1 établit une connexion temporaire avec chacun des membres actifs concernés 2, et 26, afin de leur fournir les directives de connexion (flèches référencées c et d respectivement); - le futur membre actif 3" ainsi que chacun des membres actifs concernés 2 et 26

se déconnecte du serveur central 1.

- le futur membre actif 3, se connecte à la communauté en établissant une connexion "pecr-to-peer" permanente avec chacun des membres actifs concernés 2, et 26, que le serveur central 1 lui a précédemment indiqués. Sur la figure 1, les deux connexions "peer-to-peer" ainsi établies sont représentées en pointillé et

référencées C9 et C10.

L'envoi de directives de connexion par le serveur central 1 consiste en la transmission, à chaque membre concerné par une connexion "pecrto-peer" donnée, de

l'adresse IP de l'autre, afin que ces deux membres puissent initier ensuite la connexion.

Chaque connexion "peer-to-peer" entre deux membres actifs est permanente en ce sens qu'elle existe soit jusqu'à une déconnexion volontaire ou accidentelle de l'un de ces deux membres, soit jusqu'à une réorganisation du graphe des connexions décidée par

le serveur central (cette réorganisation est discutée en détail ci-après).

Chaque connexion "peer-to-peer" entre deux membres actifs de la communauté peut être comparce à un "tunnel" supportant un trafic de données différent suivant la fonctionnalité réalisée:

2824930

- transmission de messages point-à-point; - transmission de messages de diffusion (ou messages point-multipoint); - recherche spécifique de contenu, au sein de ressources de stockage disque mises en commun par l'un des deux membres actifs; - exploration directe, au sein de ressources de stockage disque mises en commun par l'un des deux membres actifs; téléchargement de fichiers; - fonction "push", qui consiste à transmettre un ficjier vers un autre membre actif (à l'inverse du téléchargement, o l'initiative en revient à celui qui reçoit le fichier); - etc. Ces données sont par exemple transmises suivant un protocole propriétaire au dessus d'IP. Lors de la création des paquets de données, il faut dans ce cas préciser si le transfert se fera en utilisant le protocole TCP ("Tranfer Control Protocol") ou UDP 1S ("User Datagram Protocol"). La figure 4 illustre ce positionnement du protocole propriétaire, noté "protocole L2T", au méme niveau que les protocoles FTP ("File

Transfer Protocol") et http ("hyper text transfer protocol").

Les échanges de donnces entre membres actifs peuvent étre protogés par chiffrement (basé sur un principe classique de clefs publiques/clefs privées) et/ou compression de données (basée sur des algorithmes standards réputés pour leur grande sûreté). Chaque membre actif peut recevoir et renvoyer des messages. I1 agit par conséquent en tant que routeur. En pratique, cette action de routage est effectuée de

façon automatique, au sein du membre actif, par la machine exécutant le logiciel client.

Cela se passe donc de manière transparente pour la personne physique utilisatrice. On rappelle que, dans un souci de simplification, on entend par "membre de la communauté" non seulement la personne physique, mais aussi le matériel dont celle-ci

dispose (machine et logiciel client).

On distingue particulièrement deux types de messages: les messages de diffusion et les messages point-à-point. On présente maintenant un exemple de gestion

de ces deux types de messages par les logiciels clients des membres actifs.

21 2824930

Les messages de diffusion sont destinés à l' ensemble de la communauté. Ils ont un identificateur unique. Chaque logiciel client stocke dans une pile la liste des identificateurs des messages qu'il a déjà reçus. Cette liste a une taille limitée: au fur et à mesure de l'arrivoe de nouveaux messages, les identificateurs des plus anciens messages sont enlevés. Quand un logiciel client reçoit un message de diffusion, il vérifie dans sa pile d'identificateurs s'il ne l'a pas déjà reçu. S'il l'a effectivement déjà reçu, il se contente de l'effacer. Dans le cas contraire, il l'envoie à l'ensemble des logiciels clients à qui il est connecté, sauf évidemment celui qui le lui a transmis. Dans le cas d'une structure connexe, une telle politique distribuée de routage permet d'atteindre de proche en proche l' ensemble des membres actifs de la communauté. Une recherche de contenu est

un exemple typique de fonctionnalité qui utilise l'envoi d'un message de diffusion.

Les mess ages point- à-point sont destinés à un membre actif en particulier. Un message point-à-point contient lui-même l'information précise du chemin qu'il doit emprunter, sachant que celui-ci est unique. Lors de chaque routage, le logiciel client concerné se contente de rediriger le message vers le logiciel client suivant, dans l'ordre

pré-établi du chemin. La réponse à une requete est un exemple de message point-à-point.

Dans ce cas, le membre actif destinataire est celui qui a émis la requête de recherche de contenu. Le procédé selon l'invention propose également une gestion intelligente du graphe des connexions entre les membres actifs, lorsque l'un des membres actifs se déconnocte (volontairement ou non) de la communauté (et donc redevient un membre passif). Le procédé selon la présente invention consiste alors à effectuer les étapes suivantes: - le serveur central est informé de la déconnexion, par le membre redevenu passif etlou par au moins un des membres actifs, et détermine le ou les éventuels membres actifs qui se trouvent détachés de la communauté du fait de cette déconnexion;

22 2824930

- le serveur central calcule (et/ou fait calculer) à quels membres actifs chaque membre actif détaché de la communauté doit se connocter, et génère des directives de connexions correspondantes; - le serveur central établit une connexion temporaire avec chaque membre actif détaché de la communauté et avec chaque membre actif auquel celui-ci doit se connecter, de façon à leur fournir des directives de connexion; - chaque membre actif détaché de la communauté établit une connexion "pecr-to

peer" permanente avec chaque membre actif que lui a indiqué le serveur central.

Dans la mesure du possible, la déconnexion entre deux membres ne doit pas intervenir de manière brutale et inattendue. C'est pourquoi des mécanismes sont mis en

place pour détecter et signaler le plus rapidement possible la rupture de ce type de lien.

Ces mécanismes de remontée de l' information de déconnexion peuvent étre mis en _uvre dans le membre actif concerné lui-même (notamment si la déconnexion est

volontaire) et/ou dans un ou plusieurs autres membres actifs.

On présente maintenant de façon détaillée la notion de partage des ressources

machines dont disposent les membres.

Chaque membre actif (aussi appelé "résident") peut décider de mettre en partage une partie de son disque dur, c'est-à-dire d'un certain nombre d'unités de ressources de stockage disque. Il lui suffit par exemple pour cela de crcer sur son disque dur un dossier spécifique, dédié au partage. Il peut ensuite y insérer tous les sous-dossiers et fichiers qu'il accepte de partager. Cette partie de son disque dur sera disponible (généralement en lecture seule, pour des raisons de sécurité) pour les autres membres actifs, soit via une recherche spécifique de contenu, soit via une exploration directe. L'ensemble des arborescences mises en partage par les membres actifs forme la base de données répartie

de la communauté.

De la même façon, chaque membre actif peut décider de mettre en partage une partie de la capacité de calcul de son ordinateur, c'est-à-dire d'un certain nombre d'unités de ressources de calcul. Ceci revient pour le membre actif à mettre à disposition de la communauté un certain pourcentage de la CPU de son ordinateur. Dans le cas d'un

passage en mode veille, ce pourcentage peut augmenter.

23 2824930

Sur la figure 6, les ressources de stockage disque sont référencées 211, et la partie de celles-ci qui est partagée est représentée par une zone hachurce et référencce 21 lc. De même, les ressources de calcul sont référencées 212, et la partie de celles-ci

qui est partagée est représentée par une zone hachurée et référencée 212c.

Ce partage des ressources machines présente de nombreuses applications, et notamment: - site Web décentralisé: le contenu du site est hébergé par la base de donnce répartie de la communauté. Les pages Web sont générées à l'aide de la puissance de calcul de chacun des ordinateurs qui hébergent une partie du site. Cela implique un protocole particulier et une forte redondance des informations contenues dans le site; - travail collectif: les ordinateurs sont mis à contribution dans le cadre d'un travail nécessitant une forte puissance de calcul. Cette tâche doit être décomposable en sous-tâches réparties (par exemple le calcul de nombres premiers); - outil de création: cet outil de création est utilisé simultanément par plusieurs

membres actifs, dans le cadre de la réalisation d'une _uvre collective.

Comme indiqué ci-dessus, selon la présente invention, le serveur central 1 effectue une étape de gestion du graphe des connexions entre les membres actifs. Pour cela, comme illustré sur la figure 5, le serveur central 1 comprend un module 11 de

gestion du graphe des connexions.

Ce module 11 a notamment pour mission de: - conserver une image fidèle du graphe rcel de la communauté (cela implique un souci de mise à jour et de sauvegarde périodique de cette information); - gérer les requêtes des futurs membres actifs (c'est-à-dire des membres passifs souhaitant devenir membres actifs). Comme expliqué en détail ci-dessus, en relation avec la figure 1, ceci consiste à réceptionner les demandes de connexions des futurs membres actifs, à calculer le meilleur emplacement pour ces derniers, à leur transmettre des directives de connexions pour qu'ils intègrent de fait la communauté, à transmettre en parallèle ces directives de connexions aux membres actifs concernés;

24 2824930

- gérer les déconnexions, normales ou brutales, des membres actifs. Comme expliqué en détail ci-dessus, ceci consiste à rattacher au graphe les membres actifs qui se sont retrouvés détachés de la communauté à cause de ces déconnexions; - effectuer de temps en temps (mais le moins souvent possible) une réorganisation partielle ou complète de la communauté. Cela peut signifier l'envoi de directives de déconnexion/reconnexions à certains ou à tous les membres de la communauté. Afin de générer les directives de connexions et les directives de déconnexion/reconnexion, trois principaux algorithmes de calcul sont mis en ceuvre: - un premier algorithme permettant de calculer à quels membres actifs un futur membre actif doit se connecter; - un second algorithme permettant de calculer à quels membres actifs un membre actif détaché de la communauté (du fait d'une déconnexion d'un autre membre actif) doit se connecter: - un troisième algoritUme permettant de calculer une réorganisation partielle ou

totale du graphe.

Le but de ces algorithmes est d'atteindre et de rester le plus proche possible de structures jugées intéressantes suivant certains critères prédéterminés. En d'autres termes, il s'agit de prendre en compte au moins un ou plusieurs critères d'optimisation du graphe. Parmi ces critères d'optimisation, on peut citer: - la réduction de la redondance des messages échangés entre membres actifs; - l'augmentation de la vitesse de connexion des membres actifs entre eux; - l'optimisation de la répartition géographique des membres actifs; - l'augmentation de la robustesse de la structure vis-à-vis de la déconnexion de l'un des membres actifs; - la limitation du nombre moyen (moyenne instantanée sur l'ensemble des membres actifs de la communauté) de membres actifs auxquels un membre actif

est directement connecté.

Il est à noter que ces algorithmes de calcul peuvent étre exécutés de façon centralisée, dans le serveur central 1, et/ou de façon décentralisée, par les membres actifs 2s 2824930 de la communauté. I1 est possible d'utiliser des outils de simulation de réseaux, afin de tester différents algorithmes et en déduire le meilleur pour chacune des différentes

*solutions mises en place.

La figure 2 présente un exemple de structure possible pour le graphe des connexion entre les membres actifs d'une communauté. Cette structure en arbre ("spanning tree") présente l'avantage notoire d'éliminer la redondance des messages. Si de plus l'arbre est équilibré, cela permet de limiter le temps maximum de transtert d'un

message d'un utilisateur à un autre.

On présente maintenant, en relation avec la figure 5, un mode de réalisation particulier du serveur central 1 selon la présente invention. Dans ce mode de réalisation, le serveur central 1 comprend, outre le module précité 11 de gestion du graphe des connexions: - un module 12 d'authentification des membres passifs souhaitant se connecter à la communauté; - un module 13 de gestion de la sécurité de la communauté; un module 14 d'établissement de comptes-rendus (statistiques) sur l'activité des membres actifs;

- un module 15 de contrôle du contenu échangé entre membres actifs.

Le module 12 d'authentification a pour rôle de vérifier que le membre passif

ayant émis une requête de connexion fait effectivement partie de la communauté.

L' authentification consi ste par exemple en la vérific ation d'un identifi ant d'entrée ("login") et d'un mot de passe ("password") fournis par ce membre. Ceci suppose une gestion, interne ou externe au serveur central 1, de la liste des membres de la communauté. Le module 13 de gestion de la sécurité met par exemple en _uvre des méthodes classiques de type "pare-feu" ("firewall" en anglais), ainsi que des mécanismes de vérification de la validité des requêtes provenant des membres. I1 peut également assurer

une mutation contrôlée du protocole d'échange de données entre les membres actifs. Dans ce cas, chaque membre actif utilise un protocole d'échange paramétré

par une clé.

Lorsqu'il l'estime nécessaire, le serveur central invite chaque membre actif à modifier sa clé de paramétrage du protocole d'échange. Ce mécanisme de sécurité peut être résumé

26 2824930

comme suit: chaque logiciel client possède à un moment donné une clé spéciale. Cette clé spéciale est codée et cachée de manière à être hors de portée de l'utilisateur final. Sa fonction est de conditionner la manière dont sont créés et émis les paquets d'informations. Périodiquement et/ou quand une menace est pressentie, le serveur central fait "muter" les clé spéciales des logiciels clients. Cela contribue à modifier notablement le protocole d'échange sur la communauté. L'avantage de cette technique est qu'elle rend très difficile l'ingénierie inverse ("back enginecring") qui pourrait être

effectuée sur le protocole.

On présente maintenant, en relation avec la figure 3, un mode de réalisation particulier du module 15 de contrôle du contenu échangé entre membres actifs. Dans ce mode de réalisation particulier, le module 15 précité comprend lui-même un module 151 espion 151 et un module 152 de traitement etlou de décision. Le module espion 151 se comporte comme un membre actif et est connecté à au moins un membre actif (rcel) de la communauté. Le module 152 de traitement et/ou de décision reçoit du module espion 151 des informations relatives à au moins certaines des donnces échangées entre membres actifs de la communauté. Au vu de ces informations, et après leur éventuel

traitement, le module 152 précité décide si le contenu échangé est acceptable ou non.

Des membres actifs sont dits concernés par un contenu jugé inacceptable, par exemple s'ils émettent des requêtes ou partagent des fichiers contenant des éléments licencieux, à caractère nazi, protégé par droit d'Auteur, etc. Ces membres actifs peuvent être bannis de

la communauté, voire dénoncés auprès de la justice dans les cas les plus graves.

On peut envisager plusieurs types d'informations, remontées par le module esplon 151 et relatives à au moins certaines des donnces brutes échangées entre membres actifs: - soit le module espion 151 se contente de remonter, vers le module 152 de traitement et/ou de décision, les données brutes elles-mêmes. Dans ce cas, le traitement de ces donnces brutes est fait dans le module 152 de traitement et/ou de décision; - soit le module espion 151 effectue lui-même un pré-traitement des donnces brutes (afin de détecter un contenu inacceptable), et remonte, vers le module 152

de traitement et/ou de décision, des données pré-traitées.

27 2824930

Selon encore une autre variante, ce sont certains ou la totalité des membres actifs (et plus précisément leurs logiciels clients) qui effectuent le pré-traitement des donnces

brutes, et les données pré-traitées sont remontées vers le module esplon 151, qui lui-

même les remonte vers le module 152 de traitement et/ou de décision.

On présente maintenant, en relation avec la figure 6, un mode de réalisation particulier d'un membre de la communauté selon la présente invention. On rappelle que, dans un souci de simplification, on entend par membre 2 la combinaison de l'utilisateur

personne physique 23 et de sa machine 21 qui exécute un logiciel client 22.

Dans ce mode de réalisation, le logiciel client 22 comprend: - un composant 221 de connexion temporaire avec le serveur central 1, en vue d'une connexion à la communauté des membres actifs (voir explications ci dessus); - un composant 222 de partage de ressources d'unités de calcul (voir explications ci-dessus); - un composant 223 de partage de ressources d'unités de stockage (voir explications ci-dessus); - un composant 224 de communication en mode texte (chat, forum); - un composant 225 de communication en mode vidéo (visioconférence); - un composant 226 de messagerie instantanée; - un composant 227 de messagerie différée; - un composant 228 de création multimédia;

- un composant 229 de jeux et/ou d'interactivité entre membres actifs.

I1 est clair que de nombreux autres modes de réalisation de l' invention peuvent être envisagés. D'une façon générale, la présente invention possèdent de nombreuses applications, telles que notamment: - le partage d'informations au sein d'un groupe d'utilisateurs; - le partage de puissance de calcul; - la synchronisation de contenu entre plusieurs zones de stockage; - la décentralisation de services coûteux ("chat", forum, hébergement de sites internet ou de contenu multimédia,); - l'augmentation de l'interactivité entre utilisateurs, entre clients et fournisseurs;

28 2824930

- l'amélioration de la qualification et de la fidélisation de l'audience de sites internet; - l'apport de la dimension temps réel dans l'utilisation d'applications internet (web, mail, ftp,); - la mise en place de services supplémentaires rapidement déployés et peu onéreux sur des solutions de type intranet;

29 2824930

Claims

REVENDICATIONS

1. Procédé de communication et/ou de partage de ressources machines, au sein d'un réscau de communication, entre une pluralité de membres d'une communauté, chacun desdits membres étant dit membre actif ou membre passif selon qu'il est connecté ou non à la communauté, caractérisé en ce que ledit procédé comprend une étape de gestion, par au moins un serveur central, du graphe des connexions entre les membres actifs de la communauté, ladite étape de gestion comprenant elle-méme les étapes suivantes, lorsque l'un des membres passifs, dit ffitur membre actif, souhaite se connocter à la communauté: - le futur membre actif établit une connexion temporaire avec le serveur central, de façon à l'informer de son souhait de se connecter à la communauté; - le serveur central calcule, et/ou fait calculer, à quel(s) membre(s) actif(s) le futur membre actif doit se connocter, et génère des directives de connexions correspondantes; - via ladite connexion temporaire, le serveur central fournit des directives de connexion au futur membre actif; - le serveur central établit une connexion temporaire avec chaque membre actif avec lequel le futur membre actif doit se connecter, afin de lui fournir des directives de connexion; - le futur membre actif établit une connexion permanente, d'égal à égal, avec

chaque membre actif que lui a indiqué le serveur central.

2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre les étapes suivantes, lorsque l'un des membres actifs est déconnecté de la communauté: - le serveur central est informé de cette déconnexion, par le membre redevenu passif et/ou par au moins un des membres actifs, et détermine l'(es) éventuel(s) membre(s) actif(s) qui se trouve(nt) détaché(s) de la communauté du fait de cette déconnexion; - le serveur central calcule, et/ou fait calculer, à quel(s) membre(s) actif(s) chaque membre actif détaché de la communauté doit se connecter, et génère des directives de connexions correspondantes;

2824930

- le serveur central établit une connexion temporaire avec chaque membre actif détaché de la communauté et avec chaque membre actif auquel celuici doit se connecter, de façon à leur fournir des directives de connexion; - chaque membre actif détaché de la communauté établit une connexion permanente, d'égal à égal, avec chaque membre actif que lui a indiqué le serveur central.

3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que

ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre l'étape suivante: - à au moins un instant, le serveur central calcule, et/ou fait calculer, une réorganisation au moins partielle dudit graphe des connexions, touchant au moins certains membres actifs, et génère des directives de déconnexion/reconnexion correspondantes; - le serveur central établit une connexion temporaire avec chacun des membres actifs touchés par la réorganisation, afin de lui fournir des directives de déconnexion/reconnexion; - les membres actifs touchés par la roorganisation établissent entre eux des

4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les

directives de connexion et/ou les directives de déconnexion/reconnexion sont calculées selon au moins un algorithme prenant en compte au moins un critère d'optimisation du

graphe des connexions entre les membres actifs de la communauté.

5. Procédé selon la revendication 4, caractérisé en ce que ledit au moins un critère d'optimisation du graphe des connexions appartient au groupe comprenant: - la rébuction de la redondance des messages échangés entre mémbres actifs; - la limitation du temps de transfert d'un message d'un membre actif à un autre; - l'optimisation de la répartition géographique des membres actifs; - l'augmentation de la robustesse de la structure visà-vis de la déconnexion de l'un des membres actifs; - la limitation du nombre moyen de membres actifs auxquels un membre actif est

directement connecté.

L

6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que les

directives de connexion et/ou les directives de déconnexion/reconnexion sont calculées,

de façon centralisée, dans le serveur central.

7. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que les

de façon décentralisée, par les membres actifs de la communauté.

8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que

chaque connexion d'égal à égal entre deux membres actifs supporte un trafic de donnces permettant de réaliser au moins une des fonctionnalités suivantes: - transmission de messages point-à-point; - transmission de messages de diffusion, point-multipoint; - recherche spécifique de contenu, au sein de ressources de stockage disque mises en commun par l'un des deux membres actifs; - exploration directe, au sein de ressources de stockage disque mises en commun par l'un des deux membres actifs;

- téléchargement de fichiers.

9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que le

réscau de communication est de type IP.

10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que,

pour la transmission de données au sein de la communauté, chaque membre actif utilise

un protocole d'échange propriétaire.

11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que,

pour la transmission de données au sein de la communauté, chaque membre actif utilise un protocole d'échange paramétré par une clé, et en ce que ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre l'étape suivante: - à au moins un instant, le serveur central invite chaque membre actif à modifier sa clé de paramétrage du protocole d'échange, de façon que ledit protocole

d'échange soit au moins partiellement modifié.

12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que

ledit au moins un serveur central comprend: - au moins un module de gestion du graphe des connexions; - éventuellement, au moins un module réalisant au moins une fonctionnalité particulière.

13. Procédé selon la revendication 12, caractérisé en ce que ledit au moins un module réalisant au moins une fonctionnalité particulière appartient au groupe comprenant: - des modules d'authentification des membres passifs souhaitant se connecter à la communauté; - des modules de gestion de la sécurité de la communauté; - des modules d'établissement de comptes- rendus sur l'activité des membres actifs;

- des modules de contrôle du contenu échangé entre membres actifs.

- des modules de partage de ressources d'unités de calcul; - des modules de partage de ressources d'unités de stockage; - des modules de communication en mode texte (chat, forum); des modules de communication en mode vidéo (visioconférence); - des modules de création multimédia;

- des modules de jeux et/ou d'interactivité entre membres actifs.

14. Procédé selon l'une quelcouque des revendications 12 et 13, caractérisé en ce que

ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre l'étape suivante: - chaque type de module est dupliqué en un nombre d'exemplaire fonction de sa charge, relative aux connexions temporaires des membres actifs et/ou des futurs

membres actifs.

15. Procédé selon l'une quelconque des revendications 1 à 14, caractérisé en ce que

chaque membre de la communauté comprend un logiciel client comprenant luimême: - un composant de connexion temporaire avec le serveur central, en vue d'une connexion à la communauté des membres actifs; - éventuellement, au moins un composant réalisant au moins une fonctionnalité particulière.

33 2824930

16. Procédé selon la revendication 15, caractérisé en ce que ledit au moins un composant réalisant au moins une fonctionnalité particulière appartient au groupe comprenant: - des composants de partage de ressources d'unités de calcul; - des composants de partage de ressources d'unités de stockage; - des composants de communication en mode texte (chat, forum); des composants de communication en mode vidéo (visioconférence); - des composants de messagerie instantanée; - des composants de messagerie différée; - des composants de création multimédia;

- des composants de jeux ettou d'interactivité entre membres actifs.

17. Procédé selon l'une quelconque des revendications 1 à 16, caractérisé en ce que

ledit au moins un serveur central est mutualisé, de façon à pouvoir assurer la gestion d'au

moins deux communautés.

18. Procédé selon l'une quelconque des revendications 1 à 17, caractérisé en ce qu'il

comprend en outre une étape de contrôle, par le serveur central, du contenu échangé

entre membres actifs.

19. Procédé selon la revendication 18, caractérisé en ce que ladite étape de contrôle du contenu échangé entre membres actifs comprend les étapes suivantes: - au moins un module espion, hébergé par ledit au moins un serveur central et se comportant comme un membre actif, se connecte à au moins un membre actif de la communauté; - au moins un module de traitement ettou de décision, hébergé par ledit au moins un serveur central, reçoit dudit au mo ins un module esp i on de s informati on s relatives à au moins certaines des donnces échangées entre membres actifs de la communauté.

20. Procédé selon la revendication 19, caractérisé en ce que lesdites informations relatives à au moins certaines des données échangées entre membres actifs de la communauté appartiennent au groupe comprenant: - des données brutes échangées entre membres actifs de la communauté;

34 2824930

- des données résultant d'un pré-traitement, effectué par au moins un des membres actifs et/ou ledit au moins un module espion, de données brutes échangées entre

membres actifs de la communauté.

21. Procédé selon l'une quelconque des revendications 1 à 20, caractérisé en ce qu'il

comprend en outre une étape de gestion de la liste des membres de la communauté, et en ce que ladite étape de gestion du graphe des connexions entre les membres actifs de la communauté comprend en outre l'étape suivante: - authentification, par le serveur central, du futur membre actif souhaitant se connocter à la communauté, ladite authentification consistant à vérifier que le

futur membre actif appartient à ladite liste des membres de la communauté.

22. Programme d'ordinateur, caractérisé en ce qu'il comprend des séquences d' instructions adaptées à la mise en _uvre d'un procédé selon l' une quelconque des

revendications 1 à 21 lorsque ledit programme est exécuté sur un ordinateur.

23. Serveur central d'un système de communication et/ou de partage de ressources machines, au sein d'un réseau de communication, entre une pluralité de membres d'une communauté, chacun desdits membres étant dit membre actif ou membre passif selon qu'il est connecté ou non à la communauté, c aractéri sé en ce que ledit serveur central comprend des moyen s de ge s ti on du grap he de s connexion s entre le s membres actifs de l a communauté, les dits moyen s de gesti on comprenant euxmêmes les moyens suivants: - des moyens d'établissement d'une connexion temporaire avec un des membres passifs, dit futur membre actif, qui souhaite l'informer de son souhait de se connecter à la communauté; - des moyens de calcul, de façon à déterminer à quel(s) membre(s) actif(s) le futur membre actif doit se connecter; - des moyens de génération de directives de connexions correspondantes; - des moyens de fourniture desdites directives de connexion, via ladite connexion temporaire, au futur membre actif; - des moyens d'établissement d'une connexion temporaire avec chaque membre actif avec lequel le futur membre actif doit se connecter, afin de lui fournir des directives de connexion;

2824930

de façon que le futur membre actif établisse une connexion permanents, d'égal à égal,