Fonction de rappel LPWSPIOCTL (ws2spi.h)

Article
08/28/2023

La fonction LPWSPIoctl contrôle le mode d’un socket.

Syntaxe

LPWSPIOCTL Lpwspioctl;

int Lpwspioctl(
  [in]  SOCKET s,
  [in]  DWORD dwIoControlCode,
  [in]  LPVOID lpvInBuffer,
  [in]  DWORD cbInBuffer,
  [out] LPVOID lpvOutBuffer,
  [in]  DWORD cbOutBuffer,
  [out] LPDWORD lpcbBytesReturned,
  [in]  LPWSAOVERLAPPED lpOverlapped,
  [in]  LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine,
  [in]  LPWSATHREADID lpThreadId,
  [in]  LPINT lpErrno
)
{...}

Paramètres

[in] s

Descripteur identifiant un socket.

[in] dwIoControlCode

Code de contrôle de l’opération à effectuer.

[in] lpvInBuffer

Pointeur vers la mémoire tampon d’entrée.

[in] cbInBuffer

Taille, en octets, de la mémoire tampon d’entrée.

[out] lpvOutBuffer

Pointeur vers la mémoire tampon de sortie.

[in] cbOutBuffer

Taille, en octets, de la mémoire tampon de sortie.

[out] lpcbBytesReturned

Pointeur vers le nombre réel d’octets de sortie.

[in] lpOverlapped

Pointeur vers une structure WSAOverlapped (ignoré pour les sockets non chevauchés).

[in] lpCompletionRoutine

Type : _In_opt_ LPWSAOVERLAPPED_COMPLETION_ROUTINE

Pointeur vers la routine d’achèvement appelée une fois l’opération terminée (ignorée pour les sockets qui ne se chevauchent pas). Consultez la section Notes.

[in] lpThreadId

Pointeur vers une structure WSATHREADID à utiliser par le fournisseur dans un appel ultérieur à WPUQueueApc. Le fournisseur doit stocker la structure WSATHREADID référencée (et non le pointeur) jusqu’à ce que la fonction WPUQueueApc soit retournée.

[in] lpErrno

Pointeur vers le code d’erreur.

Valeur retournée

Si aucune erreur ne se produit et que l’opération s’est terminée immédiatement, LPWSPIoctl retourne zéro. Notez que dans ce cas, la routine d’achèvement, si elle est spécifiée, aura déjà été mise en file d’attente. Sinon, la valeur SOCKET_ERROR est retournée et un code d’erreur spécifique est disponible dans lpErrno. Le code d’erreur WSA_IO_PENDING indique qu’une opération qui se chevauche a été lancée avec succès et que l’achèvement sera indiqué ultérieurement. Tout autre code d’erreur indique qu’aucune opération chevauchée n’a été lancée et qu’aucune indication d’achèvement ne se produira.

Code d'erreur	Signification
WSA_IO_PENDING	Une opération superposée a été lancée avec succès et l’achèvement sera indiqué ultérieurement.
WSAEFAULT	Le paramètre lpvInBuffer, lpvOutBuffer ou lpcbBytesReturned n’est pas totalement contenu dans une partie valide de l’espace d’adressage utilisateur, ou le paramètre cbInBuffer ou cbOutBuffer est trop petit.
WSAEINVAL	DwIoControlCode n’est pas une commande valide ou un paramètre d’entrée fourni n’est pas acceptable, ou la commande n’est pas applicable au type de socket fourni.
WSAEINPROGRESS	La fonction est appelée lorsqu’un rappel est en cours.
WSAENETDOWN	Le sous-système réseau a échoué.
WSAENOTSOCK	Le descripteur s n’est pas un socket.
WSAEOPNOTSUPP	Impossible de réaliser la commande IOCTL spécifiée. Par exemple, les spécifications de flux spécifiées dans SIO_SET_QOS ne peuvent pas être satisfaites.
WSAEWOULDBLOCK	Le socket est marqué comme non bloquant et l’opération demandée est bloquée.

Remarques

Cette routine est utilisée pour définir ou récupérer les paramètres d’exploitation associés au socket, au protocole de transport ou au sous-système de communication. Si lpOverlapped et lpCompletionRoutine ont la valeur NULL, le socket dans cette fonction est traité comme un socket non inexploité.

Pour les sockets non superposés, les paramètres lpOverlapped et lpCompletionRoutine sont ignorés et cette fonction peut se bloquer si le socket est en mode bloquant. Notez que si le socket est en mode non bloquant, cette fonction peut retourner WSAEWOULDBLOCK si l’opération spécifiée ne peut pas être terminée immédiatement. Dans ce cas, le client SPI windows Sockets peut changer le socket en mode bloquant et réémettre la demande ou attendre l’événement réseau correspondant (par exemple, FD_ROUTING_INTERFACE_CHANGE ou FD_ADDRESS_LIST_CHANGE en cas de SIO_ROUTING_INTERFACE_CHANGE ou de SIO_ADDRESS_LIST_CHANGE) à l’aide du message Windows (via LPWSPAsyncSelect ou du mécanisme de notification basé sur l’événement (à l’aide de LPWWSPEventSelect).

Pour les sockets qui se chevauchent, les opérations qui ne peuvent pas être effectuées immédiatement sont lancées et l’achèvement sera indiqué ultérieurement. La valeur DWORD pointée par le paramètre lpcbBytesReturned retourné peut être ignorée. L’achèvement final status et les octets retournés peuvent être récupérés lorsque la méthode d’achèvement appropriée est signalée lorsque l’opération est terminée.

Tout IOCTL peut être bloqué indéfiniment, en fonction de l’implémentation du fournisseur de services. Si le client SPI Windows Sockets ne peut pas tolérer le blocage dans un appel LPWSPIoctl , les E/S qui se chevauchent sont recommandées pour les IOCTL qui sont les plus susceptibles de se bloquer, notamment :

SIO_ADDRESS_LIST_CHANGE
SIO_FINDROUTE
SIO_FLUSH
SIO_GET_QOS
SIO_GET_GROUP_QOS
SIO_ROUTING_INTERFACE_CHANGE
SIO_SET_QOS
SIO_SET_GROUP_QOS

Certains IOCTL spécifiques au protocole peuvent également être particulièrement susceptibles de bloquer. Pour obtenir les informations disponibles, consultez l’annexe appropriée spécifique au protocole.

Le prototype de la routine d’achèvement vers laquelle pointe le paramètre lpCompletionRoutine est le suivant.

void CALLBACK 
CompletionRoutine(  
  IN DWORD           dwError, 
  IN DWORD           cbTransferred, 
  IN LPWSAOVERLAPPED lpOverlapped, 
  IN DWORD           dwFlags 
);

CompletionRoutine est un espace réservé pour un nom de fonction fourni par l’application. Le paramètre dwError spécifie le status d’achèvement pour l’opération qui se chevauche, comme indiqué par le paramètre lpOverlapped. Le paramètre cbTransferred spécifie le nombre d’octets reçus. Le paramètre dwFlags n’est pas utilisé pour cet IOCTL. La routine d’achèvement ne retourne pas de valeur.

Dans la mesure où le paramètre dwIoControlCode est désormais une entité 32 bits, il est possible d’adopter un schéma d’encodage qui offre un moyen pratique de partitionner l’espace d’identificateur d’opcode. Le paramètre dwIoControlCode est construit 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 se présente sous la forme suivante.

bit 31	bit 30	bit 29	bits 28 et 27	bits 26 à 16	bits 15 à 0
I	O	V	T	Famille de fournisseurs/d’adresses	Code

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. Notez que pour les codes avec des paramètres d’entrée et de sortie, les Eet S sont définies.

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

T est une quantité deux bits qui définit le type d’IOCTL. Les valeurs suivantes sont définies.

0 indique que l’IOCTL est un code UNIX IOCTL standard, comme avec FIONREAD, FIONBIO, etc.
1 indique que l’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 indique que l’IOCTL s’applique uniquement à une famille d’adresses spécifique.
3 L’IOCTL s’applique uniquement au fournisseur d’un fournisseur spécifique. Ce type permet aux entreprises de se voir attribuer un numéro de fournisseur qui apparaît dans le membre de la famille Fournisseur/Adresse . Ensuite, le fournisseur peut définir de nouveaux IOCTL spécifiques à ce fournisseur sans avoir à inscrire l’IOCTL auprès d’un centre d’échange, offrant ainsi flexibilité et confidentialité au fournisseur.

La famille fournisseur/adresse est une 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 membre 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 membre peut être utilisé comme extension du membre de code pour fournir des valeurs de code supplémentaires.

Code est le code IOCTL spécifique pour l’opération.

Les commandes UNIX suivantes sont prises en charge :

FIONBIO

Active ou désactive le mode sans blocage sur les sockets. Le paramètre lpvInBuffer pointe vers un long non signé, qui est différent de zéro si le mode sans blocage 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 sans blocage est désactivé). Cela est cohérent avec les sockets BSD (Berkeley Software Distribution).

La routine LPWSPAsyncSelect ou LPWSPEventSelect définit automatiquement un socket en mode non bloquant. Si LPWSPAsyncSelect ou LPWSPEventSelect a été émis sur un socket, toute tentative d’utilisation de LPWSPIoctl pour remettre le socket en mode bloquant échoue avec WSAEINVAL. Pour remettre le socket en mode bloquant, un client SPI Windows Sockets doit d’abord désactiver LPWSPAsyncSelect en appelant LPWSPAsyncSelect avec le paramètre lEvent égal à zéro, ou désactiver LPWSPEventSelect en appelant LPWSPEventSelect avec le paramètre lNetworkEvents égal à zéro.

FIONREAD

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

Si le socket passé 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étermine 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 d’être lue, 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 une partie ou la totalité des données précédant la marque ; Le client SPI Windows Sockets 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 (OOB), elles sont reçues dans l’ordre. (Notez que les opérations de réception ne combineront jamais les données OOB et normales dans le même appel.) lpvOutBuffer pointe vers un BOOL dans lequel LPWSPIoctl stocke le résultat.

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 nécessite 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 : T==1)

Pour recevoir une notification des modifications dans la liste des adresses de transport locales de la famille de protocoles du socket à laquelle le client SPI Windows Sockets peut lier. Aucune information de sortie ne sera fournie à l’issue du présent IOCTL; 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 qu’il ne soit pas obligatoire) que le client SPI Windows Sockets utilise des E/S qui se chevauchent pour être averti de la modification par l’achèvement 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 et lpCompletionRoutine ont la valeur NULL), il se termine immédiatement avec l’erreur WSAEWOULDBLOCK. Le client SPI Windows Sockets peut ensuite attendre des événements de modification de liste d’adresses par le biais d’un appel à LPWSPEventSelect ou LPWSPAsyncSelect avec le FD_ADDRESS_LIST_CHANGE 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 de la SIO_ADDRESS_LIST_CHANGE IOCTL, qui fournit la notification par le biais d’E/S superposées 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 d’un 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é.

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_ASSOCIATE_HANDLE (paramètre opcode : I, T==1)

Associe 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 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. Pour plus d’informations, reportez-vous à la section appropriée de l’annexe Protocol-Specific et /ou de la documentation windows sockets 2 et/ou à la documentation relative à l’interface complémentaire spécifique. (Ces ressources ne peuvent être disponibles qu’en anglais.) 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 :

Une grande quantité de contrôle supplémentaire sur le comportement d’un socket.
Contrôles spécifiques au fournisseur qui ne sont pas mappés à des fonctions Windows Socket existantes (ou à l’avenir).

Il est recommandé d'utiliser le modèle COM (Component Object Model) plutôt que cet IOCTL pour rechercher et assurer le suivi d'autres interfaces pouvant ê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_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 fonction Bind é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 ne doit jamais intercepter 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 .

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 .

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 de 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_ENABLE_CIRCULAR_QUEUEING (paramètre opcode : V, T==1)

Indique à un fournisseur de services orienté message 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 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 LPWSPSendTo.

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, T==1)

Réservé.

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 .

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 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 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_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 d’opcode : O, T==1)

Récupère 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 QOS . 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é de service.

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 (ISB) idéale. 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 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 Service Pack 1 (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 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 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.

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 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 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.

SIO_KEEPALIVE_VALS permet d’activer ou de désactiver les sondes keep-alive et de définir le délai d’expiration et l’intervalle de conservation d’activité. Le délai d’expiration keep-alive spécifie le délai d’expiration, en millisecondes, sans activité jusqu’à l’envoi du premier paquet keep-alive. L’intervalle keep-alive spécifie l’intervalle, en millisecondes, entre l’envoi de paquets keep-alive 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 la conservation tcp 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 le protocole 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 maintien en vie, 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_MULTIPOINT_LOOPBACK (paramètre opcode : I, 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. La valeur d’étendue 1 (valeur par défaut) indique que la transmission sera placée sur le câble, mais qu’elle ne traversera aucun routeur. Les valeurs d’étendue supérieures déterminent le nombre de routeurs qui peuvent être traversés. Notez que cela correspond au paramètre de durée de vie (TTL) dans la multidiffusion IP.

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

Les requêtes déchargent les interfaces 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.

void CALLBACK 
CompletionRoutine(  
  IN DWORD           dwError, 
  IN DWORD           cbTransferred, 
  IN LPWSAOVERLAPPED lpOverlapped, 
  IN DWORD           dwFlags 
);

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 assez grande pour la structure de RSS_SCALABILITY_INFO ( le cbOutBuffer est inférieur à la taille d’un RSS_SCALABILITY_INFO) ou si le paramètre lpvOutBuffer est un pointeur NULL , SOCKET_ERROR est retourné à la suite de cette durée de vie IOCTL et WSAGetLastError renvoie WSAEINVAL.

Dans les réseaux à haut débit où plusieurs processeurs résident dans un seul système, la capacité de la pile de protocoles réseau à bien évoluer sur un système multi-PROCESSEUR est entravé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 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_WFP_ALE_ENDPOINT_HANDLE (paramètre opcode : O, T===3)

Interroge le handle du 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. Dans Windows Vista, PAM se concentre sur les scénarios où l’ordinateur hôte est le point de terminaison de communication. Dans 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 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. Ce IOCTL est utilisé pour fournir un handle de socket au mappage de handles de point de terminaison de couche de transport.

Si la mémoire tampon de sortie n’est pas assez 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é à la suite de cette IOCTL et WSAGetLastError retourne WSAEINVAL.

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

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

Pour obtenir le descripteur de socket du fournisseur suivant dans la chaîne dont dépend le socket actuel dans le sens PnP. Ce IOCTL est appelé par la DLL Windows Sockets 2 uniquement sur les sockets des fournisseurs de services non-IFS créés via l’appel WPUCreateSocketHandle . Le fournisseur doit retourner dans la mémoire tampon de sortie le handle de socket du fournisseur suivant de la chaîne dont dépend un handle de socket donné au sens PnP (par exemple, la suppression de l’appareil qui prend en charge le handle sous-jacent entraîne l’invalidation du handle au-dessus de lui dans la chaîne).

Si une opération qui se chevauche se termine immédiatement, cette fonction retourne la valeur zéro et le paramètre lpcbBytesReturned est mis à jour avec le nombre d’octets dans la mémoire tampon de sortie. Si l’opération qui se chevauche est correctement lancée et se terminera ultérieurement, cette fonction retourne SOCKET_ERROR et indique le code d’erreur WSA_IO_PENDING. Dans ce cas, lpcbBytesReturned n’est pas mis à jour. Lorsque l’opération qui se chevauche se termine, la quantité de données dans la mémoire tampon de sortie est indiquée par le biais du paramètre cbTransferred dans la routine d’achèvement (si spécifié), ou par le biais du paramètre lpcbTransfer dans LPWSPGetOverlappedResult.

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 :

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 vous lier à INADDR_ANY ou in6addr_any.

Sur Windows Server 2008 et versions antérieures, le SIO_RCVALL paramètre IOCTL ne capture pas les paquets locaux envoyés à partir d’une interface réseau. Cela comprenait les paquets reçus sur une autre interface et transférait 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 vers l’interface réseau liée au socket avec SIO_RCVALL IOCTL.

La définition de ce IOCTL nécessite un privilège 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 (NIC), 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) seront 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 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 les paquets dirigés vers des adresses IP spécifiques, mais recevra également tous les paquets IPv4 ou IPv6 reçus par la carte réseau. 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_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 runtime à 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 sous la forme d’une structure de sockaddr ). Aucune information de sortie sur la nouvelle interface de routage ne sera fournie à l’achèvement du présent 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 du SIO_ROUTING_INTERFACE_QUERY IOCTL.

Il est supposé (bien que non obligatoire) que l’application utilise des E/S qui se chevauchent pour être avertie de la modification de l’interface de routage lors de l’achèvement de SIO_ROUTING_INTERFACE_CHANGE demande. 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 avec l’erreur WSAEWOULDBLOCK et le client SPI du socket Windows peut attendre le routage des événements de modification à l’aide d’un appel à LPWSPEventSelect ou LPWSPAsyncSelect avec le 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 le fait de demander à 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 :

Le client SPI Windows Sockets peut spécifier une adresse générique spécifique à la famille de protocoles (identique à celle utilisée dans l’appel Bind lors de la demande de liaison à n’importe quelle adresse disponible) pour demander des notifications de modifications de routage. Cela permet au client SPI Windows Sockets de ne conserver qu’un seul SIO_ROUTING_INTERFACE_CHANGE en suspens pour tous les sockets et destinations dont il dispose, puis d’utiliser SIO_ROUTING_INTERFACE_QUERY pour obtenir les informations de routage réelles.

Le fournisseur de services peut choisir d’ignorer les informations fournies par le client SPI windows Sockets dans la mémoire tampon d’entrée de l’SIO_ROUTING_INTERFACE_CHANGE (comme si le client SPI Windows Sockets spécifiait une adresse générique) et d’effectuer l’SIO_ROUTING_INTERFACE_CHANGE événement IOCTL ou de signal FD_ROUTING_INTERFACE_CHANGE 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 multidiffusion. Dans tous les cas, l’adresse d’interface retournée peut être utilisée par l’application dans une requête Bind suivante.

Notez que les itinéraires peuvent être modifiés. Par conséquent, les clients SPI de socket Windows ne peuvent pas s’appuyer sur les informations retournées par SIO_ROUTING_INTERFACE_QUERY être persistantes. Les clients SPI peuvent s’inscrire pour recevoir des notifications de modification de routage à l’aide de la SIO_ROUTING_INTERFACE_CHANGE IOCTL, qui fournit la notification par le biais d’E/S qui se chevauchent ou d’un événement FD_ROUTING_INTERFACE_CHANGE. La séquence d’actions suivante peut être utilisée pour garantir que le client SPI du socket Windows 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 avertit le client WinSock SPI d’une modification de routage (via des 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 assez grande pour contenir l’adresse de l’interface, SOCKET_ERROR est retourné comme résultat de cette propriété IOCTL et WSAGetLastError renvoie 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 :

} 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_QOS (paramètre opcode : I, T==1)

Associez la structure QOS fournie 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_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. Pour plus d’informations, reportez-vous à la section appropriée de l’annexe Protocol-Specific et /ou de la documentation windows sockets 2 et/ou à la documentation relative à l’interface complémentaire spécifique. 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 à 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.

Lorsqu’il est appelé avec un socket qui se chevauche, le paramètre lpOverlapped doit être valide pendant la durée de l’opération qui se chevauche.

Si le paramètre lpCompletionRoutine a la valeur NULL, le fournisseur de services signale le membre hEvent de lpOverlapped lorsque l’opération qui se chevauche se termine s’il contient un handle d’objet d’événement valide. Le client SPI Windows Sockets peut utiliser LPWSPGetOverlappedResult pour interroger ou attendre sur l’objet d’événement.

Si lpCompletionRoutine n’a pas la valeur NULL, le membre hEvent est ignoré et peut être utilisé par le client SPI Windows Sockets pour transmettre des informations de contexte à la routine d’achèvement. Un client qui transmet un lpCompletionRoutine non NULL et appelle ultérieurement WSAGetOverlappedResult pour la même demande d’E/S qui se chevauche ne peut pas définir le paramètre fWait pour cet appel de WSAGetOverlappedResult sur TRUE. Dans ce cas, l’utilisation du membre hEvent n’est pas définie et une tentative d’attente sur le membre hEvent produit des résultats imprévisibles.

Il incombe au fournisseur de services d’organiser l’appel de la routine d’achèvement spécifiée par le client lorsque l’opération qui se chevauche se termine. Étant donné que la routine d’achèvement doit être exécutée dans le contexte du même thread que celui qui a lancé l’opération superposée, elle ne peut pas être appelée directement à partir du fournisseur de services. Le WS2_32.DLL offre un mécanisme d’appel de procédure asynchrone (APC) pour faciliter l’appel des routines d’achèvement.

Un fournisseur de services organise l’exécution d’une fonction dans le contexte de thread et de processus appropriés en appelant WPUQueueApc. Cette fonction peut être appelée à partir de n’importe quel contexte de processus et de thread, même dans un contexte différent du thread et du processus utilisé pour lancer l’opération qui se chevauche.

WPUQueueApc prend comme paramètres d’entrée un pointeur vers une structure WSATHREADID (fournie au fournisseur via le paramètre d’entrée lpThreadId ), un pointeur vers une fonction APC à appeler et une valeur de contexte 32 bits qui est ensuite passée à la fonction APC. Étant donné qu’une seule valeur de contexte 32 bits est disponible, la fonction APC elle-même ne peut pas être la routine d’achèvement spécifiée par le client. Le fournisseur de services doit à la place fournir un pointeur vers sa propre fonction APC qui utilise la valeur de contexte fournie pour accéder aux informations de résultat nécessaires pour l’opération qui se chevauche, puis appelle la routine d’achèvement spécifiée par le client.

Le prototype de la routine d’achèvement fournie par le client est le suivant :

);

CompletionRoutine est un espace réservé pour une fonction fournie par le client. DwError spécifie le status d’achèvement pour l’opération qui se chevauche, comme indiqué par lpOverlapped. CbTransferred spécifie le nombre d’octets retournés. Actuellement, aucune valeur d’indicateur n’est définie et dwFlags sera égal à zéro. Cette fonction ne retourne pas de valeur.

Le retour à partir de cette fonction permet l’appel d’une autre routine d’achèvement en attente pour ce socket. Les routines d’achèvement peuvent être appelées dans n’importe quel ordre, mais pas nécessairement dans le même ordre que celui où les opérations qui se chevauchent sont terminées.

Compatibilité

Les codes IOCTL avec T == 0 sont un sous-ensemble des codes IOCTL utilisés dans les sockets Berkeley. En particulier, il n’existe aucune commande équivalente à FIOASYNC.

Notes

Toutes les E/S initiées par un thread donné sont annulées lorsque ce thread se ferme. Pour les sockets qui se chevauchent, les opérations asynchrones en attente peuvent échouer si le thread est fermé avant la fin des opérations. Pour plus d’informations, consultez ExitThread .

Spécifications


Client minimal pris en charge	Windows 2000 Professionnel [applications de bureau uniquement]
Serveur minimal pris en charge	Windows 2000 Server [applications de bureau uniquement]
En-tête	ws2spi.h

Voir aussi

Fonction de rappel LPWSPIOCTL (ws2spi.h)

Syntaxe

Paramètres

Valeur retournée

Remarques

Compatibilité

Spécifications

Voir aussi

Commentaires

Commentaires

Ressources supplémentaires