Winsock IOCTLs

  • Article

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 afin de contrôler le mode d’un socket, le protocole de transport ou le sous-système de communication.

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

Il est possible d’adopter un schéma d’encodage qui conserve les opcodes ioctlsocket actuellement définis tout en offrant un moyen pratique de partitionner l’espace d’identificateur d’opcode dans la mesure où 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 la forme suivante.

I O V T Famille fournisseur/adresse Code
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

Notes

Les bits du paramètre dwIoControlCode affichés dans la table doivent être lus verticalement de haut en bas par colonne. Par conséquent, le bit le plus à gauche est le bit 31, le bit suivant est le bit 30 et le bit le plus à droite est le bit 0.

I est 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 à l’aide de tampons d’entrée et de sortie définissent les E et O.

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 IOCTL Unix 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 les sockets Windows 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 de se voir attribuer un numéro de fournisseur qui apparaît dans le paramètre de la famille Fournisseur/Adresse . Ensuite, le fournisseur peut définir de nouvelles IOCTL spécifiques à ce fournisseur sans avoir à inscrire le IOCTL auprès d’un centre d’information, offrant ainsi flexibilité et confidentialité au 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 un long non signé (QoS), qui est différent 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 remettre le socket en mode de blocage échoue avec WSAEINVAL. Pour remettre 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 de manière atomique à partir des sockets. Le paramètre lpvOutBuffer pointe vers un long non signé dans lequel WSAIoctl stocke le résultat.

Si le socket transmis dans le paramètre s est orienté vers le flux (par exemple, le type SOCK_STREAM), FIONREAD retourne la quantité totale de données pouvant être lues en 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 transmis dans le paramètre s est orienté message (par exemple, type SOCK_DGRAM), FIONREAD retourne les rapports le nombre total d’octets disponibles en 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 type stream (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 d’être lue, l’opération retourne TRUE. Sinon, il retourne FALSE, et l’opération de réception suivante effectuée sur le socket récupérera tout ou partie des données précédant la marque ; l’application doit utiliser l’opération SIOCATMARK pour déterminer s’il en reste. S’il existe des données normales précédant les données urgentes (hors bande), elles sont reçues dans l’ordre. (Notez que les opérations recv ne combineront jamais OOB et données 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 ports 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 durent uniquement 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 port persistant créées à l’aide de la fonction CreatePersistentTcpPortReservation ou CreatePersistentUdpPortReservation peuvent être consommées par n’importe quel processus ayant 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 apportées à la liste des adresses de transport locales de la famille de protocoles du socket à laquelle l’application peut se lier. Aucune information sur la sortie ne sera fournie une fois le présent IOCTL terminé; la saisie semi-automatique indique simplement que la liste des adresses locales disponibles a changé et doit être interrogée à nouveau via SIO_ADDRESS_LIST_QUERY.

Il est supposé (bien que non obligatoire) que l’application utilise des E/S qui se chevauchent pour être avertie de la modification par l’achèvement de SIO_ADDRESS_LIST_CHANGE demande. Si le SIO_ADDRESS_LIST_CHANGE IOCTL est émis sur un socket non bloquant et sans paramètres qui se chevauchent (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 la liste d’adresses via 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 se lier. La liste des adresses varie en fonction de la famille d’adresses et certaines adresses sont exclues de la liste.

Notes

Dans les environnements Windows Plug-n-Play, les adresses peuvent être ajoutées et supprimées dynamiquement. Par conséquent, les applications ne peuvent pas s’appuyer sur les informations retournées par SIO_ADDRESS_LIST_QUERY être persistantes. Les applications peuvent s’inscrire aux notifications de changement d’adresse par le biais du SIO_ADDRESS_LIST_CHANGE IOCTL qui fournit la notification par le biais d’E/S qui se chevauchent ou de FD_ADDRESS_LIST_CHANGE événement. La séquence d’actions suivante peut être utilisée pour garantir que l’application dispose toujours des informations de liste d’adresses actuelles :

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

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é 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 afin de 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)

Associe ce socket au handle spécifié d'une interface connexe. La mémoire tampon d’entrée contient la valeur entière correspondant à la constante de manifeste pour 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 toutes les 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 ce IOCTL. Le handle associé par ce 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 pour qu’ils ne soient pas mappés à des fonctions Windows Socket existantes ou à celles susceptibles d’être définies à l’avenir. Il est recommandé d’utiliser com (Component Object Model) à la place de cet 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 d’exécution pour un bloc de ports TCP ou UDP identifiés par le jeton de réservation de port. Le SIO_ASSOCIATE_PORT_RESERVATION IOCTL doit être émis avant que le socket ne soit lié. Si et quand le socket est lié, le port qui lui est affecté 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 la 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 cet 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 assez grande pour un handle de socket (la valeur cbOutBuffer est inférieure à la taille d’un SOCKET) ou si le paramètre lpvOutBuffer est un pointeur NULL , SOCKET_ERROR est retourné comme résultat de ce IOCTL et WSAGetLastError renvoie 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 assez grande pour un handle de socket (la valeur cbOutBuffer est inférieure à la taille d’un SOCKET) ou si le paramètre lpvOutBuffer est un pointeur NULL , SOCKET_ERROR est retourné comme résultat de ce IOCTL et WSAGetLastError renvoie 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 assez grande pour un handle de socket (la valeur cbOutBuffer est inférieure à la taille d’un SOCKET) ou si le paramètre lpvOutBuffer est un pointeur NULL , SOCKET_ERROR est retourné comme résultat de ce IOCTL et WSAGetLastError renvoie 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 assez 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é comme résultat de ce IOCTL et WSAGetLastError renvoie 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 de transition), 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é de service du Kit de développement logiciel (SDK) de plateforme.

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

Active le partage de port et la parallélisation d’indication 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 entre les sockets en fonction du hachage RSS (Receive Side Scaling). Les paramètres RSS ne changent pas, de sorte qu’un 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 au même socket. Ce IOCTL doit être appelé avant la liaison, sinon WSAEINVAL est retourné. La mémoire tampon d’entrée est un index de processeur (basé sur 0) de type USHORT. Le IOCTL n’est pas compatible avec SO_REUSEADDR et SO_REUSE_MULTICASTPORT. Pris en charge uniquement pour les sockets UDP.

Notes

Si vous ciblez la version 10.0.19041.0 (Windows 10, version 2004) du Kit de développement logiciel (SDK) Windows, utilisez la valeur 0x98000015 au lieu du nom SIO_CPU_AFFINITY.

SIO_ENABLE_CIRCULAR_QUEUEING (paramètre d’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 la 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 qui vient d’arriver. Aucune mémoire tampon d’entrée et de sortie n’est requise. Notez que cet IOCTL n’est valide que pour les sockets associés à des protocoles orientés messages non fiables. Le code d’erreur WSAENOPROTOOPT est indiqué pour les fournisseurs de services qui ne prennent pas en charge ce IOCTL.

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

Lorsqu’il est émis, cet 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 de l’IPX de Novell, cet appel lance un GetLocalTarget (GLT) IPX, 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 ce IOCTL.

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

Cet IOCTL remplit la mémoire tampon de sortie avec une structure sockaddr contenant une adresse de diffusion appropriée à utiliser avec sendto/ WSASendTo. Cet 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 pour les 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 :

Terme Description
WSAID_ACCEPTEX
 Fonction d’extension AcceptEx .
WSAID_CONNECTEX
 Fonction d’extension ConnectEx .
WSAID_DISCONNECTEX
 Fonction d’extension DisconnectEx .
WSAID_GETACCEPTEXSOCKADDRS
 Fonction d’extension GetAcceptExSockaddrs .
WSAID_TRANSMITFILE
 Fonction d’extension TransmitFile .
WSAID_TRANSMITPACKETS
 Fonction d’extension TransmitPackets .
WSAID_WSARECVMSG
 Fonction d’extension LPFN_WSARECVMSG (WSARecvMsg).
WSAID_WSASENDMSG
 Fonction d’extension WSASendMsg .

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

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

Récupérez la structure QOS associée au groupe de sockets auquel ce socket appartient. La mémoire tampon d’entrée est facultative. Certains protocoles (par exemple, RSVP) permettent d’utiliser la mémoire tampon d’entrée pour qualifier une demande de qualité de service. La structure QOS sera 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 en tant que tableau de structures INTERFACE_INFO .

Notes

La prise en charge de cette commande est obligatoire pour les fournisseurs de services TCP/IP compatibles Windows Sockets 2.

Le paramètre lpvOutBuffer pointe vers la mémoire tampon dans laquelle stocker les informations sur les interfaces en tant que tableau de structures INTERFACE_INFO pour les adresses IP unicast 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 socket s n’est pas défini comme IPPROTO_IP, WSAEINVAL est retourné. Un appel à la fonction WSAIoctl avec SIO_GET_INTERFACE_LIST renvoie WSAEFAULT si le paramètre cbOutBuffer qui spécifie la longueur de la mémoire tampon de sortie est trop petit 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é à une utilisation ultérieure avec des sockets.

Retourne une liste d’interfaces IP configurées et de leurs paramètres en tant que tableau de structures INTERFACE_INFO_EX .

Le paramètre lpvOutBuffer pointe vers la mémoire tampon dans laquelle stocker les informations sur les interfaces en tant que tableau de structures INTERFACE_INFO_EX pour les adresses IP unidiffusion 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é à 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 d’utiliser la mémoire tampon d’entrée pour qualifier une demande de qualité de service. La structure QOS sera 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 ne peut 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

Socket IOCTL 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 socket SIO_TIMESTAMPING IOCTL. 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.

Notes

Les horodatages TX ne sont pas pris en charge lors d’un envoi coalesced via UDP_SEND_MSG_SIZE.

Voir également Horodatage Winsock.

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

Avertit une application lorsque la valeur du backlog d’envoi idéal (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 non encore reconnues) dans TCP afin d’obtenir le débit le plus élevé. La valeur idéale pour la quantité de données en attente pour obtenir le meilleur débit pour la connexion TCP est appelée taille de backlog d’envoi idéale (ISB). La valeur ISB est fonction du produit de délai de bande passante de la connexion TCP et de la fenêtre de réception annoncée du récepteur (et en partie de 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 les versions ultérieures du système d’exploitation. Le SIO_IDEAL_SEND_BACKLOG_CHANGE IOCTL peut être utilisé par une application pour obtenir 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 les 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 (ISB) idéale 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 non encore reconnues) dans TCP afin d’obtenir le débit le plus élevé. La valeur idéale pour la quantité de données en attente pour obtenir le meilleur débit pour la connexion TCP est appelée taille de backlog d’envoi idéale (ISB). La valeur ISB est fonction du produit de délai de bande passante de la connexion TCP et de la fenêtre de réception annoncée du récepteur (et en partie de 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. Le SIO_IDEAL_SEND_BACKLOG_QUERY IOCTL peut être utilisé 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 les versions ultérieures du système d’exploitation.

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

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

SIO_KEEPALIVE_VALS permet d’activer ou de désactiver les sondes de conservation et de définir le délai d’expiration et l’intervalle de conservation. Le délai d’attente de conservation spécifie le délai d’attente, en millisecondes, sans activité tant que le premier paquet keep-alive n’est pas envoyé. L’intervalle de conservation spécifie l’intervalle, en millisecondes, entre l’envoi de paquets de conservation successifs 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 le maintien tcp en vie sur une connexion, ainsi que pour interroger l’état actuel de cette option. Pour savoir 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 la conservation TCP est activée avec SO_KEEPALIVE, les paramètres TCP par défaut sont utilisés pour le délai d’attente et l’intervalle de conservation, 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 une latence plus faible et des opérations plus rapides sur l’interface de bouclage. Ce IOCTL demande que la pile TCP/IP utilise un chemin d’accès rapide spécial pour les opérations de bouclage sur ce socket. Le SIO_LOOPBACK_FAST_PATH IOCTL ne peut être utilisé qu’avec des sockets TCP. Ce IOCTL doit être utilisé des 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é.

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 de multidiffusion sur l’interface de bouclage. La valeur TRUE entraîne la remise des données de multidiffusion envoyées par une application sur l’ordinateur local à un socket d’écoute sur l’interface de bouclage. La valeur FALSE empêche les données de multidiffusion envoyées 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 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 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 de un (valeur par défaut) indique que la transmission sera placée sur le réseau, mais ne traversera aucun routeur. Des valeurs d’étendue plus élevées 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 de SOCKET_PROCESSOR_AFFINITY qui contient le PROCESSOR_NUMBER et l’ID de nœud NUMA. La structure 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 tant que résultat de ce IOCTL et WSAGetLastError retourne WSAEINVAL.

Dans la mise en réseau à haut débit où plusieurs processeurs résident dans un seul système, la capacité de la pile de protocoles de mise en réseau à bien évoluer sur un système multi-processeur est freinée, car l’architecture de NDIS 5.1 et des 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 l’équilibrage de la charge réseau à partir d’une carte réseau 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 les TRANSPORT_SETTING_ID passées dans le paramètre lpvInBuffer .

Le seul paramètre de transport actuellement défini concerne la fonctionnalité 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 que le socket TCP utilisé avec le ControlChannelTrigger reçoive des notifications réseau en arrière-plan dans une application du Windows Store. Si l’appel WSAIoctl ou WSPIoctl réussit, cet IOCTL retourne une structure REAL_TIME_NOTIFICATION_SETTING_OUTPUT avec la status actuelle.

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 Application Layer Enforcement (ALE).

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

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 pour découvrir le handle de point de terminaison de la couche 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. Cet IOCTL est utilisé pour fournir un handle de socket au mappage de handles de point de terminaison de la couche de transport.

Si la mémoire tampon de sortie n’est pas suffisamment grande pour le handle de point de terminaison (le cbOutBuffer est inférieur à la taille d’un UINT64) ou si le paramètre lpvOutBuffer est un pointeur NULL , SOCKET_ERROR est retourné en tant que résultat 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 pour un enregistrement de redirection utilisé par un service de redirection de plateforme de filtrage Windows (PAM).

Le SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT IOCTL est utilisé pour fournir un suivi de connexion proxié 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 vers 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 la plateforme de filtrage Windows (PAM).

Le SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS IOCTL est utilisé pour fournir un suivi de connexion proxié 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 vers 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 suivants :

  • Un 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 IOCTL SIO_RCVALL 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 vers l’interface réseau spécifiée pour le 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 hors de l’interface réseau liée au socket avec SIO_RCVALL IOCTL.

La définition de ce IOCTL nécessite des privilèges d’administrateur sur l’ordinateur local.

Cette fonctionnalité est parfois appelée mode promiscuous.

Les valeurs possibles pour l’option IOCTL SIO_RCVALL 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 :

Terme Description
RCVALL_OFF
 Désactivez cette option afin qu’un socket ne reçoive pas tous les paquets IPv4 ou IPv6 sur le réseau.
RCVALL_ON
 Activez cette option pour qu’un socket reçoive tous les paquets IPv4 ou IPv6 sur le réseau. Cette option active le mode promiscuous sur l’interface réseau carte (carte réseau), si la carte réseau prend en charge le mode promiscuous. Sur un segment LAN avec un hub réseau, une carte réseau qui prend en charge le mode promiscuous capture tout le trafic IPv4 ou IPv6 sur le réseau local, y compris le trafic entre d’autres ordinateurs sur le même segment LAN. Tous les paquets capturés (IPv4 ou IPv6, selon le socket) sont remis au socket brut.
Cette option ne capture pas d’autres paquets (paquets ARP, IPX et NetBEUI, par exemple) sur l’interface.
Netmon utilise le même mode pour l’interface réseau, mais n’utilise pas cette option pour capturer le trafic.
RCVALL_SOCKETLEVELONLY
 Cette fonctionnalité n’étant pas implémentée actuellement, la définition de cette option n’a aucun impact.
RCVALL_IPLEVEL
 Activez cette option pour qu’un socket IPv4 ou IPv6 reçoive tous les paquets au niveau ip sur le réseau. Cette option n’active pas le mode promiscuous sur l’interface réseau carte. Cette option affecte uniquement le traitement des paquets au niveau de l’adresse IP. La carte réseau reçoit toujours uniquement des paquets dirigés vers ses adresses de monodiffusion et de multidiffusion configurées. Toutefois, un socket avec cette option activée recevra non seulement des paquets dirigés vers des adresses IP spécifiques, mais recevra également tous les paquets IPv4 ou IPv6 que la carte réseau reçoit.
Cette option ne capture pas les autres paquets (paquets ARP, IPX et NetBEUI, par exemple) reçus sur l’interface.

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’autre trafic IP de multidiffusion. Le handle de socket passé à la fonction WSAIoctl doit être de AF_INET famille d’adresses, SOCK_RAW type de socket et 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 que le socket est lié et que l’IOCTL est défini, les appels aux fonctions WSARecv ou recv retournent des datagrammes IP de multidiffusion via l’interface donnée. Notez que vous devez fournir une mémoire tampon suffisamment grande. La définition de ce IOCTL nécessite des privilèges d’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 de multidiffusion sur le réseau (autrement dit, tous les paquets IP destinés aux adresses IP dans la plage de 224.0.0.0 à 239.255.255.255). Le handle de socket passé à la fonction WSAIoctl doit être de AF_INET famille d’adresses, SOCK_RAW type de socket et protocole IPPROTO_UDP. 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 que le socket est lié et que l’IOCTL est défini, les appels aux fonctions WSARecv ou recv retournent des datagrammes IP de multidiffusion via l’interface donnée. Notez que vous devez fournir une mémoire tampon suffisamment grande. La définition de ce IOCTL nécessite des privilèges d’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 du 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 en tant que structure sockaddr ). Aucune information de sortie sur la nouvelle interface de routage ne sera fournie à l’issue du présent IOCTL; L’achèvement 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 obligatoire, que l’application utilise des E/S qui se chevauchent pour être avertie de la modification de l’interface de routage par 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 retourne immédiatement et WSAEWOULDBLOCK en tant qu’erreur, et l’application peut ensuite attendre le routage des événements de modification via un appel à WSAEventSelect ou WSAAsyncSelect avec FD_ROUTING_INTERFACE_CHANGE bit défini dans le masque de bits d’événement réseau.

Il est reconnu que les informations de routage restent stables dans la plupart des cas, de sorte que l’exigence de l’application de conserver plusieurs IOCTL en attente pour recevoir des notifications sur toutes les destinations qui l’intéressent, ainsi que le fait que le fournisseur de services effectue le suivi de ces demandes de notification utilise 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 à la 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 toute modification de routage. Cela permet à l’application de ne conserver qu’une seule SIO_ROUTING_INTERFACE_CHANGE en suspens pour tous les sockets et destinations qu’elle possède, 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 de l’SIO_ROUTING_INTERFACE_CHANGE (comme si l’application avait spécifié une adresse générique) et d’effectuer la 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 en tant que 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 d’interface retournée peut être utilisée par l’application dans une demande bind() ultérieure.

Notez que les itinéraires sont susceptibles d’être modifiés. Par conséquent, les applications ne peuvent pas s’appuyer sur les informations retournées par SIO_ROUTING_INTERFACE_QUERY être persistantes. Les applications peuvent s’inscrire pour le routage des notifications de modification via le SIO_ROUTING_INTERFACE_CHANGE IOCTL qui fournit la 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 des 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 d’une modification de 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é.

Si la mémoire tampon de sortie n’est pas assez grande pour contenir l’adresse de l’interface, SOCKET_ERROR est retourné comme résultat 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 entièrement 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é en tant que résultat de ce IOCTL et WSAGetLastError renvoie 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 d’une version de Windows à l’autre. La structure d’argument 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.

Terme Description
WsaBehaviorAll
 Cela revient à demander tous les comportements compatibles possibles définis pour WSA_COMPATIBILITY_BEHAVIOR_ID.
WsaBehaviorReceiveBuffering
 Lorsque le membre TargetOsVersion est défini sur une valeur pour Windows Vista ou version ultérieure, les réductions de la taille de la mémoire tampon de réception TCP sur ce socket à l’aide de l’option de socket SO_RCVBUF sont autorisées même après l’établissement d’une connexion TCP.
Lorsque le membre TargetOsVersion est défini sur une valeur antérieure à Windows Vista, les réductions de la taille de la mémoire tampon de réception TCP sur ce socket à l’aide de l’option de socket SO_RCVBUF ne sont pas autorisées après l’établissement de la connexion.
WsaBehaviorAutoTuning
 Lorsque le membre TargetOsVersion est défini sur une valeur pour Windows Vista ou version ultérieure, le réglage automatique de la fenêtre de réception est activé et le facteur d’échelle de fenêtre TCP est réduit à 2 à partir de la valeur par défaut 8.
Lorsque TargetOsVersion est défini sur une valeur antérieure à Windows Vista, le réglage automatique de la fenêtre de réception est désactivé. L’option de mise à l’échelle de fenêtre TCP est également désactivée et la taille maximale de la fenêtre de réception réelle est limitée à 65 535 octets. L’option de mise à l’échelle de la fenêtre TCP ne peut pas être négociée sur la connexion même si l’option de socket SO_RCVBUF a été appelée sur ce socket en spécifiant une valeur supérieure à 65 535 octets avant l’établissement de la connexion.

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 une indication au protocole de transport sous-jacent pour traiter le trafic sur ce socket avec une priorité spécifique. 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 MICROSOFT Windows TCP prend en charge cette durée de vie ioc à 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 ce IOCTL. LEDBAT est un algorithme de charognard, dont l’objectif est de maintenir une latence faible et d’éviter tout effet négatif sur le trafic de priorité normale en se déchaînant lorsque le trafic de priorité normale est présent.

Consultez é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é de 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

Socket IOCTL 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 pour SIO_TIMESTAMPING est la structure TIMESTAMPING_CONFIG .

Consultez également Timestamping Winsock.

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

Pour obtenir un handle correspondant pour les sockets valide 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 tous 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 cet IOCTL pour l’interface complémentaire spécifiée. Cet IOCTL récupère le handle associé à l’aide de SIO_TRANSLATE_HANDLE.

Il est recommandé d’utiliser com (Component Object Model) à la place de cet IOCTL pour découvrir et suivre d’autres interfaces qui peuvent être prises en charge par un socket. Cet 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 PORT_UNREACHABLE UDP sont signalés. Définissez sur TRUE pour activer la création de rapports. Définissez sur 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 sur le nouveau socket TCP utilisé pour la connexion à la destination finale à utiliser par un service de redirection de la plateforme de filtrage Windows (PAM).

Le SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS IOCTL est utilisé dans le cadre du suivi des connexions par proxy 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 vers 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 des statistiques TCP avec la fonction GetPerTcpConnectionEStats , la récupération des statistiques TCP avec ce code de contrôle ne nécessite 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.

Notes

Les ioctls Winsock 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, la organization 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

Condition requise Valeur
En-tête
Winsock2.h;
Mstcpip.h;
Mswsock.h;
Mswsockdef.h sur Windows Vista, Windows Server 2008 et Windows 7 (inclure Mswsock.h) ;
Ws2def.h sur Windows Vista, Windows Server 2008 et Windows 7 (incluent Winsock2.h) ;
Ws2ipdef.h sur Windows Vista, Windows Server 2008 et Windows 7 (y compris Ws2tcpip.h)