Vous êtes sur la page 1sur 11

Ecole Supérieure d’Ingénieurs en

Electronique et Electrotechnique
d’Amiens

2019-2020 Rapport de projet


développement réseau

Développement d’un
logiciel pair à pair
centralisé

ETUDIANTS :
 ALI ELHAOUAT
 CHEKAIRI HAMZA
Table des matières

Introduction …………………………………………………………..

I) Les architectures Client/serveur et P2P………………………….

1.1) L’architecture Client/serveur………………………………….

1.2) L’architecture P2P……………………………………………..

II) Le Protocole TCP………………………………………………..

III) Test et capture


d’écran………………………………………………..

IV) Problèmes rencontrés et solutions


…………………………………

V) Conclusion………………………………………………………….
LISTE DES FIGURES

Figure 1 : Exemple d’architecture client/serveur……………………… .…


Figure 2 : Exemple d’architecture P2P…………………………………………….
Figure 3 : Représentation des clients………………………………………………
Figure 4 : Communication Client/Serveur………………………………………..
Figure 5 : Répertoire racine du client 2…………………………………………..
Figure 6 : Transfert d’un fichier texte……………………………………………..
Figure 7 : Répertoire racine du client 1…………………………………………….
INTRODUCTION

Le but de ce projet est de développer un système de gestion de fichier répartis.


Sur chaque PC, un répertoire « racine » contient des fichiers et des répertoires. Un serveur
central contient l’arborescence de chaque machine. Quand un utilisateur demande à lire un
fichier, soit il existe sur sa machine, soit il va interroger le serveur central qui va rediriger
l’utilisateur vers le bon PC. Utilisateur et PC dialoguent sur le serveur central.

But : développer les clients et le serveur pour mettre en œuvre cette architecture « peer to
peer » centralisée.
II) Client/serveur et P2P
Lorsque l'on souhaite partager de l'information entre plusieurs ordinateurs, il existe de
nombreuses solutions. Celle qui est la plus mise en œuvre aujourd'hui est le modèle
client/serveur.

2.1) Client/serveur :

Les clients désignent les applications qui cherchent à exploiter des services proposés par
un serveur. Les clients ne disposent pas d'informations, mais sont capables d'aller en
chercher.
De l'autre côté sont les serveurs. Souvent situés sur des machines puissantes afin de
pouvoir servir plusieurs clients en même temps ; ils ont l'information à disposition.
Un des gros avantages de ce mode client/serveur est sa relative simplicité de
fonctionnement. En effet, une fois qu’on a l'information qu’on souhaite partager, on ouvre
un serveur et on n’a plus qu'à attendre les clients.
Figure 1 : Exemple d’architecture client/serveur

2.2) P2P :

L'acronyme P2P signifie Peer to Peer, soit en français : Pair à Pair.


C’est une autre manière de partager de l'information est de ne pas se servir de serveurs,
mais de relier tous les possesseurs d'informations. Cela a pour avantage de supprimer les
serveurs, qui sont des machines coûteuses car très puissantes. En revanche, cela
complique énormément la notion de recherche d'informations.
On peut considérer que chaque utilisateur d'un P2P est à la fois un peu client et serveur.
Une fois que le demandeur sait où
est l'information qu'il
désire, les deux ordinateurs sont
alors en mesure de s'échanger
directement des informations, sans
plus devoir passer par une
machine tierce, c'est-à-dire sans
utiliser des ressources autres que
les leurs.

Figure 2 : Exemple d’architecture P2P

III) le protocole TCP :


IV) Test

Dans notre projet, les clients sont représentés par des répertoire (CL1, CL2, CL3 …), chaque
répertoire (client) contient un répertoire « racine » qui de son tour contient l’ensemble des
fichiers et des répertoires que ce client dispose.
Figure 3 : Représentation des clients

Le programme serveur crée un socket d’écoute puis dans une boucle infinie, utilise le socket
d’écoute pour attendre les clients.
Le port écouté par le serveur est connu par tous les clients.
Pour chaque client, le programme ouvre un socket de communication avec ce client puis
exécute les méthodes que nous avons définie, qui sont destiner à rendre le service qui est de
rechercher un fichier précis chez les autres clients et de renvoyer l’adresse IP et numéro de
port écouté par le client qui dispose du fichier au client qui recherche le fichier.
Afin d’obtenir l’adresse IP et le port le client est obligé donc de communiquer avec le serveur
qui sont rôle se finit après la fourniture de ces informations.
Un serveur attend des clients pour leur rendre le service, lorsqu’un client souhaite rechercher
un fichier il établit une connexion avec le serveur, une fois la connexion établit, le serveur
demande au client le nom du fichier qu’il cherche et son extension (pour effectuer une
recherche bien précise).

Figure 4 : Communication Client/Serveur

Le client répond avec le nom du fichier et son extension, dans le cas ci-dessus en recherche le
fichier texte appelé « toto ».
Figure 5 : Répertoire racine du client 2

Le serveur effectue la recherche indique que c’est le client 2 qui a le fichier et envoie les
informations qui vont permettre d’ouvrir la connexion avec le client 2 :
- Adresse IP : 127.0.0.1 (adresse de la boucle locale dans notre cas)
- Port écouté (63990)
Une fois ces informations sont obtenues le client va essayer d’ouvrir une connexion avec
l’autre client disposant du fichier recherché, une fois la connexion est acceptée ce dernier va
devenir un serveur et le partage de la ressource s’effectuera donc entre les deux sans aucune
intervention d’un serveur intermédiaire.

Figure 6 : Transfert d’un fichier texte

Pour que le partage soit effectué nous avons définis un tableau d’octet « bytearray » qui
contient des données temporaires, et définis des objets à lire dans le fichier de transfert, les
données lues seront donc renseignées dans l'objet le tableau d’octet « bytearray », puis nous
avons défini une méthode qui résume tout ça c.-à-d. qu’elle lit le fichier et stocke les données
lues sont stockées dans le bytearray.
Nous avons défini un flux externe qui fournit un canal pour communiquer avec le client. Les
données lues du bytearray sont écrit dans le flux de sortie.
Nous avons défini un objet InputStream appelé dans lequel nous collectons toutes les
informations transmises au canal d’entrée du client, c’est-à-dire aux fichiers ou même aux
messages transférés au client. Puis un objet FileOutputStream qui pointe vers le fichier qui
sera rempli avec les données copiées à partir du fichier du serveur, Et un
BufferedOutputStream qui nous aide à écrire des données dans le fichier de sortie via un
tableau d'octets ce qui nous permet d’envoyer tous type de fichier.
En utilisant la méthode de lecture de l'objet nous lisons les données du flux d'entrée. Les
données lues sur le canal d'entrée sont stockées donc dans le tableau d'octets. Nous avons
initialement défini variable sur le nombre d'octets lus.
Nous avons implémenté une boucle do-while qui lit à partir du flux d'entrée, si le nombre
d’octet à lire est supérieure ou égale à zéro, on met à jour l'objet notre variable d’octet lus,
après chaque lecture, et lorsque le nombre d’octet à lire est égal à -1, c'est-à-dire qu'il ne reste
aucune donnée sur le flux d'entrée, la boucle do-while se ferme. Et après cela, nous écrivons
les octets finalement lus sur le fichier puis fermons le flux et le fichier est bien transféré.
Figure 7 : Répertoire racine du client 1