La programmation réseau en Python

J’ai commencé à détailler le fonctionnement des sockets en mode DGRAM.

Ça fait un peu spam toutes ces mises à jour de la bêta… mais bon, au moins ça montre que le tuto est vivant !

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Salut, je suis en train de lire tout ça et j’aime beaucoup l’approche. Il y a un mot qui a disparu dans la partie où tu parles de bind()

Pour les sockets UDP, un peu c’est pareil. L’un interlocuteurs

Je repasse si je vois autre chose ou si j’ai des remarques.

Premiers chapitres vraiment lourds/denses avant la première expérimentation J’ai donc relu les deux premiers chapitres. Je trouve les explications claires et les choses bien ficelées. Par contre, le tout est vraiment dense.

En page précédente, je vantais ton choix de commencer par le concept de protocole. Mais je trouve maintenant que le premier exemple de code tarde à arriver. Il faut vraiment bouffer beaucoup de texte avant de commencer à expérimenter.

En parlant d’exemples de codes, l’affichage des codes côte à côte dans le chapitre 2 est vraiment bof. Ça rend mal et c’est difficilement sélectionnable. Est-il réellement nécessaire de les afficher en parallèle ?

Pour le côté dense, c’est pas faux !

Il faudrait peut-être que je rebatte les cartes pour être moins académique. Je ne pense pas qu’il y ait des choses à refaire entièrement, mais peut-être que je peux diffuser le monticule d’explications théoriques dans plusieurs chapitres et commencer les premiers exemples de code dès le premier chapitre.

D’ailleurs c’est pas parce que la notion de protocole est importante que je suis pour autant obligé de m’attarder autant dessus dès le chapitre 1. Pareil pour le modèle IP.

Je vais voir ce que je peux faire.

Pour l’exemple côte à côte également.

Ok j’ai une idée : pourquoi ne pas reorganiser les premiers chapitres comme ça ?

• chapitre 1 :

  • "des programmes qui communiquent entre eux"
  • echo-server (sockets en mode dgram)
  • "suivez le protocole !"

• chapitre 2 :

  • introduction du premier projet : un serveur TFTP
  • parseur de paquets TFTP
  • la machine à états du protocole

• chapitre 3 (élargir la vue):

  • "le modèle internet"
  • sockets en mode connecté (stream)

• chapitre 4 :

  • introduction du second projet (serveur HTTP)
  • implémentation basée sur des sockets

• chapitre 5 :

  • reprise de l’exemple précédent avec socketserver
  • puis introduction du module http.server

Bon j’ai commencé à réorganiser les chapitres en suivant le plan ci-dessus. Il va falloir que je me fasse une passe sur les transitions entre les divers chapitres et sections avant de vous montrer le résultat en bêta.

Je pense que ça peut être pas mal, ça évitera d’inonder le lecteur de nouvelles notions dès le début.

Je pense aussi que c’est un bon moyen de mettre l’accent sur la notion de protocole :

• Chapitre 1: le lecteur a joué un peu avec des sockets udp, il sait strictement tout ce qu’il y a à savoir sur les sockets pour implémenter un serveur TFTP.
• Chapitre 2: le lecteur découvre la réalité d’une application réseau : manipuler le socket, c’est à peine 10% du boulot. La vraie problématique étant le parseur et la state machine.

Et tout ça sans avoir besoin de faire un long discours préliminaire dessus. En fait, le lecteur n’a même pas encore touché à un socket TCP qu’il a déjà une image plus réaliste et plus complète du domaine qu’après, au hasard, ce chapitre du tuto python du site orange.

C’est ça qui me plait dans ce nouveau plan : il correspond bien plus à ce que je voulais faire à la base.

J’ai fini la partie sur le format de données du protocole TFTP. Reste à expliquer l’implémentation du client et du serveur.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Merci pour le contenu.

J’aime bien ce nouveau plan. Par contre, je me demande un peu quels sont les pré-requis et les objectifs du cours. Dès le départ, tu fais appel à des notions de réseau (protocole, TCP, UDP, interface…), donc on ignore un peu ce que le lecteur est censé savoir. J’imagine que tu vas compléter l’introduction, mais il peut être intéressant d’expliciter le contexte pour les relecteurs.

Ce type de connexion possède un certain nombre d’avantages2 par rapport aux sockets Internet classiques

Un socket Internet, c’est un socket de famille AF_INET[6] ?

Sur les sockets Internet, ce mode correspond à une transmission de données selon le protocole UDP.

Je ne saurais pas expliquer pourquoi, mais j’ai buté sur le "selon". Je pense que c’est lié à ma question précédente, c’est-à-dire au fait que je n’avais pas intégré qu’un socket Internet utilisait le protocole IP.

Au niveau du schéma Client-serveur en mode non-connecté, tu termines le client par un close(), sans que ça n’apparaisse nulle part dans le code. Il me semble préférable de l’enlever, surtout que cette instruction aura une signification particulière pour les connexions TCP.

Sur la fin, tu communiques avec toi-même (localhost). Ne penses-tu pas que cela pourrait perturber des débutants en réseau ? On en revient un peu à la question des pré-requis.

Merci.

Le problème c’est que toutes les explications sur la notion de protocole et les divers protocoles courants (TCP, IP, etc.) se trouvaient initialement dans le chapitre 1, et que je me suis contenté de déplacer les deux sections sur les sockets du chapitre 2 vers le premier. Il faudra surement que je refasse une passe pour adoucir le contenu du chapitre 1 lorsque j’aurai fini les deux premiers chapitres.

Pour le close() sur le socket UDP, il est rendu implicite dans l’exemple par le with. Comme pour un fichier. Il faut fermer les sockets, sinon tu crées une fuite de fd.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

>>> import psutil
>>> p = psutil.Process()
>>> p.num_fds()
8
>>> from socket import socket, AF_INET, SOCK_DGRAM
>>> s = socket(AF_INET, SOCK_DGRAM)
>>> p.num_fds()
9
>>> s.close()
>>> p.num_fds()
8

PS : oui un socket internet c’est un socket de la famille INET ou INET6 (INET est un raccourcis pour "Internet").

Après non je ne crois pas que ce soit un problème de mentionner le terme de protocole, TCP ou IP avant que ces notions soient introduites en détail. Le pre-requis sur ce cours c’est de vivre sur Terre : tout le monde a entendu parler d’adresses IP. Au moment où j’en parle pour la première fois, ça va passer au dessus de la tête de certains lecteurs et parler à d’autres : c’est pas grave, l’important dans ce chapitre c’est de s’envoyer des données sur un socket. La pile TCP/IP et la réalité du réseau, ça n’a d’importance que plus loin, au moment où je fais le rappel.

Sur la fin, tu communiques avec toi-même (localhost). Ne penses-tu pas que cela pourrait perturber des débutants en réseau ? On en revient un peu à la question des pré-requis.

Cette question est cool, elle montre un truc que je ne rends pas assez explicite. Ce n’est pas parce que je me connecte à 127.0.0.1 que je me connecte à moi-même. L’adresse d’un service n’est pas qu’une adresse IP, mais une adresse IP + un port.

L’adresse IP ne sert (grossièrement) qu’à désigner un hôte. Mais tu peux avoir des tas de services derrière cet hôte, chacun sur un port différent.

Pire, hôte != machine. Si je me connecte à un service sur Internet, l’adresse IP sera généralement celle d’une gateway, qui va rediriger le flux de tel port vers telle IP+port sur son réseau local.

Bref, à partir du moment où on comprend qu’une adresse forme un tout, que le serveur soit hébergé sur la même machine ou non n’a aucune espèce d’importance.

Il faut que j’arrive à traduire ça dans le cours.

Pour illustrer cela, tu pourrais divaguer avec un conteneur ou une machine virtuelle, de façon à avoir un hôte avec une adresse IP différente.

Mais ça fait quelque chose d’un peu lourd à mettre en place juste pour ça.

Oui j’y avais pensé, mais il y a déjà tellement de choses à expliquer dans le cours que je préfère garder ça pour une annexe ou un tuto indépendant.

Au fil de la rédaction je me rends compte qu’il y a un monticule de micro-détails qu’on ne retrouve qu’en programmation réseau, comme le masquage des bits, le module struct, les bytes (plus tard les memoryview)… Du coup je préfère mettre l’accent sur ces notions python au moins au départ.

Un futur article dans les cartons sur scapy / wireshark ?

Après non je ne crois pas que ce soit un problème de mentionner le terme de protocole, TCP ou IP avant que ces notions soient introduites en détail. Le pre-requis sur ce cours c’est de vivre sur Terre : tout le monde a entendu parler d’adresses IP. Au moment où j’en parle pour la première fois, ça va passer au dessus de la tête de certains lecteurs et parler à d’autres : c’est pas grave, l’important dans ce chapitre c’est de s’envoyer des données sur un socket. La pile TCP/IP et la réalité du réseau, ça n’a d’importance que plus loin, au moment où je fais le rappel.

Je souhaitais juste revenir là-dessus, parce que c’est une question que je me pose régulièrement. Si tu ne précises pas que le lecteur peut se permettre de passer sur ces notions sans les comprendre, ne risques-tu pas de provoquer une des deux situations suivantes ?

• Le lecteur n’a pas l’habitude d’apprendre en autodidacte, il se dit que s’il ne comprend pas des termes dans la première section, qui n’aborde que les bases, il va être perdu par la suite, donc que le tutoriel n’est pas fait pour lui.
• Le lecteur a l’habitude de faire des recherches par lui-même et va donc se documenter sur TCP, UDP, IPv6… Il tombe alors sur le modèle OSI et d’autres notions de réseau théoriques, ce que tu souhaites je crois éviter vu que tu as déplacé ce contenu plus loin dans le tutoriel.

Tu as dit que tu allais probablement repasser sur le premier chapitre donc peut-être que ces remarques n’ont plus lieu d’être, mais c’est juste une question que je me pose en général donc je poste quand même.

Pour illustrer mes propos, j’ai bien aimé l’approche adoptée ici :

C’est hors sujet par rapport à ce tuto.

@Vayel: Je vois ce que tu veux dire. Je vais essayer d’arranger ça.

Je pense également que la partie 2 qui est actuellement prévue dans le plan va purement et simplement sortir de ce tuto. En discutant avec Kje, on s’est dit que asyncio pouvait intéresser des gens qui connaissaient déjà la programmation réseau, donc que ce serait plus impactant si on était capables de prendre ces gens en cours de route (en faisant un tuto dédié vers lequel on pourra renvoyer à la fin de celui-ci).