WSCSetProviderInfo32-Funktion (ws2spi.h)

Syntax

int WSCSetProviderInfo32(
  [in]  LPGUID                 lpProviderId,
  [in]  WSC_PROVIDER_INFO_TYPE InfoType,
  [in]  PBYTE                  Info,
  [in]  size_t                 InfoSize,
  [in]  DWORD                  Flags,
  [out] LPINT                  lpErrno
);

Parameter

[in] lpProviderId

Ein Zeiger auf einen Globally Unique Identifier (GUID) für den Anbieter.

[in] InfoType

Die Für diesen LSP-Protokolleintrag festzulegende Informationsklasse.

[in] Info

Ein Zeiger auf einen Puffer, der die Für den LSP-Protokolleintrag festzulegenden Informationsklassendaten enthält.

[in] InfoSize

Die Größe des Puffers in Bytes, auf den der Info-Parameter verweist.

[in] Flags

Die Flags, die zum Ändern des Verhaltens des WSCSetProviderInfo32-Funktionsaufrufs verwendet werden.

[out] lpErrno

Ein Zeiger auf den Fehlercode, wenn die Funktion fehlschlägt.

Rückgabewert

Wenn kein Fehler auftritt, gibt WSCSetProviderInfo32ERROR_SUCCESS (null) zurück. Andernfalls wird SOCKET_ERROR zurückgegeben, und im lpErrno-Parameter wird ein bestimmter Fehlercode zurückgegeben.

Hinweise

WSCSetProviderInfo32 ist eine streng 32-Bit-Version von WSCSetProviderInfo. Auf einem 64-Bit-Computer werden alle Aufrufe, die nicht speziell 32-Bit-Versionen (z. B. alle Funktionen, die nicht auf "32" enden) im nativen 64-Bit-Katalog ausgeführt. Prozesse, die auf einem 64-Bit-Computer ausgeführt werden, müssen die spezifischen 32-Bit-Funktionsaufrufe verwenden, um mit einem strikten 32-Bit-Katalog zu arbeiten und die Kompatibilität aufrechtzuerhalten. Die Definitionen und Semantik der spezifischen 32-Bit-Aufrufe sind identisch mit ihren nativen Entsprechungen.

WSCSetProviderInfo32 wird verwendet, um die Daten der Informationsklasse für einen 32-Bit-Mehrschichtdienstanbieter festzulegen. Wenn der InfoType-Parameter auf ProviderInfoLspCategories festgelegt ist, legt WSCSetProviderInfo32 bei Erfolg die vom Anbieter implementierten LSP-Kategorieflags basierend auf dem im Info-Parameter übergebenen Wert fest.

Winsock 2 bietet mehrstufige Protokolle. Ein mehrschichtiges Protokoll ist ein Protokoll, das nur Kommunikationsfunktionen auf höherer Ebene implementiert, während ein zugrunde liegender Transportstapel für den tatsächlichen Austausch von Daten mit einem Remoteendpunkt verwendet wird. Ein Beispiel für ein mehrschichtiges Protokoll oder einen mehrschichtigen Dienstanbieter wäre eine Sicherheitsebene, die dem Verbindungsaufbauprozess protokolliert, um die Authentifizierung durchzuführen und ein gegenseitig vereinbartes Verschlüsselungsschema einzurichten. Ein solches Sicherheitsprotokoll erfordert im Allgemeinen die Dienste eines zugrunde liegenden zuverlässigen Transportprotokolls wie TCP oder SPX. Der Begriff Basisprotokoll bezieht sich auf ein Protokoll wie TCP oder SPX, das die Datenkommunikation mit einem Remoteendpunkt durchführen kann. Der Begriff Mehrschichtprotokoll wird verwendet, um ein Protokoll zu beschreiben, das nicht allein stehen kann. Eine Protokollkette würde dann als ein oder mehrere mehrstufige Protokolle definiert, die zusammengekettet und durch ein Basisprotokoll verankert sind. Bei einem Basisprotokoll ist der ChainLen-Member der WSAProtocol_Info-Struktur auf BASE_PROTOCOL festgelegt, der als 1 definiert ist. Bei einem mehrstufigen Protokoll ist der ChainLen-Member der WSAPROTOCOL_INFO-Struktur auf LAYERED_PROTOCOL festgelegt, der als null definiert ist. In einer Protokollkette ist der ChainLen-Member der WSAPROTOCOL_INFO-Struktur auf größer als 1 festgelegt.

Während der LSP-Initialisierung muss der LSP Zeiger auf eine Reihe von Winsock SPI-Funktionen bereitstellen. Diese Funktionen werden während der normalen Verarbeitung von der Ebene direkt über dem LSP aufgerufen (entweder ein anderer LSP oder Ws2_32.dll).

Ein LSP, der ein installierbares Dateisystem (Installable File System, IFS) implementiert, kann selektiv Zeiger auf Funktionen bereitstellen, die selbst implementiert werden, oder die von der Ebene direkt unterhalb des LSP bereitgestellten Zeiger zurückgeben. Nicht-IFS-LSPs müssen alle Winsock SPI-Funktionen implementieren, da sie ihre eigenen Handles bereitstellen. Dies liegt daran, dass für jede SPI der LSP alle erstellten Sockethandles dem Sockethandle des unteren Anbieters (entweder ein anderer LSP oder das Basisprotokoll) zugeordnet werden muss.

Alle LSPs führen ihre spezifische Arbeit jedoch durch zusätzliche Verarbeitung nur für eine Teilmenge der Winsock SPI-Funktionen aus.

Es ist möglich, LSP-Kategorien basierend auf der Teilmenge der SPI-Funktionen zu definieren, die ein LSP implementiert, und der Art der zusätzlichen Verarbeitung, die für jede dieser Funktionen ausgeführt wird.

Durch das Klassifizieren von LSPs sowie durch das Klassifizieren von Anwendungen, die Winsock-Sockets verwenden, wird es möglich, selektiv zu bestimmen, ob ein LSP zur Laufzeit an einem bestimmten Prozess beteiligt werden soll.

Unter Windows Vista und höher kann ein LSP basierend darauf klassifiziert werden, wie er mit Windows Sockets-Aufrufen und -Daten interagiert. Eine LSP-Kategorie ist eine identifizierbare Gruppe von Verhaltensweisen für eine Teilmenge der Winsock SPI-Funktionen. Beispielsweise würde ein HTTP-Inhaltsfilter als Dateninspektor (die kategorie LSP_INSPECTOR ) kategorisiert werden. Die LSP_INSPECTOR Kategorie überprüft parameter für SPI-Funktionen der Datenübertragung, aber ändert sie nicht. Eine Anwendung kann die Kategorie eines LSP abfragen und den LSP basierend auf der LSP-Kategorie und dem Satz zulässiger LSP-Kategorien der Anwendung nicht laden.

In der folgenden Tabelle sind Kategorien aufgeführt, in die ein LSP klassifiziert werden kann.

Ein LSP kann zu mehr als einer Kategorie gehören. Beispielsweise kann der Firewall-/Sicherheits-LSP sowohl zu den Kategorien Inspektor (LSP_INSPECTOR) als auch Firewall (LSP_FIREWALL) gehören.

Wenn für einen LSP keine Kategorie festgelegt ist, wird er als in der Kategorie Alle anderen betrachtet. Diese LSP-Kategorie wird nicht in Dienste oder Systemprozesse geladen (z. B. lsass, winlogon und viele svchost-Prozesse).

Die WSCSetProviderInfo32-Funktion kann nur von einem Benutzer aufgerufen werden, der als Mitglied der Gruppe Administratoren angemeldet ist. Wenn WSCSetProviderInfo32 von einem Benutzer aufgerufen wird, der kein Mitglied der Gruppe Administratoren ist, schlägt der Funktionsaufruf fehl, und WSANO_RECOVERY wird im lpErrno-Parameter zurückgegeben. Diese Funktion kann auch aufgrund der Benutzerkontensteuerung (User Account Control, UAC) fehlschlagen. Wenn eine Anwendung, die diese Funktion enthält, von einem Benutzer ausgeführt wird, der als Mitglied der Gruppe Administratoren angemeldet ist, die nicht der integrierten Administratorgruppe angehört, schlägt dieser Aufruf fehl, es sei denn, die Anwendung wurde in der Manifestdatei mit einem requestedExecutionLevel gekennzeichnet, der auf requireAdministrator festgelegt ist. Wenn in der Anwendung unter Windows Vista oder Windows Server 2008 diese Manifestdatei nicht vorhanden ist, muss ein Benutzer, der sich als Mitglied der Gruppe "Administratoren" angemeldet hat und nicht der integrierte Administrator die Anwendung in einer erweiterten Shell als integrierter Administrator (RunAs-Administrator) ausführen, damit diese Funktion erfolgreich ist.

Anforderungen

Weitere Informationen

Kategorisieren von mehrschichtigen Dienstanbietern und Anwendungen

WSAProtocol_Info

WSCGetApplicationCategory

WSCGetProviderInfo32

WSCSetApplicationCategory

WSCSetProviderInfo

WSC_PROVIDER_INFO_TYPE