Mini projet

Mini projet
GI3 - ISD
Enoncé :
Les architectures Peer-to-Peer se basent sur un principe simple de partage de fichiers sur internet où
chaque participant peut jouer le rôle d’un client et d’un serveur en même temps. Dans cette
épreuve, il s’agit d’élaborer un exemple assez basique de systèmes de fichiers en « peer-to-peer »
dont voici le principe :
1) Connexion au réseau peer-to-peer
- Chaque utilisateur dispose d’une application pour partager le contenu d’un répertoire
spécifié en ligne de commande en tant que argument à la classe principale de cette
application.
- En démarrant cette application, l’utilisateur dispose d’une application qui joue le rôle d’un
client et d’un serveur.
- Au démarrage, cette application charge le contenu d’un fichier servers.txt dans un vector
servers. Ce fichier contient une liste d’adresse IP d’autres utilisateurs du réseau Peer-to-Peer.
2) Recherche de fichiers
- Le client lance une requête spécifiant un nom de fichier à télécharger dans une première
ligne et son adresse IP dans une deuxième ligne. Cette requête est envoyée aux serveurs que
le client connaît à travers le vecteur servers. Ce client reste en écoute des réponses des
autres machines sur un port par défaut 1234. Voici un exemple de ce genre de requêtes :
SEARCH maChonson.mp3
134.120.1.67
- Chaque application qui reçoit cette requête vérifie si le fichier existe dans son répertoire
partagé et envoi un message au client qui cherche le fichier pour lui dire que le fichier a été
trouvé. Voici un exemple de ce genre de messages (deuxième ligne = adresse de la machine
où le fichier a été trouvée):
FOUND maChanson.mp3
134.120.1.124
- Lors de la réception d’un message FOUND l’adresse IP de la machine contenant le fichier est
ajoutée au vecteur de serveurs si ce vecteur ne le contient pas déjà.
- Chaque application qui reçoit une requête SEARCH doit aussi transmettre la requête aux
autres nœuds qu’il connaît en ajoutant son adresse IP dans la deuxième ligne. Voici un
exemple :
SEARCH maChonson.mp3
134.120.1.67 134.120.1.124
- Pour éviter les recherches interminables, l’application qui reçoit une requête de recherche
d’un fichier ne doit la transmettre qu’aux nœuds qui n’ont pas déjà traité cette requête.
3) Téléchargement de fichiers
- Si un client veut télécharger un fichier d’un nœud particulier (après avoir obtenu le résultat
de recherche), ce dernier doit envoyer une requête DOWNLOAD du style :
Tarak CHAARI
1/2
Mini projet
GI3 - ISD
DOWNLOAD maChonson.mp3
- L’application qui reçoit une requête DOWNLOAD doit envoyer le contenu du fichier demandé
vers le client concerné
4) Déconnexion
- Si un client veut quitter le réseau Peer-to-Peer, il doit enregistrer le contenu du vecteur
servers et envoyer aux nœuds qu’il connait une requête sur deux lignes contenant QUIT et
son adresse IP:
QUIT
134.120.1.67
- Chaque nœud qui reçoit une requête QUIT doit enlever l’adresse spécifiée dans la requête
de son vecteur servers et transmettre cette requête aux autres machines enregistrées dans
ce même fichier tout en ajoutant son adresse à la fin de la deuxième ligne
QUIT
134.120.1.67 134.120.1.124
- Pour éviter les transmissions interminables, l’application qui reçoit une requête QUIT ne doit
la transmettre qu’aux nœuds qui n’ont pas déjà traité cette requête.
Travail demandé :
-
-
Elaborer les diagrammes UML de cas d’utilisation, de classes et d’activité de cette
application.
Développer le code de l’application demandée selon l’énoncé ci-dessus en utilisant les
sockets JAVA dans le cadre d’une programmation modulaire à plusieurs classes et plusieurs
méthodes.
Enrichir cette application par une interface graphique SWING qui assure l’interaction avec ses
différents cas d’utilisation.
Rappel :
-
Un diagramme de cas d’utilisation illustre les fonctionnalités externes de l’application
Un diagramme de classes illustre les entités du système
Un diagramme d’activité illustre les méthodes impliquées dans un cas d’utilisation (comme
un diagramme de séquence) ou le contenu d’une méthode (instructions).
Tarak CHAARI
2/2