Bruno Deniaud at 11:06, 27 February 2006

2006-02-27T11:06:34Z

Laurent Toutain at 06:27, 19 December 2005

2005-12-19T06:27:22Z

New page

L'API « avancée » (''Advanced API''), définie par le RFC 3542, a pour objet la standardisation de la manipulation en émission/réception des datagrammes IPv6. Elle permet notamment au programmeur d'écrire des applications utilisant les nouvelles fonctionnalités proposées par le protocole IPv6 et ce de façon portable.

Cette API avancée concerne essentiellement les sockets de type <tt>SOCK_DGRAM</tt> (UDP) ou de type <tt>SOCK_RAW</tt> (ICMPv6,...). En effet, comme il n'y a pas de correspondance biunivoque entre les opérations de réception (respectivement d'émission) et les segments TCP reçus (respectivement émis), la plupart des options proposées ne sont pas applicables ou voire dénuées de sens pour une socket de type <tt>SOCK_STREAM</tt>. L'API avancée est utile pour programmer des applications comme <tt>ping</tt>, <tt>traceroute</tt>, des implémentations de protocoles de routage et, de manière générale, toute application construite avec des sockets de type <tt>SOCK_RAW</tt> et devant accéder aux champs des en-têtes IPv6 ou ICMPv6.

La standardisation des appels systèmes et de fonctions a pour but de fournir un interface uniforme, évitant ainsi l'hétérogénéité qui existe en IPv4.

Les opérations disponibles sont les suivantes :

* Calcul/vérification des checksums par le noyau (pour les sockets de type <tt>SOCK_RAW</tt>)
* Filtrage des réceptions des paquets ICMPv6
* Modification des caractéristiques du datagramme IPv6 (packet information)
* Manipulation des en-têtes d'extension IPv6
* proche-en-proche (hop-by-hop)
* routage par la source (routing header)
* destination (destination)
* Gestion du MTU et du mécanisme de découverte du PMTU (Path MTU discovery)

En outre, des fonctions facilitant le traitement des en-têtes d'extension IPv6 ont été définies ainsi qu'une interface étendant les primitives <tt>rresvport</tt>, <tt>rcmd</tt> et <tt>rexec</tt> à IPv6. Cette API avancée ne prend pas en compte les en-têtes d'extension IPv6 liés à IPsec.

L'implémentation de ce nouveau standard est réalisé à l'aide des primitives <tt>sendmsg</tt> et <tt>recvmsg</tt>, les données en émission/réception étant traitées via les données auxiliaires (ancillary data) associées à la socket et gérées par ces primitives. Également, de nouvelles options ont été définies pour les sockets.

← Older revision		Revision as of 11:06, 27 February 2006
Line 1:		Line 1:
		+	{{suivi\| Utilisation du multicast \| Utilisation du multicast \| L'implémentation \| L'implémentation }}
	L'API « avancée » (''Advanced API''), définie par le RFC 3542, a pour objet la standardisation de la manipulation en émission/réception des datagrammes IPv6. Elle permet notamment au programmeur d'écrire des applications utilisant les nouvelles fonctionnalités proposées par le protocole IPv6 et ce de façon portable.		L'API « avancée » (''Advanced API''), définie par le RFC 3542, a pour objet la standardisation de la manipulation en émission/réception des datagrammes IPv6. Elle permet notamment au programmeur d'écrire des applications utilisant les nouvelles fonctionnalités proposées par le protocole IPv6 et ce de façon portable.

Line 19:		Line 20:

	L'implémentation de ce nouveau standard est réalisé à l'aide des primitives <tt>sendmsg</tt> et <tt>recvmsg</tt>, les données en émission/réception étant traitées via les données auxiliaires (ancillary data) associées à la socket et gérées par ces primitives. Également, de nouvelles options ont été définies pour les sockets.		L'implémentation de ce nouveau standard est réalisé à l'aide des primitives <tt>sendmsg</tt> et <tt>recvmsg</tt>, les données en émission/réception étant traitées via les données auxiliaires (ancillary data) associées à la socket et gérées par ces primitives. Également, de nouvelles options ont été définies pour les sockets.
		+	{{suivi\| Utilisation du multicast \| Utilisation du multicast \| L'implémentation \| L'implémentation }}

Programmation avancée - Revision history

Bruno Deniaud at 11:06, 27 February 2006

Laurent Toutain at 06:27, 19 December 2005