Cours du 30 avril 2014, 8:30-10:20

Démonstration de communication via l’interface réflexive entre deux instances de netcat.

Liste des interfaces réseau déployées sur la machine DevPangolin, obtenue par l’exécution de ifconfig.

Démonstration de communication via l’interface Ethernet entre deux instances de netcat exécutées sur la même machine.

Le port 80 est privilégié, on ne peut y connecter netcat à moins d’être root.

Interface des sockets: le client se connecte.

Petit protocole de communication très simple, côté client.

Le serveur a planté à la ligne 8, car il n’a pas récupéré les objets en retour de <socket>.accept() correctement. Il plante donc au moment de recevoir, de sorte que le client se fait déconnecter avec l’exception Connection reset by peer.

Si on termine un serveur de manière malpropre et qu’il ne ferme pas son socket d’écoute correctement, le noyau du système d’exploitation retient ce socket comme en usage pendant un moment. On ne peut pas alors attacher un autre serveur au même port pour environ 60 secondes. On résout ceci en réglant l’option du socket d’écoute SO_REUSEADDR à 1…

… comme ceci. On voit aussi le reste du code du serveur. Ceci complétait le tutoriel de base sur les sockets.

Cours du 1er mai 2014, 8:30-10:20

netcat “traditionnel” vs. netcat OpenBSD, ou pourquoi j’ai eu des problèmes durant la démo de la veille.

Routines de sérialisation, d’envoi et de réception des messages pour le système de messagerie instantanée.

Implantation suffisante du serveur pour accueillir les clients.

Multiplexage de l’attente des nouveaux clients et des nouveaux messages des clients connectés à l’aide de select.

Squelette du client. Échoue car il n’envoie pas de message de connexion au serveur de manière à assumer une identité.

Début de la séance de déboguage du client à l’aide de pdb.

Suite et fin de la séance de déboguage du client.

Code

• msgs.py
• serveur.py
• client.py

Quatre problèmes encore à régler avec cette application

1. Le client reçoit ses propres échos – est-ce convenable?
2. Le client doit lire l’entrée standard et attendre les échos du serveur en même temps.
3. Le client doit se déconnecter plus élégamment, en propageant la fermeture de l’entrée standard (stdin) au socket.
4. Le serveur se casse vraisemblablement le nez lorsqu’un client se déconnecte: il faut qu’il gère ce cas en douceur, en éliminant le client déconnecté de sa table.

Cours du 7 mai 2014, 8:30-10:20

Rappel du problème de déconnexion: lorsqu’un client brise la connexion avec le serveur, cela l’envoie dans une boucle infinie.

Client: traitement simultané de la connexion au serveur et de l’entrée standard, grâce au module select.

Client: interception de la fin de l’entrée standard pour fermer la connexion au serveur et quitter.

Serveur: mise en place du débogueur pour en comprendre le comportement lorsqu’un client se déconnecte.

Serveur: trace du module msgs.py sur réception d’un honnête message.

Mise en oeuvre de la détection d’une connexion coupée sur le serveur via une modification de msgs.py.

Code du serveur modifié pour gérer correctement les déconnexions des clients.

Client modifié pour bien gérer le cas où le serveur brise lui-même la connexion.

Test du client et du serveur dûment modifiés pour bien gérer les déconnexions.

Debut de l’implantation du support pour les groupes de discussion dans le serveur.

Client supportant toutes les fonctionnalités des groupes de discussion.

Code

• msgs.py
• serveur.py
• client.py