Mécanisme pour l’étape 5 #42

Update protocol.md
Impl. protocol elements
Update tracker
Update client
Update server
Décrire le fonctionnement des ratios dans la documentation

- [x] Update protocol.md - [x] Impl. protocol elements - [x] Update tracker - [x] Update client - [x] Update server - [x] Décrire le fonctionnement des ratios dans la documentation

Je propose un mécanisme de ratio (d'abord sur chaque fichier servi, on verras pour un global après), 1 etant le serveur a envoyé le fichier en entier, mais peux continuer d'envoyer.

Le client télécharge déja les mêmes quantités partout.

Le tracker pourrais recupérer les ratios des clients/serveurs et commencer par avertir les autres serveurs, on verras ensuite comment les pénaliser (peut etre avec des wait)

Je propose un mécanisme de ratio (d'abord sur chaque fichier servi, on verras pour un global après), 1 etant le serveur a envoyé le fichier en entier, mais peux continuer d'envoyer. Le client télécharge déja les mêmes quantités partout. Le tracker pourrais recupérer les ratios des clients/serveurs et commencer par avertir les autres serveurs, on verras ensuite comment les pénaliser (peut etre avec des wait)

À ajouter au protocole

RATIO REQUEST

prend en paramètres:

port (2 bytes)
hostname
réponse: RATIO RESPONSE ou UNKNOWN HOST

RATIO RESPONSE

prend en paramètres:

port (2 bytes)
hostname suivi de \n
bytes total envoyés (8 bytes)
bytes total reçus (8 bytes)

UPDATE RATIO

prend en paramètres:

port du serveur(2 bytes)
port du client(2 bytes) [note: celui qui a été utilisé par le client pour s’enregistrer sur le tracker]
hostname du serveur suivi de \n
hostname du client suivi de \n [note: celui qui est utilisé par le client pour s’enregistrer sur le tracker]
bytes envoyés par le serveur (8 bytes)

réponse: Pas de réponse ou UNKNOWN HOST (si le client n’est pas enregistré ou que le serveur n’est pas enregistré).

UNKNOWN HOST

pas de paramètre, il s’agit d’un code d’erreur

DENIED (erreur seulement pour les LOAD REQUESTS)

paramètres:

filename
offset

À modifier dans le protocole

LOAD REQUEST

ajouter:

port utilisé par le client [note: celui qui fait la LOAD REQUEST] pour s’enregistrer sur le tracker
addresse utilisée par le client [note: celui qui fait la LOAD REQUEST] pour s’enregistrer sur le tracker
possiblité de répondre DENIED (si le client n’a pas un bon ratio ou n’est pas connu du tracker)

Notes

La gestion des ratio est séparée pour les instances UDP et TCP.
Il est nécessaire que le serveur cache pendant un instant les ratio des clients pour éviter des requêtes en boucle au tracker.
Le client doit attendre d’avoir téléchargé la totalité du fichier et vérifié le hash avant d’envoyer pour chaque serveur qui a participé la UPDATE RATIO au tracker. Il est donc nécessaire de tenir à jour une liste.

# À ajouter au protocole ## RATIO REQUEST prend en paramètres: - port (2 bytes) - hostname réponse: RATIO RESPONSE ou UNKNOWN HOST ## RATIO RESPONSE prend en paramètres: - port (2 bytes) - hostname suivi de `\n` - bytes total envoyés (8 bytes) - bytes total reçus (8 bytes) ## UPDATE RATIO prend en paramètres: - port du serveur(2 bytes) - port du client(2 bytes) [note: celui qui a été utilisé par le client pour s’enregistrer sur le tracker] - hostname du serveur suivi de `\n` - hostname du client suivi de `\n` [note: celui qui est utilisé par le client pour s’enregistrer sur le tracker] - bytes envoyés par le serveur (8 bytes) réponse: Pas de réponse ou UNKNOWN HOST (si le client n’est pas enregistré ou que le serveur n’est pas enregistré). ## UNKNOWN HOST pas de paramètre, il s’agit d’un code d’erreur ## DENIED (erreur seulement pour les LOAD REQUESTS) paramètres: - filename - offset # À modifier dans le protocole ## LOAD REQUEST ajouter: - port utilisé par le client [note: celui qui fait la LOAD REQUEST] pour s’enregistrer sur le tracker - addresse utilisée par le client [note: celui qui fait la LOAD REQUEST] pour s’enregistrer sur le tracker - possiblité de répondre DENIED (si le client n’a pas un bon ratio ou n’est pas connu du tracker) # Notes - La gestion des ratio est séparée pour les instances UDP et TCP. - Il est nécessaire que le serveur cache pendant un instant les ratio des clients pour éviter des requêtes en boucle au tracker. - Le client doit attendre d’avoir téléchargé la totalité du fichier et vérifié le hash avant d’envoyer pour chaque serveur qui a participé la UPDATE RATIO au tracker. Il est donc nécessaire de tenir à jour une liste.

Le serveur interroge régulièrement le tracker pour connaitre le ratio et décider si il peut servir ou doit punir en refusant aléatoirement le téléchargement d’un bloc selon le ratio (comme le prof a répondu ici).

Pour la « punition » je propose l’algo suivant :

assert punishmentFactor > 1 : "The punishment factor must be greater than 1";
if ((punishmentFactor * ratio.uploaded) >= ratio.downloaded) {
	rejectProb = 0
} else {
	rejectProb = (ratio.downloaded - ratio.uploaded)/(ratio.downloaded * punishmentFactor)
}

Le serveur interroge régulièrement le tracker pour connaitre le ratio et décider si il peut servir ou doit punir en refusant aléatoirement le téléchargement d’un bloc selon le ratio ([comme le prof a répondu ici](https://stri-online.net/FTLV/mod/forum/discuss.php?d=213&parent=322)). Pour la « punition » je propose l’algo suivant : ```java assert punishmentFactor > 1 : "The punishment factor must be greater than 1"; if ((punishmentFactor * ratio.uploaded) >= ratio.downloaded) { rejectProb = 0 } else { rejectProb = (ratio.downloaded - ratio.uploaded)/(ratio.downloaded * punishmentFactor) } ```

Labels Milestones

Mécanisme pour l’étape 5 #42

À ajouter au protocole

RATIO REQUEST

RATIO RESPONSE

UPDATE RATIO

UNKNOWN HOST

DENIED (erreur seulement pour les LOAD REQUESTS)

À modifier dans le protocole

LOAD REQUEST

Notes