Partager via

Protocol-Independent données hors bande

  • Article

L’abstraction de socket de flux inclut la notion de données hors bande (OOB). De nombreux protocoles permettent aux parties de données entrantes d’être marquées comme spéciales d’une certaine manière, et ces blocs de données spéciaux peuvent être remis à l’utilisateur hors de la séquence normale. Les exemples incluent des données accélérées dans X.25 et d’autres protocoles OSI, ainsi que des 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 urgentes TCP suit l’explication indépendante du protocole. Dans chaque discussion, l’utilisation de recv implique également recvfrom, WSARecvet WSARecvFrom, et des références à WSAAsyncSelect s’appliquent également à WSAEventSelect.

Données OOB indépendantes du protocole

Les données OOB sont un canal de transmission indépendant logiquement 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 remis à l’utilisateur à tout moment. Pour les protocoles de communication qui prennent en charge la signalisation en bande (par exemple, TCP, où les données urgentes sont remises 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 (laissant un écart 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 hors séquence 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 duioctlsocketou fonction WSAIoctl avec la fonction SIOCATMARK IOCTL. Pour les protocoles où le concept de position du bloc de données OOB dans le flux de données normal est significatif, tel que TCP, un fournisseur de services Windows Sockets conserve un marqueur conceptuel indiquant la position du dernier octet des 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 où le concept de position du bloc de données OOB dans le flux de données normal est significatif, une application peut traiter les données hors bande inline, dans le cadre du flux de données normal. Pour ce faire, définissez l’option de socket SO_OOBINLINE avec la fonction setsockopt. Pour les autres protocoles où les blocs de données OOB sont réellement 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 la fonction SIOCATMARK IOCTL pour déterminer s’il existe des données OOB non lues précédant la marque. Par exemple, il peut utiliser ces informations pour resynchroniser avec son homologue en garantissant 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 est inscrite pour notification auprès de WSAAsyncSelect, de la même façon que FD_READ est utilisée pour notifier la présence de données normales. Autrement dit, FD_OOB est publié lorsque les données OOB arrivent sans données OOB précédemment mises en file d’attente. Le FD_OOB est également publié lorsque les données sont lues à l’aide de l’indicateur de MSG_OOB tandis que certaines données OOB restent mises en file d’attente une fois l’opération de lecture retournée. FD_READ messages ne sont pas publiés pour les données OOB.
  • Les sockets Windows retournent de sélectionnez avec les appropriés, sauf 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 saute 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, Les sockets Windows notifient l’application avec FD_OOB ou avec à l’exception des lors de l’utilisation de sélectionnez.
  • Pour les protocoles où les données OOB ont une position dans le flux de données normal, une seule opération de recv n’étend 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 à des fins de sélectionner et fonctions WSAAsyncSelect, et indiquées en définissant le socket dans readfds ou en envoyant respectivement un message FD_READ.
  • L’application ne peut pas appeler recv avec l’indicateur de 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 l’indicateur MSG_OOB défini. Toutes les données OOB sont remises dans son ordre correct dans le flux de données normal. Les données OOB ne sont jamais mélangées à des données normales. Il doit y avoir trois demandes de lecture pour obtenir les données OOB. La première retourne les données normales avant le bloc de données OOB, la deuxième retourne les données OOB, la troisième retourne les données normales à la suite des données OOB. En d’autres termes, les limites du bloc de données OOB sont conservées.

La routine WSAsyncSelect convient particulièrement bien à 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 discussion suivante sur les données hors bande (OOB), implémentées à l’aide de données urgentes TCP, suit le modèle utilisé dans la distribution logicielle de Berkeley. Les utilisateurs et les implémenteurs doivent être conscients que :

 

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

  • L’implémentation des données OOB dans la distribution de logiciels de Berkeley (BSD) n’est pas conforme aux exigences de l’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 compatible 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 en tant qu’octet de données urgent).

    Pour réduire les problèmes d’interopérabilité, les enregistreurs d’applications sont invités à ne pas utiliser de données OOB, sauf s’il est nécessaire d’interagir avec un service existant. Les fournisseurs Windows Sockets 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 octet unique de données OOB dans le flux de données TCP. Le bloc de données OOB est d’une taille d’octet. Le pointeur urgent est un décalage positif du 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 les 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 urgents (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 se produit dans la distribution de logiciels De Berkeley). Toutefois, il n’est jamais remplacé dans le flux de données.

Avec 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 arrive contenant des données urgentes. La marque de données OOB existante est mise à jour vers la nouvelle position.

Note

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.