Protocole IndependentOut-of-Band Data in the SPI

Les données OOB (Out-of-Band) sont un canal de transmission indépendant logiquement associé à une 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 en bande (c’est-à-dire 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 OOB.

Un utilisateur peut déterminer s’il existe des données OOB en attente de lecture à l’aide de la fonction WSPIoctl (SIOCATMARK). Pour les protocoles où le concept de position du bloc de données OOB dans le flux de données normal est significatif (c’est-à-dire 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 de la fonctionnalité WSPIoctl (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 préférer 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 (consultez la section WSPIoctl). Pour les autres protocoles où les blocs de données OOB sont réellement indépendants du flux de données normal, toute tentative de définition de SO_OOBINLINE entraîne une erreur. Une application peut utiliser la commande SIOCATMARK WSPIoctl pour déterminer s’il existe des données OOB non lues précédant la marque. Par exemple, il peut l’utiliser 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é (par défaut) :

• Le fournisseur de services Winsock avertit un client d’un événement FD_OOB, si le client s’est inscrit pour notification avec WSPAsyncSelect, de la même façon que FD_READ est utilisé pour notifier la présence de données normales. Autrement dit, FD_OOB est publiée lorsque les données OOB arrivent et qu’aucune donnée OOB n’a été précédemment mise en file d’attente, ainsi que lorsque les données sont lues à l’aide de l’indicateur de MSG_OOB, et certaines données OOB restent lues une fois l’opération de lecture retournée. FD_READ messages ne sont pas publiés pour les données OOB.
• Le fournisseur de services Winsock retourne à partir de WSPSelect avec les appropriés, sauf si les données OOB sont mises en file d’attente sur le socket.
• Le client peut appeler WSPRecv avec MSG_OOB pour lire le bloc de données urgent à tout moment. Le bloc de données OOB saute la file d’attente.
• Le client peut appeler WSPRecv 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 à WSPRecv, le fournisseur de services avertit le client avec FD_OOB ou via à l’exception des lors de l’utilisation de WSPSelect.
• Pour les protocoles où les données OOB ont une position dans le flux de données normal, une seule opération WSPRecv ne s’étend pas sur cette position. Une WSPRecv retourne les données normales avant la marque, et une deuxième WSPRecv 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 : pour les WSPSelect et fonctions WSPAsyncSelect, les données OOB sont traitées comme des données normales et indiquées par la définition du socket dans readfds ou en envoyant respectivement un message FD_READ.
• Le client n’appelle peut-être pas WSPRecv avec l’indicateur de MSG_OOB défini pour lire le bloc de données OOB. Le code d’erreur WSAEINVAL est retourné.
• Le client peut appeler WSPRecv 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 seront jamais mélangées à des données normales : il doit y avoir trois demandes de lecture pour passer 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 routineWSPAsyncSelectconvient particulièrement bien à la gestion de la notification de la présence de données OOB lorsque SO_OOBINLINE est désactivé.