Reseau complétement décentralisé

Bonsoir,

je vais réaliser une messagerie instantanée, et n'ayant pas les moyens de mettre en place un gros serveur qui géreraient les connectés, je vais me tourner vers une architecture décentralisée. Et je pense à une vraie décentralisation, sans aucun "super noeud" comme c'est le cas dans certains réseaux d'échange de fichiers.
Je suis tombé sur les tables de hachage décentralisées, qui semblent avoir un bel avenir devant elles. Et ça me semble interessant comme méthode.

D'abord, est-ce que c'est une technique viable pour une messagerie instantanée ? (à terme on espère quelques milliers d'utilisateurs simultanément, au maximum)

Je voudrais donc savoir si vous avez des infos (descriptions détaillées de protocoles, d'architecture, etc) dans ce domaine.
J'ai un peu cherché sur le net et j'ai trouvé des trucs, mais ça fait léger techniquement parlant.
Alors pour m'éviter d'avoir à réinventer la roue, je demande ici si vous avez des infos.

Merci d'avance.

Bonsoir,

Envoyé par sir_gcc

[..] Et je pense à une vraie décentralisation, sans aucun "super noeud" comme c'est le cas dans certains réseaux d'échange de fichiers.

A quels systemes d'echanges/protocoles faites vous allusion exactement?

Envoyé par sir_gcc

Alors pour m'éviter d'avoir à réinventer la roue, je demande ici si vous avez des infos.

La description de votre projet me fait penser a IRC... Quels seraient les difference entre IRC et votre projet?

Ar@mi$

Bonjour,

comme premiere source d'info, j'ai cherché "reseau décentralisé" dans Google et je suis tombé sur la page de wikipédia http://fr.wikipedia.org/wiki/P2P#Architecture_d.C3.A9centralis.C3.A9e (pas directement).
Il s'agit de protocoles d'échange de fichiers mais je me suis dit que peut-être les idées étaient bonnes à étudier pour réaliser une messagerie.
Les réseaux et protocoles dont je parle sont d'après ce texte FastTrack, Kazaa ou encore eDonkey2000.

ALors je n'ai peut-être pas bien compris le principe, et dans ce cas, pouvez-vous me remettre dans le droit chemin ?

Je vais me pencher sur le cas IRC, je ne le connais pas, et ne l'utilise pas.

Merci pour vos réponses.

Re,

Envoyé par sir_gcc

Je vais me pencher sur le cas IRC, je ne le connais pas, et ne l'utilise pas.

Dans ce cas la je me permets de faire reference a votre premier poste, comment pouvez vous eviter de re-inventer la roue si vous n'avez pas fait le tour des protocoles et applications qui permettent l'echange de messages instantanee:
IRC est "vieux" comme mode de communication. Qui plus est, il a ete mis au point a une epoque ou il n'y avait que tres peu de "serveurs" puissants ou super noeud et pourtant pres de 20 ans apres c'est toujours tres utilise. Certes, IRC n'est pas MSN Messenger, Yahoo! Messenger ou assimiles mais il n'empehce qu'il existe une multitude de solutions techniques pour pallier a de grands nombres de connexions simultanees; le Service/Serveur Area Network (SAN) par exemple... Un poignee d'adresses IP les connexions sont reparties de maniere a ce que la charge soit la meme sur tous les serveurs. Et cela de maniere totalement transparentes a l'utilisateurs.
Pour terminer, le focus sur les protocoles pair-a-pair me fait penser a Skype... En effet, Skype permet aussi l'echange de messages instantanes... Par contre, je n'ai jamais cherche a savoir si ce mode fonctionnait totalement en p2p ou bien en client/server. De toute facon, si on en croit GangSoleil, meme les reseaux p2p fonctionnent en client/server .

HTH

Ar@mi$

Re,

Envoyé par gangsoleil

Ton plus gros problème va être de savoir comment deux contacts peuvent se joindre.

+1. D'ailleurs en consedirant le cas de Skype, je pense que ce probleme a ses fondements. Combien de fois ai je attendu un coup de fil de mes parents sans voir leur profil se mettre a jour! On etait tous connectes mais pas moyen Skype ne met pas a jour la liste des contacts et leur status.

Envoyé par gangsoleil

Je te conseil de te pencher sur les articles des chercheurs qui travaillent actuellement dans ce domaine, ca devrait t'aider.

Etant chercheur moi meme, je mettrais en garde contre les tres bonnes idees qui n'ont malheureusement pas d'implementation disponible ou bien qui ont juste les maths

Ar@mi$

PS: J'aurai pu faire plus long mais je suis en train de surveiller un TP.

Oui, en effet le plus gros problème c'est de se faire connaitre et de trouver quelqu'un lors de la connexion. Comme point d'entrée dans le réseau, il est prévu de mettre en place un serveur, mais sa capacité à gérer tout le routage est à mon avis trop faible (et de toute façon, on préfére ne pas être soumis au bon vouloir de ce serveur, un peu de robustesse ne fait pas de mal).

Je me suis penché sur le cas de Kademlia, ça semble pas mal, et pas trop difficile à implémenter. Comme algo de routage ça a l'air interessant.
Dites moi un peu ce que vous en pensez.

Je me rapelle les cours d'informatique mobile de maitrise... j'aurais du y aller plus souvent. (Mr S, si vous nous regardez...)

Merci encore de votre participation active.

Personne n'a plus d'algo de routage à me proposer ?
Il ya bien des gens qui connaissent ça dans la salle quand meme...

J'attends toujours vos participations avec impatience.

Et que pensez-vous de kademlia ? Pertinent pour ce type d'utilisation ?

Re,

Envoyé par sir_gcc

Personne n'a plus d'algo de routage à me proposer ?

heu... je croyais que vous alliez developper une application.. pourquoi auriez vous besoin d'un algorimth de routage??? Le routage est typiquement une tache accomplie par un router/firewall/ATM switches et etc. Generalement, les details de communication entre deux entites dans un reseau (aussi bien sur l'Internet qu'en local) n'est pas sous le controle du developpeur d'application (cf. ma discussion avec khayyam90 ici ). Par contre, si vous appelez des specifications des protocoles vous permettant de realiser une application IM, je pense bien qu'elles soient disponibles quelque part. Je pense que powa

Envoyé par sir_gcc

Il ya bien des gens qui connaissent ça dans la salle quand meme...

Ouais ouais.. que est ce qu'on discute RIPv1, RIPv2, OSPF, BGP ????

Envoyé par sir_gcc

Et que pensez-vous de kademlia ? Pertinent pour ce type d'utilisation ?

Je passe car je n ai pas eu le temps de lire les specifications. Cependant, je m'interoge sur les implications de votre projet. En effet, beaucoup de systemes de communication instantanee sont supportes/developpes par des grosses societes et du coup je suis convaincu que leur choix et leur design refletent la proportion du marche qu'elles esperent avoir. Par consequent, que cherchez vous a faire? un prototype? une preuve (desole je n'arrive pas a traduire "proof of concept" ) ? Si par contre, ceci est un projet perso et ludique, je suis certain que l'experience en terme de programmation sera applicable a d'autres domaines. Auquel cas, votre choix de protocole n'est pas si "primordial".



Ar@mi$ networking dude?

Par routage je veux dire le fait de trouver le chemin d'un noeud vers un autre.
Prenons le cas d'un noeud X qui veut trouver l'IP d'un noeud Y.
Le fait de trouver une route (en utilisant des tables de routage distribuées) de X vers Y sans connaitre son IP est bien un routage.

Je veux juste contruire une application dont le but est de pouvoir échanger des messages instantanés entre plusieurs postes.
On pourrait faire un truc tout bête à base d'un serveur et de plusieurs clients.
Mais cette solution ne tient pas la charge(avec un prix de serveur abordable, selon moi) lorsque le nombre de clients devient trop élevé.

Voila pourquoi je souhaite utiliser une architecture décentralisée. Car c'est un moyen efficace pour que les "servent" (server/client) se trouvent mutuellement assez facilement.

Voila un petit résumé du protocole kademlia http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf
Il ne fait que 6 petites pages, comme ça l'esprit global pourra être connu.

Merci encore pour vos commentaires.

Bonjour,

Supposons que Skype, par exemple, soit totalement p2p en ce qui concerne l'echange de messages instantanes. Je suis d'avis que tous les logiciels clients consultent une table de connecter en fonction des informations qu'ils ont sur leurs contacts. Par exemple, j'ai peu etre des contacts ici en Grande Bretagne et mon client regarde la liste des connectes sur le Noeud en charge de ma location mais je dois aussi regarde la base Europe puisque mes parents sont en France et etc. Or, si le(s) "tracker(s)" (il me semble que cela soit le terme en p2p) n'est pas a jour je ne peux savoir avec certitude qui est connecte. Et du coup je pense que l'algorithm de mis a jour a beaucoup avoir le probleme discuter ici.

Prennons maintenant la situation ou les informations sont a jour. Les utilisateurs ne peuvent pas se rendre compte si un message arrive en 2 ou bien 3 secondes. Le plus difficile semblerai de garantir l'envoi/reception de messages sans que cela devient une communication client/server avec tout cela implique.

Envoyé par sir_gcc

Je veux juste contruire une application dont le but est de pouvoir échanger des messages instantanés entre plusieurs postes.
On pourrait faire un truc tout bête à base d'un serveur et de plusieurs clients.
Mais cette solution ne tient pas la charge(avec un prix de serveur abordable, selon moi) lorsque le nombre de clients devient trop élevé.

Okay, je me repete mais il existe une multitude de solutions divers et varies pour pallier a ce genre de probleme, du S.A.N decrit ci dessus au Server Farm. A mon avis, la ou votre projet pourrai se distinguer c'est dans le fonctionnement interne du logiciel. Votre logiciel sera plus "lourd" sur les clients ou bien les noeuds? Peu etre qu'un "bon" logiciel pourra s'occuper de plus de clients, que disons un server MSN Messenger, pour un server de la meme puissance... et etc. Enfin bref, c'est a vous de determiner les differences/avantages que votre creation va avoir. Cependant, cela est tres difficile sans de bonnes connaissances et comprehension de se qui se fait deja et des systemes a venir.

Envoyé par sir_gcc

Voila pourquoi je souhaite utiliser une architecture décentralisée. Car c'est un moyen efficace pour que les "servent" (server/client) se trouvent mutuellement assez facilement.

Je serai tres etonne que le protocole que vous allez choisir n'ai pas de solution a cela D'ailleurs, je pense que si le protocole/systeme ne possede pas de solution pour cela il ne vaut pas la peine de le considerer.

HTH

Ar@mi$

Re,

Gangsoleil,

dans le protocole kademlia, pour qu'un noeud (dans ce protocole un noeud est un client/serveur, chaque entité du reseau créé réalisant exactement les même choses que sa voisine) se connecte au reseau, il lui faut connaitre un noeud déjà connecté à ce reseau.
Je l'avoue, je ne vois pas bien comment implémenter cet aspect, mais c'est une autre question.
Donc en principe il n'y a pas de risque de créer des réseaux séparés qui ne se connaissent pas mutuellement.
D'après ce que j'ai compris de kademlia, en utilisant des DHT (Distributed hash Table) chaque noeud ne conserve que les informations qui concernent ses voisins proches (la notion de proximité étant dans ce que j'ai trouvé liée à un XOR entre les IDs de chaque noeud). Donc pas de problème en cas de découverte d'un réseau important.

Ce que je vois comme fonctionnement est plus basique que l'échange de fichier. Dans un premier temps un noeud se connecte au reseau (par l'intermédiaire d'un noeud connu). Il calcule ses voisins les plus proches, et les informe de sa présence.
Une fois ses caractéristiques connues (IP, port, ID) il est contactable en utilisant le fameux algo de routage de kademlia.

Lorsqu'un noeud veut parler à un autre noeud, il lui suffit de chercher son adresse IP. Pour faire référence à kademlia, la référence vers le noeud à chercher (la clé dans le pdf donné plus haut) serait l'ID de ce noeud.
Après l'avoir trouvé, le demandeur connait l'IP et le port de sa cible et peut donc communiquer avec lui directement.

Aramis,

C'est vrai, je ne sais pas encore trop comment gérer les contacts ou amis. Mis à part un stockage chez les clients de leurs propres informations (pseudos des amis/contacts par exemple), je ne vois pas d'autre solution dans un reseau complétement décentralisé.
Pour ce qui est de la présence en ligne ou non d'un contact Y, on pourrait imaginer que si un noeud X se connectant au reseau connait le pseudo de ce contact Y, il cherche tout de suite à le contacter pour l'informer de sa présence. Le problème serait sans doute un peu plus complexe pour le cas d'une déconnexion sauvage du reseau. Comment informer le noeud X que son contact Y n'est plus en ligne. A la limite, personne ne le sait jusqu'à ce qu'on essaie de le contacter. Or il y a un système de rafraichissement automatique toutes les heures avec kademlia, ce qui n'est vraiment pas assez fréquent dans mon cas.
Alors en conclusion, oui, il y a un travail à fournir au niveau de l'algo de mise à jour.

sir_gcc a écrit:
Voila pourquoi je souhaite utiliser une architecture décentralisée. Car c'est un moyen efficace pour que les "servent" (server/client) se trouvent mutuellement assez facilement.

Je serai tres etonne que le protocole que vous allez choisir n'ai pas de solution a cela Confused D'ailleurs, je pense que si le protocole/systeme ne possede pas de solution pour cela il ne vaut pas la peine de le considerer.

Je suis bien d'accord, mais si j'utilise une architecture décentralisée (complètement, j'insiste là-dessus), il y a nettement moins d'algorithmes proposés que pour des architectures centralisées. Kademlia me semblait pas mal. Et c'est pour ça que je vous demandais votre avis.
On pourrait prendre le problème à l'envers: quels systèmes de messagerie instantannée à architecture décentralisée connaissez-vous ? Que valent-elles ? Et surtout quel est le protocole utilisé ?

En fait, je ne sais plus trop quoi vous demander. Je pourrais résumer par :
"Avec mes faibles moyens financiers, quelle est la meilleure méthode pour implémenter une messagerie instantanée (topologie, protocole, ...)."

Vous m'avez fourni déjà beaucoup d'élèments de réponse. Mais malgrè ça, j'ai un peu de mal à me fixer.
Le but n'est pas de révolutionner l'IM mais surtout de réaliser un produit viable à une echelle correcte (quelques milliers d'utilisateurs au maximum simultanément).


Dans le pire des cas, si une architecture décentralisée était trop difficile à implémenter, je pourrais sans doute me tourner vers une architecture à base de serveur. Mais je ne connais pas bien les capacités nécessaires à un serveur unique pour assurer tous les services demandés par une telle organisation.

Voilà pour ce long discours...

Merci.

PS: Aramis, on ne pourrait pas se tutoyer ? On est des grandes personnes maintenant

Bonjour,

desole pour ne pas avoir repondu plus tot mais j'avais un article a finir pour un conference.

Envoyé par sir_gcc

On pourrait prendre le problème à l'envers: quels systèmes de messagerie instantannée à architecture décentralisée connaissez-vous ? Que valent-elles ? Et surtout quel est le protocole utilisé ?

<mode_chercheur="on">
Le seul moyen de repondre a cela est de faire des recherches. Les membres de DVP.com, comme GangSoleil et moi meme, ne peuvent vous donner qu'une information limitee. Je suis d'avis que dans ce genre de projet la plus grande partie des decouvertes est faites par le(s) developpeur(s), et une recherche exhaustive est souvent necessaire pour creer quelque chose de viable. GangSoleil et moi meme avont de l'experience dans le domaine de la recherche, et je suis certain qu'il sera d'accord avec moi lorsque je dis que c'est une tache, longue, ingrate mais necessaire sinon on ne fait que re-inventer la roue.....
</mode_chercheur>

Envoyé par sir_gcc

En fait, je ne sais plus trop quoi vous demander. Je pourrais résumer par :
"Avec mes faibles moyens financiers, quelle est la meilleure méthode pour implémenter une messagerie instantanée (topologie, protocole, ...)."

Je ne pense pas que DVP.com soit une boite de consulting et par consequent, je ne pense que les avis exprimes soient autorites

Envoyé par sir_gcc

Vous m'avez fourni déjà beaucoup d'élèments de réponse. Mais malgrè ça, j'ai un peu de mal à me fixer.
Le but n'est pas de révolutionner l'IM mais surtout de réaliser un produit viable à une echelle correcte (quelques milliers d'utilisateurs au maximum simultanément).

Encore une fois, vous ne pourrez repondre a ces questions que si votre connaissances dans le/les domaine(s) concerne(s) est tres bonne. Et cela sans recherches, c'est tres difficile.

Envoyé par sir_gcc

Dans le pire des cas, si une architecture décentralisée était trop difficile à implémenter, je pourrais sans doute me tourner vers une architecture à base de serveur. Mais je ne connais pas bien les capacités nécessaires à un serveur unique pour assurer tous les services demandés par une telle organisation.

Ce paragraphe montre bien que meme dans votre tete le sujet n'est pas finalise. Chose qui n'est pas inhabituelle, pas de soucis . Sachant que vous n'avez pas les moyens financiers/humains de Google, M$, Yahoo and co, qui ont eux developpe les interfaces clients ainsi que les protocoles d'echanges necessaires, la question devient donc quelle est l'avenue la plus interressante/lucrative? le client/utilisation ou bien le porteur/FAI ?? Choix probablement Shakespearien

Envoyé par sir_gcc

Aramis, on ne pourrait pas se tutoyer ? On est des grandes personnes maintenant

Arf... vivre a l'etranger donne de mauvaise habitude desole . Mais bon ne le prennez pas personnellement, je n'utilise le tutoyement qu'avec l'equipe de moderation/redaction de DVP.com ; Je suis d'avis que le vouvoiement maintient un certain professionalisme sur DVP.com

Bien bien bien,

Merci pour vos réponses à tous les deux.
Je vais pour l'instant clôturer ce sujet, et entreprendre des recherches personnelles plus approfondies.
Si un jour j'ai des nouvelles interessantes, je ferai un nouveau sujet.

Merci encore.