:: Enseignements :: ESIPE :: E4INFO :: 2010-2011 :: Applications réseaux ::
![[LOGO]](http://igm.univ-mlv.fr/ens/resources/mlv.png) |
Multicast et TCP
|
Exercice 1 - Forum de discussion Multicast
En utilisant une socket de multicast UDP, écrire une petite
application qui envoie sur un port donné d'un groupe de multicast,
correspondant à une adresse IP donnée, tout ce qui est écrit sur la ligne
de commande. L'application affichera
sur la ligne de commande tout ce qui est reçu sur ce groupe de multicast
à destination de ce port (il vous faut donc 2 threads).
En utilisant tous ce même numéro de port et la même adresse IP,
vous pouvez obtenir une version basique d'un forum de discussion.
Attention à choisir une
adresse
et un
port libres
Exercice 2 - TCP Longue Somme de Long
On souhaite mettre en place une calculette permettant à un client
de demander le résultat de la somme de plusieurs nombres (long sur 64 bits).
Le client doit envoyer chaque opérande un par un en binaire dans la convention "network order"
(i.e. big endian -- l'octet de poids fort est enregistré à l'adresse mémoire la plus petite).
Le résultat est renvoyé par le serveur à reception d'une opérande nulle (i.e. 0) du client.
- Est on obligé, comme en UDP, de prévoir le cas où les opérandes de
plusieurs clients différents arriveraient entrelacés sur le serveur? Pourquoi?
- Qu'arrive-t-il à un second client qui cherche à utiliser le service
alors que le client précédent n'a pas fini de l'utiliser?
- Proposez une implémentation qui permette de servir plusieurs clients
simltanément.
Exercice 3 - Serveur de mise en majuscules
Écrire un programme,
UpperCaseTCPServer, implantant un serveur
TCP itératif renvoyant les chaînes de caractères envoyées au format
"ISO8859-1" par des clients après les avoir mis en majuscules.
Ce serveur crée une socket serveur (objet de la classe
java.net.ServerSocket),
puis est "démarré". Il attend alors une connexion d'un client, via la méthode
accept()
appelée sur l'objet
ServerSocket.
Lorsque des clients contactent le serveur, l'une des
connexions correspondantes est élue par la méthode
accept(),
qui retourne un objet de la classe
Socket.
Celle-ci est alors dite socket de service. Le serveur peut ainsi satisfaire
la ou les requêtes successives émises par le client sur la socket de service.
Puisque notre serveur est itératif, lorsque les différentes requêtes de ce client
sont traitées, la socket de service peut être fermée, et une nouvelle
connexion pendante peut être élue comme
socket de service par un appel à
accept()
sur l'objet
ServerSocket.
Le principe du serveur
UpperCaseTCPServer, pour le traitement des
requêtes d'une socket de service qu'il vient d'accepter, est le suivant :
-
Envoyer au client un message de bienvenue.
-
Les données doivent être envoyées ligne par ligne, et une
ligne contenant uniquement '.' termine la session.
Pour chaque ligne reçue par le client, le serveur la met en majuscules et la
renvoie au client.
-
Une ligne contenant uniquement '.' entraîne la fermeture la socket.
-
Si la connexion reste trop longtemps ouverte sans activité, elle est fermée par le
serveur en utilisant un setSoTimeout() sur la socket de service.
À son lancement, le serveur affiche son adresse et son numéro de port d'attachement
local, afin que les clients puissent accéder à son service.
Exercice 4 - Proxy
Écrire une application Proxy qui permet de relayer entre un client et un serveur
toutes les données transitant sur une connexion TCP. Le proxy est lancé sur
une machine ProxyMachine en fournissant un numéro de port local
(ProxyPort) ainsi que l'adresse de la socket distante du serveur
auquel il doit relayer les données
(RemoteMachine:RemotePort).
Lorsque ProxyMachine reçoit sur son port ProxyPort
une demande de connexion depuis un client, elle accepte cette connexion et
doit à son tour demander l'établissement d'une connexion entre elle-même et
le port RemotePort de
RemoteMachine.
Une fois ces deux connexions établies, le proxy crée et démarre deux
processus légers chargés de relayer les informations circulant, d'une part, entre le client
et la machine distante et, d'autre part, entre la machine distante et le client.
© Université de Marne-la-Vallée