Programmation TCP

Prélude

Vous devez rendre tout ce que vous avez obtenu pendant le TP, sur arche

Vous pouvez le finir chez vous, ou le rendre à la fin du TP.

Exercice 1

Ecrire :

  • un client TCP client8 qui envoie deux entiers au serveur, sous la forme d’un seul send de 8 octets, et qui récupérera la somme
  • un serveur TCP server8 qui récupère les deux entiers avec un seul recv(8), en fait la somme, et la renvoie au client.
  • un client TCP client4 qui fait la même chose, mais qui envoie les deux entiers avec deux send de 4 octets.
  • un serveur TCP server4 qui récupère les deux entiers avec deux recv(4), en fait la somme, et la renvoie au client.

On veillera à bien gérer les erreurs.

PREMIER RENDU: Les quatre fichiers client8.py, server8.py, client4.py, server4.py et deux captures wireshark, une montrant client8 et server8 qui communiquent, et une montrant client4 et server4 qui communiquent.

Exercice 2

On rappelle que TP est un protocole en mode flux et non pas message. Quand on demande l’envoi de 8 octets comme dans client8, il est possible que cet envoi se fasse en 3 messages de 2,3, et 3 octets par exemple.

Pour cet exercice, on part de l’hypothèse que:

  • client8 a envoyé les 8 octets en un seul message, qui est bien reçu par le serveur
  • client4 a envoyé les 8 octets en deux messages de 4 octets, qui sont bien reçus par le serveur

Il faut répondre aux questions de cet exercice dans un fichier README.md

  • Au vu des captures wireshark réalisées précédemment, est-ce que l’hypothèse est bien vérifiée ?

  • Est-ce que client8.py est compatible avec server4.py ? Justifier. (Attention: ce n’est pas parce que tout a fonctionné correctement quand vous lancez l’expérience que les programmes sont compatibles. Vous avez peut-être eu de la chance).

  • Est-ce que client4.py est compatible avec server8.py ? Justifier.

DEUXIEME RENDU: Un fichier README.md

Exercice 3

  • Dupliquer les 4 fichiers client4, server4, client8, server8 en newclient4, newserver4, newclient8, newserver8.

  • Créer un fichier functions.py

  • L’instruction recv(n) signifie “recevoir au maximum n octets”. Ecrire dans le fichier functions.py une fonction really_recv(s, n) qui prend en argument une socket et un entier n et qui reçoit exactement n octets, en appellant éventuellement plusieurs fois recv si on en a pas assez la première fois. Faites attention au cas où la fonction recv renvoie 0 octets (ce qui signifie que la connection est fermée)

  • L’instruction send(message) renvoie un entier qui est le nombre d’octets réellement envoyés. Il peut être inférieur à la taille complète du message, si jamais TCP n’a pas réussi à tout envoyer. Ecrire dans le fichier functions.py une fonction really_send(s,message) qui prend en argument une socket et un message et qui envoie tout le message, en appellant éventuellement plusieurs fois send si nécessaire.

  • Modifiez les fichiers newclient4, newserver4, newclient8, newserver8 pour qu’ils utilisent ces nouvelles commandes.

  • Est-ce que newclient4.py est compatible avec newserver8.py ? Justifier.

  • Est-ce que newclient8.py est compatible avec newserver4.py ? Justifier.

TROISIEME RENDU: Les 5 nouveaux fichiers et la réponse aux questions dans un fichier README

Exercice 4

  • Dupliquer les 2 fichiers newclient4, newserver4 en finalclient4 et finalserver4

  • Modifier le client pour qu’il commence d’abord par se connecter, puis demande premier entier, puis l’envoie, puis demande le deuxième entier et l’envoie (il est possible que vous n’ayez rien à modifier)

  • Ajouter un while True au serveur pour qu’il puisse gérer plusieurs clients consécutivement.

  • Essayez d’appuyer à plusieurs moments sur ctrl-C pendant l’exécution du client. Notez ce qui se passe niveau serveur. Arrangez vous pour que :

    • Le serveur ne plante jamais
    • Le serveur n’envoie rien au client si celui-ci a planté.

QUATRIEME RENDU: Les 2 nouveaux fichiers et une explication des comportements observés et comment ils ont été pris en compte dans le serveur