Conception Et Réalisation D'un Réseau Social Distribué

République Algérienne Démocratique et Populaire
Ministère de l'Enseignement Supérieur et de la Recherche Scientique
Université Abderrahmane Mira de béjaia

Faculté des sciences exactes
Département informatique
Mémoire de n de cycle
En vue d'obtention du diplôme de master professionnel en informatique
Option : Administration et Sécurité des Réseaux

Thème :
Conception et Réalisation d'un Réseau Social Distribué

"NetPeers"
Mémoire soutenu le 26/06/2016 par :
M. BENSLIMANE Yanis
M. OUAKKOUCHE A.Karim
Devant le jury composé de :

Présidente : Mm.METIDJI Rebiha M.A.A, U.A.M Béjaia
Examinateur : M. OMAR Mawloud M.C.A, U.A.M Béjaia

lle
Examinatrice : M HOUHA Amel M.A.B, U.A.M Béjaia
me
Encadreur : M BELALTA Ramla M.A.B, U.A.M Béjaia
Année univerrsitaire 2015/2016

Table des matières
Table des matières i
Table des gures iii
Liste des abréviations iv
Introduction Générale 1
1 Généralités sur les réseaux Peer-To-Peer 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Classication des systèmes informatiques . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Réseau Peer-To-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Dénition de P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Les caractéristiques du peer to peer . . . . . . . . . . . . . . . . . . . . . . 4
1.3.4 Les applications du P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.5 Problèmes des réseaux P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Architecture des réseaux peer to peer . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Architecture centralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2 Architecture décentralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.3 Architecture hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Table de hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Les tables de hachage distribuées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 La sauvegarde Friendstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Etat de l'art sur les réseaux distribués 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Objectifs de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Condentialité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Exemples des réseaux distribués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 PeerSon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Decent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Cachet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Architecture des réseaux sociaux distribués . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Architecture de PeerSon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
i
TABLE DES MATIÈRES
2.4.2 Architecture de Decent et Cachet . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Prototype des réseaux sociaux distribués . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Protocole de PeerSon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2 Prototype de Decent et Cachet . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Stockage des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Présentation et Conception de l'application 21

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 L'objectif de l'application NetPeers . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 L'architecture de l'application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Le processus unié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1 Dénition d'un processus de développement logiciel . . . . . . . . . . . . . . 23
3.4.2 Dénition du processus unié (UP) . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Analyse et spécication des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.1 Les besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.2 Les besoins non Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.1 Présentation de d'UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.2 Présentation de diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.3 Les diagrammes d'UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Analyse et conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7.1 Diagramme de cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7.2 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7.3 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.5 Règles de dérivation du modèle relationnel à partir d'un modèle de classes . 37
3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 Implémentation 39
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Environnement de développement de l'application . . . . . . . . . . . . . . . . . . . 39
4.2.1 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Outils Utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.3 Langage de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Présentation des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Conclusion Générale et Perspectives 48
ii
Table des gures
1.1 Classication des systèmes informatiques. . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Structure du réseau P2P[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Architecture centralisée[1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Architecture décentralisée[1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Architecture Hybride[8]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Architecture de PeerSon[22]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Architecture de Decent à gauche et architecture de Cachet à droite[23]. . . . . . . . 18
3.1 L'architecture globale de l'application NetPeers. . . . . . . . . . . . . . . . . . . . . 23

3.2 La liste des diagrammes UML 2.0 [28]. . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Diagramme de cas d'utilisation général. . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Partage des clés "Utilisateur / DHT". . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Partage des clés "Utilisateur / Utilisateur". . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Diagramme de séquence Ìnscription'. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Diagramme de séquence `Messagerie instantanée'. . . . . . . . . . . . . . . . . . . . 32
3.8 Diagramme de séquance Àppel'. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.9 diagramme de séquance àbonnement' en présence de la DHT. . . . . . . . . . . . . 34
3.10 Diagramme de séquence Àbonnement' en absence de la DHT. . . . . . . . . . . . . 35
3.11 Diagramme de déploiement de NetPeers. . . . . . . . . . . . . . . . . . . . . . . . . 36
3.12 Diagramme de classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 Interface d'inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Interface de connexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Interface de prol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Interface de paramètre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Interface de messagerie instantanée. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 Interface de publication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.7 Interface d'appel émis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8 Interface d'appel reçu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.9 Interface de test messagerie instantanée. . . . . . . . . . . . . . . . . . . . . . . . . 45
4.10 Interfaces d'échanges vocaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
iii
Liste des abréviations
AOL American On Line
CAN Content Addressable Network
CPU Central Processing Unit
DES Data Encryption Standard
DHT Distributed Hash Table
IBM International Business Machines
IDE Integrated Development Environment
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
JDK Java Developpement Kit
JRE Java Runtime
JVM Java Vertuelle Machine
KBR Key Based Routing
MAS Machine Aperating System
MSN Micro Soft Network
PC Personnel Computer
PHP Hypertext Preprocessor
P2P Peer 2 Peer
RSA Rivest Shamir et Adlman
SNS Super Noeud Serveur
UDP User Datagram Protocol
UML Unied Modeling Language
UP Anied processus
iv
Introduction Générale
La révolution nommée Internet a déclenché l'apparition d'innombrables services qui ont
révolutionnés la communication et la diusion de l'information. Les réseaux sociaux, en particulier,
sont devenus très populaires au sein de la communauté d'Internet et les grandes entreprises utili-
sant ces réseaux sociaux comme moyen de publicité pour vendre leurs services. Un grand nombre
de sites internet dits de réseautage social ont fait leur apparition : Facebook et Twitter en sont
des exemples.
La popularité des réseaux sociaux centralisés est expliquée par la gratuité d'accès. L'utilisa-
teur doit, en contrepartie, fournir des renseignements personnels et privés que les réseaux sociaux
sauvegardent pour des raisons de sécurité. Cette pratique engendre un problème majeur pouvant
se résumer au droit à la vie privée et le risque de divulgation des informations condentielles sur
les utilisateurs. Si le cadre législatif semble être décient actuellement, d'autres solutions, même
imparfaites, permettent pourtant de proposer une alternative technique au problème de la sécurité
des informations. Parmi ces solutions se trouve celle des réseaux sociaux distribués.
Dans le cadre de notre travail, nous tentons de concevoir et réaliser un réseau social décen-
tralisé crypté pour palier au problème des réseaux sociaux centralisés. Le réseau social que nous
réaliserons tout au long de notre travail aura comme but principal d'orir aux utilisateurs un outil
de communication sécurisé. À cet eet, l'étude menée dans ce mémoire sera organisée comme suit :
• Le premier chapitre, généralités sur les réseaux peer-to-peer présentera quelques concepts
théoriques sur les réseaux distribués incluant le modèle Peer to Peer, son architecture et son his-
torique ainsi que les tables de hachage distribuées.
• Dans le deuxième chapitre, État de l'art sur les réseaux sociaux distribués , nous commencerons
par dénir les objectifs de la sécurité. Ensuite, nous présenterons l'architecture et les prototypes
de trois exemples de réseaux sociaux distribués, à savoir, PeerSon, Decnet et Cachet.
• Le troisième chapitre, Présentation et Conception de l'application portera sur la conception de
notre réseau social netPeers où nous détaillerons son architecture à travers diérents diagrammes
UML.
•Le quatrième chapitre Implémentation concernera la partie implémentation de notre travail
où nous présenterons les outils technologiques choisis pour la réalisation de netPeers.
• Une conclusion générale suivie de perspectives sur le futur de netPeers clôturera ce mémoire.
1
Chapitre 1
Généralités sur les réseaux Peer-To-Peer
1.1 Introduction
Avec l'arrivée de l'Internet et son rôle actif croissant dans l'économie et la société, l'informa-
tique réseau n'a eu de cesse de trouver des innovations pour exploiter les ressources qu'un réseau
de cette ampleur contient.
Le monde de l'informatique est en eervescence autour d'un phénomène portant le nom de peer
to peer. Mal identiée, mal comprise et mal considérée à ses débuts, l'idée a beaucoup mûrie aux
cours des deux dernières années. Aujourd'hui, on parle sérieusement du peer-to-peer comme un
modèle de communication capable de changer radicalement certaines approches de l'informatique
en réseau.
Dans ce chapitre, nous présentons les diérents niveaux de décentralisation des réseaux P2P,
ainsi que les tables de hachage distribuées qui sont les principales structures de routage distribuées
dans les systèmes pair à pair.
1.2 Classication des systèmes informatiques

Les systèmes informatiques peuvent être classer en deux grandes catégories comme illustré dans
la gure (1.1) : les systèmes centralisés et les systèmes distribués. Les systèmes distribués peuvent
a leur tour être selon deux modèles : le modèle client/serveur plat ou hiérarchique et le modèle
peer to peer qui peut être centralisé, décentralisé ou hybride. [11]
2
Généralités sur les réseaux Peer-to-Peer
Figure 1.1 Classication des systèmes informatiques.
1.3 Réseau Peer-To-Peer

1.3.1 Dénition de P2P
Un client P2P ou peer est une application, s'exécutant sur une machine (PC, PDA, téléphone
portable,. . .), qui a la capacité de communiquer avec d'autres peers.
Un réseau peer to peer est un réseau dans lequel chaque utilisateur est en mesure de mettre
certaines ressources de son ordinateur à la disposition des autres par transfert direct. Un réseau
peer to peer est dynamique, au sens que les éléments le constituant peuvent aller et revenir et que
sa topologie n'est pas stable.
Contrairement a une architecture de réseau de type client/serveur, dans une architecture peer
to peer pure, il n'y a pas de serveur centralisé. Ainsi, chaque ordinateur dans un tel réseau joue
a la fois le rôle de serveur et de client d'où leur appellation de servent ( contraction de serveur et
client). [2]
3
Figure 1.2 Structure du réseau P2P[2]
1.3.2 Historique
Mai 1999 : Naissance du premier logiciel de téléchargement utilisé à grande échelle : Napster.
A la base il est le fruit de la réexion du jeune Shawn Fanning (dix-huit ans) qui décide de créer
un logiciel lui permettant d'échanger des musiques en comité restreint avec ses amis. Très vite,
Napster devient le premier véritable phénomène Peer-to-Peer global.
Décembre 1999 : Les majors prennent peur et entament des procédures pour fermer Napster.
Elles obtiendront gain de cause et Napster fermera en 2002.
Début 2000 : Naissance de Kazaa. Ore la possibilité nouvelle de pouvoir télécharger un

même chier depuis sur plusieurs sources an d'accroître la vitesse de réception.
2003 : Apparition d'eMule et d'eDonkey : nouvelle façon de télécharger les chiers. Il s'agit
de la technique de "fractionnement de chier" : à peine un téléchargement est commencé que la
partie récupérée est disponible pour l'envoi. Cette méthode permet d'augmenter encore la vitesse
de transfert de chiers. Elle est encore aujourd'hui très populaire.
Fin 2005 : An de faire face aux majors qui entament de plus en plus de procédures à l'encontre
des internautes qui téléchargent, une nouvelle génération de clients et réseaux P2P a vu le jour. Il
s'agit de réseaux totalement cryptés et anonymes techniquement quasi-impossible à contrôler. [3]
1.3.3 Les caractéristiques du peer to peer

Les réseaux peer to peer sont caractérisés par un certain nombre de propriétés, nous en citons
[4] :
•Auto organisation :
Le système ne nécessite pas l'intervention d'une entité externe pour revenir à son état
stable.
4
•Dynamisme :
Les systèmes distribués peer to peer sont caractérisés par un taux élevé d'arrivées et
de départs de noeuds. Il est important que l'insertion (placement d'un nouveau noeud
dans le réseau) ou le retrait d'un n÷ud (suppression d'un ; qu'il soit volontaire, ou dû
à une panne) ne soient peu coûteux.
•Equilibrage de charge et mutualisation des ressources :

Il est possible d'équilibrer les traitements de requêtes en les répartissant sur l'ensemble
des n÷uds, qui partagent la même responsabilité.
•Passage a l'échelle :
La principale limitation des modèles clients serveurs vient de l'incapacité des serveurs
à gérer un nombre élevé de clients et de ressources. En eet, la machine qui prend en
charge l'exécution du serveur doit être susamment dotée en ressources de calcul, de
stockage et de communication. Contrairement au modèle client serveur dans un modèle
P2P, ces ressources augmentent avec le nombre de noeuds. Dans le cadre du partage
de données, la capacité de passage à l'échelle vers des milliers ou des millions de par-
ticipants est souhaitable, comme une utilisation plus ecace des ressources physiques
ou la protection de l'anonymat des utilisateurs.
•Disponibilité :
L'absence de centralisation dans un système peer to peer le rend particulièrement inté-
ressant pour le maintien de la disponibilité des objets (par exemple, en répliquant les
données sur un certain nombre de noeuds du réseau).
•Tolérance aux fautes :

C'est la capacité des systèmes de continuer à fournir des services d'une manière régulière
malgré la présence des fautes dans le software ou le hardware, ainsi que les arrivées et
les départs fréquents des noeuds [5].
Un système peer to peer doit pouvoir gérer les pannes suivantes :
Panne d'arrêt : cette panne intervient lorsqu'un peer quitte le réseau sans prévenir, par
accident ou volontairement.
Panne intermittente : un peer ayant cette panne ne répond aux requêtes qui lui sont
destinées que durant certains intervalles de temps.
Panne byzantine : cette panne survient lorsqu'un adversaire ayant une connaissance globale
du réseau, tente de rendre le fonctionnement de ce dernier incorrect.
•Contrôle :
Les systèmes centralisés permettent plus facilement un contrôle sur les noeuds qui
peuvent accéder aux informations fournies par le serveur. Il est en eet relativement
aisé de contrôler le point unique d'accès à l'information, qui est la plupart du temps
clairement identiable.
•Anonymat :
Il est déni comme étant le degré pour lequel les systèmes peer to peer tiennent compte
des opérations non identiées.
5
1.3.4 Les applications du P2P

L'avantage principale que représentent les applications P2P est l'exploitation maximale des
ressources des diérentes machines connectées au réseau (espace de stockage puissant, puissance
processeur, imprimantes,. . .).
Plusieurs types d'applications P2P existent, elles peuvent être regroupées en quatre classes :
application de partage de chiers, application de collaboration, application de traitement distribué
et application de communication.
•Partage de chiers :
Les premières applications populaires du peer to peer ont été des applications de partage
de chiers de diérentes natures (texte, multimédia, audio, . .). Parmi ces applications,
nous citons Napster, Gnutella et KaZaA.
•Collaboration :
Cet aspect concerne les entreprises (travail collaboratif ). En eet, les usagers colla-
borent en temps réel pour réaliser ensemble un projet distribué. Nous citons comme
exemple Groove et Magi. [4]
Groove est une application P2P pour travailler en groupe. Elle ore de nombreux ser-
vices comme la messagerie instantanée, le partage de documents ainsi que des outils
pour planication de tâches. Par ailleurs elle fournit une plate forme d'échange peer
to peer destinée à faciliter les échanges entre les collaborateurs. L'objectif majeur des
applications de collaborations est de diminuer les coûts de communication particuliè-
rement dans le cas où les collaborateurs sont répartis.
•Traitement distribué :
L'architecture P2P peut être mise à prot pour exploiter en parallèle les capacités
de calcul d'un grand nombre d'ordinateurs. Par exemple un traitement qui peut être
décomposé et parallélisé, c'est-à-dire il peut être divisé en parties susceptibles d'être
traitées d'une manière quasi simultanée. Les peers coopèrent pour réaliser ce traitement
en exploitant leurs ressources (puissance processeur, espaces de stockage,. . .)
•Communication :
Les applications les plus connues sont la messagerie instantanée comme Yahoo Messen-
ger, AOL, MSN Messenger, la vidéo conférence et la téléphonie par Internet (Skype).
Il existe d'autres applications P2P comme : les moteurs de recherche qui ont pour ob-
jectifs de palier aux limites des moteurs classiques qui passent à coté de beaucoup de
contenu (recherche partielle). Le principe est de chercher sur tous les appareils connec-
tés au réseau. Un exemple de moteur de recherche qui se base sur le principe des réseaux
pur P2P est YaCy pour Yet another Cyberspace. On trouve aussi les bases de données
réparties, l'idée est de sauvegarder des chiers et des données d'une manière répartie
pour orir un espace de stockage plus grand (sans se limiter au disque dur local). [6]
6
1.3.5 Problèmes des réseaux P2P

Parmi les problèmes posés dans les réseaux P2P, nous citons :
•Sécurité :
Dans les réseaux purs peer to peer, le téléchargement et le partage de chiers se font
directement entre machines. En conséquence, la sécurité sera touchée, par exemple lors
de téléchargement de chiers qui peuvent être infectés par un virus. A un moment
donné, un simple peer peut devenir un serveur pour un autre peer, mais il ne pourra
pas remplir tous les aspects de sécurité fournis par les serveurs [7].
•Interopérabilité :
Dans les réseaux P2P, les applications utilisent diérentes technologies réseau ainsi que
diérentes plateformes. Le fait que plusieurs plateformes puissent exister au sein du
réseau avec diérents systèmes de sécurité, rend l'interopérabilité dicile.
•Bande passante :
Puisque le nombre d'utilisateurs du réseau P2P n'est pas limité et ne cesse d'augmenter
cela engendre un problème de trac et de saturation du réseau.
•Découverte des ressources :

Il n'y a pas de serveurs dans les réseaux P2P, ainsi que les adresses IP ne sont pas
toujours permanentes, l'utilisation d'un bon algorithme de découverte et localisation
des ressources est indispensable. [7]
1.4 Architecture des réseaux peer to peer

Les P2P peuvent être déployés en 3 architectures : centralisée, décentralisée, hybride.
1.4.1 Architecture centralisée

Cette architecture est composée d'un unique serveur central auquel se connectent
les utilisateurs, dans le but de s'identier et de recenser les diérents chiers proposés
par les clients (utilisateurs). Ce serveur centralisé dispose d'une table de hachage qui
contient principalement deux types d'informations : celles sur les chiers (Nom du
chier, taille,...) et celles sur les utilisateurs (nom d'utilisateur, adresse IP, nombre
de chiers proposés, .). Lorsqu'un client est connecté au réseau en utilisant un logiciel
client peer to peer, il peut faire des recherches de ressources. Il obtient alors une liste des
ressources correspondant à sa recherche, puis choisit une d'entre elles, après il choisit
d'où il veut la télécharger. Les nouveaux réseaux permettent le téléchargement à partir
de plusieurs peers en parallèle (eDonkey, BitTorent). Il lui sut dès lors de cliquer sur
le lien qui l'intéresse pour commencer le téléchargement. L'étape de téléchargement est
complètement indépendante du serveur c'est-à-dire que le chargement se fait entre les
deux machines sans passer par le serveur [1].
7
Figure 1.3 Architecture centralisée[1].
•Avantages :
La recherche de ressources est facile, car le serveur sait si un chier est disponible sur le
réseau ou pas.
Aisance d'utilisation, puisqu'il n'y a pas de soucis de connexion au bon serveur.
•Inconvénients :
Le serveur est un point critique car il sut de le compromettre pour compromettre tout le
réseau
Aucun anonymat n'est possible puisque chaque utilisateur est identié sur le serveur. En plus,
chaque peer peut trouver l'adressage des peers à partir desquels il est entrain de télécharger
les chiers. [1]
1.4.2 Architecture décentralisée

Cette architecture ne s'appuie sur aucun serveur, chaque peer joue les rôles de client et de
serveur. Les peers sont connectés entre eux an de relayer les requêtes de PC à PC. Contrairement
aux réseaux centralisés, où il susait de se connecter au serveur pour avoir accès aux informations,
dans cette architecture, le client diuse une demande pour l'identication de tous les noeuds
membres du réseau auquel il est connecté. Les n÷uds recevant la demande vont à leur tour l'envoyer
à tous les noeuds voisins et ainsi de suite. Chaque noeud recevant cette demande répond avec une
identication.
8
Figure 1.4 Architecture décentralisée[1].
•Avantages :
Cette architecture présente quelques avantages qui sont :
La taille d'un tel réseau est théoriquement innie, contrairement aux autres architectures
dont le nombre de clients dépend du nombre et de la puissance des serveurs ;
La disparition d'un ou de plusieurs peers ne sura pas à stopper le réseau.[6]
•Inconvénients :
Plus il y a de peers sur le réseau, plus le trac de données augmente exponentiellement. Des
techniques existent pour éviter ce problème, parmi elles nous citons la méthode d'horizon et
le timeout ;
La méthode d'horizon consiste à. limiter volontairement le nombre de peers visibles par un

autre peer. Ce qui permet de limiter l'envoi des requêtes aux seuls peers constituant l'horizon.
En cas d'échec, les requêtes sont alors envoyées au-delà de l'horizon ;
La méthode du timeout consiste en la mise en place d'un délai limité avant l'abandon d'une
requête en cas de non réponse ;
Anonymat implique risques de piratage. [6]
1.4.3 Architecture hybride

Cette architecture est qualiée d'hybride parce quelle est basée sur les deux architectures cen-
tralisée et décentralisée (distribuée).
Dans ce type de réseau des machines particulières et puissantes jouent le rôle de serveurs locaux
appelés supers noeuds (SNS) ou supers peers, gérant un groupe de peers. Le choix d'un super noeud
dépend de ses caractéristiques à savoir : la bande passante, les performances CPU et l'accessibilité
(temps de présence sur le réseau).
Les supers noeuds sont reliés entre eux suivant une architecture décentralisée et chacun dis-
posant d'un index de ressources de son cluster (l'ensemble des peers connectés à lui). Les noeuds
(clients) avec une faible bande passante sont reliés à un super peer en mode client serveur. Le
fonctionnement de cette architecture est comme suit :
Lorsqu'un nouveau peer se connecte, il est aecté à l'un de ces groupes et la recherche d'une
ressource s'eectue de la manière suivante : le peer envoie sa requête au super n÷ud auquel il
9
est connecté, ce dernier vérie l'existence de cette ressource dans son répertoire. Si elle existe, il
renvoie la réponse au demandeur sinon il transmet la requête à un autre super noeud ou bien il
renvoie l'adresse d'un super noeud au demandeur pour renouveler sa requête.
Ce principe de fonctionnement permet de bénécier d'une meilleure bande passante grâce à la

réduction du trac des requêtes. [8]
Figure 1.5 Architecture Hybride[8].

•Avantages :
Parmi les avantages que présente une architecture hybride, nous citons :
Optimisation de l'utilisation de la bande passante du réseau : Equilibrage de la charge du

réseau ;
Diminuer les nombres de connexions sur chaque serveur (super noeud), et ainsi d'éviter les
problèmes de bandes passantes.
•Inconvénients :
Parmi les inconvénients de cette architecture, nous citons :
La diculté et la complexité pour mettre en place une telle architecture ;
Si un super noeud tombe en panne cela signie que tous les noeuds connectés à lui seront
déconnectés complètement de réseau ;
L'anonymat de l'utilisateur n'est plus assuré puisque les super noeuds gardent les informa-
tions sur lui.
Anonymat implique risques de piratage. [6]
1.5 Table de hachage

Une table de hachage est une structure de données qui associe par hachage une clé à un objet
an de construire un index. Une clé est le résultat d'une fonction de hachage appliquée à un élément
de l'objet. Par exemple, la clé d'un pair est le résultat de l'application d'une fonction de hachage
sur l'adresse IP de son noeud, alors que la clé d'un objet peut être le hachage de son nom. [9]
10
1.6 Les tables de hachage distribuées

Les tables de hachage distribuées (Distributed Hash Table, ou DHT) sont des systèmes de
stockage repartis qui utilisent une infrastructure s'appuyant sur des protocoles de routage par clés
(KeyBased Routing, ou KBR). Les DHT fournissent au développeur un haut niveau d'abstrac-
tion pour l'implémentation de systèmes de stockage persistant à large échelle, masquant ainsi la
complexité des protocoles de tolérance aux fautes, de la réplication et du routage réseau. C'est
pourquoi les DHT sont de plus en plus utilisées pour des applications ayant un fort besoin de
abilité, telles que les systèmes de sauvegarde, de gestion distribuée de chiers, ou les systèmes de
distribution de données. [10]
Il existe actuellement plusieurs DHTs sur le marché, certaines sont accessibles publiquement
et gratuitement, d'autres sont restreintes aux personnes aliées aux entreprises ou établissements
accueillant des n÷uds, nous en avons sélectionnés cinq pour notre présentation :
•kademlia :
Kademlia est une table de hachage distribuée (DHT) protocole de communication pour
les réseaux décentralisés peer-to-peer. Le réseau Kademlia est composé d'un large éven-
tail de n÷uds, qui interagissent les uns avec les autres par User Datagram Protocol
(UDP). Chaque n÷ud du réseau est identié par un nombre binaire unique appelé ID
de n÷ud. L'ID de n÷ud est utilisé pour localiser les valeurs (bloc de données) dans
l'algorithme Kademlia. Les valeurs sont également reliées entre elles dans un réseau
Kademlia avec la clé d'une valeur spécique, un nombre binaire de longueur xe. [11]
•CAN :
CAN (Content Adressable Network) : cette table de hachage utilise un espace vectoriel
cartésien multidimensionnel : chaque noeud gère une portion de l'espace et dispose
d'informations sur ses voisins immédiats. Chaque identiant unique de ressource est
converti en coordonnées dans l'espace CAN et le routage est réalisé de proche-en-
proche : pour réaliser un saut, le noeud réceptionnant la requête la communique au
voisin le plus proche des coordonnées recherchées. [12]
•Chord :
Les n÷uds sont organisés en anneau. Chaque n÷ud dispose d'un identiant qui est
charge de gérer l'index pour les identiants qui lui sont supérieurs ou égaux et infe-
rieurs a l'identiant du n÷ud suivant sur l'anneau. Un n÷ud d'identiant n maintient
une table de routage vers les n÷uds d'identiants (n + 2i-1). La table est donc de taille
logarithmique et les opérations de recherche de clé sont réalisées en temps logarith-
mique. [12]
•Pastry :
Ce système s'inspire de la topologie en anneau de Chord. Chaque noeud maintient
une table de routage d'une taille O(logN) (avec N le nombre de noeuds actifs dans le
réseau) : le routage est alors assuré en choisissant pour le prochain saut le noeud de la
table présentant le plus long préxe binaire commun avec l'identiant de la ressource
(en pratique, les identiants ont une taille de 128 bits). [12]
•OpenDHT :
OpenDHT [19] est une table de hachage distribuée accessible publiquement, qui est
apparue en 2005 et qui appartient à Planet-lab [20], qui lui est un réseau d'ordinateurs
11
utilisé en tant que plateforme d'essais pour de la recherche orientée réseaux et systèmes
distribués. Aucune information d'identication ou de création des comptes n'est requise
pour utiliser le service. De plus le stockage de données est réparti équitablement entre
tous les clients actifs. Par conséquent, put et get peuvent être émises à n'importe
quel n÷ud de la DHT. Ce model de service de la DHT simplie considérablement le
déploiement des applications clientes. En eet, en utilisant OpenDHT pour le lookup
et le stockage des données, les clients peuvent ignorer la complexité du déploiement
et le maintien de la DHT pour se concentrer sur le développement des applications
réparties. [13]
1.7 La sauvegarde Friendstore

Friendstore est un mécanisme de sauvegarde coopératif des données en ligne avec les n÷uds de
conance étant généralement les amis de la vie réelle, facile d'utilisation pouvant servir pour des
raisons diverses comme par exemple :
• Il n'y a aucun besoin de payer pour un service de sauvegarde en ligne ;
• La coopération entre les amis en ligne et les données sauvegardées pour chacun ;
• Si l'utilisateur est hors ligne, les amis qui gardent une copie de ses données peuvent servir les
demandeurs de ses informations. [14]
1.8 Conclusion
Dans ce chapitre, nous avons fait un tour d'horizon sur les réseaux P2P, à savoir leurs diérents
aspects et problèmes ainsi que les trois architectures sous ils peuvent se présenter : centralisé,
décentralisé et hybride en ajoutant quelque modèles de table de hachage distribués. Nous avons
appris dans cette étude que les réseaux P2P sont confrontés à des problèmes liés à leurs tailles, leurs
sensibilités à la charge et leurs dynamismes. En eet, ces réseaux doivent pouvoir gérer des millions
de machines en restant ecaces, malgré les connexions et les déconnexions très fréquentes. Nous
décrivons dans le chapitre suivant les diérents réseaux distribués utilisant pour assurer l'intégrité
et la condentialité des données sauvegardées dans le réseau P2P.
12
Chapitre 2
Etat de l'art sur les réseaux distribués
2.1 Introduction
Les réseaux sociaux distribués en ligne sont apparus an de riposter au problème majeur des
réseaux sociaux centralisés évoqué dans l'introduction à savoir la protection des données des uti-
lisateurs.
La particularité que ces réseaux ont en commun ce compose de trois objectifs : La condentialité,
la disponibilité et l'intégrité. Certains essayent de respecter au moins deux de ces contraintes,
d'autres au contraire les respectent toutes, C'est ce que nous allons voir dans ce chapitre. Parmi
l'ensemble des réseaux disponibles, nous en avons sélectionnés trois majeurs en fonction de leur
capacité à permettre notre présentation mais voyons d'abord ce que signient ces objectifs.
2.2 Objectifs de la sécurité

2.2.1 Authentication
L'authentication est la procédure qui consiste, pour un système informatique, à vérier l'iden-
tité d'une entité (personne ou d'un ordinateur) an de lui autoriser ou pas, l'accès à des ressources
bien spéciées.[15]
2.2.2 Condentialité
La condentialité est le fait que l'information soit lue et consultée uniquement par ceux qui en
ont le droit et l'accès. On entend par condentialité le fait de restreindre la diusion de l'information
à des destinataires qui doivent être identiés, le but principal étant que l'information garde sa valeur
en ne se retrouvant pas aux yeux de tous. [15]
2.2.3 Disponibilité
La disponibilité est le fait de garantir que la donnée est accessible (lisible, consultable). Une
information disponible a une valeur et représente une plus-value et une force pour l'entreprise. Une
information qui n'est pas ou plus consultable au moment où nous en avons besoin ne représente
rien et revient au même point que la non possession de l'information. [15]
13
2.2.4 Intégrité
L'intégrité garantit que l'information ne subit aucune modication de son fond ou sa forme lors
de sa transmission, de son traitement ou de son stockage. Plus généralement, c'est la garantie du
fait que l'information est vrai (dans le sens non faussée par un tiers). On cherche donc à
être certain que l'information soit lisible dans son exactitude et également dans son intégralité. [15]
Et pour réaliser celle-ci nous avons utilisé :
RSA
RSA est un algorithme de cryptage qui a vu le jour en 1977, et qui doit son nom à ses trois
inventeurs Rivest-Shamir-Adleman (Ron Rivest, Adi Shamir, et Leonard Adleman). Le RSA in-
nove dans le domaine du cryptage, cat il utilise une clé publique et une clé privée. Il repose sur la
factorisation d'un entier.
• La clé publique peut être connue de tous, elle permet uniquement le chirement.
• La clé privée permet le déchirement, elle est personnelle. [16]
DES
Le DES (Data Encryption Standard) est un système de cryptographie symétrique par bloc. [17]
2.3 Exemples des réseaux distribués

Dans cette section, nous citons quelques exemples des réseaux distribués
2.3.1 PeerSon
PeerSon est une approche peer-to-peer distribuée et couplée avec un système de chirement.
Son infrastructure est faite justement pour supporter les caractéristiques les plus importantes des
réseaux sociaux en ligne (telles que : la messagerie instantanée, le mur, le l d'actualité,. . . ) dans
un environnement distribué. Il vise à maintenir les caractéristiques des réseaux sociaux en ligne
en surmontant deux limitations : La question de condentialité et l'exigence d'une connectivité
internet pour toutes les transactions.
Pour résoudre le problème de condentialité, un système de cryptage et de contrôle d'accès

est utilisé en couplage avec une approche P2P pour remplacer l'autorité centralisée des réseaux
sociaux en ligne classiques. Ces mesures empêchent les violations de la vie privée des utilisateurs
par les fournisseurs de ces systèmes, les annonceurs et même les utilisateurs eux même.
Sa conception répond principalement à trois exigences : Le chirement des données, la décen-

tralisation de l'architecture et l'échange direct entre les utilisateurs. En un mot, le chirement
assure la condentialité pour les utilisateurs, la décentralisation basée sur l'utilisation d'une infra-
structure P2P permet quant à elle l'indépendance des fournisseurs des réseaux sociaux en ligne, ce
qui rend plus facile l'intégration de l'échange direct des données entre les appareils des utilisateurs
dans le système.
14
a - Le chirement des données
Le moyen de protection de la vie privée dans ce contexte est de permettre aux utilisateurs de
crypter et contrôler l'accès à leurs données. L'accès à ces données se fait à travers le partage de la
clé appropriée, cependant, les considérations de la sécurité incluent l'amorçage, la distribution et
la révocation des clés.
b- La décentralisation de l'architecture
Pour mieux protéger la vie privée, les données des utilisateurs sont cryptées et accessibles
uniquement à ceux qui ont les clés de déchirement. C'est l'utilisateur lui même qui détermine
avec qui partager les clés de décryptages des données qu'il publie. Par ailleurs, il n'est pas nécessaire
de faire valoir le fait que même si les données sont cryptées et centralisées, le prestataire du service
central pourrait être en mesure de décrypter ces données et de les utiliser.
c- Echange directe entre les utilisateurs
Puisque le service du réseau social est décentralisé et n'est pas basé sur un serveur web, les utili-
sateurs n'ont pas besoin d'être constamment en ligne pour l'utiliser. Ils peuvent donc échanger des
informations directement entre eux quand ils se connectent. Ainsi, les utilisateurs peuvent stocker
les données des autres utilisateurs et diuser les informations à travers le réseau social physique
ou retarder le téléchargement des données jusqu'à ce que quelqu'un dispose d'une connectivité en
ligne. [18]
2.3.2 Decent
Decent est un réseau social en ligne décentralisé, qui emploie une DHT pour stocker et récupérer
des objets de données créés par leurs propriétaires. Chaque objet est crypté pour fournir la con-
dentialité. L'avantage principal de cette architecture est sa modularité, c'est-à-dire, les politiques
d'accès, les mécanismes cryptographiques et la DHT sont trois composants séparés, interagissant
l'un avec l'autre par des interfaces bien dénies.[37]
Pour la mise en ÷uvre du prototype, la conception modulaire fournit la capacité d'utiliser

n'importe quel type de DHT et n'importe quel type de plan cryptographique. C'est une concep-
tion concernant les réseaux sociaux décentralisés mettant l'accent sur la sécurité et la vie privée.
Les utilisateurs de Decent utilisent un mécanisme cryptographique ecace pour la condentialité,
combinant des plans cryptographiques traditionnels et avancés pour l'intégrité et la disponibilité.
La simulation et les expériences avec le prototype préliminaire de Decent montrent que le respect
de la vie privée a été amélioré.
L'architecture Decent fournit la exibilité pour la direction de données dans une conception
orientée objet. Elle utilise un plan cryptographique approprié et avancé qui soutient une révocation
d'accès ecace et des politiques Fine-Grained Policy sur chaque pièce de données. Les autres
architectures se concentrent seulement sur un ou deux des trois contraintes des réseaux sociaux
distribués citées dans l'introduction. La nouveauté de cette architecture se trouve dans l'intégration
d'existants primitifs qui sont adaptés pour améliorer la sécurité et la vie privée des réseaux sociaux
en ligne. Ces existants primitifs sont entre autre la politique d'accès, le mécanisme de chirement
et les algorithmes utilisés dans les DHTs. [19]
15
2.3.3 Cachet
Cachet est une approche d'un réseau social distribué, basée sur Decent, qui donne une sécurité
optimale ainsi que le respect de la vie privée. En particulier cachet protège la condentialité, l'in-
tégrité et la disponibilité des données des utilisateurs, aussi bien que l'intimité de leurs relations
via le réseau.
Cachet utilise un réseau distribué de noeuds pour le stockage des données et assure la dis-
ponibilité de ces derniers. Mais ces noeuds ne sont pas dignes de conance, donc, le niveau de
cryptographie a été augmenté par rapport à Decent pour protéger les données. Le contenu des
données des utilisateurs est stocké dans un groupe de noeuds distribués basé sur la DHT FreePas-
try. Une cryptographie adaptée est utilisée pour le stockage des données dans les noeuds pour une
authentique mise à jour des requêtes. Un cryptage basé sur les attributs des objets échangés dans
le réseau est utilisé pour diminuer le temps de cryptage et de décryptage qui était important dans
l'architecture de Decent.
Cachet est en réalité une évolution de Decent. Le résultat obtenu montre l'importance d'utiliser
le réseau de Cachet, qui réduit la latence de la visualisation d'une page d'actualité de 100s en
moins de 10s. Cette architecture démontre que la combinaison de plusieurs systèmes distribués et
les techniques cryptographiques peuvent être utilisées pour avoir une alternative de protection de
vie privée convaincante par rapport aux réseaux sociaux centralisés. [20]
2.4 Architecture des réseaux sociaux distribués

Nous avons étudié soigneusement les architectures et les composants de ces trois réseaux so-
ciaux, et nous les avons simpliés an de les présenter comme suit :
2.4.1 Architecture de PeerSon

Sonja et al ont dénit une approche P2P distribuée couplée avec un système de chirement et
une extension de l'approche décentralisée par l'échange directe des données entre les utilisateurs.
Pour valider cette approche, Doris Schiöberg a conçu une architecture 2 tiers avec des protocoles qui
recréent les caractéristiques fondamentales des réseaux sociaux classiques de manière décentralisée.
[21]
a 1er tiers : (LE LOOK UP SERVICE)
Il s'agit d'un système de consultation des DHT, qui stocke les métadonnées telles que : Les
adresses IP, les informations sur les chiers, des informations sur les utilisateurs, . . . Ces méta-
données sont nécessaires an de pouvoir trouver les utilisateurs, leurs statuts et les données qu'ils
stockent.
PeerSon utilise OpenDHT, donc si l'utilisateur est hors ligne, alors la DHT pourra stocker les
données qu'elle reçoit pour une durée limitée. Plus de détails peuvent être retrouvés sur OpenDHT
dans le chapitre I.
16
b - 2e tiers : (LES PEERS)
Ce tiers est constitué des peers et contient les données des utilisateurs. Chaque utilisateur
qui se connecte au réseau contactera d'abord le lookup service pour le prévenir de sa connexion.
Un utilisateur qui souhaite communiquer avec un autre de manière synchrone ou asynchrone in-
terroge d'abord le lookup service pour obtenir toutes les informations nécessaires. Les peers se
connectent directement entre eux après cela et interrompent leur lien de conversation directement
après l'échange des messages asynchrones. [22] Une représentation simpliée de l'architecture de
PeerSon est montrée dans la gure(2.1).
Figure 2.1 Architecture de PeerSon[22].
2.4.2 Architecture de Decent et Cachet

Decent comme montré dans la gure(2.2), est basé sur une architecture 2 tiers où les données
sont stockées comme des objets dans une DHT qui utilise un object ID comme clé en plus
d'un standard push and get operation ; la DHT supporte aussi une opération additionnelle
au stockage dans les noeuds avec la WritePolicy sur les objets. Goldfarb, Writing policies and
procedures manuals, IEEE Transactions on Professional Communication, 2013.
La disponibilité des données est assurée par leur réplication. Le lookup service utilise le pro-
tocole de la WritePolicy pour empêcher les utilisateurs malveillants de modier ou supprimer les
données disponibles dans la DHT parce qu'ils n'ont pas la bonne signature. Celle-ci est générée
par le hachage de la clé publique de la WritePolicy et le cryptage des données. Elle fera partie de
l'objet métadonnée également crypté. Donc le noeud de stockage refusera de réécrire l'objet stocké
sauf si la nouvelle donnée est signée proprement par la clé WritePolicy.
La clé publique de la WritePolicy est aléatoire pour chaque objet an d'empêcher la liaison d'un
objet à son propriétaire. Cependant, vu que Cachet est une évolution de Decent alors il se base
bien évidemment sur son architecture mais en rajoutant un tiers, là ou dans Decent il n'y avait
que les peers et les DHT, Cachet a rajouté des DHT pilotes comme montré dans la gure (2.2).
Ces DHTs contiennent l'annuaire globale du réseau, parce qu'elles ont connaissance de contacts
appartenant à quelle DHT. Cela facilitera la recherche et optimisera le temps. [23]
17
Figure 2.2 Architecture de Decent à gauche et architecture de Cachet à droite[23].
2.5 Prototype des réseaux sociaux distribués

2.5.1 Protocole de PeerSon
Cette section décrit comment l'architecture de PeerSon est implémentée et à quoi ressemblent
les diérents protocoles.
a Identiant global unique (GUID)
Le système du réseau social distribué doit résister à des attaques importantes comme les at-
taques Sybil et les dénis de services tout en s'assurant que les identités des utilisateurs sont uniques.
Cette résistance peut être facilement déployée dans un environnement centralisé, hormis le fait
que dans un environnement décentralisé le déploiement est très dicile. PeerSon assume qu'au-
jourd'hui chaque utilisateur possède une adresse email qui est unique et donc utilisable comme
identiant. Mais pour empêcher les n÷uds malicieux dans les DHT de collecter les adresses emails,
un hash de chaque émail est calculé et utilisé comme identiant unique.
b La procédure de connexion
Se connecter au réseau signie qu'un certain utilisateur annonce qu'il est actuellement en ligne
avec les métadonnées nécessaires pour le joindre, ainsi qu'une liste des chiers que ce peer stocke.
Cette annonce est envoyée à l'OpenDHT qui à son tour prévient les autres utilisateurs. C'est ce
qui permet aux utilisateurs de suivre le statut de leurs amis.
c La récupération d'un chier
Les messages sur PeerSon sont traités comme des chiers. La découverte de ces chiers est
traitée par des requêtes envoyées à la DHT pour trouver quel peer contient le chier recherché. Le
résultat renvoie le nom du chier si celui-ci existe, le numéro de la (les) version (s) existante(s)
ainsi que le nom du peer contenant ce chier. C'est l'utilisateur demandant qui décidera quelle
version il souhaite-t-il obtenir et depuis quel peer.
18
d Les messages asynchrones
PeerSon permet les messages asynchrones tel que le mur de Facebook ou la messagerie instan-
tanée même lorsque l'utilisateur est déconnecté. La réception en mode hors ligne est gérée par le
stockage des messages au sein de la DHT jusqu'à ce que le récepteur se reconnecte.
2.5.2 Prototype de Decent et Cachet

Decent et Cachet ont implémenté diérentes parties dans leurs prototypes propres à eux et
qui font leurs points forts tels que l' ABE Policy et la Cryptography Policy , où ils sont
passés de quelques centaines de seconde de cryptage et décryptage chez Decent à quelques dizaine
de seconde seulement chez Cachet.
Pour leur prototype, Decent et Cachet ont développé un mur et une page d'actualité qui pour
un utilisateur est une collection des derniers statuts mise à jour par chacun de ses contacts (amis)
pour avoir une page d'actualité pour chaque utilisateur ; L'ABE format contient la politique néces-
saire pour le chirement des données, les utilisateurs peuvent savoir s'ils seront aptes à décrypter
l'objets ou non et s'ils seront autorisés à lire les informations ou pas donc ils ne perdront pas de
temps à décrypter des informations s'ils n'ont pas le droit de les lire.
Dans l'architecture de Decent, le décryptage des données nécessitait beaucoup de temps sans
aucune performance de caching pour générer la page d'actualité. Par ailleurs, l'utilisateur
n'avait pas besoin de lire toutes les actualités de ses contacts, une sélection devenait donc néces-
saire, elle fut introduite dans l'architecture de Cachet. De plus, Cachet adopte le social caching
, car étant donné l'utilisation de la décentralisation et la cryptographie dans l'architecture précé-
dente qui est Decent, télécharger et reconstruire le mur d'un contact social ou la page d'actualité
est un long processus exigeant les étapes suivantes :
• Décrypter des objets de mise à jour, qui sont ABEncrypted suivant la ABE Policy ;
• Rapporter des métadonnées comme une mise à jour ;
• Indexer la clé de décryptage symétrique dans la DHT ;
• Accéder à des petits objets multiples situés dans diérents noeuds de stockage utilisant la DHT
fournie dans l'étape précédente ;
• Décrypter des objets de mise à jour avec leurs clés symétriques correspondantes.
a Recherche d'un contact social
Pour permettre aux utilisateurs de rechercher leurs contacts, Cachet propose un service cen-
tralisé d'administration qui maintient le mapping entre les contacts et leurs racines (prole). Pour
permettre à ce service de connaître les relations des utilisateurs, cette architecture utilise :
• Un canal de communication anonyme ;
• An de cacher les noms des utilisateurs dans l'annuaire de la DHT, il est nécessaire d'augmenter
le niveau du protocole de sécurité concernant la vie privée. Il est d'usage de croire que cachet
garantit le respect de la vie privée et surpasse tous les autres systèmes existant dans ce domaine
mais, beaucoup de changements an de l'améliorer sont encore à mettre en place tels que :
• l'algorithme de social caching transmet des informations sur les identités des utilisateurs ;
• le mur d'actualité révèle si un utilisateur est en ligne ou hors ligne.
19
b Suppression et annulation
Quand un utilisateur eace un objet ou modie la politique d'accès à celui-ci, ces changements
sont aectés immédiatement aux données. Le protocole de modication n'est pas spécié dans ce
travail, l'utilisateur peut donc envoyer une requête de révocation pour eacer des objets sur Cachet.
c Protocole de présence
En générale dans un réseau centralisé le serveur garde la trace de la présence de ses utilisateurs.
Cependant, dans Cachet une approche distribuée est appliquée quand chaque n÷ud enregistre sa
présence dans la DHT an que la présence des utilisateurs dans le réseau soit eective. La présence
de cet utilisateur en ligne a la même structure que les objets et est cryptée avec ABEncryption
pour empêcher la DHT de lire le contenu de cet objet. Cette structure est dénie par une adresse
IP et un numéro de port. Ce qui permet à l'utilisateur d'eectuer des modications à son prol en
ajoutant ou supprimant des informations quand il le désire. La DHT met à jours ces informations
qui sont similaires au remplissage de la page d'actualité. [24]
2.6 Stockage des données

Pour le prototype actuel de PeerSon, la meilleure façon pour stocker les données est de le faire
chez leurs propriétaires ainsi que sur l'espace de stockage de leurs amis en suivant l'algorithme
Friendstore. Dans ce cas là, ces données ne sont disponibles que lorsque le propriétaire et/ou ses
amis sont en ligne. Ceux qui veulent les consulter doivent avoir les permissions nécessaires.
Cependant, Decent et Cachet utilisent un autre système de stockage, ils stockent les données
dans des DHTs distribuées an d'assurer une disponibilité permanente tout en augmentant le
niveau de cryptage de données pour assurer l'intégrité et la condentialité. [25]
2.7 Conclusion
Dans ce chapitre, nous avons déni les contraintes de la sécurité et certains systèmes distribués
tout en présentant leurs dénitions, leurs architectures, prototypes et leur stockage de données.
Le chapitre suivant sera consacré pour la présentation de notre application NetPeers ainsi que sa
modélisation.
20
Chapitre 3
Présentation et Conception de l'application
3.1 Introduction
Dans ce chapitre, nous présenterons l'idée principale de l'application NetPeers, pour cela nous
avons divisé le travail en deux parties ; La première partie, intitulée 'Présentation de l'application' ;
explique les objectifs de l'application et les services qu'elle ore aux utilisateurs qui serra suivie de
son architecture général.
Dans la deuxième partie nous nous sommes basés sur la méthode UP (processus unié) pour
présenter l'analyse et la spécication des besoins, suivie de la conception de l'application. L'étape
d'analyse et de spécication des besoins ore une description de l'application suivie des besoins
fonctionnels et non fonctionnels.
L'étape de conception consiste à suivre les étapes nécessaires pour concevoir un système de
services d'aide aux étudiants sous forme d'application. Pour cela, nous allons utiliser UML 2.0
comme langage de modélisation car il ore une souplesse remarquable qui s'exprime par la pos-
sibilité d'obtenir des modèles de systèmes reétant la réalité en utilisant les diagrammes les plus
importants. Enn nous achèverons le chapitre avec une conclusion.
Partie I : Presentation de NetPeers
3.2 L'objectif de l'application NetPeers

L'objectif de notre application est de proposer un système distribué tout en étant sécurisé,
permettant de préserver la vie privée des utilisateurs et de faire communiquer diérentes instances
de NetPeers installées sur diérentes machine à travers le monde.
Chaque échange qui se déroule entre la DHT et l'Utilisateur est sécurisé avec un algorithme de
RSA an de permettre aux utilisateurs de consulter leurs données que par eux même et les contacte
avec qui il est partage, chaque utilisateurs possède une paire de clés(clé publique clé prive) an de
partager une clé DES lors d'un échange entre eux.
Ci-dessous nous allons présenter les diérentes parties que nous avons implémentées dans Net-
Peers :
21
1. Inscription :
Lors de la première utilisation de NetPeers, le nouvel utilisateur devra s'inscrire en précisant
un mot de passe et un login. Ces derniers seront envoyer vers la DHT (mot de passe haché),
ensuite elle vérie si le login est déjà utilisé si c'est le cas alors elle revoie une erreur sinon
elle conrme l'inscription.
2. Authentication :
Après s'être inscris, l'utilisateur s'authentie auprès de la DHT avec son login et son mot de
passe an d'accéder a son interface.
3. Messagerie instantanée :
Lorsqu'un utilisateur A veut communiquer avec un autre utilisateur B, il envoie d'abord une
requête à la DHT pour lui demander l'adresse IP du peer B, si ce dernier est en ligne la DHT
répond à la requête de A par l'adresse IP de B, après cela la communication asynchrone entre
les deux Peers sera établie.
4. Appel :
Pour eectuer un appel vocal depuis le peer A au peer B , A demande adresse IP de B à la
DHT si B fait partie de la liste des personnes en ligne alors la DHT revoie l'adresse IP de B
au peer A, à cet instant A peut joindre B par un appel.
5. Abonnement :
Chaque utilisateur a la possibilité de suivre (follow) une ou plusieurs personnes seulement
en ayant le login de la personne concernée, en validant le login du Peer B dans le champ de
Recherche par Peer A, une requête est envoyée vers la DHT demandent l'adresse IP du
Peer B, si ce dernier est en ligne alors la DHT répond par l'IP correspondante, a ce niveau,
A s'abonne directement a B.
6. Publication :
Cette partie est destinée aux partages d'informations d'un utilisateur qui sera vue par l'en-
semble de ses abonnés, si un utilisateur veut publier un contenu ceci est directement envoyé
à ses abonnés.
3.3 L'architecture de l'application

Le schéma ci-dessous - gure 3.1 - illustre l'architecture de l'application et les services qui y
sont disponibles.
22
Figure 3.1 L'architecture globale de l'application NetPeers.
Partie II : Conception
3.4 Le processus unié

3.4.1 Dénition d'un processus de développement logiciel
Un processus dénit une séquence d'étapes, partiellement ordonnées, qui participent à l'ob-
tention d'un système logiciel ou à l'évolution d'un système existant. L'objectif d'un processus de
développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisa-
teurs dans un court délai et à des coûts moindres. [26]
3.4.2 Dénition du processus unié (UP)

Pour dénir le processus unié, nous allons simplement dénir les deux termes qui le composent :
Processus :Suite continue d'opérations constituant la manière de fabriquer. En d'autres

termes, c'est une succession de tâches dans le but d'accomplir un travail, un projet.
Unié : Participe passé du verbe unier, être amené à l'unité, se fondre en un tout. En
fait, les méthodes d'analyse et de conception orientées objet, étaient variées jusqu'à ce que
RAMBAUGH, JACOBSON et BOOCH eut l'idée de les unier. [27]
Le processus de développement d'une application passe par les étapes suivantes :
Analyse et spécication des besoins ;
23
Conception ;
Implémentation ;
Test.
Dans ce chapitre, nous développerons uniquement les deux premières étapes, à savoir l'analyse
et la spécication des besoins et la conception, les deux autres étapes seront développées dans le
chapitre suivant.
3.5 Analyse et spécication des besoins

L'analyse et la spécication des besoins représentent la première phase du cycle de développe-
ment d'un logiciel. Elle sert à identier les acteurs réactifs du système et leur associer à chacun
l'ensemble d'actions avec lesquelles il intervient dans l'objectif de donner un résultat optimal et
satisfaisant au utilisateur.
3.5.1 Les besoins Fonctionnels

L'application NetPeers ore des services principaux, le. . . . . . .. Avant d'acceder aux secvices,
il faut d'abord que ùser ` s'authentie. L'authentication dans l'application NetPeers permet de
s'assurer de l'identité de l'utilisateur et de garantir la sécurité des données.
• Service Messagerie instantanée : Permet de discuter (texte + émoticônes)

en toute sécurité avec n'importe quel utilisateur gurant dans la liste d'amis.
• Service Appel : Est une fonctionnalité qui permet à son utilisateur commu-
niquer par voix instantanée avec un utilisateur de sa liste d'amis.
• Service Abonnement : Chaque utilisateur a la possibilité de suivre (s'abonné)

ou être suivie par un ou plusieurs utilisateurs (abonnant).
• Service Publication : Donne aux utilisateurs la possibilité de partager du

contenu avec leurs entourages.
3.5.2 Les besoins non Fonctionnels

Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumis le système
pour sa réalisation et son bon fonctionnement.
1. Existence d'un réseau ;
2. Ergonomie attractive et ecace : le design des interfaces doit permettre une identication
immédiate de ses diérents éléments pour permettre à l'utilisateur d'accéder de manière in-
tuitive à ce qu'il cherche, dès la première utilisation ;
3. Rapidité du traitement : l'application doit assurer une rapidité de traitement pour qu'elle
s'approche au maximum d'une exécution en temps réel.
24
3.6 Conception
3.6.1 Présentation de d'UML
UML (Unied Modeling Language), se dénit comme un langage de modélisation graphique
et textuel destiné à comprendre et à dénir des besoins, spécier et documenter des systèmes,
esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.
UML modélise l'ensemble des données et des traitements en élaborant des diérents diagrammes
[28].
3.6.2 Présentation de diagrammes UML

UML dans sa version 2.0 s'articule autour de treize types de diagrammes, chacun d'entre eux est
dédié à la représentation d'un système logiciel suivant un point de vue particulier. Ces diagrammes
sont regroupés dans deux grands ensembles : les diagrammes structurels et les diagrammes com-
portementales [28]. L'ensemble des quatorze types de diagrammes UML peut ainsi être résumé sur
la gure ci-dessous :
Figure 3.2 La liste des diagrammes UML 2.0 [28].
25
3.6.3 Les diagrammes d'UML

UML dans sa 2ème version (UML 2.0) propose treize (13) diagrammes pouvant être utilisés
dans la description d'un système. Ces diagrammes sont regroupés dans deux grands ensembles
[29] :
a- Les diagrammes structurels
Diagrammes de structure, ils sont largement utilisés dans la documentation de l'architecture

logicielle de systèmes logiciels. Ces diagrammes, au nombre de six (06), servent à représenter
l'aspect statique d'un système.
•Diagramme de classe : représente la description statique du système.
•Diagramme d'objet : permet la représentation d'instances des classes et des

liens entre celles-ci.
•Diagramme de composant : représente les déférents constituants du logiciel au

niveau de l'implémentation d'un système.
•Diagramme de déploiement : décrit l'architecture technique d'un système.
•Diagramme de paquetage : donne une vue d'ensemble du système structuré

en paquetage. Un paquetage représente un ensemble homogène d'éléments du système
(classes, composants, etc.).
•Diagramme de structure composite : permet de décrire la structure interne

d'un ensemble complexe composé.
b- Les diagrammes de comportement
Ces diagrammes représentent la partie dynamique d'un système réagissant aux événements
et permettant de produire les résultats attendus par les utilisateurs. Sept (07) diagrammes sont
proposés par UML.
•Diagramme des cas d'utilisation :est destiné à représenter les besoins des
utilisateurs par rapport au système. Vue sur l'organisme d'accueil et méthodologie de
conception
•Diagramme d'état-transition : montre les diérents états des objets en réaction

aux événements.
•Diagramme d'activités : donne une vision des enchaînements des activités

propres à un cas d'utilisation. Il permet aussi de représenter les ots de contrôle et
les ots de données.
•Diagramme de séquence : permet de décrire les scénarios de chaque cas d'uti-

lisation en mettant l'accent sur la chronologie des opérations en interaction avec les
objets.
•Diagramme de communication : est une autre représentation des scénarios

des cas d'utilisation qui met plus l'accent sur les objets et les messages échangés.
•Diagramme global d'interaction : fournit une vue générale des interactions

décris dans le diagramme de séquence et des ots de contrôle décrits dans le diagramme
d'activités.
26
•Diagramme de temps : permet de représenter les états et les interactions d'ob-

jets dans un contexte où le temps a une forte inuence sur le comportement du système
à gérer.
Nous présentons ci-dessous les diagrammes UML 2.0, que nous avons utilisés dans le cadre de ce
projet et quelques notions de base qui leurs sont associées.
•Dénition de diagramme de cas d'utilisation : Décrit la fonctionnalité four-

nie par un système en termes d'acteurs, leurs objectifs représentés comme des cas
d'utilisation, et les dépendances entre les cas d'utilisation.
Acteur : Représente un rôle joué par une entité externe (utilisateur humain, dispositif ma-
tériel ou autre système) qui interagit directement avec le système étudié [30].
Cas d'utilisation (use case) : Représente un ensemble de séquences d'actions qui sont
réalisées par le système et qui produisent un résultat observable intéressant pour un acteur
particulier. [30]
Les relations entre acteurs : La seule relation entre acteur est la relation de généralisa-
tion. Quand un acteur ls hérite d'un acteur père, il hérite en réalité de toutes les associations
du père. [30]
Les relations entre cas d'utilisation :

Relation d'inclusion (Include) : Une relation d'inclusion d'un cas d'utilisation A par
rapport à un cas d'utilisation B signie qu'une instance de A contient le comportement
décrit dans B.
Relation d'extension (Extend) : Une relation d'extension d'un cas d'utilisation A par
un cas d'utilisation B signie qu'une instance de A peut être étendue par le comportement
décrit dans B.
Relation de généralisation : Les cas d'utilisation descendants héritent de la description
de leurs parents communs. Chacun d'entre eux peut néanmoins comprendre des interactions
spéciques supplémentaires. [30]
• Dénition de diagramme de séquence : Montre comment les objets com-

muniquent entre eux en fonction d'une séquence de messages. Indique également les
durées de vie des objets relatifs à ces messages.
Scénario : Représente une succession particulière d'enchaînements, s'exécutant du début à

la n du cas d'utilisation, un enchaînement étant l'unité de description de séquences d'actions.
Ligne de vie : Représente l'ensemble des opérations exécutées par un objet.
Message : Un message est une transmission d'information unidirectionnelle entre deux

objets, l'objet émetteur et l'objet récepteur. Dans un diagramme de séquence, deux types de
messages peuvent être distingués :
Message synchrone : Dans ce cas l'émetteur reste en attente de la réponse à son message
avant de poursuivre ses actions.
Message asynchrone : Dans ce cas, l'émetteur n'attend pas de réponse à son message, il
poursuit l'exécution de ses opérations. [31]
27
• Dénition diagramme de communication : Montre les interactions entre les

objets ou des parties en termes de messages séquencés.
• Dénition de diagramme de classe : Le diagramme de classes est considéré

comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors
d'une telle modélisation, il décrit la structure d'un système en montrant les classes du
système, leurs attributs, et les relations entre les classes.
La classe : Représente la description abstraite d'un ensemble d'objets possédant les mêmes
caractéristiques. On peut parler également de type.
Un objet : Est une entité aux frontières bien dénies, possédant une identité et encapsulant
un état et un comportement. Un objet est une instance (ou occurrence) d'une classe.
Un attribue : Représente un type d'information contenu dans une classe.
Une opération : Représente un élément de comportement (un service) contenu dans une
classe.
Une association : Représente une relation sémantique durable entre deux classes.
Une superclasse : Est une classe plus générale reliée à une ou plusieurs autres classes plus
spécialisées (sous-classes) par une relation de généralisation. Les sous-classes" Héritent " des
propriétés de leur superclasse et peuvent comporter des propriétés spéciques supplémen-
taires. [32]
•Diagramme de déploiement : Utilisé pour représenter l'architecture physique

d'un système. Il montre la distribution des composants logiciels sur la base d'unités
d'exécution (les n÷uds). Les n÷uds et les artéfacts représentent le concept principal
du diagramme de déploiement. [33]
Apres avoir expliqué le fonctionnement des diérents diagrammes nous allons dé-
tailler leurs utilisation dans l'analyse et la conception.
3.7 Analyse et conception

3.7.1 Diagramme de cas d'utilisation
Nous illustrons ci-dessous Figure(3.3), le diagramme du cas d'utilisation générale.
28
Figure 3.3 Diagramme de cas d'utilisation général.
3.7.2 Diagrammes de séquences

Dans ce qui suit nous allons présenter les diagrammes de séquences de notre application, pour
une bonne ergonomie des diagrammes, tout message transitant entre la DHT et les utilisateurs
sont chirés an de respecter la condentialité l'intégrité des données.
Partage des clés RSA et DES entre les entités .
29
Utilisateur / DHT :
Figure 3.4 Partage des clés "Utilisateur / DHT".
Utilisateur / Utilisateur :
Figure 3.5 Partage des clés "Utilisateur / Utilisateur".
30
Diagramme de séquence Ìnscription'
Figure 3.6 Diagramme de séquence Ìnscription'.
31
Diagramme de séquence `Messagerie instantané'
Figure 3.7 Diagramme de séquence `Messagerie instantanée'.
32
Diagramme de séquence Àppel'
Figure 3.8 Diagramme de séquance Àppel'.
33
Diagramme de séquence Àbonnement'
• En présence de la DHT
Figure 3.9 diagramme de séquance àbonnement' en présence de la DHT.
34
• En absence de la DHT (ex : panne ou autre)
Figure 3.10 Diagramme de séquence Àbonnement' en absence de la DHT.
35
3.7.3 Diagramme de déploiement
Figure 3.11 Diagramme de déploiement de NetPeers.

DHT : elle contient seulement les inscris dans le chier Inscris.txt .
Utilisateurs : ils contiennent tous les mêmes chiers, IFollow.txt MyFollowers.txt Parametres.txt,
Messages.txt, Publications.txt.
3.7.4 Diagramme de classe
Figure 3.12 Diagramme de classe.
36
3.7.5 Règles de dérivation du modèle relationnel à partir d'un modèle

de classes
Règle 1 : Transformation des classes
Chaque classe du diagramme UML devient une relation. Il faut choisir un attribut de la classe
pouvant jouer le rôle d'identiant. Si aucun attribut ne convient en tant qu'identiant, il faut en
ajouter un de telle sorte que la relation dispose d'une clé primaire.
Règle 2 : Transformation de l'héritage
Trois décompositions sont possibles pour traduire la relation d'héritage en fonction des contraintes
existantes :
Décomposition par distinction : il faut transformer chaque sous-classe en une relation. La clé
primaire de la sur-classe, migre dans la (les) relation(s) issue(s) de la (des) sous-classe(s) et devient
à la fois clé primaire et clé étrangère.
Décomposition descendante (push-down) : s'il existe une contrainte de totalité ou de parti-

tion sur l'association d'héritage, il est possible de ne pas traduire la relation issue de la sur-classe.
Il faut alors faire migrer tous ses attributs dans la (les) relation(s) issue(s) de la (des) sous-classe(s).
Décomposition ascendante (push-up) : il faut supprimer la (les) relation(s) issue(s) de la (des)

sous-classe(s) et faire migrer les attributs dans la relation issue de la sur-classe.
Règle 3 : Association un-à-plusieurs
Cette règle consiste à ajouter un attribut de type clé étrangère dans la relation ls de l'asso-
ciation. L'attribut porte le nom de la clé primaire de la relation père de l'association.
Règle 4 : Associations plusieurs-à-plusieurs ou classes-associations
L'association devient une relation dont la clé primaire est composée par la concaténation des
identiants des classes connectées à l'association. Les attributs de l'association doivent être ajoutés
à la nouvelle relation. Ces attributs ne sont ni clé primaire, ni clé étrangère.
Règle 5 : Associations un-à-un
Cette règle consiste à ajouter un attribut clé étrangère dans la relation dérivée de l'entité ayant
la cardinalité minimale égale à zéro.
Règle 6 : Composition
La clé primaire des relations déduites des classes composantes doit contenir l'identiant de la
classe composite (quelles que soient les multiplicités).
37
En appliquant cette règle à notre modèle, nous obtenons les relations suivantes :
Peer ( username, password, adresseip)
Abonner ( idabon#, idabonnem#)
Notication (idnot, Text, type)
Avoir (idnot#, username#)
Message(idmsg,adresseipemm,adresseiprec, username#)
Publication(idpub, adresseipemm, adresseippub, nbrjaime, nbrjaimep, username#)
3.8 Conclusion
A l'issu de cette étape, nous avons pu exprimer les objectifs attendus de la future application
à concevoir, ainsi que les diérents diagrammes UML an de bien entamer l'implémentation et la
réalisation de l'application NetPeers.
38
Chapitre 4
Implémentation
4.1 Introduction
A ce stade du processus, les cas d'utilisation sont terminés, le problème a été analysé en profon-
deur ; nous avons déni une conception que nous espérons la mieux appropriée. Nous pouvons alors
entreprendre la dernière activité du Processus Unié composée de deux parties (implémentation
et test), avec comme objectif d'aboutir à un produit nal, exploitable par les utilisateurs.
Dans ce chapitre nous allons présenter l'environnement logiciel, les technologies et les langages
de programmation que nous avons utilisés ainsi que quelques interfaces d'implémentation de l'ap-
plication NetPeers, et nous achèverons le chapitre par la phase de test.
4.2 Environnement de développement de l'application

4.2.1 Environnement logiciel
- NetBeans
NetBeans est un environnement open-source de développement intégré (IDE) pour le dévelop-

pement avec Java, PHP, C ++, et d'autres langages de programmation. NetBeans est également
désigné comme une plate-forme de composants modulaires utilisés pour développer des applica-
tions de bureau Java.
NetBeans est codé en Java et fonctionne sur la plupart des systèmes d'exploitation avec une ma-
chine virtuelle Java (JVM), y compris Solaris, Mac OS et Linux. NetBeans gère les fonctionnalités
et les composants de la plateforme suivantes :
• Paramètres utilisateur ;
• Fenêtres (placement, apparence, etc.) ;
• NetBeans Visual Library ;
• Stockage ;
• outils de développement intégrés ;
• Assistant-cadre. [34]
39
Implémentation
4.2.2 Outils Utilisés

- Eclipse IDE
Eclipse est un IDE, (Integrated Development Environment), c'est-à-dire un logiciel qui simplie
la programmation en proposant un certain nombre de raccourcis et d'aides à la programmation. Il
est développé par IBM, est gratuit et disponible pour la plupart des systèmes d'exploitation. [35]
- JDK
(Java Développement Kit) Un environnement de développement logiciel Java d'Oracle. Il com-

prend la JVM, compilateur, débogueur et d'autres outils pour développer des applets et des ap-
plications Java. Chaque nouvelle version du JDK ajoute des fonctionnalités et des améliorations
à la langue. Lorsque les programmes Java sont développés dans le cadre de la nouvelle version,
l'interpréteur Java (Java Virtual Machine) qui l'exécute doit être également mis à jour. [36]
- JRE
L'environnement d'exécution Java (JRE) est un ensemble d'outils logiciels pour le développe-
ment d'applications Java. Il combine la machine virtuelle Java (JVM), les classes de base de la
plate - forme et les bibliothèques de support. JRE fait partie du kit de développement Java (JDK),
mais peut être téléchargé séparément. JRE a été initialement développé par Sun Microsystems
Inc., une liale en propriété exclusive d'Oracle Corporation. Aussi connu sous runtime Java. [37]
4.2.3 Langage de programmation

Java
Java est un langage de programmation et une plate-forme informatique créée par Sun Microsys-
tems en 1995. Il s'agit de la technologie sous-jacente qui permet l'exécution de programmes dernier
cri, notamment des utilitaires, des jeux et des applications professionnelles. Le langage Java est
utilisé sur plus de 850 millions d'ordinateurs de bureau et un milliard de périphériques dans le
monde, dont des périphériques mobiles et des systèmes de diusion télévisuelle[38]
4.3 Présentation des interfaces

Le volet technique de ce chapitre étant terminé, nous allons désormais consacrer cette partie
du chapitre à la présentation des principales interfaces de l'application NetPeers. Les diérentes
fonctionnalités de notre application sont réparties sur ses interfaces qui suit : L'interface d'ac-
cueil, l'interface d'inscription, l'interface de connexion, l'interface de la discussion instantanée et
l'interface d'appel.
40
Implémentation
•Interface d'inscription
Cette interface ore un aperçu sur la page d'inscription de l'application NetPeers.
Dans cette interface, nous pouvons voir les trois champs 'username','mot de passe' et
'conrmer mot de passe' que l'utilisateur doit saisir puis il aura à cliquer sur le bouton
'valider' an de s'inscrire.
Figure 4.1 Interface d'inscription.
•Interface de connexion
Cette interface ore un aperçu de l'interface de connexion de l'application NetPeers.
Dans cette interface nous remarquons deux champs `Login' et `mot de passe' que l'uti-
lisateur doit saisir pour accéder à l'application.
Figure 4.2 Interface de connexion.
41
Implémentation
•Interface Prol
Cette interface ore un aperçu de l'interface de prol d'un utilisateur.
Figure 4.3 Interface de prol.
•Interface de paramètre
Cette interface ore un aperçu de l'interface de paramètre de l'application NetPeers.
Figure 4.4 Interface de paramètre.
42
Implémentation
•Interface de messagerie instantanée

Cette interface ore un aperçu sur la page de Messagerie instantanée de l'application
NetPeers.
Figure 4.5 Interface de messagerie instantanée.
•Interface de publication
Cette interface ore un aperçu sur le statut publié par un utilisateur
Figure 4.6 Interface de publication.
43
Implémentation
•Interfaces d'appel
Interface d'appel émis
Figure 4.7 Interface d'appel émis.
Interface d'appel reçu
Figure 4.8 Interface d'appel reçu.
44
Implémentation
4.4 Test
Des tests unitaires se sont eectués tout au long du développement de l'application. Les gures
présentées ci-joint illustrent des scénarios d'exécution de NetPeers :
•Interface de discussion
Figure 4.9 Interface de test messagerie instantanée.
45
Implémentation
•Interfaces d'échanges vocaux
Figure 4.10 Interfaces d'échanges vocaux .
46
Implémentation
4.5 Conclusion
A travers ce chapitre, nous avons présenté la réalisation de l'application en justiant nos choix
technologiques, en représentant quelques interfaces graphiques que nous avons jugées les plus im-
portantes et en décrivant brièvement comment nous avons planié notre projet en terme de pro-
grammation.
47
Conclusion Générale et Perspectives
Les réseaux sociaux sont aujourd'hui l'un des services les plus prédominants de la toile. Ces
réseaux visent un large éventail d'utilisateurs de toutes tranches d'âges, de sexes et pour diverses
raisons qu'elles soient personnelles ou professionnelles.
Les données que l'utilisateur publie sont stockées dans les serveurs du fournisseur du réseau
social utilisé ; cela permet une disponibilité totale du contenu stocké. Cependant, les données per-
sonnelles et privées des utilisateurs sont parfois utilisées par les réseaux sociaux centralisés de
façon frauduleuse à des ns commerciales et mercantiles ou sous couvert de la demande de certains
gouvernements. Ce problème doit être solutionné par une approche forte et innovante. La mise en
sécurité des données personnelles et le respect de la vie privée sont deux priorités essentielles sur
lesquelles peut se construire une réponse pertinente.
C'est dans cette perspective que nous avons conçu et réalisé un outil de communication sécurisé
se présentant sous la forme d'un réseau social que nous avons nommé NetPeers. Les utilisateurs de
NetPeers ont la possibilité de s'échanger des messages à travers un système de discussion instanta-
née et d'eectuer des appels vocaux. NetPeers permet également aux utilisateurs de s'abonner entre
eux et de s'échanger des informations à travers des publications. Nous avons aussi pris en considé-
ration la question de sécurité des informations des utilisateurs en se servant des protocoles RSA et
DES. En eet, les logins et les mots de passe hachés des utilisateurs de NetPeers sont chirés avec
la clé publique de la DHT ; tous les messages échangés entre les utilisateurs sont chirés avec le pro-
tocole RSA et DES la communication entre les utilisateurs et la DHT est sécurisée à l'aide de RSA.
En guise de perspectives, nous prévoyons d'améliorer NetPeers. Parmi les améliorations pos-
sibles, nous citons :
• Assurer la disponibilité des données des utilisateurs même en l'absence de ces derniers tout en
restant dans la décentralisation.
• Introduire des appels audio-vidéos et le partage de données ( images, chiers txt ...).
• Optimiser et gérer le stockage de données chez les utilisateurs.
48
Bibliographie
[1] Gabrielle Feltin, Guillaume Doyen et Olivier Festor, Les protocoles Peer to Peer, leur utili-
sation et leur détection, Octobre 2003.http :/,2003.jres.org actes, paper.70.pdf (Consulté le
15/04/2016).
[2] Commission générale de terminologie et de néologie, Journal Oiciel, 13, 05 2006. http :
franceterme.culture.fr/ FranceTerme,recherche.html/COGE409-ouverture //28 (Consulté le
17/04/2016).
[3] http ://morebus.free.fr/siteMemoire/historique02.html (Consulté le 15/04/2016).
[4] Peer-to-peer : partager et répartir traitements et données, extrait du magazine hebdomadaire :

Décision Informatique http : 7 'www.01net.com/article/189227.html (Consulté le 20/04/2016)
[5] Clarke Siobhan, Dependability in Peer-to-Peer System, IEEE Internet Computing, 2004.
http :/ ; ieeexplore. ieee.org Xplore login.jspurl= iel5 4236729152 01315565.pdf (Consulté le
20/16/2016).
[6] Fabrice Schuler, Etude et utilisation des technologies des P2P, Avril 2005.http : schu-
ler.developpez.com articles p2p L2.1.3. (Consulté le 20/04/2016).
[7] Bartlomiej Sieka, Ajay D. Kshemkalyani, and Mukesh Singhal, On the Security of Polling Pro-
tocols in Peer-to-Peer Systems, IEEE internet Computing, Proceedings of the Fourth Interna-
tional Conference on Peer-to-Peer Computing (P2P-04) (2004). http 2,7/ieeex-plore.ieee.org
xpl freeabs-all.jsparnumber=1334929/ (Consulté le 25/04/2016).
[8] Manuel D.O., Mieux comprendre le peer-to-peer (p2p), Mai 2007. http : www.generation-
nt.com commenter peer-to-peer-peer2peer-p2ppartage-chiers-internet-article-40573-3.html
(Consulté le 25/04/2016).
[9] https ://tel.archives-ouvertes.fr/pastel-00005737/document (Consulté le 28/04/2016).
[10] https ://pages.lip6.fr/Sergey.Legtchenko/data/cfse09.pdf (Consulté le 28/04/2016).
[11] https ://www.techopedia.com/denition/10691/kademlia-kad (Consulté le 28/04/2016).
[12] http ://igm.univ-mlv.fr/ chilowi/unsortable/m2/replication.article.pdf (Consulté le

15/04/2016).
[13] http ://opendht.org/ (Consulté le 15/04/2016).
[14] http ://friendstore.news.cs.nyu.edu/ (Consulté le 15/04/2016).
[15] http ://www.information-security.fr/quest-ce-que-la-securite-de-linformation/ (Consulté le

15/05/2016).
[16] http ://alexandre.goyon.pagesperso-orange.fr/RSA.htm (Consulté le 15/05/2016).
[17] Pako Chaber une initiation a la cryptographie,edition 2004 paris .
[18] www.peerson.net (Consulté le 15/04/2016).
49
[19] Nikita Borisov and .al, DECENT : A Decentralized Architecture for Enforcing Privacy in
Online Social Networks, IEEE International Conference on Pervasive Computing and Com-
munications Workshops (PERCOM Workshops), 2012. (Consulté le 15/04/2016).
[20] Nikita Borisov and .al, Cachet : A Decentralized Architecture for Privacy Preserving So-
cial Networking with Caching, CoNEXT '12 Proceedings of the 8th international conference
on Emerging networking experiments and technologies, Pages 337-348, 2012 (Consulté le
15/04/2016).
[21] Doris Schiöberg, A Peer-to-peer Infrastructure for Social Networks, Diplomarbeit in Informa-
tik, Technische Universität Berlin Fakultät IV, Dezember 2008. (Consulté le 15/04/2016).
[22] Sonja Buchegger and .al, PeerSoN : P2P Social Networking Early Experiences and Insights,
SNS '09 Proceedings of the Second ACM EuroSys Workshop on Social Network Systems, 2009.
(Consulté le 17/04/2016).
[23] Goldfarb, Writing policies and procedures manuals, IEEE Transactions on Professional Com-
munication, 2013. (Consulté le 17/04/2016).
[24] Jinguang Han, Privacy-Preserving Decentralized Key-Policy Attribute-Based 6Encryption,

IEEE Transactions on Parallel and Distributed Systems, 2012. (Consulté le18/04/2016 ).
[25] Dinh Nguyen and .al, Friendstore : cooperative online backup using trusted nodes, Proceedings
of the 1st Workshop on Social Network Systems Pages 37-42, 2008. (Consulté le18/04/2016).
[26] P.Gerard. Processus de Développement Logiciel. Paris, Éditions eyrolles edition,

2008.http ://lipn.univ-paris13.fr/ gerard/docs/cours/methodo-support.pdf (Consulté le
4/06/2016).
[27] http ://www.memoireonline.com/06/12/5976/m-Conception-et-realisation-d-un-site-web-

dynamique-pour-un-magazine-en-ligne7.html (Consulté le 6/06/2016).
[28] P. Roques. Le cahier du programmeur : UML 2 Modéliser une application web. Paris, 4
Éditions eyrolles edition, Juin 2008. (Consulté le 6/06/2016).
[29] http ://training-course-material.com/training/UML-2.5-Intro (Consulté le 8/06/2016).
[30] P.Roques. UML 2 par la pratique : étude de cas et exercices corrigés. Paris, Éditions eyrolles
edition, Septembre 2011 (Consulté le).
[31] J.Gabay and D.Gabay. Mise en oeuvre guidée avec études de cas. 2011. (Consulté le ).
[32] http ://laurent-audibert.developpez.com/Cours-UML/ ?page=diagramme-classes (Consulté

le).
[33] http ://support.objecteering.com/objecteering6.1/help/fr/objecteering-uml-

modeler/diagrams/deployment-diagrams.htm (Consulté le 08/06/2016).
[34] https ://www.techopedia.com/denition/24735/netbeans (Consulté le12/06/2016).
[35] http ://www.enseignement.polytechnique.fr/informatique/profs/Julien.Cervelle/eclipse/

(Consulté le12/06/2016).
[36] http ://www.pcmag.com/encyclopedia/term/45608/jdk (Consulté le12/06/2016).
[37] https ://www.techopedia.com/denition/5442/java-runtime-environment-jre (Consulté

le12/08/2016).
[38] S.CHELOUAH, D.KABLI,"Conception et Réalisation d'un Système d'Authentication dis-

tribué ",memoire de n d'étude, UNIVERSITE DE BEJAIA, FACULTER DES SCIENCE
ET SCIENCE DE L'INGENIEUR, DEPARTEMENT INFORMATIQUE,OPTION :Système
distribué et parallèles, DUNOD,2006/2007.
50
Glossaire
BitTorrent
Est un protocole de transfert de données pair à pair (P2P) à travers un réseau informatique.
Cyberespace
Désigne un ensemble de données numérisées constituant un univers d'information et un milieu

de communication, lié à l'interconnexion mondiale des ordinateurs.
eDonkey
Est un logiciel de partage de chiers en pair à pair utilisant des techniques de P2P. Il était
développé par l'entreprise MetaMachine Inc et utilise le protocole de transfert de chiers multi
source eDonkey.
eMule
eMule est un logiciel gratuit de partage de chiers en pair à pair, il fonctionne sur Microsoft
Windows. Fondé en mai 2002 dans le but de contourner eDonkey2000.
Gnutella
Protocole informatique décentralisé de recherche et de transfert de chiers pair-à-pair (aussi

appelés P2P). Il a été imaginé en 2000 par Tom Pepper (en) et Justin Frankel.
Groove
Est une application P2P pour travailler en groupe. Elle ore de nombreux services comme la
messagerie instantanée, le partage de documents ainsi que des outils pour planication de tâches.
Par ailleurs elle fournit une plate forme d'échange peer to peer destinée à faciliter les échanges
entre les collaborateurs. L'objectif majeur des applications de collaborations est de diminuer les
coûts de communication particulièrement dans le cas où les collaborateurs sont répartis.
Kazaa
Client pair à pair développé par les programmeurs Ahti Heinla, Priit Kasesalu et Jaan Tallinn1
pour les entrepreneurs de Skype .Kazaa se connecte sur le réseau FastTrack, caractérisé par son
architecture décentralisée.
51
Napster
A été le nom de deux services de musique en ligne. À l'origine, Napster était un pionnier
des services de partage de chiers en pair à pair. Le service se spécialisait dans le partage de
chiers audios, en particulier de chiers musicaux généralement encodés au format MP3. Le service
permettait à ses utilisateurs d'échanger facilement des chansons.
YaCy
Est un moteur de recherche libre fonctionnant selon le principe d'un réseau pair à pair (P2P).
Ce logiciel est développé en Java et était installé, n 2006, sur des centaines d'ordinateurs appelés
YaCy-peers ou postes-YaCy . Un réseau YaCy est caractérisé par une architecture distribuée (non
centralisée). Tous les n÷uds (peers) YaCy sont équivalents et il n'existe pas de serveur principal.
52

Conception Et Réalisation D'un Réseau Social Distribué

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Et Réalisation D'un Réseau Social Distribué

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire

Ministère de l'Enseignement Supérieur et de la Recherche Scientique

Université Abderrahmane Mira de béjaia

Option : Administration et Sécurité des Réseaux

Conception et Réalisation d'un Réseau Social Distribué

Mémoire soutenu le 26/06/2016 par :

Devant le jury composé de :

Examinateur : M. OMAR Mawloud M.C.A, U.A.M Béjaia

Année univerrsitaire 2015/2016

Table des matières i

Table des gures iii

Liste des abréviations iv

1 Généralités sur les réseaux Peer-To-Peer 2

2 Etat de l'art sur les réseaux distribués 13

2.4.2 Architecture de Decent et Cachet . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Présentation et Conception de l'application 21

Conclusion Générale et Perspectives 48

1.1 Classication des systèmes informatiques. . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Architecture de PeerSon[22]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 L'architecture globale de l'application NetPeers. . . . . . . . . . . . . . . . . . . . . 23

4.1 Interface d'inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

1.2 Classication des systèmes informatiques

Figure 1.1  Classication des systèmes informatiques.

1.3 Réseau Peer-To-Peer

Figure 1.2  Structure du réseau P2P[2]

Début 2000 : Naissance de Kazaa. Ore la possibilité nouvelle de pouvoir télécharger un

1.3.3 Les caractéristiques du peer to peer

•Equilibrage de charge et mutualisation des ressources :

•Tolérance aux fautes :

Un système peer to peer doit pouvoir gérer les pannes suivantes :

1.3.4 Les applications du P2P

1.3.5 Problèmes des réseaux P2P

•Découverte des ressources :

1.4 Architecture des réseaux peer to peer

1.4.1 Architecture centralisée

Figure 1.3  Architecture centralisée[1].

 Aisance d'utilisation, puisqu'il n'y a pas de soucis de connexion au bon serveur.

1.4.2 Architecture décentralisée

Figure 1.4  Architecture décentralisée[1].

 La disparition d'un ou de plusieurs peers ne sura pas à stopper le réseau.[6]

 La méthode d'horizon consiste à. limiter volontairement le nombre de peers visibles par un

 Anonymat implique risques de piratage. [6]

1.4.3 Architecture hybride

Ce principe de fonctionnement permet de bénécier d'une meilleure bande passante grâce à la

Figure 1.5  Architecture Hybride[8].

 Optimisation de l'utilisation de la bande passante du réseau : Equilibrage de la charge du

Parmi les inconvénients de cette architecture, nous citons :

 La diculté et la complexité pour mettre en place une telle architecture ;

 Anonymat implique risques de piratage. [6]

1.5 Table de hachage

1.6 Les tables de hachage distribuées

1.7 La sauvegarde Friendstore

2.2 Objectifs de la sécurité

Et pour réaliser celle-ci nous avons utilisé :

2.3 Exemples des réseaux distribués

Pour résoudre le problème de condentialité, un système de cryptage et de contrôle d'accès

Sa conception répond principalement à trois exigences : Le chirement des données, la décen-

a - Le chirement des données

c- Echange directe entre les utilisateurs

Pour la mise en ÷uvre du prototype, la conception modulaire fournit la capacité d'utiliser

2.4 Architecture des réseaux sociaux distribués

2.4.1 Architecture de PeerSon

a  1er tiers : (LE LOOK UP SERVICE)

Ministère de l'Enseignement Supérieur et de la Recherche Scientique

Table des gures iii

1.1 Classication des systèmes informatiques. . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Classication des systèmes informatiques

Figure 1.1 Classication des systèmes informatiques.

Figure 1.2 Structure du réseau P2P[2]

Début 2000 : Naissance de Kazaa. Ore la possibilité nouvelle de pouvoir télécharger un

Figure 1.3 Architecture centralisée[1].

Aisance d'utilisation, puisqu'il n'y a pas de soucis de connexion au bon serveur.

Figure 1.4 Architecture décentralisée[1].

La disparition d'un ou de plusieurs peers ne sura pas à stopper le réseau.[6]

La méthode d'horizon consiste à. limiter volontairement le nombre de peers visibles par un

Anonymat implique risques de piratage. [6]

Ce principe de fonctionnement permet de bénécier d'une meilleure bande passante grâce à la

Figure 1.5 Architecture Hybride[8].

Optimisation de l'utilisation de la bande passante du réseau : Equilibrage de la charge du

La diculté et la complexité pour mettre en place une telle architecture ;

Anonymat implique risques de piratage. [6]

Pour résoudre le problème de condentialité, un système de cryptage et de contrôle d'accès

Sa conception répond principalement à trois exigences : Le chirement des données, la décen-

a - Le chirement des données

a 1er tiers : (LE LOOK UP SERVICE)

Figure 2.1 Architecture de PeerSon[22].

Figure 2.2 Architecture de Decent à gauche et architecture de Cachet à droite[23].

a Identiant global unique (GUID)

c La récupération d'un chier

d Les messages asynchrones

a Recherche d'un contact social

3.2 L'objectif de l'application NetPeers

Figure 3.1 L'architecture globale de l'application NetPeers.

3.4 Le processus unié

3.4.2 Dénition du processus unié (UP)

Processus :Suite continue d'opérations constituant la manière de fabriquer. En d'autres

Analyse et spécication des besoins ;

3.5 Analyse et spécication des besoins

• Service Messagerie instantanée : Permet de discuter (texte + émoticônes)

• Service Abonnement : Chaque utilisateur a la possibilité de suivre (s'abonné)

• Service Publication : Donne aux utilisateurs la possibilité de partager du

Figure 3.2 La liste des diagrammes UML 2.0 [28].

•Diagramme d'état-transition : montre les diérents états des objets en réaction

•Dénition de diagramme de cas d'utilisation : Décrit la fonctionnalité four-

Les relations entre cas d'utilisation :

• Dénition de diagramme de séquence : Montre comment les objets com-

Scénario : Représente une succession particulière d'enchaînements, s'exécutant du début à

Ligne de vie : Représente l'ensemble des opérations exécutées par un objet.

Message : Un message est une transmission d'information unidirectionnelle entre deux

• Dénition diagramme de communication : Montre les interactions entre les

• Dénition de diagramme de classe : Le diagramme de classes est considéré

Un attribue : Représente un type d'information contenu dans une classe.

Figure 3.3 Diagramme de cas d'utilisation général.

Partage des clés RSA et DES entre les entités .

Figure 3.4 Partage des clés "Utilisateur / DHT".

Figure 3.5 Partage des clés "Utilisateur / Utilisateur".

Figure 3.6 Diagramme de séquence `Inscription'.

Figure 3.7 Diagramme de séquence `Messagerie instantanée'.

Figure 3.8 Diagramme de séquance `Appel'.

Figure 3.9 diagramme de séquance `abonnement' en présence de la DHT.