LPWSPDUPLICATESOCKET-Rückruffunktion (ws2spi.h)

Die LPWSPDuplicateSocket--Funktion gibt eine WSAPROTOCOL_INFO Struktur zurück, die zum Erstellen eines neuen Socketdeskriptors für einen freigegebenen Socket verwendet werden kann.

Syntax

LPWSPDUPLICATESOCKET Lpwspduplicatesocket;

int Lpwspduplicatesocket(
  [in]  SOCKET s,
  [in]  DWORD dwProcessId,
  [out] LPWSAPROTOCOL_INFOW lpProtocolInfo,
  [out] LPINT lpErrno
)
{...}

Parameter

[in] s

Lokaler Socketdeskriptor.

[in] dwProcessId

Bezeichner des Zielprozesses, für den der freigegebene Socket verwendet wird.

[out] lpProtocolInfo

Zeiger auf einen puffer, der vom Client zugeordnet ist, der groß genug ist, um eine WSAPROTOCOL_INFO Struktur zu enthalten. Der Dienstanbieter kopiert den Inhalt der Protokollinformationsstruktur in diesen Puffer.

[out] lpErrno

Zeigen Sie auf den Fehlercode.

Rückgabewert

Wenn kein Fehler auftritt, gibt LPWSPDuplicateSocket Null zurück. Andernfalls wird der Wert von SOCKET_ERROR zurückgegeben, und eine bestimmte Fehlernummer ist in lpErrnoverfügbar.

Bemerkungen

Ein Quellprozess ruft LPWSPDuplicateSocket- auf, um eine spezielle WSAPROTOCOL_INFO Struktur zu erhalten. Es verwendet einige Interprocess Communications (IPC)-Mechanismen, um den Inhalt dieser Struktur an einen Zielprozess zu übergeben, der ihn wiederum in einem Aufruf von LPWSPSocket- verwendet, um einen Deskriptor für den duplizierten Socket abzurufen. Beachten Sie, dass die spezielle WSAPROTOCOL_INFO Struktur nur einmal vom Zielprozess verwendet werden kann.

Es liegt in der Verantwortung des Dienstanbieters, alle Vorgänge auszuführen, die im Quellprozesskontext erforderlich sind, und eine WSAPROTOCOL_INFO Struktur zu erstellen, die erkannt wird, wenn sie anschließend als Parameter angezeigt wird, um LPWSPSocket im Kontext der Zielprozesse zu . Der Anbieter muss dann einen Socketdeskriptor zurückgeben, der auf einen gemeinsamen zugrunde liegenden Socket verweist. Das dwProviderReserved Mitglied der WSAPROTOCOL_INFO-Struktur steht für die Verwendung des Dienstanbieters zur Verfügung und kann zum Speichern nützlicher Kontextinformationen verwendet werden, einschließlich eines duplizierten Handles.

Wenn ein neuer Socketdeskriptor zugewiesen wird, muss ein installierbarer Dateisystemanbieter WPUModifyIFSHandle-aufrufen, und ein Nicht-IFS-Anbieter muss WPUCreateSocketHandle-aufrufen. Ein IFS-Anbieter kann die DuplicateHandle--Funktion verwenden. Um die ordnungsgemäße Ausführung der Socketduplizierung sicherzustellen, muss ein Nicht-IFS-Dienstanbieter die LPWSPDuplicateSocket--Funktion verwenden.

Ein mögliches Szenario für das Einrichten und Verwenden eines freigegebenen Sockets im Übergabemodus ist im folgenden Beispiel dargestellt.

Die Deskriptoren, die auf einen freigegebenen Socket verweisen, können unabhängig voneinander verwendet werden, soweit E/A betroffen ist. Die Windows Sockets-Schnittstelle implementiert jedoch keinen Zugriffssteuerungstyp, sodass es an den beteiligten Prozessen liegt, ihre Vorgänge in einem freigegebenen Socket zu koordinieren. Eine typische Verwendung für freigegebene Sockets besteht darin, einen Prozess zu haben, der für das Erstellen von Sockets und das Herstellen von Verbindungen verantwortlich ist, Sockets an andere Prozesse zu übergeben, die für den Informationsaustausch verantwortlich sind.

Da es sich um duplizierte Socketdeskriptoren und nicht um den zugrunde liegenden Socket handelt, werden alle Zustände, die einem Socket zugeordnet sind, in allen Deskriptoren gemeinsam gehalten. Beispielsweise wird ein WSPSetSockOpt- Vorgang, der mit einem Deskriptor ausgeführt wird, anschließend mithilfe eines LPWSPGetSockopt- von beliebigen oder allen Deskriptoren sichtbar. Ein Prozess kann LPWSPCloseSocket- in einem duplizierten Socket aufrufen, und der Deskriptor wird umgestellt. Der zugrunde liegende Socket bleibt jedoch geöffnet, bis LPWSPClosesocket- vom letzten verbleibenden Deskriptor aufgerufen wird.

Die Benachrichtigung über freigegebene Sockets unterliegt den üblichen Einschränkungen LPWSPAsyncSelect- und LPWSPEventSelect-. Durch das Ausgeben einer dieser Aufrufe mit einem der freigegebenen Deskriptoren wird jede vorherige Ereignisregistrierung für den Socket abgebrochen, unabhängig davon, welcher Deskriptor für diese Registrierung verwendet wurde. Ein freigegebener Socket kann z. B. keine FD_READ Ereignisse zum Verarbeiten von A- und FD_WRITE Ereignissen zum Verarbeiten von B liefern. In Situationen, in denen eine solche enge Koordination erforderlich ist, wird empfohlen, dass Entwickler Threads anstelle separater Prozesse verwenden.

Ein Schichtdienstanbieter stellt eine Implementierung dieser Funktion, aber es ist auch ein Client dieser Funktion, wenn und wenn er LPWSPDuplicateSocket der nächsten Ebene in der Protokollkette aufruft. Einige besondere Aspekte gelten für die lpProtocolInfo Parameter dieser Funktion, da sie über die Ebenen der Protokollkette verteilt wird.

Wenn die nächste Ebene in der Protokollkette eine andere Ebene ist, muss diese Ebene übergeben werden, wenn die LPWSPDuplicateSocket- der nächsten Ebene aufgerufen wird, eine lpProtocolInfo-, die auf dieselbe unveränderte WSAPROTOCOL_INFO Struktur mit den gleichen unveränderten Ketteninformationen verweist. Wenn die nächste Ebene jedoch das Basisprotokoll (d. h. das letzte Element in der Kette) ist, führt diese Ebene beim Aufrufen der LPWSPDuplicateSocketeine Ersetzung durch. In diesem Fall sollte auf die WSAPROTOCOL_INFO Struktur des Basisanbieters durch den parameter lpProtocolInfo verwiesen werden.

Ein wesentlicher Vorteil dieser Richtlinie ist, dass Basisdienstanbieter keine Protokollketten kennen müssen. Diese Richtlinie gilt auch beim Verteilen einer WSAPROTOCOL_INFO Struktur über eine ebenenweise Abfolge anderer Funktionen wie LPWSPAddressToString, WSPStartup, LPWSPSocketoder LPWSPStringToAddress.

Anforderungen

Siehe auch

WPUCreateSocketHandle-

WPUModifyIFSHandle-