Akzeptieren von Verbindungsanforderungen
Wenn eine Anwendung die Funktion WSAAccept, accept oder AcceptEx aufruft, um eine eingehende Verbindungsanforderung für einen Socket zu akzeptieren, leitet der Windows Sockets-Switch diesen Aufruf immer an den TCP/IP-Dienstanbieter weiter. Wenn eine eingehende Verbindungsanforderung aus einem Nicht-SAN-Netzwerk eingeht, fließt sie durch den NDIS-Pfad, und der TCP/IP-Dienstanbieter verarbeitet sie. Wenn eine Verbindungsanforderung von einem Remotepeer auf einem SAN eingeht, fungiert der Switch als Vermittler zwischen dem TCP/IP-Dienstanbieter und dem SAN-Dienstanbieter, um zu bestimmen, ob die Verbindungsanforderung akzeptiert werden soll, und um die WSAAccept-, Accept- oder AcceptEx-Funktion der Anwendung abzuschließen.
Die folgende Abbildung zeigt eine Übersicht über die Interaktion zwischen dem Windows Sockets-Switch und dem SAN-Dienstanbieter bei der Bestimmung, ob eine eingehende Verbindungsanforderung angenommen oder abgelehnt werden soll. In den folgenden Sequenzen und Abschnitten wird die Akzeptanzbestimmung ausführlicher beschrieben.
So akzeptieren oder ablehnen Sie eine Verbindungsanforderung
Beim Empfang einer eingehenden Verbindungsanforderung von einem Remotepeer signalisiert der SAN-Dienstanbieter ein Ereignisobjekt, wie unter Lauschen auf Verbindungen in einem SAN beschrieben.
Der Windows Sockets-Switch ruft die WSPEnumNetworkEvents-Funktion des SAN-Dienstanbieters auf, um den FD_ACCEPT Ereigniscode zu empfangen.
Beim Empfang des FD_ACCEPT Ereigniscodes ruft der Switch die WSPAccept-Funktion des SAN-Dienstanbieters auf, um die eingehende Verbindungsanforderung zu akzeptieren oder abzulehnen.
Im Aufruf des Switches an die WSPAccept-Funktion des SAN-Dienstanbieters gibt der Switch eine Bedingungsfunktion an. Der SAN-Dienstanbieter muss diese Bedingungsfunktion im selben Thread aufrufen, in dem die WSPAccept-Funktion aufgerufen wurde, bevor vom WSPAccept-Aufruf zurückgegeben wird.
Der Schalter gibt den CF_ACCEPT oder CF_REJECT Code aus dieser Bedingungsfunktion zurück, um anzugeben, dass die Verbindungsanforderung akzeptiert bzw. abgelehnt wird.
Annehmen einer Verbindungsanforderung und Erstellen eines akzeptierenden Sockets
Wenn eine Anwendung eine eingehende Verbindungsanforderung akzeptiert, gibt der Switch den CF_ACCEPT Code an den SAN-Dienstanbieter zurück, um die Bedingungsfunktion des Switches abzuschließen. Beim Empfang CF_ACCEPT initialisiert der SAN-Dienstanbieter eine interne Datenstruktur, in der er Informationen zum übernehmenden Socket speichert. Die WSPAccept-Funktion des SAN-Dienstanbieters muss als Nächstes die WPUCreateSocketHandle-Funktion aufrufen, um einen Deskriptor für den akzeptierenden Socket vom Switch abzurufen. Der SAN-Dienstanbieter muss den Deskriptor des Switches in seiner internen Datenstruktur für den übernehmenden Socket speichern und einen eigenen Deskriptor für den akzeptierenden Socket zurückgeben, um den WSPAccept-Aufruf abzuschließen. Der Switch muss den internen Deskriptor des SAN-Dienstanbieters für den akzeptierenden Socket bereitstellen, wenn die Funktionen des SAN-Dienstanbieters aufgerufen werden, während der SAN-Dienstanbieter den Socketdeskriptor des Switches bei Aufrufen an den Switch bereitstellen muss.
Vor dem erfolgreichen Abschließen von WSPAccept sollte der SAN-Dienstanbieter die Win32 ResetEvent-Funktion aufrufen, um das Ereignisobjekt zurückzusetzen. Dadurch kann der SAN-Dienstanbieter später die Win32 SetEvent-Funktion aufrufen, um dem Switch zu signalisieren, dass er die nächste eingehende Verbindungsanforderung akzeptiert.
Ablehnen einer Verbindungsanforderung
Wenn eine Anwendung eine eingehende Verbindungsanforderung ablehnt, gibt der Switch den CF_REJECT Code an den SAN-Dienstanbieter zurück, um die Bedingungsfunktion des Switches abzuschließen. Beim Empfang CF_REJECT sollte der SAN-Dienstanbieter den WSAECONNREFUSED-Fehlercode an den Switch zurückgeben, um den WSPAccept-Aufruf abzuschließen.
Angeben der Annahme oder Ablehnung einer Verbindungsanforderung an einen Remotepeer
Bevor ein SAN-Dienstanbieter einem Remotepeer mitteilen kann, dass er die Verbindungsanforderung des Remotepeers akzeptiert oder ablehnt, muss der SAN-Dienstanbieter die Bedingungsfunktion des Switches aufrufen. Abhängig vom Wert, den die Bedingungsfunktion des Switches zurückgibt, sollte der SAN-Dienstanbieter dem Remotepeer einen der folgenden Hinweise geben:
Wenn die Bedingungsfunktion des Switches CF_ACCEPT zurückgibt, sollte der SAN-Dienstanbieter angeben, dass er die Verbindungsanforderung des Remotepeers akzeptiert. Der SAN-Dienstanbieter auf dem Remotepeer kann dann erfolgreich seinen Verbindungsvorgang abschließen, der durch einen WSPConnect-Aufruf initiiert wurde.
Wenn die Bedingungsfunktion des Switches CF_REJECT zurückgibt, sollte der SAN-Dienstanbieter angeben, dass er die Verbindungsanforderung des Remotepeers ablehnt. Der SAN-Dienstanbieter auf dem Remotepeer muss seinen Verbindungsvorgang, der durch einen WSPConnect-Aufruf mit dem WSAECONNREFUSED-Fehlercode initiiert wurde, fehlschlagen.
Sitzungsverhandlung
Nachdem der Switch erfolgreich einen SAN-Dienstanbieter verwendet hat, um eine Verbindungsanforderung von einem Remotepeer anzunehmen, handelt der Switch eine Sitzung mit diesem Peer aus.
So verhandeln Sie eine Sitzung
Der Switch auf dem Remotepeer ruft die WSPRecv-Funktion des SAN-Dienstanbieters auf, um eine Reihe von Empfangspuffern zu posten.
Der Switch auf dem Remotepeer ruft die WSPSend-Funktion des SAN-Dienstanbieters auf, um eine Sitzungsverhandlungsnachricht an den Switch am lokalen akzeptierenden Endpunkt zu senden. Diese Meldung enthält die Anzahl der Empfangspuffer, die der Switch auf dem Remotepeer bereitgestellt hat.
Der Switch am lokalen akzeptierenden Endpunkt ruft die WSPRecv-Funktion des lokalen SAN-Dienstanbieters auf, um seine eigenen Empfangspuffer zu veröffentlichen, aber möglicherweise nicht rechtzeitig, um die Sitzungsverhandlungsnachricht zu empfangen. Wenn der lokale Switch nicht rechtzeitig einen Empfangspuffer postet und die zugrunde liegende NIC die Flusssteuerung nicht unterstützt, muss der SAN-Dienstanbieter am lokalen akzeptierenden Endpunkt die Sitzungsverhandlungsnachricht des Remoteswitches in seinen eigenen privaten Empfangspuffern puffern. Wenn der Switch Puffer empfängt, kopiert der SAN-Dienstanbieter Daten aus seinen privaten Empfangspuffern 1:1 in die Switchpuffer, bis alle Daten aus den privaten Puffern in die Switchpuffer kopiert wurden.
Der SAN-Dienstanbieter führt die normale Empfangsverarbeitung für nachfolgende Switchpuffer aus, d. h., er sendet alle diese Switchpuffer in die Empfangswarteschlange auf der NIC.
Beachten Sie, dass ein SAN-Dienstanbieter eine Verbindung nicht abbrechen darf, nur weil der Switch vor dem Eintreffen der Sitzungsverhandlungsmeldung keinen Empfangspuffer bereitgestellt hat. Die maximale Länge einer Sitzungsverhandlungsnachricht beträgt 256 Bytes.
Der Schalter am lokalen Akzeptierenden Endpunkt stellt seine Empfangspuffer bereit, bevor auf die Sitzungsverhandlungsnachricht reagiert wird. Der lokale Switch ruft die WSPSend-Funktion des lokalen SAN-Dienstanbieters auf, um auf die Sitzungsverhandlungsnachricht zu reagieren. Die Antwort des lokalen Switches enthält die Anzahl der Empfangspuffer, die der lokale Switch bereitgestellt hat. Ab diesem Zeitpunkt garantiert der lokale Switch, dass der bereitgestellte Satz von Empfangspuffern eine ausreichende Größe hat, um jede Nachricht zu empfangen, die über die Verbindung eingeht.
Wenn eine Anwendung in ihrem AcceptEx-Aufruf einen anfänglichen Empfangspuffer angibt, wartet der Schalter, bis die erste Datennachricht von ihrem Remotepeer empfangen wird, bevor der AcceptEx-Aufruf der Anwendung abgeschlossen wird.
Wenn die Anwendung ihren eigenen Annahmeaufruf abbricht, ruft der Switch die WSPCloseSocket-Funktion des entsprechenden SAN-Dienstanbieters auf, um den akzeptierenden SAN-Socket zu schließen.