Fonction WSCSetProviderInfo (ws2spi.h)

**Remarque** Les fournisseurs de services en couches sont déconseillés. À compter de Windows 8 et Windows Server 2012, utilisez la plateforme de filtrage Windows.
 
La fonction **WSCSetProviderInfo** définit la valeur de données pour la classe d’informations spécifiée pour un fournisseur de services en couches (LSP).

Syntaxe

int WSCSetProviderInfo(
  [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 du 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 WSCSetProviderInfo .

[out] lpErrno

Pointeur vers le code d’erreur si la fonction échoue.

Valeur retournée

Si aucune erreur ne se produit, WSCSetProviderInfo retourne ERROR_SUCCESS (zéro). Sinon, il retourne SOCKET_ERROR, et un code d’erreur spécifique est retourné dans le paramètre lpErrno .

Code d'erreur Signification
ERROR_CALL_NOT_IMPLEMENTED
L’appel n’est pas implémenté. Cette erreur est retournée si **ProviderInfoAudit** est spécifié dans le paramètre InfoType .
WSAEFAULT
Un ou plusieurs des arguments ne se trouve pas dans une partie valide de l’espace d’adressage utilisateur.
WSAEINVAL
Un ou plusieurs arguments ne sont pas valides.
WSANO_RECOVERY
Une erreur irré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.
WSA_NOT_ENOUGH_MEMORY
La mémoire disponible était insuffisante. Cette erreur est retournée quand la mémoire est insuffisante pour allouer une nouvelle entrée de catalogue.

Remarques

WSCSetProviderInfo est utilisé pour définir les données de classe d’informations pour un fournisseur de services en couches. Lorsque le paramètre InfoType est défini sur ProviderInfoLspCategories, le paramètre WSCSetProviderInfo définit les indicateurs de catégorie LSP appropriés implémentés par le fournisseur en fonction de la valeur transmise dans le paramètre Info .

Winsock 2 prend en charge les protocoles en couches. Un protocole en couches 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 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 est alors définie comme un ou plusieurs protocoles en couches enchaînés 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éfini 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.

Lors de l’initialisation LSP, le fournisseur de services 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 directement au-dessus du LSP (soit un autre LSP ou 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 qui sont implémentées par lui-même, ou de renvoyer les pointeurs fournis par la couche située directement sous le LSP. Les LSP non-IFS, car ils fournissent leurs propres handles, doivent implémenter toutes les fonctions Winsock SPI. Cela est dû au fait que chaque SPI aura besoin du fournisseur de services pour mapper tous les handles de socket qu’il a créés au handle de socket du fournisseur inférieur (soit un autre LSP ou le protocole de base).

Toutefois, tous les fournisseurs de services LSP effectuent leur travail spécifique en effectuant un traitement supplémentaire uniquement 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 fournisseurs de services LSP et en classant les applications qui utilisent des sockets Winsock, il devient possible de déterminer de manière sélective si un fournisseur de services partagés doit être impliqué dans un processus donné au moment de l’exécution.

Sur Windows Vista et versions ultérieures, un fournisseur de services partagés peut être classé en fonction de la façon dont il interagit avec les appels et les données des sockets Windows. Une catégorie LSP est un groupe identifiable de comportements sur un sous-ensemble de fonctions Winsock SPI. Par exemple, un filtre de contenu HTTP est classé en tant qu’inspecteur de données (catégorie LSP_INSPECTOR ). La catégorie LSP_INSPECTOR inspecte, mais ne modifie pas, les paramètres pour les 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 fournisseur de services 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 fournisseur de services LSP est un fournisseur de pare-feu.
**LSP_LOCAL_CACHE** Le fournisseur de services LSP est un fournisseur de cache local.
**LSP_INBOUND_MODIFY** Le fournisseur de services LSP modifie les données entrantes.
**LSP_INSPECTOR** Le fournisseur de services LSP inspecte ou filtre les données.
**LSP_OUTBOUND_MODIFY** Le LSP modifie les données sortantes.
**LSP_PROXY** Le fournisseur de services LSP agit comme un proxy et redirige les paquets.
**LSP_REDIRECTOR** Le fournisseur de services LSP est un redirecteur réseau.
**LSP_SYSTEM** Le LSP est acceptable pour une utilisation dans les services et les processus système.
  Un fournisseur de services LSP peut appartenir à plusieurs catégories. Par exemple, le pare-feu/sécurité LSP peut appartenir aux catégories inspecteur (**LSP_INSPECTOR**) et pare-feu (**LSP_FIREWALL**).

Si un fournisseur de services LSP n’a pas défini de catégorie, 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 WSCSetProviderInfo ne peut être appelée que par un utilisateur connecté en tant que membre du groupe Administrateurs. Si WSCSetProviderInfo 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 paramètre 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 alors exécuter l’application dans un interpréteur de commandes amélioré en tant qu’administrateur intégré (administrateur RunAs) pour que cette fonction réussisse.

**Remarque** La fonctionnalité TDI est déconseillée et sera supprimée dans les versions futures de Microsoft Windows. Selon la façon dont vous utilisez TDI, utilisez le noyau Winsock (WSK) ou la plateforme de filtrage Windows (PAM). Pour plus d’informations sur le PAM et WSK, consultez Plateforme de filtrage Windows et Noyau Winsock. Pour obtenir une entrée de blog windows Core Networking sur WSK et TDI, consultez Présentation du noyau Winsock (WSK).
 

Spécifications

   
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 couchesWSAPROTOCOL_INFOWSCGetApplicationCategoryWSCGetProviderInfoWSCSetApplicationCategoryWSC_PROVIDER_INFO_TYPE