Protocol-Independent données hors bande

L’abstraction de socket de flux inclut la notion de données hors bande (OOB). De nombreux protocoles permettent à des parties de données entrantes d’être marquées comme spéciales d’une manière ou d’une autre, et ces blocs de données spéciaux peuvent être remis à l’utilisateur en dehors de la séquence normale. Les exemples incluent les données accélérées dans X.25 et d’autres protocoles OSI, et les données urgentes dans l’utilisation de TCP par BSD UNIX. La section suivante décrit la gestion des données OOB de manière indépendante du protocole. Une discussion sur les données OOB implémentées à l’aide de données d’urgence TCP suit l’explication indépendante du protocole. Dans chaque discussion, l’utilisation de recv implique également recvfrom, WSARecv et WSARecvFrom, et les références à WSAAsyncSelect s’appliquent également à WSAEventSelect.

Données OOB indépendantes du protocole

Les données OOB sont un canal de transmission logiquement indépendant associé à chaque paire de sockets de flux connectés. Les données OOB peuvent être remises à l’utilisateur indépendamment des données normales. L’abstraction définit que les installations de données OOB doivent prendre en charge la livraison fiable d’au moins un bloc de données OOB à la fois. Ce bloc de données peut contenir au moins un octet de données, et au moins un bloc de données OOB peut être en attente de remise à l’utilisateur à tout moment. Pour les protocoles de communication qui prennent en charge la signalisation in-band (comme TCP, où les données urgentes sont fournies en séquence avec les données normales), le système extrait normalement les données OOB du flux de données normal et les stocke séparément (en laissant un vide dans le flux de données normal). Cela permet aux utilisateurs de choisir entre recevoir les données OOB dans l’ordre et les recevoir dans l’ordre sans avoir à mettre en mémoire tampon toutes les données intermédiaires. Il est possible d’examiner les données hors bande (OOB).

Un utilisateur peut déterminer si des données OOB attendent d’être lues à l’aide de la fonction ioctlsocket ou WSAIoctl avec SIOCATMARK IOCTL. Pour les protocoles pour lesquels le concept de la position du bloc de données OOB dans le flux de données normal est significatif, comme TCP, un fournisseur de services Windows Sockets conserve un marqueur conceptuel indiquant la position du dernier octet de données OOB dans le flux de données normal. Cela n’est pas nécessaire pour l’implémentation des fonctions ioctlsocket ou WSAIoctl qui prennent en charge SIOCATMARK. La présence ou l’absence de données OOB est requise.

Pour les protocoles pour lesquels le concept de la position du bloc de données OOB dans le flux de données normal est significatif, une application peut traiter des données hors bande inline, dans le cadre du flux de données normal. Pour ce faire, définissez l’option socket SO_OOBINLINE avec la fonction setsockopt . Pour d’autres protocoles où les blocs de données OOB sont vraiment indépendants du flux de données normal, la tentative de définition de SO_OOBINLINE entraîne une erreur. Une application peut utiliser la fonction ioctlsocket ou WSAIoctl avec SIOCATMARK IOCTL pour déterminer s’il existe des données OOB non lus avant la marque. Par exemple, il peut utiliser ces informations pour resynchroniser avec son homologue en s’assurant que toutes les données jusqu’à la marque dans le flux de données sont ignorées le cas échéant.

Avec SO_OOBINLINE désactivé (paramètre par défaut) :

• Windows Sockets avertit une application d’un événement FD_OOB, si l’application s’est inscrite pour la notification auprès de WSAAsyncSelect, exactement de la même manière FD_READ est utilisé pour notifier la présence de données normales. Autrement dit, FD_OOB est publié lorsque les données OOB arrivent sans aucune donnée OOB précédemment mise en file d’attente. Le FD_OOB est également publié lorsque les données sont lues à l’aide de l’indicateur MSG_OOB tandis que certaines données OOB restent mises en file d’attente après le retour de l’opération de lecture. FD_READ messages ne sont pas publiés pour les données OOB.
• Les sockets Windows retournent à partir de select avec le socket exceptfds approprié défini si les données OOB sont mises en file d’attente sur le socket.
• L’application peut appeler recv avec MSG_OOB pour lire le bloc de données urgent à tout moment. Le bloc de données OOB fait sauter la file d’attente.
• L’application peut appeler recv sans MSG_OOB pour lire le flux de données normal. Le bloc de données OOB n’apparaît pas dans le flux de données avec des données normales. Si les données OOB restent après un appel à recv, Windows Sockets avertit l’application avec FD_OOB ou avec exceptfds lors de l’utilisation de select.
• Pour les protocoles où les données OOB ont une position dans le flux de données normal, une seule opération recv ne couvre pas cette position. Une recv retourne les données normales avant la marque, et une deuxième recv est nécessaire pour commencer à lire les données après la marque.

Avec SO_OOBINLINE activé :

• FD_OOB messages ne sont pas publiés pour les données OOB. Les données OOB sont traitées comme normales pour les fonctions select et WSAAsyncSelect , et indiquées en définissant le socket dans readfds ou en envoyant un message FD_READ respectivement.
• L’application ne peut pas appeler recv avec l’indicateur MSG_OOB défini pour lire le bloc de données OOB. Le code d’erreur WSAEINVAL est retourné.
• L’application peut appeler recv sans le jeu d’indicateurs MSG_OOB. Toutes les données OOB sont remises dans leur ordre correct dans le flux de données normal. Les données OOB ne sont jamais mélangées avec des données normales. Il doit y avoir trois demandes de lecture pour dépasser les données OOB. Le premier retourne les données normales antérieures au bloc de données OOB, le second retourne les données OOB, le troisième retourne les données normales après les données OOB. En d’autres termes, les limites du bloc de données OOB sont conservées.

La routine WSAAsyncSelect est particulièrement adaptée à la gestion de la notification de la présence de données hors bande lorsque SO_OOBINLINE est désactivé.

Données OOB dans TCP

Important

La présentation suivante des données hors bande (OOB), implémentées à l’aide de données d’urgence TCP, suit le modèle utilisé dans la distribution de logiciels Berkeley. Les utilisateurs et les implémenteurs doivent savoir que :

 

• Il existe actuellement deux interprétations contradictoires de la RFC 793 (où le concept est introduit).

• L’implémentation des données OOB dans Berkeley Software Distribution (BSD) n’est pas conforme aux exigences d’hôte spécifiées dans RFC 1122.

  Plus précisément, le pointeur d’urgence TCP dans BSD pointe vers l’octet après l’octet de données urgent, et un pointeur TCP urgent conforme à RFC pointe vers l’octet de données urgent. Par conséquent, si une application envoie des données urgentes d’une implémentation compatible BSD à une implémentation compatible avec RFC 1122, le récepteur lit l’octet de données urgent incorrect (il lit l’octet situé après l’octet correct dans le flux de données comme octet urgent).

  Pour réduire les problèmes d’interopérabilité, il est recommandé aux enregistreurs d’applications de ne pas utiliser de données OOB, sauf si cela est nécessaire pour interagir avec un service existant. Les fournisseurs de sockets Windows sont invités à documenter la sémantique OOB (BSD ou RFC 1122) que leur produit implémente.

L’arrivée d’un segment TCP avec le jeu d’indicateurs URG (pour urgent) indique l’existence d’un seul octet de données OOB dans le flux de données TCP. Le bloc de données OOB a une taille d’un octet. Le pointeur urgent est un décalage positif par rapport au numéro de séquence actuel dans l’en-tête TCP qui indique l’emplacement du bloc de données OOB (ambiguë, comme indiqué dans le précédent). Il peut donc pointer vers des données qui n’ont pas encore été reçues.

Si SO_OOBINLINE est désactivé (valeur par défaut) lorsque le segment TCP contenant l’octet pointé par le pointeur urgent arrive, le bloc de données OOB (un octet) est supprimé du flux de données et mis en mémoire tampon. Si un segment TCP suivant arrive avec le jeu d’indicateurs urgent (et un nouveau pointeur urgent), l’octet OOB actuellement mis en file d’attente peut être perdu car il est remplacé par le nouveau bloc de données OOB (comme cela se produit dans Berkeley Software Distribution). Toutefois, il n’est jamais remplacé dans le flux de données.

Une fois SO_OOBINLINE activé, les données urgentes restent dans le flux de données. Par conséquent, le bloc de données OOB n’est jamais perdu lorsqu’un nouveau segment TCP contenant des données urgentes arrive. La marque de données OOB existante est mise à jour vers la nouvelle position.

Notes

Lorsque l’option de socket SO_OOBINLINE est définie, SIOCATMARK IOCTL retourne toujours TRUE et les données OOB sont retournées à l’utilisateur en tant que données normales.