Discussion :

[parano]

Bonjour,

j'ai crée un programme dont le principe est le suivant :
- Clients et serveurs disposent d'une liste d'adresses IP de serveurs connus (dans un fichier).
- Le client lance une requête spécifiant un nom de fichier à télécharger.
- Cette requête est transmise aux serveurs que le client connaît
- Lorsqu'un serveur reçoit une requête, il renvoie le fichier demandé s'il le détient, et sinon réémet la requête vers les autres serveurs qu'il connaît, etc...
- Dés que le fichier demandé est trouvé quelque part, il est ramené vers le client et la recherche s'arrête.
- Le serveur est multiprogrammé.

Je voudrais modifié mon programme pour qu'au lieu de télécharger un fichier TOTO en une seule fois, le serveur qui s'occupe du fichier TOTO indique en combien de fragments ce fichier a été découpé ainsi que pour chaque fragment, quels sont les clients qui l'ont.
Le client choisira alors chez qui il récuperera les fragments
Par exemple, admettons qu'un client CLIENT souhaite télécharger le fichier TOTO.
CLIENT envoie cette requete aux serveurs (dont il connait les IP).
C'est le serveur B (par exemple) qui gere ce fichier donc le serveur répond à CLIENT que le fichier TOTO a été découpé en 4 fragments et que :
-le client 1 a les fragments 1 et 3
-le client 2 a les fragments 1 et 4
-le client 3 a le fragment 2
Donc CLIENT aura le choix pour récupérer le fragment 1 entre client 1 et client 2, pour le fragment 2 il devra le télécharger chez le client 3, etc ...
Des que CLIENT télécharge un fragment, il doit informer le serveur B qu'il a recupéré un fragment et devient à son tour un client pour les autres.

Le soucis que j'ai, c'est comment faire pour que le serveur B sache les clients qui ont les fragments du fichier TOTO et pour CLIENT informe le serveur B qu'un fragment a été récupéré.

PS : j'ai déjà crée une méthode permettant de découper un fichier en différents fragments ainsi que pour la reconstruction du fichier initial à partir de tous les fragments.

Merci

[Clorish]

1- Quand un client se connecte au serveur il emet la liste des fragments qu'il possede, ceux ci etant sauvegardé dans une liste sur le serveur.
2- Quand un client effectue uen requette sur un server, le server envoit aux clients connectes une requete sur le fichier et les parties possede par les clients.

Les requettes passent bien sur de serveurs en serveurs pour compelter la liste.

LE client recoit la liste integrale des clients qui possedent des parties de son fichier et selectionne une liste de couples clients/Parties qu'il transmet au server. en cas de choix multiples sur les parties, une selection alatoire ou respectant certaines regles peut etre faite.

Regles :
- privilegier une partie sur un client qui ne s'occupe pas deja d'une autre partie ex : Client1 : part1, part2 - Client2 : part2 => liste : client1,PArt1 - Client2 part2.
Cela permet d'optimiser les transferts en effectuant du parallellisme sur la bande passante montante des clients.
- Lancer une requette sur TOUS les fichiers parts de TOUS les clients, le premier terminé clot les autres, ou le plus rapide (apres un test sur le dl de quelques octets) clots les autres.

Je ne connait pas ton protocole de transfert, mais je definirais une taille de buffer, et j'emetrais des requetes au serveur : [DL ClientID PartID Offset] avec offset incrementé de la taille du buffer quand les donnes ont ete recues.
LE server lui ne s'occupe ainsi que de demander un buffer de bytes a un seul client, la gestion des DL etant faite pas le client.

[Clorish]

Bon je crois qu'il va faloir repartir de zero
d'abort on eclairci le concept et ensuite on vois la technique.
Par contre je suis debutant en Java donc compte pas trop sur moi pour le codage ... mais question conception pas de problemes

1- Quel est concept exact : Gestion Peer-2-peer a la facon emule ou bien autre chose.

2- Les serveurs hebergent ils les fichiers (tous ou partie) ou bien seul les clients hebergent les fichiers. Les serveurs n'ayant qu'une liste des fichiers.

3- pour chaques serveurs, une liste de fichier est definie et fixée ?

4- Les clients sont ils associés a un seul serveur ? ou peuvent ils choisir le serveur de connection ?

5- que sont les fichier "parts" ? des morceaux de fichiers en cours de telechargements ? ou une facon de representer les fichiers ?

6- La gestion des serveurs est elle indivuduelle ou a la maniere des disque dur sous forme de RAID.
Je m'explique : Les serveurs communiquent entre eux : ok. Mais on peux voir les choses de 2 facons : des serveurs avec des adresses IP differentes, et un choix de connection, les utilisateurs choisisent leurs serveru de connection, ou bien "fusionné". Dans ce dernier cas, un client peut n'utiliser qu'un seul serveur, de la meme maniere que si il en existait qu'un seul. La communication entre les serveur est totalement transparente.

7- LEs serveurs peuvent etre du genre "lourd" avec une gestion complete des transferts, ou bien "leger" en ne servant juste d'intermediaire, et le transfert se fait de client a client.

Bon voila deja pour demarrer ... si j'ai d'autre question je te le ferais savoir

[Clorish]

C'est une gestion p2p de fichier "simple". Pas de fichier vidéo, etc ...

ok. de toute facon le principe reste le meme.

Les serveurs ont une liste de fichier. Les fragments doivent être téléchargés chez les clients.

Si j'ai bien compris :
- LEs clients peuvent telecharger des fichiers chez d'autres clients resenssés sur d'autres serveurs.
- Un client peut se connecter sur un des serveurs au choix.
- Un client peut donc etre le seul client connecté a partager un fichier et qui plus est connecté sur un serveur n'etant pas le serveur de base qui ressence ce fichier dans sa liste.
Question : Peut il dans ce cas partager le fichier avec un client qui le demande ? ou du fait qu'il ne soit pas connu du serveur qui ressence ce fichier, il ne peut pas le proposer ?

Non, les serveurs n'ont pas une liste de fichier fixé. Il y a 2 types de demandes pour les clients :
-télécharger un ou plusieurs fichiers.
-publier un fichier, c'est à dire devenir serveur des fragments de ce fichier. Le client commence par demander si ce fichier (caractérisé par son nom) existe déjà sur le réseau. Si c'est le cas, le client prévenient le serveur correspondant qu'il possède tous les fragments de ce fichier. Dans le cas contraire, le serveur auquel il s'est adressé devient le serveur pour ce fichier.

Ok.
Quand tu parle de liste de fichier fixé, bien sur que c'est dynamique. On peut faire varier le nombre de fichiers partagés ca va de soit.
je pensais a "fixe" dans le temps de partage du fichier. c'est a dire qu'une fois ressencé, seul ce serveur le propose et connait ce fichier (que le client possesseur soit connecte ou non) jusqu'a ce qu'il soit retiré du reseau, ou bien cette liste peut varier en fonction de l'etat des client possesseur des fichier et des cliens qui se connectent sur le serveur.
On peut :
- sauvegarder la liste dans un fichier qui sera charge au prochain lancement du serveur et non mises a jour lors d'une connection/deconnection du client possesseur, et autoriser les mises a jour que sur des commande "share file" ou "unshare file".
- generer dinamiquement la liste en fonction de ce que possede le client qui se connecte sur le serveur.

En principe, il est possible de choisir le serveur de connection.
Un client possède une liste initiale (qui peut être complété) de serveurs à contacter. Dans le cas, ou cette liste d'IPs est contenue dans un fichier,il faudrait pouvoir atteindre les IPs situés avant et après l'IPs choisi.
J'avais dans l'idée de parcourir le fichieren partant de la premiere et de descendre.

Ok. Donc c'est le client qui genere et complete sa propre liste de clients a contacter en effectuant des requettes successives sur plusieurs serveurs, et non pas les serveurs qui communiquent entre eux pour generer une liste complete que le serveur de conenction retournera au client. Ce 2e cas est ce que j'appelais le mode "RAID" des serveurs. Pour un client l'ensemble des serveur n'apparait que sous la forme d'un seul serveur : son serveur de connection.
Un interet a ca : eviter de diffuser des informations sur la localisation des autres seveurs, et d'assurer un control de la charge sur les serveur car on sait combient de client max sont connecté sur un serveur. Inconvenient : si u nserveur est Down, tous les client sont "out".

Un fichier donné ne peut être référencé que par un seul serveur. Par exemple si un serveur A a comme liste de fichier TOTO, TITI, TATA, les autres serveurs ne peuvent pas les avoir.

Ca c'est une affirmation ? ou une consequence de ta conseption ?
Parce que ca rejoint ma premiere question : Si un client possede des fragments d'un fichier ressencé par le serveur A et qu'il se connecte sur le serveur B, comment un client connecté sur B peut connaitre et telecharger les parties ? puisque pour le serveur A, le client les possedant n'est pas connecté.
Si ce n'est pas un point de ton cahier des charges, il serait peut etre preferable que chaques serveurs genere une liste des fichiers et des parties proposées par les clients qui sont connecté chez lui. Cela rends inutile la gestion des liste de fichiers sur les serveurs.
A moins que lors de la publication d'un fichier par un client, le serveur stocke l'adresse IP du client, qu'il sera capable de fournir au client demandeur, meme si le client possesseur n'est pas connecté. Le client demandeur n'aurra qu'a attendre la conenction future du client possesseur.
Pour cela il faut etre sur que les IP des clients ne changerons pas .....

Les fichiers "parts" sont des "portions" du fichier initial. Dans le découpage que j'ai codé, je donne une taille maximale au fichier pour chaque découpage et je numérote les fichiers crées pour pouvoir retrouver l'ordre.
Par exemple, admettons que je veuille découper le fichier TOTO de taille 5000 octets.
Je choisis comme taille maximale 1000 octets pour chaque fichier découpé.
Donc 5 fichiers de taille 1000 vont être crées et les fichiers obtenus seront TOTO_1, TOTO_2, TOTO_3, TOTO_4, TOTO_5.
C'est comme cela que j'ai codé le découpage.

Oki ca je l'avais supposé.
Par contre, quand un client publie un fichier : Il demande a l'utilisateur de choisir un fichier, il le decoupe et en copie les morceaux dans un repertoire "share" qu'il va conserver tant que le fichier est publié par lui ?
Tu peut peut etre ameliorer ton algo en ne decoupant pas ton fichier original mais en jouant sur les offsets. une partie est definie en fonction du nom du fichier de l'offset de depart et de la taille.
LEs requettes iront donc charger le fichier, et transmettrons que les octets de offset a offset+size.
LEs 2 methodes on des avantages et des inconvenients.

Je ne sais pas si ça va répondre à ta question.
Chaque serveur de cartographie(les serveurs sont appelés comme cela) est en possession d'informations sur les autres serveurs et sur un ensemble de fichiers que lui seul cartographie. Par conséquent, pour un fichier donné, il ne doit y avoir qu'un seul serveur le cartographiant, c'est-à-dire, maintenant à jour pour chaque fragment des fichiers qu'il gère, la liste des clients possédant ce fragment.

Sur ce point : Si un client partage un fichier qui est deja partagé sur un serveur, differents de celui sur lequel il est connecté, l'information doit d'une maniere ou d'une autre transiter jusqu'a serveur ressenssant ce fichier, pour completer la liste des client possesseur de ce fichier ?

Le transfert se fait de client à client.
Les serveur indiquent en combien de fragments les fichiers qu'il gerent sont découpés et, pour chaque fragment, l'ensemble des clients qui le possèdent.

Ok.

Bon voici deja quelques elements de reponse, j'attends ton avis sur ce post pour les completer.
- J'opterais pour un type de serveur RAID :
* un client se conencte QUE sur un serveur.
* les serveurs possedent une liste des adresse des autres serveurs
* les serveurs communiquent entre eux pour apparaitre aux yeaux du client comme un seul serveur unique : Le serveru de connection etablie une liste premiere des solutions a la requette client, interroge les autres serveurs tour a tour pour la completer et transmettre la reponse a la fin au client.
* Pour eviter les la mise hors circuit d'un ou des client quand un serveru est down, le client peut avoir connaissance des adresses des autres serveur pour choisir son point d'entree. De cette manier on peu considerer l'ensemble comme un seul serveur virtuel dont les adresses ip des serveurs phisique correspondrais a un porte de connection sur le serveur virtuet. D'ou le rapprochement avec le systeme RAID des HDD.
Le telechargement des adresses ip des serveurs "online" par une requette sur le serveur de connection lors de la connection d'un client est uen bonne chose et facilite la maintenance de l'applciation cliente en cas de changement des adresses IP des serveurs.

- Les serveurs possedent la liste des "fichiers/numeroPartie" dont il a connaissance. A toi de voir comment la generer (cf questions plus haut).

- Les clients envoient une requette sur le serveur de connection, le serveur complete se reponse par requette successive sur les autres serveurs et envoie la liste integrale (avec doublons) ou optimisé (sans doublons) des adresses IPs des machines hebergeant les parties. A toi de voir si il est preferable que ca soit le client ou le serveur qui optimise la liste.

- Le client se conencte sur le client possesseur et effectue le DL puis transmet une requette au serveur de conenction sur le fait qu'il possede une partie de plus. Cette information est directement traite par le serveur ou transmise par le server aux autre serveurs pour mettre a jour les données sur le "bon serveur".

[Clorish]

Le problemes des "projets" c'est qu'ils ont un interet que si il exploitent les competences enseignés. Le theme est un pretexte a l'exploitation de ces competences, tout en attirant un max d'attention de l'eleve.
Le but recherché n'est donc pas forcement une exploitation optimale du theme entrainant parfois des "incoherences" pour arriver a cibler un max de competences

Donc de ce que j'ai compris je peut te proposer quelques pistes :

- Un fichier est defini par un ensemble de données : Nom, nombre de partie, taille des parties, liste des parties, liste des adresses ip cliente qui possede une partie (et son numero), etc ... a toi de defini le ou les classes imbriquées la dedans.
- Le serveur possede 1 listes de fichiers dont on viens de definir le type juste au dessus et N autres listes correspondant aux autres serveur.
- Chacunes des listes externes possede une info supplementaire : L'ip du serveur auquel il est rattaché. D'ailleur peut etre vaut il mieux creer une classe "ServerInfo" qui receuille les infos d'un serveur externe, qui possede une liste de fichiers.
- Les serveurs sont interconnecté entre eux via une liste d'adresse ip defini par serveurs. Un serveur peut donc etablir une connection sur un autre serveur en parcourant sa liste d'IP et recuperer via une requette la liste des fichiers qu'il heberge.
Note : Un serveur n'est pas ainsi pas obligé de connaitre TOUS les autresserveur ... ca permet de "herarchiser" ou "confiner" les acces aux telechargements ... rechechi un peu a ce que l'on peut en faire
- periodiquement ou sur commande ou au lancement du serveur, le serveur se met a jour en recuperant la liste des ficheir des autres serveur connu de lui.

Voila qui devrais deja permettre de maintenir sur chaque server une liste exausthive des fichiers partage sur le reseau, ainsi que les couples partie/CLient.

LE client :
- LE client lui n'etablit une conenction et effectue une requete que sur UN seul serveur. PArcourir la liste des serverus connu pour effectuer des recherches n'est pas une bonne idee car ca sous entends uen succession de connections/deconnection .. c'ets bof
De plus le systme de gestion des fichiers du serveur permet de "simuler" une requette sur els autres serveurs en parcourant la (les) liste des fichiers "externes".
- Le client possede une lsite des serveurs poru choisir son serveru de connection. Avec le systeme de hierarchisation des serveur amoecé plus haut, cela lui permet d'acceder a des ressources plus ou moins elargies.
Une mise a jour de sa liste des serveurs peut etre faite par simple requete sur le server qui lui envoie sa propre liste.
- Le client qui effectue une requette fichier, la fait sur son serveur de connection. Une lsite de couples "parts/IP" est genere sur le serveur a partir de des donnees contenue dans sa propre liste ou celles des fichiers externes.
la liste est ensuite transmise au client trié ou non. J'entends par "tri" une selection des IP en cas de doubons sur les numeros de partie. ce tri peut etre fait par rapidite, temps de connection online, etat Onlin/offline etc ...
Il peut etre gere par le client qui lance simultanement plusieurs DL et ferme ceux qui sont trop lent.
-Des que le client recoit une partie, ses infos sont envoyés sur le serveur qui met a jour sa liste ou sert de relais vers le serveur qui l'heberge. l'info est donc mise a jour dans ses liste ET repercute sur les autres serveur pour qu'ils se mettent a jour aussi.
Astuce : on peut fusonner les 2 listes interne et externe ensemble pour n'effectuer qu'une boucle. Un champs supplementaire est specifie pour la classe "ficheir" : l'ip du serveur. Bien sur on mettra "localhost" si c'est un fichier herberge sur ce serveur ....
-Si un fichier ajoute un fichier en partage : le fichier est decoupé, et on utilise les memes requettes qu'apres un telechargment. Nuance : Si aucun fichier n'est trouvé, alors on ajoute une entree dans la lsite des fichiers du serveur (effectuee si la boucle sur la liste fichier ne trouve pas de fichier correspondant, la creation se fera sur la requette de la msie a jour de la premiere partie, les autres trouverons l'entree qui a deja ete cre par la premiere partie).
- Si un client supprime un fichier (ou des parties) une requette est envoyé au serveur et effectue le meme traitement que l'ajout .... mais en suppression. Logique

Voila pour la theorie. Je suis dispo pour la faire evoluer si besoin, corriger ou detailler
Pour ce qui est du codage ... je n'ai pas encore toutes les competences et tu trouveras mieux aupres d'autres personnes ... ou dans tes cours

bon courrage !!