WPUModifyIFSHandle-Funktion (ws2spi.h)

Die WPUModifyIFSHandle-Funktion empfängt ein (möglicherweise) geändertes IFS-Handle von Ws2_32.dll.

Syntax

SOCKET WPUModifyIFSHandle(
  [in]  DWORD  dwCatalogEntryId,
  [in]  SOCKET ProposedHandle,
  [out] LPINT  lpErrno
);

Parameter

[in] dwCatalogEntryId

Deskriptor, der den aufrufenden Dienstanbieter identifiziert.

[in] ProposedHandle

IFS-Handle, das vom Anbieter zugewiesen wird.

[out] lpErrno

Zeiger auf den Fehlercode.

Rückgabewert

Wenn kein Fehler auftritt, gibt WPUModifyIFSHandle das geänderte Sockethandle zurück. Andernfalls wird INVALID_SOCKET zurückgegeben, und ein bestimmter Fehlercode ist in lpErrno verfügbar.

Hinweise

Das WPUModifyIFSHandle-Handle ermöglicht es dem WS2_32.dll, seine internen Vorgänge zu optimieren, indem eine möglicherweise geänderte Version des bereitgestellten IFS-Handle zurückgegeben wird. Das zurückgegebene Handle ist für das Betriebssystem garantiert nicht vom vorgeschlagenen Handle zu unterscheiden. IFS-Anbieter müssen diese Funktion aufrufen, bevor sie einen neu erstellten Socketdeskriptor an einen Dienstanbieter zurückgeben. Der Dienstanbieter verwendet das geänderte Handle nur für nachfolgende Socketvorgänge. Diese Routine wird nur von IFS-Anbietern verwendet, deren Socketdeskriptoren echte IFS-Handles sind.

Diese Prozedur kann auch von einem Mehrschichtanbieter verwendet werden, der sich auf einem Basis-IFS-Anbieter befindet und die Sockethandles des Basisanbieters als eigene verfügbar machen möchte, anstatt sie mit einem WPUCreateSocketHandle-Aufruf zu erstellen. Ein Mehrschichtanbieter, der den IFS-Socket "durchlaufen" möchte, der ihn von der nächsten Ebene in der Kette empfängt, kann WPUModifyIFSHandle aufrufen und seine eigene Katalogeintrags-ID als dwCatalogEntryId übergeben. Dadurch wird die Windows Sockets-DLL darüber informiert, dass diese Ebene und nicht die nächste Ebene das Ziel für SPI-Aufrufe mit diesem Sockethandle sein sollte.

Es gibt mehrere Einschränkungen, die ein Anbieter mit mehreren Ebenen beachten sollte, wenn er diesen Ansatz verfolgt.

• Der Anbieter sollte Basisanbietereinstiegspunkte für LPWSPSend und LPWSPRecv in der Prozedur-Dispatchtabelle verfügbar machen, die er zum Zeitpunkt von WSPStartup zurückgibt, um sicherzustellen, dass der Zugriff des Windows Sockets SPI-Clients auf diese Funktionen so effizient wie möglich ist.
• Der Anbieter kann sich nicht darauf verlassen, dass seine Funktionen LPWSPSend und LPWSPRecv für alle E/A-Vorgänge aufgerufen werden, insbesondere bei den E/A-Systemfunktionen ReadFile und WriteFile. Diese Funktionen würden den Mehrschichtanbieter umgehen und die Implementierung des Basis-IFS-Anbieters direkt aufrufen, auch wenn der Mehrschichtanbieter seine eigenen Einstiegspunkte für diese Funktionen in die Prozedurverteilungstabelle einfügt.
• Der Anbieter kann sich nicht auf die Möglichkeit verlassen, überlappende E/A mithilfe von LPWSPSend, LPWSPSendTo, LPWSPRecv, LPWSPRecvFrom oder LPWSPIoctl nachzuverarbeiten. Nachverarbeitungsbenachrichtigungen können über Vervollständigungsports erfolgen und den Mehrschichtanbieter vollständig umgehen. Ein Anbieter mit Ebenen hat keine Möglichkeit, festzustellen, ob ein Vervollständigungsport verwendet wurde oder welcher Port er ist. Der Mehrschichtanbieter hat keine Möglichkeit, sich selbst in die Benachrichtigungssequenz einzufügen.
• Der Anbieter sollte alle überlappenden E/A-Anforderungen direkt an den Basisanbieter übergeben, indem er die ursprünglichen überlappenden Parameter verwendet (z. B. die WSAOVERLAPPED-Struktur und den Vervollständigungsroutinezeiger). Der Anbieter sollte den Einstiegspunkt des Basisanbieters für WSPGetOverlappedResult verfügbar machen. Da einige überlappende E/A-Anforderungen den Mehrschichtanbieter vollständig umgehen können, kann der Mehrschichtanbieter WSAOVERLAPPED-Strukturen nicht zuverlässig markieren, um zu bestimmen, für welche Er Ergebnisse melden kann und welche an das WSPGetOverlappedResult des zugrunde liegenden Anbieters übergeben werden müssen. Dies bedeutet effektiv, dass LPWSPIoctl ein Passthrough-Vorgang für den zugrunde liegenden Anbieter sein muss.

Anforderungen

Weitere Informationen

WPUCreateSocketHandle

WSAOVERLAPED

WSPGetOverlappedResult

LPWSPIoctl

LPWSPRecv

LPWSPSend