WSCSetProviderInfo32, fonction (ws2spi.h)
Syntaxe
int WSCSetProviderInfo32(
[in] LPGUID lpProviderId,
[in] WSC_PROVIDER_INFO_TYPE InfoType,
[in] PBYTE Info,
[in] size_t InfoSize,
[in] DWORD Flags,
[out] LPINT lpErrno
);
Paramètres
[in] lpProviderId
Pointeur vers un identificateur global unique (GUID) pour le fournisseur.
[in] InfoType
Classe d’informations à définir pour cette entrée de protocole LSP.
[in] Info
Pointeur vers une mémoire tampon qui contient les données de la classe d’informations à définir pour l’entrée de protocole LSP.
[in] InfoSize
Taille, en octets, de la mémoire tampon pointée vers le paramètre Info .
[in] Flags
Indicateurs utilisés pour modifier le comportement de l’appel de fonction WSCSetProviderInfo32 .
[out] lpErrno
Pointeur vers le code d’erreur en cas d’échec de la fonction.
Valeur retournée
Si aucune erreur ne se produit, WSCSetProviderInfo32 retourne ERROR_SUCCESS (zéro). Sinon, elle retourne SOCKET_ERROR et un code d’erreur spécifique est retourné dans le paramètre lpErrno .
| Code d'erreur | Signification |
|---|---|
|
L’appel n’est pas implémenté. Cette erreur est retournée si **ProviderInfoAudit** est spécifié dans le paramètre InfoType . |
| Un ou plusieurs arguments ne se trouve pas dans une partie valide de l’espace d’adressage utilisateur. | |
| Un ou plusieurs arguments ne sont pas valides. | |
| Une erreur non récupérable s’est produite. Cette erreur est retournée dans plusieurs conditions, notamment : l’utilisateur n’a pas les privilèges d’administration nécessaires pour écrire dans le registre Winsock ou un échec s’est produit lors de l’ouverture d’une entrée de catalogue Winsock. | |
| La mémoire disponible était insuffisante. Cette erreur est retournée lorsque la mémoire est insuffisante pour allouer une nouvelle entrée de catalogue. |
Remarques
WSCSetProviderInfo32 est une version strictement 32 bits de WSCSetProviderInfo. Sur un ordinateur 64 bits, tous les appels ne sont pas spécifiquement 32 bits (par exemple, toutes les fonctions qui ne se terminent pas par « 32 ») fonctionnent sur le catalogue 64 bits natif. Les processus qui s’exécutent sur un ordinateur 64 bits doivent utiliser les appels de fonction 32 bits spécifiques pour fonctionner sur un catalogue strictement 32 bits et préserver la compatibilité. Les définitions et la sémantique des appels 32 bits spécifiques sont les mêmes que leurs équivalents natifs.
WSCSetProviderInfo32 est utilisé pour définir les données de la classe d’informations d’un fournisseur de services en couches 32 bits. Lorsque le paramètre InfoType est défini sur ProviderInfoLspCategories, en cas de réussite, WSCSetProviderInfo32 définit les indicateurs de catégorie LSP appropriés implémentés par le fournisseur en fonction de la valeur passée dans le paramètre Info .
Winsock 2 prend en charge les protocoles en couches. Un protocole en couches est un protocole qui implémente uniquement des fonctions de communication de niveau supérieur, tout en s’appuyant sur une pile de transport sous-jacente pour l’échange réel de données avec un point de terminaison distant. Un exemple de protocole en couches ou de fournisseur de services en couches serait une couche de sécurité qui ajoute un protocole au processus d’établissement de la connexion afin d’effectuer l’authentification et d’établir un schéma de chiffrement mutuellement convenu. Un tel protocole de sécurité nécessite généralement les services d’un protocole de transport fiable sous-jacent, tel que TCP ou SPX. Le terme protocole de base fait référence à un protocole tel que TCP ou SPX qui est capable d’effectuer des communications de données avec un point de terminaison distant. Le terme protocole en couches est utilisé pour décrire un protocole qui ne peut pas être autonome. Une chaîne de protocole serait alors définie comme un ou plusieurs protocoles en couches, liés entre eux et ancrés par un protocole de base. Un protocole de base a le membre ChainLen de la structure WSAProtocol_Info défini sur BASE_PROTOCOL qui est défini sur 1. Un protocole en couches a le membre ChainLen de la structure WSAPROTOCOL_INFO définie sur LAYERED_PROTOCOL qui est défini sur zéro. Une chaîne de protocole a le membre ChainLen de la structure WSAPROTOCOL_INFO défini sur supérieur à 1.
Pendant l’initialisation LSP, le LSP doit fournir des pointeurs vers un certain nombre de fonctions Winsock SPI. Ces fonctions seront appelées pendant le traitement normal par la couche située directement au-dessus du LSP (soit un autre LSP, soit un autre Ws2_32.dll).
Un fournisseur de services LSP qui implémente un système de fichiers installable (IFS) peut choisir de manière sélective de fournir des pointeurs vers des fonctions implémentées par elle-même, ou de renvoyer les pointeurs fournis par la couche juste sous le LSP. Les fournisseurs de services de sécurité non-IFS, car ils fournissent leurs propres handles, doivent implémenter toutes les fonctions Winsock SPI. Cela est dû au fait que chaque SPI nécessite que le fournisseur LSP mappe tous les handles de socket qu’il a créés au handle de socket du fournisseur inférieur (soit un autre LSP, soit le protocole de base).
Toutefois, tous les fournisseurs LSP effectuent leur travail spécifique en effectuant un traitement supplémentaire sur un sous-ensemble des fonctions SPI winsock.
Il est possible de définir des catégories LSP en fonction du sous-ensemble de fonctions SPI qu’un LSP implémente et de la nature du traitement supplémentaire effectué pour chacune de ces fonctions.
En classant les LSP, ainsi que les applications qui utilisent des sockets Winsock, il devient possible de déterminer de manière sélective si un LSP doit être impliqué dans un processus donné au moment de l’exécution.
Sur Windows Vista et versions ultérieures, un LSP peut être classé en fonction de la façon dont il interagit avec les appels et les données Windows Sockets. Une catégorie LSP est un groupe identifiable de comportements sur un sous-ensemble de fonctions SPI Winsock. Par exemple, un filtre de contenu HTTP est classé comme inspecteur de données (catégorie LSP_INSPECTOR ). La catégorie LSP_INSPECTOR inspecte, mais ne modifie pas, les paramètres des fonctions SPI de transfert de données. Une application peut interroger la catégorie d’un LSP et choisir de ne pas charger le LSP en fonction de la catégorie LSP et de l’ensemble de catégories LSP autorisées de l’application.
Le tableau suivant répertorie les catégories dans lesquelles un LSP peut être classé.
| Catégorie LSP | Description |
|---|---|
| **LSP_CRYPTO_COMPRESS** | Le LSP est un fournisseur de chiffrement ou de compression de données. |
| **LSP_FIREWALL** | Le LSP est un fournisseur de pare-feu. |
| **LSP_LOCAL_CACHE** | Le LSP est un fournisseur de cache local. |
| **LSP_INBOUND_MODIFY** | Le LSP modifie les données entrantes. |
| **LSP_INSPECTOR** | Le LSP inspecte ou filtre les données. |
| **LSP_OUTBOUND_MODIFY** | Le LSP modifie les données sortantes. |
| **LSP_PROXY** | Le LSP agit comme un proxy et redirige les paquets. |
| **LSP_REDIRECTOR** | Le LSP est un redirecteur réseau. |
| **LSP_SYSTEM** | Le LSP est acceptable pour une utilisation dans les services et les processus système. |
Un LSP peut appartenir à plusieurs catégories. Par exemple, le LSP pare-feu/sécurité peut appartenir aux catégories inspecteur (LSP_INSPECTOR) et pare-feu (LSP_FIREWALL).
Si un LSP n’a pas de catégorie définie, il est considéré comme faisant partie de la catégorie Tous les autres. Cette catégorie LSP ne sera pas chargée dans les services ou les processus système (par exemple, lsass, winlogon et de nombreux processus svchost).
La fonction WSCSetProviderInfo32 ne peut être appelée que par un utilisateur connecté en tant que membre du groupe Administrateurs. Si WSCSetProviderInfo32 est appelé par un utilisateur qui n’est pas membre du groupe Administrateurs, l’appel de fonction échoue et WSANO_RECOVERY est retourné dans le paramètre lpErrno . Cette fonction peut également échouer en raison du contrôle de compte d’utilisateur (UAC). Si une application qui contient cette fonction est exécutée par un utilisateur connecté en tant que membre du groupe Administrateurs autre que l’administrateur intégré, cet appel échoue, sauf si l’application a été marquée dans le fichier manifeste avec un requestedExecutionLevel défini sur requireAdministrator. Si l’application sur Windows Vista ou Windows Server 2008 ne dispose pas de ce fichier manifeste, un utilisateur connecté en tant que membre du groupe Administrateurs autre que l’administrateur intégré doit ensuite exécuter l’application dans un interpréteur de commandes amélioré en tant qu’administrateur intégré (administrateur d’exécution) pour que cette fonction réussisse.
Configuration requise
| Condition requise | Valeur |
|---|---|
| Client minimal pris en charge | Windows Vista [applications de bureau uniquement] |
| Serveur minimal pris en charge | Windows Server 2008 [applications de bureau uniquement] |
| Plateforme cible | Windows |
| En-tête | ws2spi.h |
| Bibliothèque | Ws2_32.lib |
| DLL | Ws2_32.dll |
Voir aussi
Catégorisation des applications et des fournisseurs de services en couches