:: Enseignements :: Master :: M1 :: 2014-2015 :: Programmation d'applications réseaux ::
![[LOGO]](http://igm.univ-mlv.fr/ens/resources/mlv.png) |
TCP non bloquant
|
Exercice 1 - Mini additionneur TCP non bloquant
On souhaite écrire un serveur qui accepte de
multiples clients en non-bloquant et permet d'effectuer l'addition
de deux entiers pour chaque client.
Plus précisément, le client envoie deux int en Big Endian, puis ferme la
connexion en écriture. Le serveur renvoie un int en Big Endian, valant
la somme des deux entiers reçus, puis il ferme la connexion. Par exemple, si le
client envoie 7 et 10, le serveur renverra 17.
Pour simplifier, on vous donne le code du client, qui demande 2 entiers
au clavier, les envoie au serveur et attend la réponse du serveur.
-
Écrire le code du serveur ServerSumOneShot non bloquant. Il n'est pas nécessaire de vérifier
si le client a bien fermé la connexion après l'envoi des deux int.
Pour vous aider, vous pouvez utiliser le code suivant comme point de départ.
Pour cet exercice, vous stockerez dans le champ attachement un
ByteBuffer de taille 8.
Que se produirait-il si, au moment d'écrire la somme vers un client,
le serveur ne pouvait écrire que 2 des 4 octets lors d'une tentative
d'écriture non bloquante? Même s'il est improbable dans notre exemple,
prévoyez ce cas dans votre code.
Comment faut-il traiter les exceptions levées dans les méthodes doRead, doWrite et doAccept ?
-
Modifier le client pour qu'il continue (en boucle) à envoyer des
opérandes et à recevoir des résultats.
Adapter votre serveur en un serveur ServerSumMulti pour qu'il puisse traiter une succession de somme.
Exercice 2 - Serveur Echo
Ecrivez un serveur Echo en non-bloquant. Le serveur ServerEcho renvoie tous les octets écrits par le client. Il ferme la connection après que le client est fermé la connection (et après que toutes les données ont été envoyés).
Pour ce serveur, vous utiliserez en attachment une classe contenant un boolean et un ByteBuffer. Le boolean servira à mémoriser si le client a fermé la connection.
Une fois que votre serveur semble fonctionner, testez le avec le
client ci-dessous, qui envoie en boucle l'octet 1 puis l'octet 2 et dans un
autre thread affiche le numéro des octets recus.
L'intérêt de ce client est qu'il lit "lentement" et donc, à terme, ralentit
le rythme d'écriture du serveur (à cause du contrôle de flot effectué par TCP).
Ainsi, en consultant (par la commande top en linux) les ressources CPU
utilisées par votre serveur, vous devrez constater qu'elles sont très limitées.
Si le serveur consomme beaucoup de CPU, c'est par exemple parce qu'il tente d'écrire
alors que ce n'est pas possible (il fait alors une forme d'attente active): le principe
des entrées sorties non bloquantes est précisément d'éviter ces comportements.
Exercice 3 - Tuer les clients inactifs
Lorsque un client a été accepté par le serveur mais qu'il n'est plus actif
depuis une durée jugée suffisante (TIMEOUT) on aimerait que le serveur mette fin
à cette connexion. Faites évoluer votre serveur Echo non bloquant pour qu'il implémente
cette fonctionnalité.
Exercice 4 - Duplicateur
On souhaite écrire un serveur TCP non bloquant qui rend le service suivant:
pour chaque client accepté, sur le flot de lecture, lorsque 2 octets
consécutifs ont des valeurs croissantes qui se suivent (comme par exemple
65 et 66), alors le serveur renvoie au client le premier de ces deux octets.
Par exemple:
Si le serveur reçoit : 68 65 67 68 65 65 66 67 67 68 69 70 71 65
alors il renvoit : 67 65 66 67 68 69 70
Pour ce serveur, vous utiliserez comme attachment une classe
contenant deux ByteBuffer pour in et out.
Dans un premier temps, vous pouvez tester votre serveur avec
nc. Par
exemple si votre serveur est lancé sur le port 7778. Vous devriez observer:
$ nc localhost 7778
ABBBCABBCDE^D
ABABCD
Une fois que votre serveur semble fonctionner, testez le avec le
client ci-dessous, qui envoie en boucle l'octet 1 puis l'octet 2 et dans un
autre thread affiche le numéro des octets recus.
Outre le fait que le client ne doit recevoir que des octets 1 et en permanence,
l'intérêt de ce client est qu'il lit "lentement" et donc, à terme, ralentit
le rythme d'écriture du serveur (à cause du contrôle de flot effectué par TCP).
Ainsi, en consultant (par la commande top en linux) les ressources CPU
utilisées par votre serveur, vous devrez constater qu'elles sont très limitées.
Si le serveur consomme beaucoup de CPU, c'est par exemple parce qu'il tente d'écrire
alors que ce n'est pas possible (il fait alors une forme d'attente active): le principe
des entrées sorties non bloquantes est précisément d'éviter ces comportements.
Exercice 5 - Serveur Long Sum
Ecrivez un serveur non-bloquant pour le protocole long somme de longs que nous avons vu dans les TPs précédents. Le client envoie un INT avec le nombre d'opérandes puis chacunes des opérandes qui sont des LONGs. Le serveur renvoie
la somme de toutes les opérandes recues.
© Université de Marne-la-Vallée