Programmation d'applications bis - Revision history

Eduble: /* Adaptation du serveur à un cas plus général */

2011-06-07T07:47:30Z

‎Adaptation du serveur à un cas plus général

Eduble: /* Adaptation du serveur à un cas plus général */

2011-06-07T07:43:53Z

‎Adaptation du serveur à un cas plus général

Eduble: /* Programmation indépendante de la famille d'adresses */

2011-06-07T07:29:57Z

‎Programmation indépendante de la famille d'adresses

Eduble: /* L'option IPV6_V6ONLY */

2011-06-07T07:26:22Z

‎L'option IPV6_V6ONLY

Eduble: /* Deux types de serveurs */

2011-06-07T07:22:31Z

‎Deux types de serveurs

Eduble: /* Deux types de serveurs */

2011-06-07T07:21:21Z

‎Deux types de serveurs

Eduble: /* Deux types de serveurs */

2011-06-07T07:11:41Z

‎Deux types de serveurs

Eduble: /* Deux types de serveurs */

2011-06-07T07:08:16Z

‎Deux types de serveurs

Panelli: /* Erreurs d'implémentation courantes */

2011-04-27T07:51:54Z

‎Erreurs d'implémentation courantes

Panelli: /* L'option IPV6_V6ONLY */

2011-04-27T07:51:10Z

‎L'option IPV6_V6ONLY

@@ Line 765: / Line 765: @@
 ** supprimer les lignes 53 à 57 et 59 à 63 de façon à ce que l'option <tt>IPV6_V6ONLY</tt> soit positionnée à 0
-(*) En fait cette adaptation n'est pas parfaite : si le serveur TCP est installé sur une machine ne gérant pas IPv6, il ne fonctionnera pas correctement. En comparaison, l'autre type de serveur (avec deux sockets) ouvrirait bien une socket IPv4. Pour éviter cette imperfection, il faudrait détecter que IPv6 n'est pas disponible au niveau noyau, en vérifiant au préalable qu'un appel à <tt>socket()</tt> avec la famille <tt>AF_INET6</tt> ne retourne pas un code d'erreur (on ne peut rien déduire du fait que <tt>getaddrinfo()</tt> renvoie ou non des adresses IPv6, voir la note à ce sujet en paragraphe ). Si c'est le cas on devra finalement faire l'appel à <tt>getaddrinfo()</tt> (en ligne 31) en précisant <tt>hints.ai_family = AF_INET</tt>.
+(*) En fait cette adaptation n'est pas parfaite : si le serveur TCP est installé sur une machine ne gérant pas IPv6, il ne fonctionnera pas correctement. En comparaison, l'autre type de serveur (avec deux sockets) ouvrirait bien une socket IPv4. Pour éviter cette imperfection, il faudrait détecter que IPv6 n'est pas disponible au niveau noyau. Attention, on ne peut rien déduire du fait que <tt>getaddrinfo()</tt> renvoie ou non des adresses IPv6, voir la note à ce sujet dans le paragraphe "Programmation sur un système double-pile". Par contre on peut simplement vérifier au préalable qu'un appel à <tt>socket()</tt> avec la famille <tt>AF_INET6</tt> ne retourne pas de code d'erreur. Si c'est le cas on devra finalement faire l'appel à <tt>getaddrinfo()</tt> (en ligne 31) en précisant <tt>hints.ai_family = AF_INET</tt>.
 ======Le fichier tools.c======

@@ Line 765: / Line 765: @@
 ** supprimer les lignes 53 à 57 et 59 à 63 de façon à ce que l'option <tt>IPV6_V6ONLY</tt> soit positionnée à 0
-(*) En fait cette adaptation n'est pas parfaite : si le serveur TCP est installé sur une machine ne gérant pas IPv6, il ne fonctionnera pas correctement. En comparaison, l'autre type de serveur (avec deux sockets) ouvrirait bien une socket IPv4. Pour éviter cette imperfection, on pourrait vérifier si l'appel <tt>getaddrinfo()</tt> (en ligne 31) renvoie au moins une adresse, et dans le cas contraire refaire un appel en précisant cette fois <tt>hints.ai_family = AF_INET</tt>.
+(*) En fait cette adaptation n'est pas parfaite : si le serveur TCP est installé sur une machine ne gérant pas IPv6, il ne fonctionnera pas correctement. En comparaison, l'autre type de serveur (avec deux sockets) ouvrirait bien une socket IPv4. Pour éviter cette imperfection, il faudrait détecter que IPv6 n'est pas disponible au niveau noyau, en vérifiant au préalable qu'un appel à <tt>socket()</tt> avec la famille <tt>AF_INET6</tt> ne retourne pas un code d'erreur (on ne peut rien déduire du fait que <tt>getaddrinfo()</tt> renvoie ou non des adresses IPv6, voir la note à ce sujet en paragraphe ). Si c'est le cas on devra finalement faire l'appel à <tt>getaddrinfo()</tt> (en ligne 31) en précisant <tt>hints.ai_family = AF_INET</tt>.
 ======Le fichier tools.c======

@@ Line 330: / Line 330: @@
 Cette manière de programmer est recommandée car le code associé est plus facile à maintenir. De plus, ''si le protocole doit à nouveau changer dans le futur, un code indépendant de la version de protocole ne nécessitera pas de nouvelle migration''.
-A l'inverse, le fait que les primitives <tt>inet_pton()</tt> et <tt>inet_ntop()</tt> ont un argument précisant la famille d'adresse rend généralement le code qui les utilise dépendant de la famille d'adresses (sauf si cette famille est obtenue dynamiquement, par exemple via un <tt>getaddrinfo()</tt>). ''Il est donc généralement préferable d'utiliser les fonctions <tt>getaddrinfo()</tt> et <tt>getnameinfo()</tt>'', avec le flag <tt>AI_NUMERICHOST</tt>, plutôt que <tt>inet_pton()</tt> et <tt>inet_ntop()</tt>.
+A l'inverse, le fait que les primitives <tt>inet_pton()</tt> et <tt>inet_ntop()</tt> ont un argument précisant la famille d'adresse rend généralement le code qui les utilise dépendant de la famille d'adresses (sauf si cette famille est obtenue dynamiquement, par exemple via un <tt>getaddrinfo()</tt>). ''Il est donc généralement préferable d'utiliser les fonctions <tt>getaddrinfo()</tt> et <tt>getnameinfo()</tt>'', avec les flags <tt>AI_NUMERICHOST</tt> et <tt>NI_NUMERICHOST</tt>, plutôt que <tt>inet_pton()</tt> et <tt>inet_ntop()</tt>.
 De même, on évitera dans la mesure du possible d'utiliser des structures spécifiques à IPv6 ou à IPv4.

@@ Line 320: / Line 320: @@
 Ces erreurs d'implémentations sont illustrées plus loin dans l'exemple de Client/Serveur TCP.
-Si l'option <tt>IPV6_V6ONLY</tt> n'est pas définie, la valeur par défaut dépend du système d'exploitation sur lequel le serveur est exécuté. Par exemple, sur Linux/*BSD la valeur par défaut est donnée (et modifiable) par <tt>sysctl net.ipv6.bindv6only</tt>. Ceci donne <tt>0</tt> par défaut sous Linux, et <tt>1</tt> sur *BSD...
+Si l'option <tt>IPV6_V6ONLY</tt> n'est pas définie, la valeur par défaut dépend du système d'exploitation sur lequel le serveur est exécuté. Par exemple, sur Linux/*BSD la valeur par défaut est donnée (et modifiable) par <tt>sysctl net.ipv6.bindv6only</tt>. Ceci donne <tt>0</tt> par défaut sous la plupart des distributions Linux, et <tt>1</tt> sur *BSD...
 En conséquence, '''un programme qui se veut portable doit explicitement donner une valeur à cette option'''.

@@ Line 300: / Line 300: @@
 Ce deuxième type de serveur peut paraître plus simple à réaliser que le précédent (pas besoin de l'étape <tt>select()</tt> car on n'a qu'une seule socket).
-Attention cependant, en toute rigueur, à penser aux systèmes qui ne gèrent pas IPv6 (par exemple si le module IPv6 n'est pas chargé) : en effet si on tente un appel à <tt>socket()</tt> avec la famille <tt>AF_INET6</tt> sur ce genre de système, on obtiendra une erreur ; or notre programme doit, à défaut d'accepter les clients IPv6, au moins accepter les clients IPv4. On doit donc détecter cette limitation (en tentant d'ouvrir une socket IPv6 au préalable), et, si on la rencontre, passer <tt>AF_INET</tt> à <tt>getaddrinfo()</tt> pour finalement tenter d'ouvrir une socket IPv4.
+Attention cependant, en toute rigueur, à penser aux systèmes qui ne gèrent pas IPv6 (par exemple si le module IPv6 n'est pas chargé) : en effet si on tente un appel à <tt>socket()</tt> avec la famille <tt>AF_INET6</tt> sur ce genre de système, on obtiendra une erreur ; or notre programme doit, à défaut d'accepter les clients IPv6, au moins accepter les clients IPv4. On doit donc détecter cette limitation (en tentant d'ouvrir une socket IPv6 au préalable), et, si on la rencontre, passer <tt>AF_INET</tt> à <tt>getaddrinfo()</tt> pour finalement ouvrir une socket IPv4.
 ====Les adresses IPv4 mappées====

@@ Line 470: / Line 470: @@
 Nous allons maintenant observer les deux cas d'erreur d'implémentation courants qui correspondent en fait à une option <tt>IPV6_V6ONLY</tt> mal positionnée.
-Si on tente d'ouvrir une socket IPv4 et une socket IPv6 avec l'option <tt>IPV6_V6ONLY</tt> à 0, alors ces deux sockets sont susceptibles de recevoir le traffic IPv4. Ce conflit est détecté au moment de l'appel à bind() sur la deuxième socket, qui échoue donc avec l'erreur <tt>EADDRINUSE</tt>.
+Si on tente d'ouvrir une socket IPv4 et une socket IPv6 avec l'option <tt>IPV6_V6ONLY</tt> à 0, alors ces deux sockets sont susceptibles de recevoir le trafic IPv4. Ce conflit est détecté au moment de l'appel à bind() sur la deuxième socket, qui échoue donc avec l'erreur <tt>EADDRINUSE</tt>.
   $ '''./server 20000'''

@@ Line 305: / Line 305: @@
 ====L'option IPV6_V6ONLY====
-L'option <tt>IPV6_V6ONLY</tt> contrôle si une socket serveur <tt>PF_INET6</tt> doit gérer uniquement le trafic IPv6 ou bien si elle doit gérer à la fois le traffic IPv6 et le traffic IPv4 (mappé dans ce cas).
+L'option <tt>IPV6_V6ONLY</tt> contrôle si une socket serveur <tt>PF_INET6</tt> doit gérer uniquement le trafic IPv6 ou bien si elle doit gérer à la fois le trafic IPv6 et le trafic IPv4 (mappé dans ce cas).
 Sa valeur doit être définie en utilisant <tt>setsockopt()</tt>. Typiquement :
@@ Line 313: / Line 313: @@
 Voici les cas à prévoir en cas d'option mal positionnée :
 * Un serveur conçu avec deux sockets qui aurait <tt>IPV6_V6ONLY</tt> à <tt>0</tt> échouerait à ouvrir la deuxième socket (erreur <tt>EADDRINUSE</tt>).
-* Un serveur conçu avec une seule socket et qui aurait <tt>IPV6_V6ONLY</tt> à <tt>1</tt> ignorerait le traffic IPv4.
+* Un serveur conçu avec une seule socket et qui aurait <tt>IPV6_V6ONLY</tt> à <tt>1</tt> ignorerait le trafic IPv4.
 Ces erreurs d'implémentations sont illustrées plus loin dans l'exemple de Client/Serveur TCP.