Winsock IOCTLs

Cette section décrit les contrôles d’entrée/sortie winsock socket (IOCTL) pour différentes éditions de systèmes d’exploitation Windows. Utilisez la fonction WSAIoctl ou WSPIoctl pour émettre un IOCTL Winsock pour contrôler le mode d’un socket, le protocole de transport ou le sous-système de communication.

Certains IOCTL Winsock nécessitent plus d’explications que ce tableau peut transmettre ; ces options contiennent des liens vers des rubriques supplémentaires.

Il est possible d’adopter un schéma d’encodage qui conserve les opcodes ioctlsocket actuellement définis tout en fournissant un moyen pratique de partitionner l’espace d’identificateur opcode autant que le paramètre dwIoControlCode est désormais une entité 32 bits. Le paramètre dwIoControlCode est conçu pour permettre l’indépendance du protocole et du fournisseur lors de l’ajout de nouveaux codes de contrôle tout en conservant la compatibilité descendante avec les codes de contrôle Windows Sockets 1.1 et Unix. Le paramètre dwIoControlCode a le formulaire suivant.

Je suis défini si la mémoire tampon d’entrée est valide pour le code, comme avec IOC_IN.

O est défini si la mémoire tampon de sortie est valide pour le code, comme avec IOC_OUT. Les codes de contrôle utilisant des mémoires tampons d’entrée et de sortie définissent à la fois les E/S et les E/S.

V est défini s’il n’existe aucun paramètre pour le code, comme avec IOC_VOID.

T est une quantité 2 bits qui définit le type du IOCTL. Les valeurs suivantes sont définies :

0 Le IOCTL est un code UNIX IOCTL standard, comme avec FIONREAD et FIONBIO.

1 Le IOCTL est un code IOCTL Windows Sockets 2 générique. Les nouveaux codes IOCTL définis pour Windows Sockets 2 auront T == 1.

2 Le IOCTL s’applique uniquement à une famille d’adresses spécifique.

3 Le IOCTL s’applique uniquement au fournisseur d’un fournisseur spécifique, comme avec IOC_VENDOR. Ce type permet aux entreprises d’attribuer un numéro de fournisseur qui apparaît dans le paramètre de famille Fournisseur/Adresse . Ensuite, le fournisseur peut définir de nouveaux IOCTL spécifiques à ce fournisseur sans avoir à inscrire le IOCTL auprès d’un centre d’information, fournissant ainsi la flexibilité et la confidentialité du fournisseur.

Famille fournisseur/adresse Quantité 11 bits qui définit le fournisseur propriétaire du code (si T == 3) ou qui contient la famille d’adresses à laquelle le code s’applique (si T == 2). S’il s’agit d’un code IOCTL Unix (T == 0), ce paramètre a la même valeur que le code sur Unix. S’il s’agit d’un IOCTL Windows Sockets 2 générique (T == 1), ce paramètre peut être utilisé comme extension du paramètre de code pour fournir des valeurs de code supplémentaires.

Code Quantité 16 bits qui contient le code IOCTL spécifique pour l’opération.

Codes IOCTL Unix

Les codes IOCTL Unix suivants (commandes) sont pris en charge.

FIONBIO

Activez ou désactivez le mode non bloquant sur les sockets. Le paramètre lpvInBuffer pointe vers une durée non signée (QoS), qui n’est pas différente de zéro si le mode non bloquant doit être activé et zéro s’il doit être désactivé. Lorsqu’un socket est créé, il fonctionne en mode bloquant (autrement dit, le mode non bloquant est désactivé). Cela est cohérent avec les sockets BSD.

La routine WSAAsyncSelect ou WSAEventSelect définit automatiquement un socket en mode non bloquant. Si WSAAsyncSelect ou WSAEventSelect a été émis sur un socket, toute tentative d’utilisation de WSAIoctl pour définir le socket sur le mode de blocage échoue avec WSAEINVAL. Pour définir le socket en mode bloquant, une application doit d’abord désactiver WSAAsyncSelect en appelant WSAAsyncSelect avec le paramètre lEvent égal à zéro, ou désactiver WSAEventSelect en appelant WSAEventSelect avec le paramètre lNetworkEvents égal à zéro.

FIONREAD

Déterminez la quantité de données qui peuvent être lues atomiquement à partir des sockets. Le paramètre lpvOutBuffer pointe vers une longueur non signée dans laquelle WSAIoctl stocke le résultat.

Si le socket transmis dans le paramètre s est orienté flux (par exemple, type SOCK_STREAM), FIONREAD retourne la quantité totale de données pouvant être lues dans une seule opération de réception ; cela est normalement identique à la quantité totale de données mises en file d’attente sur le socket (étant donné qu’un flux de données est orienté octets, cela n’est pas garanti).

Si le socket passé dans le paramètre s est orienté message (par exemple, type SOCK_DGRAM), FIONREAD retourne le nombre total d’octets disponibles pour la lecture, et non la taille du premier datagramme (message) mis en file d’attente sur le socket.

SIOCATMARK

Déterminez si toutes les données OOB ont été lues ou non. Cela s’applique uniquement à un socket de style de flux (par exemple, type SOCK_STREAM) qui a été configuré pour la réception inline de toutes les données OOB (SO_OOBINLINE). Si aucune donnée OOB n’attend la lecture, l’opération retourne TRUE. Sinon, elle retourne FALSE et l’opération de réception suivante effectuée sur le socket récupère certaines ou toutes les données précédant la marque ; l’application doit utiliser l’opération SIOCATMARK pour déterminer s’il reste. Si des données normales précèdent les données urgentes (hors bande), elles sont reçues dans l’ordre. (Notez que les opérations recv ne combinent jamais les données OOB et normales dans le même appel.) lpvOutBuffer pointe vers un boOL dans lequel WSAIoctl stocke le résultat.

Commandes Windows Sockets 2

Les commandes Windows Sockets 2 suivantes sont prises en charge.

SIO_ACQUIRE_PORT_RESERVATION (paramètre opcode : I, T==3)

Demandez une réservation d’exécution pour un bloc de ports TCP ou UDP. Pour les réservations de port d’exécution, le pool de ports exige que les réservations soient consommées à partir du processus sur lequel la réservation a été accordée. Les réservations de port d’exécution ne durent que tant que la durée de vie du socket sur lequel le SIO_ACQUIRE_PORT_RESERVATION IOCTL a été appelé. En revanche, les réservations de ports persistants créées à l’aide de la fonction CreatePersistentTcpPortReservation ou CreatePersistentUdpPortReservation peuvent être consommées par n’importe quel processus avec la possibilité d’obtenir des réservations persistantes.

Pour plus d’informations, consultez la référence SIO_ACQUIRE_PORT_RESERVATION .

SIO_ACQUIRE_PORT_RESERVATION est pris en charge sur Windows Vista et les versions ultérieures du système d’exploitation.

SIO_ADDRESS_LIST_CHANGE (paramètre opcode : V, T==1)

Pour recevoir la notification des modifications dans la liste des adresses de transport locales de la famille de protocoles du socket à laquelle l’application peut lier. Aucune information de sortie n’est fournie à la fin de ce IOCTL ; la saisie semi-automatique indique simplement que la liste des adresses locales disponibles a changé et doit être interrogée à nouveau par SIO_ADDRESS_LIST_QUERY.

Il est supposé (bien qu’il ne soit pas nécessaire) que l’application utilise des E/S qui se chevauchent pour être avertie de la modification à l’issue de SIO_ADDRESS_LIST_CHANGE demande. Sinon, si le SIO_ADDRESS_LIST_CHANGE IOCTL est émis sur un socket non bloquant et sans paramètres superposés (lpOverlapped/ lpCompletionRoutine est défini sur NULL), il se termine immédiatement avec l’erreur WSAEWOULDBLOCK. L’application peut ensuite attendre les événements de modification de liste d’adresses par le biais d’un appel à WSAEventSelect ou WSAAsyncSelect avec FD_ADDRESS_LIST_CHANGE bit défini dans le masque de bits d’événement réseau.

SIO_ADDRESS_LIST_QUERY (paramètre opcode : O, T==1)

Obtient la liste des adresses de transport locales de la famille de protocoles du socket à laquelle l’application peut lier. La liste des adresses varie en fonction de la famille d’adresses et certaines adresses sont exclues de la liste.

• Problème SIO_ADDRESS_LIST_CHANGE IOCTL
• Problème SIO_ADDRESS_LIST_QUERY IOCTL
• Chaque fois que SIO_ADDRESS_LIST_CHANGE IOCTL avertit l’application du changement de liste d’adresses (par le biais d’E/S superposées ou en signalant FD_ADDRESS_LIST_CHANGE événement), l’ensemble de la séquence d’actions doit être répétée.

Pour plus d’informations, consultez la référence SIO_ADDRESS_LIST_QUERY . SIO_ADDRESS_LIST_QUERY est pris en charge sur Windows 2000 et versions ultérieures.

SIO_APPLY_TRANSPORT_SETTING (paramètre opcode : I, T==3)

Applique un paramètre de transport à un socket. Le paramètre de transport appliqué est basé sur la TRANSPORT_SETTING_ID passée dans le paramètre lpvInBuffer .

Le seul paramètre de transport actuellement défini concerne la fonctionnalité de REAL_TIME_NOTIFICATION_CAPABILITY sur un socket TCP.

Si le TRANSPORT_SETTING_ID passé a le membre Guid défini sur REAL_TIME_NOTIFICATION_CAPABILITY, il s’agit d’une demande d’application des paramètres de notification en temps réel pour le socket TCP utilisé avec ControlChannelTrigger pour recevoir des notifications réseau en arrière-plan dans une application du Windows Store.

Pour plus d’informations, consultez la référence SIO_APPLY_TRANSPORT_SETTING . SIO_APPLY_TRANSPORT_SETTING est pris en charge sur Windows 8, Windows Server 2012 et versions ultérieures.

SIO_ASSOCIATE_HANDLE (paramètre opcode : I, T==1)

Associez ce socket au handle spécifié d’une interface complémentaire. La mémoire tampon d’entrée contient la valeur entière correspondant à la constante manifeste de l’interface complémentaire (par exemple, TH_NETDEV et TH_TAPI.), suivie d’une valeur qui est un handle de l’interface complémentaire spécifiée, ainsi que d’autres informations requises. Reportez-vous à la section appropriée dans les annexes Winsock pour plus d’informations spécifiques à une interface complémentaire particulière. La taille totale est reflétée dans la longueur de la mémoire tampon d’entrée. Aucune mémoire tampon de sortie n’est requise. Le code d’erreur WSAENOPROTOOPT est indiqué pour les fournisseurs de services qui ne prennent pas en charge cette IOCTL. Le handle associé à cette IOCTL peut être récupéré à l’aide de SIO_TRANSLATE_HANDLE.

Une interface complémentaire peut être utilisée, par exemple, si un fournisseur particulier fournit (1) un grand nombre de contrôles supplémentaires sur le comportement d’un socket et (2) les contrôles sont suffisamment spécifiques au fournisseur qu’ils ne mappent pas aux fonctions Windows Socket existantes ou à ceux susceptibles d’être définis à l’avenir. Il est recommandé d’utiliser com (Component Object Model) au lieu de cette IOCTL pour découvrir et suivre d’autres interfaces qui peuvent être prises en charge par un socket. Ce IOCTL est présent pour la compatibilité (inverse) avec les systèmes où COM n’est pas disponible ou ne peut pas être utilisé pour une autre raison.

SIO_ASSOCIATE_PORT_RESERVATION (paramètre opcode : I, T==3)

Associez un socket à une réservation persistante ou runtime pour un bloc de ports TCP ou UDP identifiés par le jeton de réservation de port. La SIO_ASSOCIATE_PORT_RESERVATION IOCTL doit être émise avant la liaison du socket. Si et quand le socket est lié, le port affecté à celui-ci est sélectionné à partir de la réservation de port identifiée par le jeton donné. Si aucun port n’est disponible à partir de la réservation spécifiée, l’appel de fonction de liaison échoue.

Pour plus d’informations, consultez la référence SIO_ASSOCIATE_PORT_RESERVATION .

SIO_ASSOCIATE_PORT_RESERVATION est pris en charge sur Windows Vista et les versions ultérieures du système d’exploitation.

SIO_BASE_HANDLE (paramètre opcode : O, T==1)

Récupère le handle du fournisseur de services de base pour un socket donné. La valeur retournée est un SOCKET.

Un fournisseur de services en couches n’intercepte jamais ce IOCTL, car la valeur de retour doit être le handle de socket du fournisseur de services de base.

Si la mémoire tampon de sortie n’est pas suffisamment grande pour un handle de socket ( le cbOutBuffer est inférieur à la taille d’un SOCKET) ou si le paramètre lpvOutBuffer est un pointeur NULL , SOCKET_ERROR est retourné en conséquence de ce IOCTL et WSAGetLastError retourne WSAEFAULT.

SIO_BASE_HANDLE est défini dans le fichier d’en-tête Mswsock.h et pris en charge sur Windows Vista et versions ultérieures.

SIO_BSP_HANDLE (paramètre opcode : O, T==1)

Récupère le handle du fournisseur de services de base pour un socket utilisé par la fonction WSASendMsg . La valeur retournée est un SOCKET.

Ce Ioctl est utilisé par un fournisseur de services en couches pour s’assurer que le fournisseur intercepte la fonction WSASendMsg .

Si la mémoire tampon de sortie n’est pas suffisamment grande pour un handle de socket ( le cbOutBuffer est inférieur à la taille d’un SOCKET) ou si le paramètre lpvOutBuffer est un pointeur NULL , SOCKET_ERROR est retourné en conséquence de ce IOCTL et WSAGetLastError retourne WSAEFAULT.

SIO_BSP_HANDLE est défini dans le fichier d’en-tête Mswsock.h et pris en charge sur Windows Vista et versions ultérieures.

SIO_BSP_HANDLE_SELECT (paramètre opcode : O, T==1)

Récupère le handle du fournisseur de services de base pour un socket utilisé par la fonction select . La valeur retournée est un SOCKET.

Ce Ioctl est utilisé par un fournisseur de services en couches pour s’assurer que le fournisseur intercepte la fonction select .

Si la mémoire tampon de sortie n’est pas suffisamment grande pour un handle de socket ( le cbOutBuffer est inférieur à la taille d’un SOCKET) ou si le paramètre lpvOutBuffer est un pointeur NULL , SOCKET_ERROR est retourné en conséquence de ce IOCTL et WSAGetLastError retourne WSAEFAULT.

SIO_BSP_HANDLE_SELECT est défini dans le fichier d’en-tête Mswsock.h et pris en charge sur Windows Vista et versions ultérieures.

SIO_BSP_HANDLE_POLL (paramètre opcode : O, T==1)

Récupère le handle du fournisseur de services de base pour un socket utilisé par la fonction WSAPoll . Le paramètre lpOverlapped doit être un pointeur NULL . La valeur retournée est un SOCKET.

Ce Ioctl est utilisé par un fournisseur de services en couches pour s’assurer que le fournisseur intercepte la fonction WSAPoll .

Si la mémoire tampon de sortie n’est pas suffisamment grande pour un handle de socket ( le cbOutBuffer est inférieur à la taille d’un socket), le paramètre lpvOutBuffer est un pointeur NULL ou le paramètre lpOverlapped n’est pas un pointeur NULL , SOCKET_ERROR est retourné en conséquence de ce IOCTL et WSAGetLastError retourne WSAEFAULT.

SIO_BSP_HANDLE_POLL est défini dans le fichier d’en-tête Mswsock.h et pris en charge sur Windows Vista et versions ultérieures.

SIO_CHK_QOS (paramètre opcode : I, O, T==3)

Récupère des informations sur les caractéristiques du trafic QoS. Pendant la phase de transition sur le système d’envoi entre la configuration du flux et la réception d’un message RESV (voir Comment le service RSVP appelle TC pour plus d’informations sur la phase transitionnelle), le trafic associé à un flux RSVP est mis en forme en fonction du type de service (BEST EFFORT, CONTROLLED LOAD ou GUARANTEED). Pour plus d’informations, consultez Utilisation de SIO_CHK_QOS dans la section Qualité du service du KIT DE développement logiciel (SDK) de plateforme.

SIO_CPU_AFFINITY (paramètre opcode : I, T==3)

Active le partage de ports et la parallélisation des indications de réception. Lorsque votre application utilise cette option de socket pour associer des sockets à différents processeurs, puis lie les sockets à la même adresse, les indications de réception sont distribuées sur les sockets en fonction du hachage RSS (Receive Side Scale). Les paramètres RSS ne changent pas. Par conséquent, tout flux donné (point de terminaison local, paire de points de terminaison distants) est toujours indiqué sur le même processeur. Par conséquent, tous les paquets appartenant à un flux donné sont indiqués sur le même socket. Ce IOCTL doit être appelé avant la liaison, sinon WSAEINVAL sera retourné. La mémoire tampon d’entrée est un index processeur (basé sur 0) de type USHORT. Le IOCTL n’est pas compatible avec SO_REUSEADDR et SO_REUSE_MULTICASTPORT. Uniquement pris en charge pour les sockets UDP.

SIO_ENABLE_CIRCULAR_QUEUEING (paramètre opcode : V, T==1)

Indique au fournisseur de services orienté message sous-jacent qu’un message nouvellement arrivé ne doit jamais être supprimé en raison d’un dépassement de capacité de file d’attente de mémoire tampon. Au lieu de cela, le message le plus ancien de la file d’attente doit être éliminé afin de prendre en charge le message nouvellement arrivé. Aucune mémoire tampon d’entrée et de sortie n’est requise. Notez que cette IOCTL n’est valide que pour les sockets associés à des protocoles non fiables et orientés messages. Le code d’erreur WSAENOPROTOOPT est indiqué pour les fournisseurs de services qui ne prennent pas en charge cette IOCTL.

SIO_FIND_ROUTE (paramètre opcode : O, T==1)

Lorsqu’elle est émise, cette IOCTL demande que l’itinéraire vers l’adresse distante spécifiée en tant que sockaddr dans la mémoire tampon d’entrée soit découvert. Si l’adresse existe déjà dans le cache local, son entrée est invalidée. Dans le cas d’IPX de Novell, cet appel lance une adresse IPX GetLocalTarget (GLT), qui interroge le réseau pour l’adresse distante donnée.

SIO_FLUSH (paramètre opcode : V, T==1)

Ignore le contenu actuel de la file d’attente d’envoi associée à ce socket. Aucune mémoire tampon d’entrée et de sortie n’est requise. Le code d’erreur WSAENOPROTOOPT est indiqué pour les fournisseurs de services qui ne prennent pas en charge cette IOCTL.

SIO_GET_BROADCAST_ADDRESS (paramètre opcode : O, T==1)

Cette IOCTL remplit la mémoire tampon de sortie avec une structure sockaddr contenant une adresse de diffusion appropriée à utiliser avec sendto/ WSASendTo. Ce IOCTL n’est pas pris en charge pour les sockets IPv6 et retourne le code d’erreur WSAENOPROTOOPT .

SIO_GET_EXTENSION_FUNCTION_POINTER (paramètre opcode : O, I, T==1)

Récupérez un pointeur vers la fonction d’extension spécifiée prise en charge par le fournisseur de services associé. La mémoire tampon d’entrée contient un identificateur global unique (GUID) dont la valeur identifie la fonction d’extension en question. Le pointeur vers la fonction souhaitée est retourné dans la mémoire tampon de sortie. Les identificateurs de fonction d’extension sont établis par les fournisseurs de services et doivent être inclus dans la documentation du fournisseur qui décrit les fonctionnalités et la sémantique des fonctions d’extension.

Les valeurs GUID des fonctions d’extension prises en charge par le fournisseur de services TCP/IP Windows sont définies dans le fichier d’en-tête Mswsock.h . La valeur possible pour ces GUID est la suivante :

SIO_GET_GROUP_QOS (paramètre opcode : O, I, T==1)

Réservé pour une utilisation ultérieure avec des sockets.

Récupérez la structure QOS associée au groupe de sockets auquel appartient ce socket. La mémoire tampon d’entrée est facultative. Certains protocoles (par exemple, RSVP) permettent à la mémoire tampon d’entrée d’être utilisée pour qualifier une qualité de demande de service. La structure QOS est copiée dans la mémoire tampon de sortie. Si ce socket n’appartient pas à un groupe de sockets approprié, les membres SendingFlowspec et ReceiveingFlowspec de la structure QOS retournée sont définis sur NULL. Le code d’erreur WSAENOPROTOOPT est indiqué pour les fournisseurs de services qui ne prennent pas en charge la qualité du service.

SIO_GET_INTERFACE_LIST (paramètre opcode : O, T==0)

Retourne une liste d’interfaces IP configurées et de leurs paramètres sous la forme d’un tableau de structures INTERFACE_INFO .

Le paramètre lpvOutBuffer pointe vers la mémoire tampon dans laquelle stocker les informations sur les interfaces sous la forme d’un tableau de structures INTERFACE_INFO pour les adresses IP de monodiffusion sur les interfaces. Le paramètre cbOutBuffer spécifie la longueur de la mémoire tampon de sortie. Le nombre d’interfaces retournées (nombre de structures retournées dans la mémoire tampon pointée par le paramètre lpvOutBuffer ) peut être déterminé en fonction de la longueur réelle de la mémoire tampon de sortie retournée dans le paramètre lpcbBytesReturned .

Si la fonction WSAIoctl est appelée avec SIO_GET_INTERFACE_LIST et que le membre de niveau du paramètre de socket n’est pas défini comme IPPROTO_IP, WSAEINVAL est retourné. Un appel à la fonction WSAIoctl avec SIO_GET_INTERFACE_LIST retourne WSAEFAULT si le paramètre cbOutBuffer qui spécifie la longueur de la mémoire tampon de sortie est trop petite pour recevoir la liste des interfaces configurées.

SIO_GET_INTERFACE_LIST est pris en charge sur Windows Me/98 et Windows NT 4.0 avec SP4 et versions ultérieures.

SIO_GET_INTERFACE_LIST_EX (paramètre opcode : O, T==0)

Réservé pour une utilisation ultérieure avec des sockets.

Retourne une liste d’interfaces IP configurées et de leurs paramètres sous la forme d’un tableau de structures INTERFACE_INFO_EX .

Le paramètre lpvOutBuffer pointe vers la mémoire tampon dans laquelle stocker les informations sur les interfaces sous la forme d’un tableau de structures INTERFACE_INFO_EX pour les adresses IP de monodiffusion sur l’interface. Le paramètre cbOutBuffer spécifie la longueur de la mémoire tampon de sortie. Le nombre d’interfaces retournées (nombre de structures retournées dans lpvOutBuffer) peut être déterminé en fonction de la longueur réelle de la mémoire tampon de sortie retournée dans le paramètre lpcbBytesReturned .

SIO_GET_INTERFACE_LIST_EX n’est actuellement pas pris en charge sur Windows.

SIO_GET_QOS (paramètre opcode : O, T==1)

Réservé pour une utilisation ultérieure avec des sockets. Récupérez la structure QOS associée au socket. La mémoire tampon d’entrée est facultative. Certains protocoles (par exemple, RSVP) permettent à la mémoire tampon d’entrée d’être utilisée pour qualifier une qualité de demande de service. La structure QOS est copiée dans la mémoire tampon de sortie. La mémoire tampon de sortie doit être dimensionnée suffisamment grande pour pouvoir contenir la structure QOS complète. Le code d’erreur WSAENOPROTOOPT est indiqué pour les fournisseurs de services qui ne prennent pas en charge la qualité du service.

Un expéditeur peut ne pas appeler SIO_GET_QOS tant que le socket n’est pas connecté.

Un récepteur peut appeler SIO_GET_QOS dès qu’il est lié.

SIO_GET_TX_TIMESTAMP

Un IOCTL de socket utilisé pour obtenir des horodatages pour les paquets transmis (TX). Valide uniquement pour les sockets de datagramme.

Le code de contrôle SIO_GET_TX_TIMESTAMP supprime un horodatage de transmission de la file d’attente d’horodatage de transmission d’un socket. Activez d’abord la réception d’horodatage à l’aide du IOCTL du socket SIO_TIMESTAMPING . Récupérez ensuite les horodatages tx par ID en appelant la fonction WSAIoctl (ou WSPIoctl) avec les paramètres suivants.

Pour SIO_GET_TX_TIMESTAMP, l’entrée est un ID d’horodatage UINT32 et la sortie est une valeur d’horodatage UINT64 . En cas de réussite, l’horodatage tx est disponible et est retourné. Si aucun horodatage de transmission n’est disponible, WSAGetLastError retourne WSAEWOULDBLOCK.

Voir également l’horodatage Winsock.

SIO_IDEAL_SEND_BACKLOG_CHANGE (paramètre opcode : V, T==0)

Avertit une application lorsque la valeur de backlog d’envoi idéale (ISB) change pour la connexion sous-jacente.

Lors de l’envoi de données via une connexion TCP à l’aide de sockets Windows, il est important de conserver une quantité suffisante de données en attente (envoyées, mais pas encore reconnues) dans TCP afin d’atteindre le débit le plus élevé. La valeur idéale pour la quantité de données en suspens afin d’obtenir le meilleur débit pour la connexion TCP est appelée taille de backlog d’envoi idéal (ISB). La valeur ISB est une fonction du produit de délai de bande passante de la connexion TCP et de la fenêtre de réception annoncée du destinataire (et en partie la quantité de congestion dans le réseau).

La valeur ISB par connexion est disponible à partir de l’implémentation du protocole TCP dans Windows Server 2008, Windows Vista avec SP1 et versions ultérieures du système d’exploitation. La SIO_IDEAL_SEND_BACKLOG_CHANGE IOCTL peut être utilisée par une application pour recevoir une notification lorsque la valeur ISB change dynamiquement pour une connexion.

Pour plus d’informations, consultez la référence SIO_IDEAL_SEND_BACKLOG_CHANGE .

SIO_IDEAL_SEND_BACKLOG_CHANGE est pris en charge sur Windows Server 2008, Windows Vista avec SP1 et versions ultérieures du système d’exploitation.

SIO_IDEAL_SEND_BACKLOG_QUERY (paramètre opcode : O, T==0)

Récupère la valeur de backlog d’envoi idéal (ISB) pour la connexion sous-jacente.

Lors de l’envoi de données via une connexion TCP à l’aide de sockets Windows, il est important de conserver une quantité suffisante de données en attente (envoyées, mais pas encore reconnues) dans TCP afin d’atteindre le débit le plus élevé. La valeur idéale pour la quantité de données en suspens afin d’obtenir le meilleur débit pour la connexion TCP est appelée taille de backlog d’envoi idéal (ISB). La valeur ISB est une fonction du produit de délai de bande passante de la connexion TCP et de la fenêtre de réception annoncée du destinataire (et en partie la quantité de congestion dans le réseau).

La valeur ISB par connexion est disponible à partir de l’implémentation du protocole TCP dans Windows Server 2008 et versions ultérieures. La SIO_IDEAL_SEND_BACKLOG_QUERY IOCTL peut être utilisée par une application pour interroger la valeur ISB d’une connexion.

Pour plus d’informations, consultez la référence SIO_IDEAL_SEND_BACKLOG_QUERY .

SIO_IDEAL_SEND_BACKLOG_QUERY est pris en charge sur Windows Server 2008, Windows Vista avec SP1 et versions ultérieures du système d’exploitation.

SIO_KEEPALIVE_VALS (paramètre opcode : I, T==3)

Active ou désactive le paramètre de connexion de l’option tcp keep-alive qui spécifie le délai d’expiration et l’intervalle tcp keep-alive. Pour plus d’informations sur l’option keep-alive, consultez la section 4.2.3.6 sur les conditions requises pour les hôtes Internet : couches de communication spécifiées dans RFC 1122 disponible sur le site web IETF. (Cette ressource peut uniquement être disponible en anglais.)

SIO_KEEPALIVE_VALS pouvez être utilisé pour activer ou désactiver les sondes keep-alive et définir le délai d’expiration et l’intervalle de maintien en vie. Le délai d’expiration de conservation active spécifie le délai d’expiration, en millisecondes, sans activité tant que le premier paquet de conservation est envoyé. L’intervalle de conservation active spécifie l’intervalle, en millisecondes, entre le moment où les paquets keep-alive successifs sont envoyés si aucun accusé de réception n’est reçu.

L’option SO_KEEPALIVE , qui est l’une des options de socket SOL_SOCKET, peut également être utilisée pour activer ou désactiver la connexion TCP keep-alive sur une connexion, ainsi que pour interroger l’état actuel de cette option. Pour interroger si tcp keep-alive est activé sur un socket, la fonction getsockopt peut être appelée avec l’option SO_KEEPALIVE . Pour activer ou désactiver TCP keep-alive, la fonction setsockopt peut être appelée avec l’option SO_KEEPALIVE . Si tcp keep-alive est activé avec SO_KEEPALIVE, les paramètres TCP par défaut sont utilisés pour le délai d’expiration et l’intervalle de conservation actif, sauf si ces valeurs ont été modifiées à l’aide de SIO_KEEPALIVE_VALS.

Pour plus d’informations, consultez la référence SIO_KEEPALIVE_VALS . SIO_KEEPALIVE_VALS est pris en charge sur Windows 2000 et versions ultérieures.

SIO_LOOPBACK_FAST_PATH (paramètre opcode : I, T==3)

Configure un socket TCP pour réduire la latence et accélérer les opérations sur l’interface de bouclage. Cette IOCTL demande que la pile TCP/IP utilise un chemin rapide spécial pour les opérations de bouclage sur ce socket. La SIO_LOOPBACK_FAST_PATH IOCTL ne peut être utilisée qu’avec des sockets TCP. Ce IOCTL doit être utilisé sur les deux côtés de la session de bouclage. Le chemin rapide de bouclage TCP est pris en charge à l’aide de l’interface de bouclage IPv4 ou IPv6. Par défaut, SIO_LOOPBACK_FAST_PATH est désactivée.

Pour plus d’informations, consultez la référence SIO_LOOPBACK_FAST_PATH . SIO_LOOPBACK_FAST_PATH est pris en charge sur Windows 8, Windows Server 2012 et versions ultérieures.

SIO_MULTIPOINT_LOOPBACK (paramètre opcode : V, T==1)

Contrôle si les données envoyées par une application sur l’ordinateur local (pas nécessairement par le même socket) dans une session de multidiffusion seront reçues par un socket joint au groupe de destination multidiffusion sur l’interface de bouclage. La valeur TRUE entraîne la remise de données de multidiffusion par une application sur l’ordinateur local à un socket d’écoute sur l’interface de bouclage. La valeur FALSE empêche la remise de données multidiffusion par une application sur l’ordinateur local à un socket d’écoute sur l’interface de bouclage. Par défaut, SIO_MULTIPOINT_LOOPBACK est activé.

SIO_MULTICAST_SCOPE (paramètre opcode : I, T==1)

Spécifie l’étendue sur laquelle les transmissions de multidiffusion se produisent. L’étendue est définie comme le nombre de segments réseau routés à couvrir. Une portée de zéro indiquerait que la transmission de multidiffusion ne serait pas placée sur le câble, mais pourrait être diffusée entre les sockets au sein de l’hôte local. Une valeur d’étendue d’une (valeur par défaut) indique que la transmission sera placée sur le câble, mais ne traversera aucun routeur. Les valeurs d’étendue supérieure déterminent le nombre de routeurs qui peuvent être croisés. Notez que cela correspond au paramètre de durée de vie (TTL) dans la multidiffusion IP. Par défaut, l’étendue est 1.

SIO_QUERY_RSS_PROCESSOR_INFO (paramètre opcode : O, T==1)

Interroge l’association entre un socket et un cœur de processeur RSS et un nœud NUMA.

La SIO_QUERY_RSS_PROCESSOR_INFO IOCTL retourne une structure SOCKET_PROCESSOR_AFFINITY qui contient les PROCESSOR_NUMBER et l’ID de nœud NUMA. La structure de PROCESSOR_NUMBER retournée contient un numéro de groupe et un numéro de processeur relatif au sein du groupe.

Pour plus d’informations, consultez la référence SIO_QUERY_RSS_PROCESSOR_INFO . SIO_QUERY_RSS_PROCESSOR_INFO est pris en charge sur Windows 8, Windows Server 2012 et versions ultérieures.

SIO_QUERY_RSS_SCALABILITY_INFO (paramètre opcode : O, T==3)

Interroge les interfaces de déchargement pour la fonctionnalité de mise à l’échelle côté réception (RSS). La structure d’argument retournée pour SIO_QUERY_RSS_SCALABILITY_INFO est spécifiée dans la structure RSS_SCALABILITY_INFO définie dans le fichier d’en-tête Mstcpip.h . Cette structure est définie comme suit :

// Scalability info for the transport
typedef struct _RSS_SCALABILITY_INFO {
   BOOLEAN RssEnabled;
} RSS_SCALABILITY_INFO, *PRSS_SCALABILITY_INFO;

La valeur retournée dans le membre RssEnabled indique si RSS est activé sur au moins une interface.

Si la mémoire tampon de sortie n’est pas suffisamment grande pour la structure RSS_SCALABILITY_INFO (cbOutBuffer est inférieure à la taille d’un RSS_SCALABILITY_INFO) ou si le paramètre lpvOutBuffer est un pointeur NULL, SOCKET_ERROR est retourné en conséquence de ce IOCTL et WSAGetLastError retourne WSAEINVAL.

Dans la mise en réseau haute vitesse où plusieurs PROCESSEURs résident dans un seul système, la capacité de la pile de protocoles réseau à mettre à l’échelle correctement sur un système multi-UC est inhibée, car l’architecture de NDIS 5.1 et les versions antérieures limite le traitement du protocole à un seul processeur. La mise à l’échelle côté réception (RSS) résout ce problème en permettant à la charge réseau d’une carte réseau d’être équilibrée entre plusieurs processeurs.

SIO_QUERY_RSS_SCALABILITY_INFO est pris en charge sur Windows Vista et versions ultérieures.

SIO_QUERY_TRANSPORT_SETTING (paramètre opcode : I, T==3)

Interroge les paramètres de transport sur un socket. Le paramètre de transport interrogé est basé sur la TRANSPORT_SETTING_ID passée dans le paramètre lpvInBuffer .

Le seul paramètre de transport actuellement défini concerne la fonctionnalité de REAL_TIME_NOTIFICATION_CAPABILITY sur un socket TCP.

Si le TRANSPORT_SETTING_ID a le membre Guid défini sur REAL_TIME_NOTIFICATION_CAPABILITY, il s’agit d’une demande d’interrogation des paramètres de notification en temps réel pour le socket TCP utilisé avec ControlChannelTrigger pour recevoir des notifications réseau en arrière-plan dans une application du Windows Store. Si l’appel WSAIoctl ou WSPIoctl réussit, ce IOCTL retourne une structure REAL_TIME_NOTIFICATION_SETTING_OUTPUT avec l’état actuel.

Pour plus d’informations, consultez la référence SIO_QUERY_TRANSPORT_SETTING . SIO_QUERY_TRANSPORT_SETTING est pris en charge sur Windows 8, Windows Server 2012 et versions ultérieures.

SIO_QUERY_WFP_ALE_ENDPOINT_HANDLE (paramètre opcode : O, T==3)

Interroge le handle de point de terminaison ALE (Application Layer Enforcement).

La plateforme de filtrage Windows (PAM) prend en charge l’inspection et la modification du trafic réseau. Sur Windows Vista, le PAM se concentre sur les scénarios où l’ordinateur hôte est le point de terminaison de communication. Sur Windows Server 2008, toutefois, il existe des implémentations de pare-feu de périphérie qui souhaitent tirer parti de la plateforme PAM pour inspecter et proxy le trafic directe. Le serveur Internet Security and Acceleration (ISA) est un exemple d’appareil de périphérie de ce type.

Certains scénarios de pare-feu peuvent nécessiter la possibilité d’injecter un paquet entrant dans le chemin d’envoi associé à un point de terminaison existant. Il doit y avoir un mécanisme permettant de découvrir le handle de point de terminaison de couche de transport associé au point de terminaison de destination. L’application qui a créé le point de terminaison possède ces points de terminaison de couche de transport. Cette IOCTL est utilisée pour fournir un handle de socket au mappage de handle de point de terminaison de couche de transport.

Si la mémoire tampon de sortie n’est pas suffisamment grande pour le handle de point de terminaison (cbOutBuffer est inférieure à la taille d’un UINT64) ou si le paramètre lpvOutBuffer est un pointeur NULL, SOCKET_ERROR est retourné en conséquence de ce IOCTL et WSAGetLastError retourne WSAEINVAL.

SIO_QUERY_WFP_ALE_ENDPOINT_HANDLE est pris en charge sur Windows Vista et versions ultérieures.

SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT (paramètre opcode : I, T==3)

Interroge le contexte de redirection d’un enregistrement de redirection utilisé par un service de redirection de plateforme de filtrage Windows (PAM).

La SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT IOCTL est utilisée pour fournir le suivi des connexions de connexion proxiées sur les connexions de socket redirigées. Cette fonctionnalité PAM facilite le suivi des enregistrements de redirection à partir de la redirection initiale d’une connexion vers la connexion finale à la destination.

Pour plus d’informations, consultez la référence SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT . SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT est pris en charge sur Windows 8, Windows Server 2012 et versions ultérieures.

SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS (paramètre opcode : I, T==3)

Interroge l’enregistrement de redirection pour la connexion TCP/IP acceptée à utiliser par un service de redirection de plateforme de filtrage Windows (PAM).

La SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS IOCTL est utilisée pour fournir le suivi des connexions de connexion proxiées sur les connexions de socket redirigées. Cette fonctionnalité PAM facilite le suivi des enregistrements de redirection à partir de la redirection initiale d’une connexion vers la connexion finale à la destination.

Pour plus d’informations, consultez la référence SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS . SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS est pris en charge sur Windows 8, Windows Server 2012 et versions ultérieures.

SIO_RCVALL (paramètre opcode : I, T==3)

Permet à un socket de recevoir tous les paquets IPv4 ou IPv6 passant par une interface réseau. Le handle de socket passé à la fonction WSAIoctl doit être l’un des éléments suivants :

• Socket IPv4 créé avec la famille d’adresses définie sur AF_INET, le type de socket défini sur SOCK_RAW et le protocole défini sur IPPROTO_IP.
• Un socket IPv6 créé avec la famille d’adresses définie sur AF_INET6, le type de socket défini sur SOCK_RAW et le protocole défini sur IPPROTO_IPV6.

Le socket doit également être lié à une interface IPv4 ou IPv6 locale explicite, ce qui signifie que vous ne pouvez pas lier à INADDR_ANY ou in6addr_any.

Sur Windows Server 2008 et versions antérieures, le paramètre SIO_RCVALL IOCTL ne capture pas les paquets locaux envoyés à partir d’une interface réseau. Cela incluait les paquets reçus sur une autre interface et transférés l’interface réseau spécifiée pour la SIO_RCVALL IOCTL.

Sur Windows 7 et Windows Server 2008 R2, cela a été modifié afin que les paquets locaux envoyés à partir d’une interface réseau soient également capturés. Cela inclut les paquets reçus sur une autre interface, puis transférés l’interface réseau liée au socket avec SIO_RCVALL IOCTL.

La définition de ce IOCTL nécessite le privilège Administrateur sur l’ordinateur local.

Cette fonctionnalité est parfois appelée mode promiscuous.

Les valeurs possibles pour l’option SIO_RCVALL IOCTL sont spécifiées dans l’énumération RCVALL_VALUE définie dans le fichier d’en-tête Mstcpip.h . Les valeurs possibles pour SIO_RCVALL sont les suivantes :

Pour plus d’informations, consultez la référence SIO_RCVALL .

SIO_RCVALL est pris en charge sur Windows 2000 et versions ultérieures.

SIO_RCVALL_IGMPMCAST (paramètre opcode : I, T==3)

Permet à un socket de recevoir tout le trafic IP de multidiffusion IGMP sur le réseau, sans recevoir d’autres trafics IP multidiffusion. Le handle de socket transmis à la fonction WSAIoctl doit être de AF_INET famille d’adresses, de type de socket SOCK_RAW et de protocole IPPROTO_IGMP. Le socket doit également être lié à une interface locale explicite, ce qui signifie que vous ne pouvez pas lier à INADDR_ANY.

Une fois le socket lié et le jeu IOCTL, les appels aux fonctions WSARecv ou recv retournent des datagrammes d’adresse IP de multidiffusion qui transitent par l’interface donnée. Notez que vous devez fournir une mémoire tampon suffisamment importante. La définition de ce IOCTL nécessite le privilège Administrateur sur l’ordinateur local.

SIO_RCVALL_IGMPMCAST est pris en charge sur Windows 2000 et versions ultérieures.

SIO_RCVALL_MCAST (paramètre opcode : I, T==3)

Permet à un socket de recevoir tout le trafic IP multidiffusion sur le réseau (autrement dit, tous les paquets IP destinés aux adresses IP comprises entre 224.0.0.0 et 239.255.255.255.255). Le handle de socket transmis à la fonction WSAIoctl doit être de AF_INET famille d’adresses, SOCK_RAW type de socket et IPPROTO_UDP protocole. Le socket doit également être lié à une interface locale explicite, ce qui signifie que vous ne pouvez pas lier à INADDR_ANY. Le socket doit être lié au port zéro.

Une fois le socket lié et le jeu IOCTL, les appels aux fonctions WSARecv ou recv retournent des datagrammes d’adresse IP de multidiffusion qui transitent par l’interface donnée. Notez que vous devez fournir une mémoire tampon suffisamment importante. La définition de ce IOCTL nécessite le privilège Administrateur sur l’ordinateur local.

SIO_RCVALL_MCAST est pris en charge sur Windows 2000 et versions ultérieures.

SIO_RELEASE_PORT_RESERVATION (paramètre opcode : I, T==3)

Libère une réservation d’exécution pour un bloc de ports TCP ou UDP. La réservation d’exécution à libérer doit avoir été obtenue à partir du processus d’émission à l’aide de la SIO_ACQUIRE_PORT_RESERVATION IOCTL.

Pour plus d’informations, consultez la référence SIO_RELEASE_PORT_RESERVATION .

SIO_RELEASE_PORT_RESERVATION est pris en charge sur Windows Vista et les versions ultérieures du système d’exploitation.

SIO_ROUTING_INTERFACE_CHANGE (paramètre opcode : I, T==1)

Pour recevoir la notification d’une modification de l’interface de routage qui doit être utilisée pour atteindre l’adresse distante dans la mémoire tampon d’entrée (spécifiée comme structure sockaddr ). Aucune information de sortie sur la nouvelle interface de routage ne sera fournie à l’achèvement de ce IOCTL ; la saisie semi-automatique indique simplement que l’interface de routage d’une destination donnée a changé et doit être interrogée à l’aide de la SIO_ROUTING_INTERFACE_QUERY IOCTL.

Il est supposé, bien qu’il ne soit pas nécessaire, que l’application utilise des E/S superposées pour être avertie du changement de l’interface de routage via l’achèvement de SIO_ROUTING_INTERFACE_CHANGE demande. Sinon, si le SIO_ROUTING_INTERFACE_CHANGE IOCTL est émis sur un socket non bloquant avec les paramètres lpOverlapped et lpCompletionRoutine définis sur NULL), il se termine immédiatement en retour et WSAEWOULDBLOCK en tant qu’erreur, et l’application peut alors attendre le routage des événements de modification via l’appel à WSAEventSelect ou WSAAsyncSelect avec FD_ROUTING_INTERFACE_CHANGE bit défini dans le masque d’événements réseau.

Il est reconnu que les informations de routage restent stables dans la plupart des cas afin que l’application conserve plusieurs iocTLs en attente pour obtenir des notifications sur toutes les destinations qui lui intéressent, ainsi que le fait que le fournisseur de services effectue le suivi de ces demandes de notification utilisera une quantité importante de ressources système. Cette situation peut être évitée en étendant la signification des paramètres d’entrée et en assouplissant les exigences du fournisseur de services comme suit :

• L’application peut spécifier une adresse générique spécifique à une famille de protocoles (identique à celle utilisée dans l’appel de liaison lors de la demande de liaison à n’importe quelle adresse disponible) pour demander des notifications de modifications de routage. Cela permet à l’application de conserver une seule SIO_ROUTING_INTERFACE_CHANGE en attente pour tous les sockets et destinations dont elle dispose, puis d’utiliser SIO_ROUTING_INTERFACE_QUERY pour obtenir les informations de routage réelles.
• Un fournisseur de services a la possibilité d’ignorer les informations spécifiées par l’application dans la mémoire tampon d’entrée du SIO_ROUTING_INTERFACE_CHANGE (comme si l’application a spécifié une adresse générique) et de terminer l’événement SIO_ROUTING_INTERFACE_CHANGE IOCTL ou signal FD_ROUTING_INTERFACE_CHANGE événement en cas de modification des informations de routage (pas seulement l’itinéraire vers la destination spécifiée dans la mémoire tampon d’entrée).

SIO_ROUTING_INTERFACE_QUERY (paramètre opcode : I, O, T==1)

Pour obtenir l’adresse de l’interface locale (représentée sous forme de structure sockaddr ), qui doit être utilisée pour envoyer à l’adresse distante spécifiée dans la mémoire tampon d’entrée (en tant que sockaddr). Les adresses de multidiffusion distantes peuvent être envoyées dans la mémoire tampon d’entrée pour obtenir l’adresse de l’interface préférée pour la transmission de multidiffusion. Dans tous les cas, l’adresse de l’interface retournée peut être utilisée par l’application dans une requête bind() ultérieure.

Notez que les itinéraires sont susceptibles de changer. Par conséquent, les applications ne peuvent pas compter sur les informations retournées par SIO_ROUTING_INTERFACE_QUERY pour être persistantes. Les applications peuvent s’inscrire à des notifications de modification de routage via la SIO_ROUTING_INTERFACE_CHANGE IOCTL, qui fournit une notification par le biais d’E/S superposées ou d’un événement FD_ROUTING_INTERFACE_CHANGE. La séquence d’actions suivante peut être utilisée pour garantir que l’application dispose toujours d’informations d’interface de routage actuelles pour une destination donnée :

• Problème SIO_ROUTING_INTERFACE_CHANGE IOCTL
• Problème SIO_ROUTING_INTERFACE_QUERY IOCTL
• Chaque fois que SIO_ROUTING_INTERFACE_CHANGE IOCTL notifie l’application de la modification du routage (par le biais d’E/S superposées ou en signalant FD_ROUTING_INTERFACE_CHANGE événement), l’ensemble de la séquence d’actions doit être répétée.

Si la mémoire tampon de sortie n’est pas suffisamment grande pour contenir l’adresse de l’interface, SOCKET_ERROR est retournée en conséquence de ce IOCTL et WSAGetLastError retourne WSAEFAULT. La taille requise de la mémoire tampon de sortie est retournée dans lpcbBytesReturned dans ce cas. Notez que le code d’erreur WSAEFAULT est également retourné si le paramètre lpvInBuffer, lpvOutBuffer ou lpcbBytesReturned n’est pas totalement contenu dans une partie valide de l’espace d’adressage utilisateur.

Si l’adresse de destination spécifiée dans la mémoire tampon d’entrée ne peut pas être atteinte via l’une des interfaces disponibles, SOCKET_ERROR est retournée en conséquence de ce IOCTL et WSAGetLastError retourne WSAENETUNREACH ou même WSAENETDOWN si toute la connectivité réseau est perdue.

SIO_SET_COMPATIBILITY_MODE (paramètre opcode : I, T==3)

Demande comment la pile réseau doit gérer certains comportements pour lesquels la façon par défaut de gérer le comportement peut différer entre les versions de Windows. La structure d’arguments pour SIO_SET_COMPATIBILITY_MODE est spécifiée dans la structure WSA_COMPATIBILITY_MODE définie dans le fichier d’en-tête Mswsockdef.h . Cette structure est définie comme suit :

/* Argument structure for SIO_SET_COMPATIBILITY_MODE */
typedef struct _WSA_COMPATIBILITY_MODE {
    WSA_COMPATIBILITY_BEHAVIOR_ID BehaviorId;
    ULONG TargetOsVersion;
} WSA_COMPATIBILITY_MODE, *PWSA_COMPATIBILITY_MODE;

La valeur spécifiée dans le membre BehaviorId indique le comportement demandé. La valeur spécifiée dans le membre TargetOsVersion indique la version De Windows demandée pour le comportement.

Le membre BehaviorId peut être l’une des valeurs du type d’énumération WSA_COMPATIBILITY_BEHAVIOR_ID défini dans le fichier d’en-tête Mswsockdef.h . Les valeurs possibles pour le membre BehaviorId sont les suivantes.

Pour plus d’informations, consultez la référence SIO_SET_COMPATIBILITY_MODE .

SIO_SET_COMPATIBILITY_MODE est pris en charge sur Windows Vista et versions ultérieures.

SIO_SET_GROUP_QOS (paramètre opcode : I, T==1)

Réservé.

SIO_SET_PRIORITY_HINT (paramètre opcode : I, T==3)

Fournit un indicateur au protocole de transport sous-jacent pour traiter le trafic sur ce socket avec une priorité spécifique. Le lpvInBuffer doit pointer vers une variable de type PRIORITY_HINT avec cbInBuffer défini sur sizeof(PRIORITY_HINT). Les paramètres lpvOutBuffer et cbOutBuffer doivent être NULL et 0, respectivement. L’implémentation TCP de Microsoft Windows prend en charge cette IOCTL à partir de Windows 10, version 1809 (10.0 ; Build 17763) et versions ultérieures comme suit : lorsque la valeur de priorité demandée est définie sur IoPriorityHintVeryLow, TCP utilise une version modifiée de l’algorithme LEDBAT (défini dans RFC 6817) pour contrôler le taux de trafic sortant sur le socket. Le trafic entrant n’est pas affecté par cette IOCTL. LEDBAT est un algorithme de scavenger, et son objectif est de maintenir la latence faible et d’empêcher tout effet négatif sur le trafic de priorité normale en sortant du chemin lorsque le trafic de priorité normale est présent.

Voir également RFC 6817.

SIO_SET_PRIORITY_HINT est pris en charge sur Windows 10, version 1809 (10.0 ; Build 17763) et versions ultérieures.

SIO_SET_QOS (paramètre opcode : I, T==1)

Associez la structure QOS spécifiée au socket. Aucune mémoire tampon de sortie n’est requise, la structure QOS est obtenue à partir de la mémoire tampon d’entrée. Le code d’erreur WSAENOPROTOOPT est indiqué pour les fournisseurs de services qui ne prennent pas en charge la qualité du service.

SIO_TCP_INITIAL_RTO (paramètre opcode : I, T==3)

Contrôle les caractéristiques de retransmission initiales (SYN/SYN+ACK) d’un socket TCP en configurant les paramètres RTO (Initial Retransmission Timeout). Les paramètres de configuration sont spécifiés dans une structure TCP_INITIAL_RTO_PARAMETERS .

Pour plus d’informations, consultez la référence SIO_TCP_INITIAL_RTO . SIO_TCP_INITIAL_RTO est pris en charge sur Windows 8, Windows Server 2012 et versions ultérieures.

SIO_TIMESTAMPING

IocTL de socket utilisé pour configurer la réception des horodatages de transmission/réception de socket. Valide uniquement pour les sockets de datagramme. Le type d’entrée de SIO_TIMESTAMPING est la structure TIMESTAMPING_CONFIG .

Voir également l’horodatage Winsock.

SIO_TRANSLATE_HANDLE (paramètre opcode : I, O, T==1)

Pour obtenir un handle correspondant pour les sockets valides dans le contexte d’une interface complémentaire (par exemple, TH_NETDEV et TH_TAPI). Une constante de manifeste identifiant l’interface complémentaire ainsi que les autres paramètres nécessaires sont spécifiés dans la mémoire tampon d’entrée. Le handle correspondant sera disponible dans la mémoire tampon de sortie à l’achèvement de cette fonction. Reportez-vous à la section appropriée dans les annexes Winsock pour plus d’informations spécifiques à une interface complémentaire particulière. Le code d’erreur WSAENOPROTOOPT est indiqué pour les fournisseurs de services qui ne prennent pas en charge cette IOCTL pour l’interface complémentaire spécifiée. Ce IOCTL récupère le handle associé à l’aide de SIO_TRANSLATE_HANDLE.

Il est recommandé d’utiliser com (Component Object Model) au lieu de cette IOCTL pour découvrir et suivre d’autres interfaces qui peuvent être prises en charge par un socket. Ce IOCTL est présent pour la compatibilité descendante avec les systèmes où COM n’est pas disponible ou ne peut pas être utilisé pour une autre raison.

SIO_UDP_CONNRESET (paramètre opcode : I, T==3)

Windows XP : Contrôle si les messages UDP PORT_UNREACHABLE sont signalés. Définissez la valeur TRUE pour activer la création de rapports. Définissez la valeur FALSE pour désactiver la création de rapports.

SIO_UDP_NETRESET

Détermine si les messages NET_UNREACHABLE (TTL expiré) sont signalés sur les sockets UDP via recv/WSARecv/etc. Passez TRUE dans la mémoire tampon d’entrée pour l’activer (par défaut si elle est prise en charge). Passez FALSE pour désactiver la création de rapports.

SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS (paramètre opcode : I, T==3)

Définit l’enregistrement de redirection vers le nouveau socket TCP utilisé pour la connexion à la destination finale à utiliser par un service de redirection de plateforme de filtrage Windows (PAM).

La SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS IOCTL est utilisée dans le cadre du suivi des connexions proxiées sur les connexions de socket redirigées. Cette fonctionnalité PAM facilite le suivi des enregistrements de redirection à partir de la redirection initiale d’une connexion vers la connexion finale à la destination.

Pour plus d’informations, consultez la référence SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS . SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS est pris en charge sur Windows 8, Windows Server 2012 et versions ultérieures.

SIO_TCP_INFO (paramètre opcode : I, O, T==3)

Récupère les statistiques TCP d’un socket. Les statistiques TCP sont fournies dans une structure TCP_INFO_v0 .

Contrairement à la récupération de statistiques TCP avec la fonction GetPerTcpConnectionEStats , la récupération de statistiques TCP avec ce code de contrôle n’exige pas que le code utilisateur charge, stocke et filtre la table de connexion TCP et ne nécessite pas de privilèges élevés à utiliser.

Pour plus d’informations, consultez SIO_TCP_INFO. SIO_TCP_INFO est pris en charge sur Windows 10, version 1703, Windows Server 2016 et versions ultérieures.

Remarques

Winsock Ioctls sont définis dans un certain nombre de fichiers d’en-tête différents. Il s’agit notamment du fichier d’en-tête Winsock2.h, Mswsock.h et Mstcpip.h .

Sur le Kit de développement logiciel (SDK) Microsoft Windows publié pour Windows Vista et versions ultérieures, l’organisation des fichiers d’en-tête a changé et un certain nombre de Winsock Ioctls sont également définis dans les fichiers d’en-tête Ws2def.h, Ws2ipdef.h et Mswsockdef.h . Le fichier d’en-tête Ws2def.h est automatiquement inclus par le fichier d’en-tête Winsock2.h . Le fichier d’en-tête Ws2ipdef.h est automatiquement inclus par le fichier d’en-tête Ws2tcpip.h . Le fichier d’en-tête Mswsockdef.h est automatiquement inclus dans le fichier d’en-tête Mswsockdef.h .

Spécifications