Difference between revisions of "Programmation d'applications bis"
From Livre IPv6
(New page: L'évolution de IPv4 vers IPv6 a été conçue pour minimiser les changements visibles. Un grand nombre de concepts n'ont pas changé : les noms, les "ports", l'envoi et la réception de d...) |
|||
| Line 1: | Line 1: | ||
| + | |||
| + | ==<div id="Mobi:xxxx">HISTORIQUE DU TRAVAIL SUR CE CHAPITRE</div>== | ||
| + | * 2009-06-30: Copié-Collé séquentiel de l'ancienne Version sur cette page (Thierry) | ||
| + | |||
| + | ==<div id="Résumé">Résumé (TEXTE REPRIS DE L'ANCIENNE VERSION)</div>== | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
L'évolution de IPv4 vers IPv6 a été conçue pour minimiser les changements visibles. Un grand nombre de concepts n'ont pas changé : les noms, les "ports", l'envoi et la réception de données,... Un certain nombre de points ont malgré tout dû être modifiés. Le principal est lié à la taille de l'adresse : en IPv4, une adresse a une longueur de 32 bits (et de nombreux programmes confondent les types adresse et entier) alors qu'en IPv6 une adresse a une longueur de 128 bits ; les types liés aux adresses doivent donc être modifiés. En fait l'effet est plus profond : les nouvelles structures sont plus grandes, et certaines réservations de mémoire avec conversion de type implicite (en particulier : un entier pour une adresse, une struct sockaddr pour une struct sockaddr_in, un tampon de 16 octets pour afficher une adresse sous forme numérique) doivent être corrigés sous peine de débordement de mémoire. | L'évolution de IPv4 vers IPv6 a été conçue pour minimiser les changements visibles. Un grand nombre de concepts n'ont pas changé : les noms, les "ports", l'envoi et la réception de données,... Un certain nombre de points ont malgré tout dû être modifiés. Le principal est lié à la taille de l'adresse : en IPv4, une adresse a une longueur de 32 bits (et de nombreux programmes confondent les types adresse et entier) alors qu'en IPv6 une adresse a une longueur de 128 bits ; les types liés aux adresses doivent donc être modifiés. En fait l'effet est plus profond : les nouvelles structures sont plus grandes, et certaines réservations de mémoire avec conversion de type implicite (en particulier : un entier pour une adresse, une struct sockaddr pour une struct sockaddr_in, un tampon de 16 octets pour afficher une adresse sous forme numérique) doivent être corrigés sous peine de débordement de mémoire. | ||
| Line 12: | Line 22: | ||
* un exemple qui génère un trafic multicast, avec abonnement et désabonnement ; | * un exemple qui génère un trafic multicast, avec abonnement et désabonnement ; | ||
* un programme illustant l'utilisation de l'API socket avancée. | * un programme illustant l'utilisation de l'API socket avancée. | ||
| + | |||
| + | ==<div id="L'interface de programmation "socket" IPv6">L'interface de programmation "socket" IPv6 (TEXTE REPRIS DE L'ANCIENNE VERSION)</div>== | ||
| + | ** [[L'interface de programmation "socket" IPv6 bis#change|Ce qui a changé]] | ||
| + | ** [[L'interface de programmation "socket" IPv6 bis#struct|Les structures de données d'adresses]] | ||
| + | ** [[L'interface socket bis|L'interface socket]] | ||
| + | ** [[L'interface socket bis#wildcard|L'adresse "wildcard"]] | ||
| + | ** [[L'interface socket bis#loopback|L'adresse de bouclage]] | ||
| + | ** [[Les primitives de conversion entre noms et adresses bis|Les primitives de conversion entre noms et adresses]] | ||
| + | ** [[Les primitives de conversion entre noms et adresses bis#conv|Les fonctions de conversion numériques d'adresses]] | ||
| + | * [[La commande haah (host-address-address-host) bis|La commande haah (host-address-address-host)]] | ||
| + | *[[Exemple de client/serveur TCP bis|Exemple de client/serveur TCP]] | ||
| + | *[[mini-ping bis|mini-ping]] | ||
| + | *[[Utilisation du multicast bis|Utilisation du multicast]] | ||
| + | *[[Programmation avancée bis|Programmation avancée]] | ||
| + | **[[L'implémentation bis|L'implémentation]] | ||
| + | **[[L'exemple « mini-ping » revisité bis|L'exemple « mini-ping » revisité]] | ||
Revision as of 10:59, 30 June 2009
HISTORIQUE DU TRAVAIL SUR CE CHAPITRE
- 2009-06-30: Copié-Collé séquentiel de l'ancienne Version sur cette page (Thierry)
Résumé (TEXTE REPRIS DE L'ANCIENNE VERSION)
L'évolution de IPv4 vers IPv6 a été conçue pour minimiser les changements visibles. Un grand nombre de concepts n'ont pas changé : les noms, les "ports", l'envoi et la réception de données,... Un certain nombre de points ont malgré tout dû être modifiés. Le principal est lié à la taille de l'adresse : en IPv4, une adresse a une longueur de 32 bits (et de nombreux programmes confondent les types adresse et entier) alors qu'en IPv6 une adresse a une longueur de 128 bits ; les types liés aux adresses doivent donc être modifiés. En fait l'effet est plus profond : les nouvelles structures sont plus grandes, et certaines réservations de mémoire avec conversion de type implicite (en particulier : un entier pour une adresse, une struct sockaddr pour une struct sockaddr_in, un tampon de 16 octets pour afficher une adresse sous forme numérique) doivent être corrigés sous peine de débordement de mémoire.
L'interface de programmation réseau ("API") la plus connue est l'interface "socket" (dite aussi interface "BSD"). Le but de ce chapitre est de présenter pour cette interface de programmation les modifications introduites pour supporter IPv6, et notamment de donner une brève description des nouvelles primitives d'appel au DNS et de conversion d'adresses.
Ces modifications ont été définies pour être aussi transparentes que possible, et, s'il est en pratique toujours nécessaire de modifier un programme pour le porter de IPv4 à IPv6, un programme conçu avec des règles de typage strict est portable sans grandes modifications.
Ce chapitre illustrera l'interface de programmation "socket" pour IPv6 en présentant plusieurs exemples de programmes. Plus précisément, il détaillera successivement :
* un programme combinant les différentes fonctions de conversion d'adresse ; * un client/serveur TCP calculant le nombre d'utilisateurs connectés sur une machine cible. En particulier, on aura soin de comparer les codes IPv4 et IPv6 de ce client/serveur, ce qui amènera à constater qu'à ce niveau de programmation, la migration vers IPv6 n'offre aucune difficulté ; * un "mini ping" qui permettra de se familiariser avec le protocole ICMPv6 qui présente de notables différences avec son prédécesseur le protocole ICMPv4 ; * un exemple qui génère un trafic multicast, avec abonnement et désabonnement ; * un programme illustant l'utilisation de l'API socket avancée.
