LPWSPIOCTL-Rückruffunktion (ws2spi.h)

Artikel
08/28/2023

Die LPWSPIoctl-Funktion steuert den Modus eines Sockets.

Syntax

LPWSPIOCTL Lpwspioctl;

int Lpwspioctl(
  [in]  SOCKET s,
  [in]  DWORD dwIoControlCode,
  [in]  LPVOID lpvInBuffer,
  [in]  DWORD cbInBuffer,
  [out] LPVOID lpvOutBuffer,
  [in]  DWORD cbOutBuffer,
  [out] LPDWORD lpcbBytesReturned,
  [in]  LPWSAOVERLAPPED lpOverlapped,
  [in]  LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine,
  [in]  LPWSATHREADID lpThreadId,
  [in]  LPINT lpErrno
)
{...}

Parameter

[in] s

Ein Deskriptor, der einen Socket identifiziert.

[in] dwIoControlCode

Der Steuerungscode des auszuführenden Vorgangs.

[in] lpvInBuffer

Ein Zeiger auf den Eingabepuffer.

[in] cbInBuffer

Die Größe des Eingabepuffers in Bytes.

[out] lpvOutBuffer

Ein Zeiger auf den Ausgabepuffer.

[in] cbOutBuffer

Die Größe des Ausgabepuffers in Bytes.

[out] lpcbBytesReturned

Ein Zeiger auf die tatsächliche Anzahl von Bytes der Ausgabe.

[in] lpOverlapped

Ein Zeiger auf eine WSAOverlapped-Struktur (wird für nicht überlappende Sockets ignoriert).

[in] lpCompletionRoutine

Typ: _In_opt_ LPWSAOVERLAPPED_COMPLETION_ROUTINE

Ein Zeiger auf die Abschlussroutine, die aufgerufen wird, wenn der Vorgang abgeschlossen wurde (bei nicht überlappenden Sockets ignoriert). Siehe Hinweise.

[in] lpThreadId

Ein Zeiger auf eine WSATHREADID-Struktur , die vom Anbieter in einem nachfolgenden Aufruf von WPUQueueApc verwendet werden soll. Der Anbieter sollte die referenzierte WSATHREADID-Struktur (nicht den Zeiger) speichern, bis die WPUQueueApc-Funktion zurückgegeben wird.

[in] lpErrno

Ein Zeiger auf den Fehlercode.

Rückgabewert

Wenn kein Fehler auftritt und der Vorgang sofort abgeschlossen wurde, gibt LPWSPIoctl null zurück. Beachten Sie, dass in diesem Fall die Vervollständigungsroutine, sofern angegeben, bereits in die Warteschlange eingereiht wurde. Andernfalls wird der Wert SOCKET_ERROR zurückgegeben, und ein bestimmter Fehlercode ist in lpErrno verfügbar. Der Fehlercode WSA_IO_PENDING gibt an, dass ein überlappender Vorgang erfolgreich initiiert wurde und dass der Abschluss zu einem späteren Zeitpunkt angezeigt wird. Jeder andere Fehlercode gibt an, dass kein überlappender Vorgang initiiert wurde und keine Abschlussanzeige erfolgt.

Fehlercode	Bedeutung
WSA_IO_PENDING	Ein überlappender Vorgang wurde erfolgreich initiiert, und der Abschluss wird zu einem späteren Zeitpunkt angezeigt.
WSAEFAULT	Der Parameter lpvInBuffer, lpvOutBuffer oder lpcbBytesReturned ist nicht vollständig in einem gültigen Teil des Benutzeradressraums enthalten, oder der Parameter cbInBuffer oder cbOutBuffer ist zu klein.
WSAEINVAL	DwIoControlCode ist kein gültiger Befehl, oder ein bereitgestellter Eingabeparameter ist nicht akzeptabel, oder der Befehl gilt nicht für den typ des bereitgestellten Sockets.
WSAEINPROGRESS	Die Funktion wird aufgerufen, wenn ein Rückruf ausgeführt wird.
WSAENETDOWN	Fehler beim Netzwerksubsystem.
WSAENOTSOCK	Der Deskriptor s ist kein Socket.
WSAEOPNOTSUPP	Der angegebene IOCTL-Befehl kann nicht realisiert werden. Beispielsweise können die in SIO_SET_QOS angegebenen Datenflussspezifikationen nicht erfüllt werden.
WSAEWOULDBLOCK	Der Socket wird als nicht blockiert markiert, und der angeforderte Vorgang würde blockiert.

Hinweise

Diese Routine wird verwendet, um Betriebsparameter festzulegen oder abzurufen, die dem Socket, dem Transportprotokoll oder dem Kommunikationssubsystem zugeordnet sind. Wenn sowohl lpOverlapped als auch lpCompletionRoutineNULL sind, wird der Socket in dieser Funktion als nicht überlappter Socket behandelt.

Bei nicht überlappenden Sockets werden die Parameter lpOverlapped und lpCompletionRoutine ignoriert, und diese Funktion kann blockieren, wenn sich Sockets im Blockierungsmodus befinden. Beachten Sie, dass diese Funktion WSAEWOULDBLOCK zurückgeben kann, wenn sich Sockets im Nichtblockierungsmodus befinden, wenn der angegebene Vorgang nicht sofort abgeschlossen werden kann. In diesem Fall kann der SPI-Client von Windows Sockets den Socket in den Blockiermodus ändern und die Anforderung erneut ausführen oder auf das entsprechende Netzwerkereignis (z. B. FD_ROUTING_INTERFACE_CHANGE oder FD_ADDRESS_LIST_CHANGE bei SIO_ROUTING_INTERFACE_CHANGE oder SIO_ADDRESS_LIST_CHANGE) mithilfe von Windows-Nachrichten (über LPWSPAsyncSelect oder event (mit LPWSPEventSelect) warten.

Bei überlappenden Sockets werden Vorgänge initiiert, die nicht sofort abgeschlossen werden können, und der Abschluss wird zu einem späteren Zeitpunkt angezeigt. Der DWORD-Wert , auf den der zurückgegebene parameter lpcbBytesReturned verweist, kann ignoriert werden. Der endgültige Abschluss status und zurückgegebenen Bytes können abgerufen werden, wenn die entsprechende Vervollständigungsmethode signalisiert wird, wenn der Vorgang abgeschlossen ist.

Jede IOCTL kann je nach Implementierung des Dienstanbieters unbegrenzt blockiert werden. Wenn der SPI-Client von Windows Sockets keine Blockierung in einem LPWSPIoctl-Aufruf tolerieren kann, wird empfohlen, dass sich überlappende E/A für IOCTLs, die am ehesten blockieren, einschließlich:

SIO_ADDRESS_LIST_CHANGE
SIO_FINDROUTE
SIO_FLUSH
SIO_GET_QOS
SIO_GET_GROUP_QOS
SIO_ROUTING_INTERFACE_CHANGE
SIO_SET_QOS
SIO_SET_GROUP_QOS

Einige protokollspezifische IOCTLs können auch besonders wahrscheinlich blockieren. Informationen finden Sie im entsprechenden protokollspezifischen Anhang.

Der Prototyp für die Vervollständigungsroutine, auf die der lpCompletionRoutine-Parameter verweist, lautet wie folgt.

void CALLBACK 
CompletionRoutine(  
  IN DWORD           dwError, 
  IN DWORD           cbTransferred, 
  IN LPWSAOVERLAPPED lpOverlapped, 
  IN DWORD           dwFlags 
);

Die CompletionRoutine ist ein Platzhalter für einen von der Anwendung bereitgestellten Funktionsnamen. Der dwError-Parameter gibt den Abschluss status für den überlappenden Vorgang an, wie durch den lpOverlapped-Parameter angegeben. Der cbTransferred-Parameter gibt die Anzahl der empfangenen Bytes an. Der dwFlags-Parameter wird für diese IOCTL nicht verwendet. Die Vervollständigungsroutine gibt keinen Wert zurück.

So sehr der dwIoControlCode-Parameter jetzt eine 32-Bit-Entität ist, ist es möglich, ein Codierungsschema zu übernehmen, das eine bequeme Möglichkeit zum Partitionieren des Opcode-Bezeichnerbereichs bietet. Der dwIoControlCode-Parameter ist so konzipiert, dass beim Hinzufügen neuer Steuercodes Protokoll- und Herstellerunabhängigkeit gewährleistet wird, während die Abwärtskompatibilität mit Windows Sockets 1.1- und UNIX-Steuercodes beibehalten wird. Der dwIoControlCode-Parameter weist die folgende Form auf.

Bit 31	Bit 30	Bit 29	Bits 28 und 27	Bits 26 bis 16	Bits 15 bis 0
I	O	V	T	Anbieter/Adressfamilie	Code

Ich wird festgelegt, wenn der Eingabepuffer für den Code gültig ist, wie bei IOC_IN.

O wird festgelegt, wenn der Ausgabepuffer für den Code gültig ist, wie bei IOC_OUT. Beachten Sie, dass für Codes mit Eingabe- und Ausgabeparametern sowohl I als auch O festgelegt werden.

V wird festgelegt, wenn keine Parameter für den Code vorhanden sind, wie bei IOC_VOID.

T ist eine Zwei-Bit-Menge, die den Typ der IOCTL definiert. Die folgenden Werte werden definiert.

0 gibt an, dass die IOCTL ein standardmäßiger UNIX-IOCTL-Code ist, wie bei FIONREAD, FIONBIO usw.
1 gibt an, dass die IOCTL ein generischer IOCTL-Code für Windows Sockets 2 ist. Neue IOCTL-Codes, die für Windows Sockets 2 definiert sind, verfügen über T == 1.
2 gibt an, dass die IOCTL nur für eine bestimmte Adressfamilie gilt.
3 Die IOCTL gilt nur für den Anbieter eines bestimmten Anbieters. Dieser Typ ermöglicht es Unternehmen, eine Lieferantennummer zuzuweisen, die im Familienmitglied des Anbieters/Der Adresse angezeigt wird. Anschließend kann der Anbieter neue IOCTLs definieren, die für diesen Anbieter spezifisch sind, ohne die IOCTL bei einem Clearinghouse registrieren zu müssen, was dem Anbieter Flexibilität und Datenschutz bietet.

Anbieter-/Adressfamilie ist eine 11-Bit-Menge, die den Anbieter definiert, dem der Code gehört (wenn T3 == ), oder die die Adressfamilie enthält, für die der Code gilt (wenn T == 2). Wenn es sich um einen UNIX-IOCTL-Code (T == 0) handelt, hat dieser Member den gleichen Wert wie der Code unter UNIX. Wenn es sich um eine generische Windows Sockets 2 IOCTL (T1 == ) handelt, kann dieses Element als Erweiterung des Codemembers verwendet werden, um zusätzliche Codewerte bereitzustellen.

Code ist der spezifische IOCTL-Code für den Vorgang.

Die folgenden UNIX-Befehle werden unterstützt:

FIONBIO

Aktiviert oder deaktiviert den Nichtblockierungsmodus für Sockets. Der lpvInBuffer-Parameter zeigt auf einen long ohne Vorzeichen, der nichtzero ist, wenn der Nichtblockierungsmodus aktiviert werden soll, und null, wenn er deaktiviert werden soll. Wenn ein Socket erstellt wird, wird er im Blockierungsmodus ausgeführt (d. a. der Nichtblockierungsmodus ist deaktiviert). Dies ist konsistent mit Berkeley Software Distribution (BSD)-Sockets.

Die LPWSPAsyncSelect - oder LPWSPEventSelect-Routine legt einen Socket automatisch auf den Nichtblockierungsmodus fest. Wenn LPWSPAsyncSelect oder LPWSPEventSelect für einen Socket ausgestellt wurde, schlägt jeder Versuch, LPWSPIoctl zum Zurücksetzen des Sockets auf den Blockiermodus zu verwenden, mit WSAEINVAL fehl. Um den Socket wieder in den Blockiermodus zu versetzen, muss ein Windows Sockets SPI-Client zuerst LPWSPAsyncSelect deaktivieren, indem LPWSPAsyncSelect mit dem lEvent-Parameter gleich null aufgerufen wird, oder LPWSPEventSelect durch Aufrufen von LPWSPEventSelect mit dem lNetworkEvents-Parameter gleich 0.

FIONREAD

Bestimmen Sie die Menge an Daten, die atomar aus Sockets gelesen werden können. Der lpvOutBuffer-Parameter zeigt auf eine Lange ohne Vorzeichen , in der WSAIoctl das Ergebnis speichert.

Wenn der im s-Parameter übergebene Socket streamorientiert ist (z. B. Typ SOCK_STREAM), gibt FIONREAD die Gesamtmenge der Daten zurück, die in einem einzelnen Empfangsvorgang gelesen werden können. dies entspricht normalerweise der Gesamtmenge der Daten, die im Socket in die Warteschlange gestellt werden (da ein Datenstrom byteorientiert ist, ist dies nicht garantiert).

Wenn der socket, der im s-Parameter übergeben wird, nachrichtenorientiert ist (z. B. typ SOCK_DGRAM), gibt FIONREAD die Gesamtzahl der zum Lesen verfügbaren Bytes zurück, nicht die Größe des ersten Datagramms (Nachricht), das auf dem Socket in die Warteschlange gestellt wurde.

SIOCATMARK

Bestimmt, ob alle OOB-Daten gelesen wurden oder nicht. Dies gilt nur für einen Socket im Streamstil (z. B. typ SOCK_STREAM), der für den Inlineempfang beliebiger OOB-Daten (SO_OOBINLINE) konfiguriert wurde. Wenn keine OOB-Daten auf das Lesen warten, gibt der Vorgang TRUE zurück. Andernfalls wird FALSE zurückgegeben, und der nächste Empfangsvorgang, der für den Socket ausgeführt wird, ruft einige oder alle daten ab, die der Markierung vorangehen. Der Windows Sockets SPI-Client sollte den SIOCATMARK-Vorgang verwenden, um zu bestimmen, ob eine datei vorhanden ist. Wenn den dringenden (OOB)-Daten normale Daten vorangehen, werden sie in der richtigen Reihenfolge empfangen. (Beachten Sie, dass Empfangsvorgänge niemals OOB und normale Daten im selben Aufruf mischen.) lpvOutBuffer zeigt auf eine BOOL , in der LPWSPIoctl das Ergebnis speichert.

Die folgenden Windows Sockets 2-Befehle werden unterstützt:

SIO_ACQUIRE_PORT_RESERVATION (Opcodeeinstellung: I, T==3)

Fordern Sie eine Laufzeitreservierung für einen Block von TCP- oder UDP-Ports an. Für Laufzeitportreservierungen erfordert der Portpool, dass Reservierungen aus dem Prozess genutzt werden, für den die Reservierung gewährt wurde. Laufzeitportreservierungen dauern nur so lange wie die Lebensdauer des Sockets, für den die SIO_ACQUIRE_PORT_RESERVATION IOCTL aufgerufen wurde. Im Gegensatz dazu können persistente Portreservierungen, die mit der Funktion CreatePersistentTcpPortReservation oder CreatePersistentUdpPortReservation erstellt wurden, von jedem Prozess verwendet werden, der persistente Reservierungen abrufen kann.

Ausführlichere Informationen finden Sie in der referenz SIO_ACQUIRE_PORT_RESERVATION .

SIO_ACQUIRE_PORT_RESERVATION wird unter Windows Vista und höheren Versionen des Betriebssystems unterstützt.

SIO_ADDRESS_LIST_CHANGE (Opcodeeinstellung: T==1)

Um Benachrichtigungen über Änderungen in der Liste der lokalen Transportadressen der Protokollfamilie des Sockets zu erhalten, an die der Windows Sockets SPI-Client gebunden werden kann. Nach Abschluss dieser IOCTL werden keine Ausgabeinformationen bereitgestellt. die Vervollständigung gibt lediglich an, dass sich die Liste der verfügbaren lokalen Adressen geändert hat und erneut über SIO_ADDRESS_LIST_QUERY abgefragt werden sollte.

Es wird davon ausgegangen (obwohl nicht erforderlich), dass der Spi-Client von Windows Sockets überlappende E/A verwendet, um durch Abschluss SIO_ADDRESS_LIST_CHANGE Anforderung über Änderungen benachrichtigt zu werden. Wenn die SIO_ADDRESS_LIST_CHANGE IOCTL auf einem nicht blockierenden Socket und ohne überlappende Parameter (lpOverlapped und lpCompletionRoutine sind auf NULL festgelegt) ausgestellt wird, wird sie sofort mit dem Fehler WSAEWOULDBLOCK abgeschlossen. Der Windows Sockets SPI-Client kann dann über einen Aufruf von LPWSPEventSelect oder LPWSPAsyncSelect mit dem in der Netzwerkereignisbitmaske festgelegten FD_ADDRESS_LIST_CHANGE Bit auf Änderungsereignisse der Adressliste warten.

SIO_ADDRESS_LIST_QUERY (Opcodeeinstellung: O, T==1)

Ruft eine Liste der lokalen Transportadressen der Protokollfamilie des Sockets ab, an die die Anwendung gebunden werden kann. Die Liste der Adressen variiert je nach Adressfamilie, und einige Adressen werden aus der Liste ausgeschlossen.

Hinweis

In Windows Plug-n-Play-Umgebungen können Adressen dynamisch hinzugefügt und entfernt werden. Daher können Sich Anwendungen nicht darauf verlassen, dass die von SIO_ADDRESS_LIST_QUERY zurückgegebenen Informationen persistent sind. Anwendungen können sich für Adressänderungsbenachrichtigungen über die SIO_ADDRESS_LIST_CHANGE IOCTL registrieren, die Benachrichtigungen entweder überlappende E/A- oder FD_ADDRESS_LIST_CHANGE-Ereignisse bereitstellt. Die folgende Abfolge von Aktionen kann verwendet werden, um sicherzustellen, dass die Anwendung immer über aktuelle Adresslisteninformationen verfügt:

Problem SIO_ADDRESS_LIST_CHANGE IOCTL
Problem SIO_ADDRESS_LIST_QUERY IOCTL
Wenn SIO_ADDRESS_LIST_CHANGE IOCTL die Anwendung von Adresslistenänderungen benachrichtigt (entweder durch überlappende E/A oder durch Signalisierung FD_ADDRESS_LIST_CHANGE Ereignisses), sollte die gesamte Abfolge von Aktionen wiederholt werden.

Ausführlichere Informationen finden Sie in der referenz SIO_ADDRESS_LIST_QUERY . SIO_ADDRESS_LIST_QUERY wird unter Windows 2000 und höher unterstützt.

SIO_ASSOCIATE_HANDLE (Opcodeeinstellung: I, T==1)

Ordnet diesen Socket dem angegebenen Handle einer Begleitschnittstelle zu. Der Eingabepuffer enthält den ganzzahligen Wert, der der Manifestkonstante für die Begleitschnittstelle entspricht (z. B. TH_NETDEV und TH_TAPI), gefolgt von einem Wert, der ein Handle der angegebenen Begleitschnittstelle ist, sowie alle anderen erforderlichen Informationen. Weitere Details finden Sie im entsprechenden Abschnitt des Windows Sockets 2-Protocol-Specific Anhangs und/oder der Dokumentation für die jeweilige Begleitschnittstelle. (Diese Ressourcen sind möglicherweise nur auf Englisch verfügbar.) Die Gesamtgröße wird in der Eingabepufferlänge widerspiegelt. Es ist kein Ausgabepuffer erforderlich. Der WSAENOPROTOOPT-Fehlercode wird für Dienstanbieter angegeben, die diese IOCTL nicht unterstützen. Das dieser IOCTL zugeordnete Handle kann mithilfe von SIO_TRANSLATE_HANDLE abgerufen werden.

Eine Begleitschnittstelle kann beispielsweise verwendet werden, wenn ein bestimmter Anbieter Folgendes bereitstellt:

Viel zusätzliche Kontrolle über das Verhalten eines Sockets.
Anbieterspezifische Steuerelemente, die nicht vorhandenen Windows Socket-Funktionen (oder denen, die für die Zukunft wahrscheinlich sind) zugeordnet werden.

Es empfiehlt sich, COM (Component Object Model) anstelle von IOCTL zu verwenden, um weitere Schnittstellen zu ermitteln und nachzuverfolgen, die möglicherweise von einem Socket unterstützt werden. Diese IOCTL ist aufgrund der Abwärtskompatibilität mit Systemen vorhanden, bei denen COM nicht verfügbar ist oder aus einem anderen Grund nicht verwendet werden kann.

SIO_ASSOCIATE_PORT_RESERVATION (Opcodeeinstellung: I, T==3)

Ordnen Sie einen Socket einer persistenten Oder Laufzeitreservierung für einen Block von TCP- oder UDP-Ports zu, die durch das Portreservierungstoken identifiziert werden. Die SIO_ASSOCIATE_PORT_RESERVATION IOCTL muss ausgestellt werden, bevor der Socket gebunden wird. Wenn und wenn der Socket gebunden ist, wird der ihm zugewiesene Port aus der Portreservierung ausgewählt, die durch das angegebene Token identifiziert wird. Wenn keine Ports aus der angegebenen Reservierung verfügbar sind, schlägt der Aufruf der Bind-Funktion fehl.

Ausführlichere Informationen finden Sie in der referenz SIO_ASSOCIATE_PORT_RESERVATION .

SIO_ASSOCIATE_PORT_RESERVATION wird unter Windows Vista und höheren Versionen des Betriebssystems unterstützt.

SIO_BASE_HANDLE (Opcodeeinstellung: O, T==1)

Ruft das Basisdienstanbieterhandle für einen bestimmten Socket ab. Der zurückgegebene Wert ist ein SOCKET.

Ein Mehrschichtdienstanbieter sollte diese IOCTL niemals abfangen, da der Rückgabewert das Sockethandle des Basisdienstanbieters sein muss.

Wenn der Ausgabepuffer nicht groß genug für ein Sockethandle ist (der cbOutBuffer ist kleiner als die Größe eines SOCKET) oder der lpvOutBuffer-Parameter ein NULL-Zeiger ist, wird SOCKET_ERROR als Ergebnis dieses IOCTL zurückgegeben und WSAGetLastError gibt WSAEFAULT zurück.

SIO_BASE_HANDLE wird in der Headerdatei "Mswsock.h " definiert und unter Windows Vista und höher unterstützt.

SIO_BSP_HANDLE (Opcodeeinstellung: O, T==1)

Ruft das Basisdienstanbieterhandle für einen Socket ab, der von der WSASendMsg-Funktion verwendet wird. Der zurückgegebene Wert ist ein SOCKET.

Dieser Ioctl wird von einem mehrschichtigen Dienstanbieter verwendet, um sicherzustellen, dass der Anbieter die WSASendMsg-Funktion abfängt.

SIO_BSP_HANDLE wird in der Headerdatei "Mswsock.h " definiert und unter Windows Vista und höher unterstützt.

SIO_BSP_HANDLE_SELECT (Opcodeeinstellung: O, T==1)

Ruft das Basisdienstanbieterhandle für einen Socket ab, der von der Select-Funktion verwendet wird. Der zurückgegebene Wert ist ein SOCKET.

Dieses Ioctl wird von einem mehrschichtigen Dienstanbieter verwendet, um sicherzustellen, dass der Anbieter die Select-Funktion abfängt.

SIO_BSP_HANDLE_SELECT wird in der Headerdatei "Mswsock.h " definiert und unter Windows Vista und höher unterstützt.

SIO_BSP_HANDLE_POLL (Opcodeeinstellung: O, T==1)

Ruft das Basisdienstanbieterhandle für einen Socket ab, der von der WSAPoll-Funktion verwendet wird. Der lpOverlapped-Parameter muss ein NULL-Zeiger sein. Der zurückgegebene Wert ist ein SOCKET.

Dieser Ioctl wird von einem mehrschichtigen Dienstanbieter verwendet, um sicherzustellen, dass der Anbieter die WSAPoll-Funktion abfängt .

Wenn der Ausgabepuffer nicht groß genug für ein Sockethandle ist (der cbOutBuffer ist kleiner als die Größe eines SOCKET), ist der lpvOutBuffer-Parameter ein NULL-Zeiger oder der lpOverlapped-Parameter ist kein NULL-Zeiger , SOCKET_ERROR als Ergebnis dieses IOCTL zurückgegeben wird und WSAGetLastErrorWSAEFAULT zurückgibt.

SIO_BSP_HANDLE_POLL wird in der Headerdatei "Mswsock.h " definiert und unter Windows Vista und höher unterstützt.

SIO_CHK_QOS (Opcodeeinstellung: I, O, T==3)

Ruft Informationen zu QoS-Datenverkehrseigenschaften ab. Während der Übergangsphase des Sendens des Systems zwischen der Floweinrichtung und dem Empfang einer RESV-Nachricht (weitere Informationen zur Übergangsphase finden Sie unter So ruft der RSVP-Dienst TC auf) wird der einem RSVP-Fluss zugeordnete Datenverkehr basierend auf dem Diensttyp (BEST EFFORT, CONTROLLED LOAD oder GUARANTEED) strukturiert. Weitere Informationen finden Sie unter Verwenden von SIO_CHK_QOS im Abschnitt Quality of Service des Platform Software Development Kit (SDK).

SIO_ENABLE_CIRCULAR_QUEUEING (Opcodeeinstellung: V, T==1)

Gibt einem nachrichtenorientierten Dienstanbieter an, dass eine neu eingetroffene Nachricht niemals aufgrund eines Pufferwarteschlangenüberlaufs gelöscht werden soll. Stattdessen sollte die älteste Nachricht in der Warteschlange entfernt werden, um die neu eingetroffene Nachricht aufzunehmen. Es sind keine Eingabe- und Ausgabepuffer erforderlich. Beachten Sie, dass diese IOCTL nur für Sockets gültig ist, die unzuverlässigen, nachrichtenorientierten Protokollen zugeordnet sind. Der WSAENOPROTOOPT-Fehlercode wird für Dienstanbieter angegeben, die diese IOCTL nicht unterstützen.

SIO_FIND_ROUTE (Opcodeeinstellung: O, T==1)

Bei der Ausgabe fordert diese IOCTL an, dass die Route zu der Remoteadresse ermittelt wird, die als Sockaddr im Eingabepuffer angegeben ist. Wenn die Adresse bereits im lokalen Cache vorhanden ist, wird ihr Eintrag ungültig. Im Fall von Novells IPX initiiert dieser Aufruf eine IPX GetLocalTarget (GLT), die das Netzwerk nach der angegebenen Remoteadresse abfragt.

SIO_FLUSH (Opcodeeinstellung: V, T==1)

Verwirft den aktuellen Inhalt der sendenden Warteschlange, die diesem Socket zugeordnet ist. Es sind keine Eingabe- und Ausgabepuffer erforderlich. Der WSAENOPROTOOPT-Fehlercode wird für Dienstanbieter angegeben, die diese IOCTL nicht unterstützen.

SIO_GET_BROADCAST_ADDRESS (Opcodeeinstellung: O, T==1)

Diese IOCTL füllt den Ausgabepuffer mit einer sockaddr-Struktur , die eine geeignete Broadcastadresse für die Verwendung mit LPWSPSendTo enthält.

SIO_GET_EXTENSION_FUNCTION_POINTER (Opcodeeinstellung: O, I, T==1)

Rufen Sie einen Zeiger auf die angegebene Erweiterungsfunktion ab, die vom zugeordneten Dienstanbieter unterstützt wird. Der Eingabepuffer enthält eine GUID (Globally Unique Identifier), deren Wert die betreffende Erweiterungsfunktion identifiziert. Der Zeiger auf die gewünschte Funktion wird im Ausgabepuffer zurückgegeben. Erweiterungsfunktionsbezeichner werden von Dienstanbieteranbietern eingerichtet und sollten in die Herstellerdokumentation aufgenommen werden, in der die Funktionen und Semantik von Erweiterungsfunktionen beschrieben werden.

Die GUID-Werte für Erweiterungsfunktionen, die vom Windows TCP/IP-Dienstanbieter unterstützt werden, sind in der Headerdatei Mswsock.h definiert. Der mögliche Wert für diese GUIDs lautet wie folgt:

Begriff	BESCHREIBUNG
WSAID_ACCEPTEX	Die AcceptEx-Erweiterungsfunktion .
WSAID_CONNECTEX	Die ConnectEx-Erweiterungsfunktion .
WSAID_DISCONNECTEX	Die DisconnectEx-Erweiterungsfunktion .
WSAID_GETACCEPTEXSOCKADDRS	Die Erweiterungsfunktion GetAcceptExSockaddrs .
WSAID_TRANSMITFILE	Die TransmitFile-Erweiterungsfunktion .
WSAID_TRANSMITPACKETS	Die TransmitPackets-Erweiterungsfunktion .
WSAID_WSARECVMSG	Die erweiterungsfunktion LPFN_WSARECVMSG (WSARecvMsg).
WSAID_WSASENDMSG	Die WSASendMsg-Erweiterungsfunktion .

SIO_GET_GROUP_QOS (Opcodeeinstellung: O, T==1)

Reserviert.

SIO_GET_INTERFACE_LIST (Opcodeeinstellung: O, T==0)

Gibt eine Liste der konfigurierten IP-Schnittstellen und deren Parameter als Array von INTERFACE_INFO-Strukturen zurück.

Hinweis

Die Unterstützung dieses Befehls ist für Windows Sockets 2-kompatible TCP/IP-Dienstanbieter obligatorisch.

Der Parameter lpvOutBuffer verweist auf den Puffer, in dem die Informationen zu Schnittstellen als Array von INTERFACE_INFO Strukturen für Unicast-IP-Adressen auf den Schnittstellen gespeichert werden sollen. Der cbOutBuffer-Parameter gibt die Länge des Ausgabepuffers an. Die Anzahl der zurückgegebenen Schnittstellen (Anzahl der im Puffer zurückgegebenen Strukturen, auf die vom lpvOutBuffer-Parameter verwiesen wird) kann basierend auf der tatsächlichen Länge des im lpcbBytesReturned-Parameter zurückgegebenen Ausgabepuffers bestimmt werden.

Wenn die WSAIoctl-Funktion mit SIO_GET_INTERFACE_LIST aufgerufen wird und der Ebenenmember des Sockets-Parameters nicht als IPPROTO_IP definiert ist, wird WSAEINVAL zurückgegeben. Ein Aufruf der WSAIoctl-Funktion mit SIO_GET_INTERFACE_LIST gibt WSAEFAULT zurück, wenn der cbOutBuffer-Parameter , der die Länge des Ausgabepuffers angibt, zu klein ist, um die Liste der konfigurierten Schnittstellen zu empfangen.

SIO_GET_INTERFACE_LIST_EX (Opcodeeinstellung: O, T==0)

Reserviert für die zukünftige Verwendung mit Sockets.

Gibt eine Liste der konfigurierten IP-Schnittstellen und deren Parameter als Array von INTERFACE_INFO_EX-Strukturen zurück.

Der Parameter lpvOutBuffer verweist auf den Puffer, in dem die Informationen zu Schnittstellen als Array von INTERFACE_INFO_EX Strukturen für Unicast-IP-Adressen auf der Schnittstelle gespeichert werden sollen. Der cbOutBuffer-Parameter gibt die Länge des Ausgabepuffers an. Die Anzahl der zurückgegebenen Schnittstellen (Anzahl der in lpvOutBuffer zurückgegebenen Strukturen) kann basierend auf der tatsächlichen Länge des im lpcbBytesReturned-Parameter zurückgegebenen Ausgabepuffers bestimmt werden.

SIO_GET_INTERFACE_LIST_EX wird unter Windows derzeit nicht unterstützt.

SIO_GET_QOS (Opcodeeinstellung: O, T==1)

Ruft die QOS-Struktur ab, die dem Socket zugeordnet ist. Der Eingabepuffer ist optional. Bei einigen Protokollen (z. B. RSVP) kann der Eingabepuffer verwendet werden, um eine QOS-Anforderung zu qualifizieren. Die QOS-Struktur wird in den Ausgabepuffer kopiert. Der Ausgabepuffer muss groß genug sein, um die vollständige QOS-Struktur enthalten zu können. Der WSAENOPROTOOPT-Fehlercode wird für Dienstanbieter angegeben, die die Servicequalität nicht unterstützen.

SIO_IDEAL_SEND_BACKLOG_CHANGE (Opcodeeinstellung: V, T==0)

Benachrichtigt eine Anwendung, wenn sich der ideale Isb-Wert (Send Backlog) für die zugrunde liegende Verbindung ändert.

Beim Senden von Daten über eine TCP-Verbindung mithilfe von Windows-Sockets ist es wichtig, eine ausreichende Menge an daten ausstehenden (gesendeten, aber noch nicht bestätigten) In TCP zu halten, um den höchsten Durchsatz zu erreichen. Der ideale Wert für die ausstehende Datenmenge, um den besten Durchsatz für die TCP-Verbindung zu erzielen, wird als ideale Größe des Sendebacklogs (ISB) bezeichnet. Der ISB-Wert ist eine Funktion des Bandbreitenverzögerungsprodukts der TCP-Verbindung und des angekündigten Empfangsfensters des Empfängers (und teilweise der Überlastung im Netzwerk).

Der ISB-Wert pro Verbindung ist über die TCP-Protokollimplementierung in Windows Server 2008, Windows Vista mit Service Pack 1 (SP1) und höheren Versionen des Betriebssystems verfügbar. Die SIO_IDEAL_SEND_BACKLOG_CHANGE IOCTL kann von einer Anwendung verwendet werden, um eine Benachrichtigung zu erhalten, wenn sich der ISB-Wert für eine Verbindung dynamisch ändert.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_IDEAL_SEND_BACKLOG_CHANGE .

SIO_IDEAL_SEND_BACKLOG_CHANGE wird unter Windows Server 2008, Windows Vista mit SP1 und höheren Versionen des Betriebssystems unterstützt.

SIO_IDEAL_SEND_BACKLOG_QUERY (Opcodeeinstellung: O, T==0)

Ruft den idealen Isb-Wert (Send Backlog) für die zugrunde liegende Verbindung ab.

Der ISB-Wert pro Verbindung ist über die TCP-Protokollimplementierung in Windows Server 2008 und höher verfügbar. Die SIO_IDEAL_SEND_BACKLOG_QUERY IOCTL kann von einer Anwendung verwendet werden, um den ISB-Wert für eine Verbindung abzufragen.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_IDEAL_SEND_BACKLOG_QUERY .

SIO_IDEAL_SEND_BACKLOG_QUERY wird unter Windows Server 2008, Windows Vista mit SP1 und höheren Versionen des Betriebssystems unterstützt.

SIO_KEEPALIVE_VALS (Opcodeeinstellung: I, T==3)

Aktiviert oder deaktiviert die Verbindungseinstellung der TCP-Keep-Alive-Option , die das TCP-Keep-Alive-Timeout und das Tcp-Keep-Alive-Intervall angibt. Weitere Informationen zur Keep-Alive-Option finden Sie im Abschnitt 4.2.3.6 unter Anforderungen für Internethosts – Kommunikationsebenen gemäß RFC 1122 auf der IETF-Website.

SIO_KEEPALIVE_VALS können verwendet werden, um Keep-Alive-Tests zu aktivieren oder zu deaktivieren und das Keep-Alive-Timeout und das Intervall festzulegen. Das Keep-Alive-Timeout gibt das Timeout in Millisekunden ohne Aktivität an, bis das erste Keep-Alive-Paket gesendet wird. Das Keep-Alive-Intervall gibt in Millisekunden das Intervall an, zwischen dem aufeinanderfolgende Keep-Alive-Pakete gesendet werden, wenn keine Bestätigung empfangen wird.

Die option SO_KEEPALIVE , die eine der SOL_SOCKET Socketoptionen ist, kann auch verwendet werden, um tcp keep-alive für eine Verbindung zu aktivieren oder zu deaktivieren sowie den aktuellen Status dieser Option abzufragen. Um abzufragen, ob TCP keep-alive für einen Socket aktiviert ist, kann die getockopt-Funktion mit der Option SO_KEEPALIVE aufgerufen werden. Um TCP keep-alive zu aktivieren oder zu deaktivieren, kann die setockopt-Funktion mit der Option SO_KEEPALIVE aufgerufen werden. Wenn TCP keep-alive mit SO_KEEPALIVE aktiviert ist, werden die TCP-Standardeinstellungen für Keep-Alive-Timeout und Intervall verwendet, es sei denn, diese Werte wurden mithilfe von SIO_KEEPALIVE_VALS geändert.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_KEEPALIVE_VALS . SIO_KEEPALIVE_VALS wird unter Windows 2000 und höher unterstützt.

SIO_MULTIPOINT_LOOPBACK (Opcodeeinstellung: I, T==1)

Steuert, ob Daten, die von einer Anwendung auf dem lokalen Computer (nicht notwendigerweise vom gleichen Socket) in einer Multicastsitzung gesendet werden, von einem Socket empfangen werden, der mit der Multicastzielgruppe auf der Loopbackschnittstelle verknüpft ist. Der Wert TRUE bewirkt, dass Multicastdaten, die von einer Anwendung auf dem lokalen Computer gesendet werden, an einen Listening Socket auf der Loopbackschnittstelle übermittelt werden. Der Wert FALSE verhindert, dass multicastdaten, die von einer Anwendung auf dem lokalen Computer gesendet werden, an einen Listening Socket auf der Loopbackschnittstelle übermittelt werden. Standardmäßig ist SIO_MULTIPOINT_LOOPBACK aktiviert.

SIO_MULTICAST_SCOPE (Opcodeeinstellung: I, T==1)

Gibt den Bereich an, über den Multicastübertragungen erfolgen. Bereich ist definiert als die Anzahl der Routingnetzwerksegmente, die abgedeckt werden sollen. Ein Bereich von 0 würde darauf hindeuten, dass die Multicastübertragung nicht auf dem Kabel platziert, sondern über Sockel innerhalb des lokalen Hosts verteilt werden könnte. Der Bereichswert 1 (Standard) gibt an, dass die Übertragung auf dem Kabel platziert wird, aber keine Router kreuzt. Höhere Bereichswerte bestimmen die Anzahl der Router, die gekreuzt werden können. Beachten Sie, dass dies dem TTL-Parameter (Time-to-Live) im IP-Multicasting entspricht.

SIO_QUERY_RSS_SCALABILITY_INFO (Opcodeeinstellung: O, T==3)

Abfragen laden Schnittstellen für die RSS-Funktion (Receive-Side Scaling) aus. Die für SIO_QUERY_RSS_SCALABILITY_INFO zurückgegebene Argumentstruktur wird in der in der Headerdatei"Mstcpip.h " definierten RSS_SCALABILITY_INFO-Struktur angegeben. Diese Struktur wird wie folgt definiert.

void CALLBACK 
CompletionRoutine(  
  IN DWORD           dwError, 
  IN DWORD           cbTransferred, 
  IN LPWSAOVERLAPPED lpOverlapped, 
  IN DWORD           dwFlags 
);

Der im RssEnabled-Member zurückgegebene Wert gibt an, ob RSS auf mindestens einer Schnittstelle aktiviert ist.

Wenn der Ausgabepuffer nicht groß genug für die RSS_SCALABILITY_INFO-Struktur ist (der cbOutBuffer ist kleiner als die Größe eines RSS_SCALABILITY_INFO) oder der lpvOutBuffer-Parameter ein NULL-Zeiger ist, wird SOCKET_ERROR als Ergebnis dieser IOCTL zurückgegeben und WSAGetLastError gibt WSAEINVAL zurück.

Bei Hochgeschwindigkeitsnetzwerken, bei denen sich mehrere CPUs in einem einzelnen System befinden, ist die Fähigkeit des Netzwerkprotokollstapels, auf einem Multi-CPU-System gut zu skalieren, gehemmt, da die Architektur von NDIS 5.1 und früheren Versionen die Protokollverarbeitung auf eine einzelne CPU beschränkt. Die empfangsseitige Skalierung (RSS) behebt dieses Problem, indem die Netzwerklast eines Netzwerkadapters auf mehrere CPUs ausgeglichen werden kann.

SIO_QUERY_RSS_SCALABILITY_INFO wird unter Windows Vista und höher unterstützt.

SIO_QUERY_WFP_ALE_ENDPOINT_HANDLE (Opcodeeinstellung: O, T==3)

Fragt das ALE-Endpunkthandle (Application Layer Enforcement) ab.

Die Windows-Filterplattform (WFP) unterstützt die Überprüfung und Änderung des Netzwerkdatenverkehrs. In Windows Vista konzentriert sich WFP auf Szenarien, in denen der Hostcomputer der Kommunikationsendpunkt ist. In Windows Server 2008 gibt es jedoch Edgefirewallimplementierungen, die die WFP-Plattform nutzen möchten, um Passthroughdatenverkehr zu überprüfen und zu proxyn. Der ISA-Server (Internet Security and Acceleration) ist ein Beispiel für ein solches Edgegerät.

Es gibt einige Firewallszenarien, die möglicherweise die Möglichkeit erfordern, ein eingehendes Paket in den Sendepfad einzufügen, der einem vorhandenen Endpunkt zugeordnet ist. Es muss ein Mechanismus zum Ermitteln des Dem Zielendpunkt zugeordneten Endpunkthandles der Transportschicht vorhanden sein. Die Anwendung, die den Endpunkt erstellt hat, besitzt diese Endpunkte auf Transportebene. Diese IOCTL wird verwendet, um die Zuordnung des Sockethandles für Die Transportschichtendpunkt-Handle bereitzustellen.

Wenn der Ausgabepuffer nicht groß genug für das Endpunkthandle ist (der cbOutBuffer ist kleiner als die Größe eines UINT64) oder der lpvOutBuffer-Parameter ein NULL-Zeiger ist, wird SOCKET_ERROR als Ergebnis dieser IOCTL zurückgegeben und WSAGetLastError gibt WSAEINVAL zurück.

SIO_QUERY_WFP_ALE_ENDPOINT_HANDLE wird unter Windows Vista und höher unterstützt.

SIO_QUERY_PNP_TARGET_HANDLE (Opcodeeinstellung: O, T==1)

So erhalten Sie den Socketdeskriptor des nächsten Anbieters in der Kette, von der der aktuelle Socket im PnP-Sinne abhängt. Diese IOCTL wird von der Windows Sockets 2-DLL nur für Sockets von Nicht-IFS-Dienstanbietern aufgerufen, die über den WPUCreateSocketHandle-Aufruf erstellt wurden. Der Anbieter sollte im Ausgabepuffer das Sockethandle des nächsten Anbieters in der Kette zurückgeben, von dem ein bestimmtes Sockethandle im PnP-Sinne abhängt (beispielsweise führt das Entfernen des Geräts, das den zugrunde liegenden Handle unterstützt, zur Ungültigkeit des darüber liegenden Handles in der Kette).

Wenn ein überlappender Vorgang sofort abgeschlossen wird, gibt diese Funktion den Wert 0 zurück, und der lpcbBytesReturned-Parameter wird mit der Anzahl der Bytes im Ausgabepuffer aktualisiert. Wenn der überlappende Vorgang erfolgreich initiiert wurde und später abgeschlossen wird, gibt diese Funktion SOCKET_ERROR zurück und gibt fehlercode WSA_IO_PENDING an. In diesem Fall wird lpcbBytesReturned nicht aktualisiert. Wenn der überlappende Vorgang abgeschlossen ist, wird die Datenmenge im Ausgabepuffer entweder über den cbTransferred-Parameter in der Vervollständigungsroutine (sofern angegeben) oder über den lpcbTransfer-Parameter in LPWSPGetOverlappedResult angegeben.

SIO_RCVALL (Opcodeeinstellung: I, T==3)

Ermöglicht es einem Socket, alle IPv4- oder IPv6-Pakete zu empfangen, die über eine Netzwerkschnittstelle übergeben werden. Das an die WSAIoctl-Funktion übergebene Sockethandle muss einer der folgenden sein:

Ein IPv4-Socket, der erstellt wurde, wobei die Adressfamilie auf AF_INET festgelegt ist, der Sockettyp auf SOCK_RAW und das Protokoll auf IPPROTO_IP festgelegt wurde.
Ein IPv6-Socket, der erstellt wurde, wobei die Adressfamilie auf AF_INET6 festgelegt ist, der Sockettyp auf SOCK_RAW und das Protokoll auf IPPROTO_IPV6 festgelegt wurde.

Der Socket muss auch an eine explizite lokale IPv4- oder IPv6-Schnittstelle gebunden sein, was bedeutet, dass Sie nicht an INADDR_ANY oder in6addr_any binden können.

Unter Windows Server 2008 und früher erfasst die Einstellung SIO_RCVALL IOCTL keine lokalen Pakete, die über eine Netzwerkschnittstelle gesendet wurden. Dies umfasste Pakete, die auf einer anderen Schnittstelle empfangen und die für die SIO_RCVALL IOCTL angegebene Netzwerkschnittstelle weitergeleitet wurden.

Unter Windows 7 und Windows Server 2008 R2 wurde dies geändert, sodass auch lokale Pakete erfasst werden, die von einer Netzwerkschnittstelle gesendet werden. Dies schließt Pakete ein, die von einer anderen Schnittstelle empfangen und dann die Netzwerkschnittstelle weitergeleitet werden, die mit SIO_RCVALL IOCTL an den Socket gebunden ist.

Das Festlegen dieser IOCTL erfordert Administratorrechte auf dem lokalen Computer.

Dieses Feature wird manchmal als promiscuous-Modus bezeichnet.

Die möglichen Werte für die option SIO_RCVALL IOCTL werden in der RCVALL_VALUE-Enumeration angegeben, die in der Headerdatei "Mstcpip.h " definiert ist. Die möglichen Werte für SIO_RCVALL sind wie folgt:

Begriff	BESCHREIBUNG
RCVALL_OFF	Deaktivieren Sie diese Option, damit ein Socket nicht alle IPv4- oder IPv6-Pakete im Netzwerk empfängt.
RCVALL_ON	Aktivieren Sie diese Option, damit ein Socket alle IPv4- oder IPv6-Pakete im Netzwerk empfängt. Diese Option aktiviert den promiscuous-Modus auf der Netzwerkschnittstelle Karte (NIC), wenn die NIC den promiskten Modus unterstützt. In einem LAN-Segment mit einem Netzwerkhub erfasst eine NIC, die den promiskten Modus unterstützt, den gesamten IPv4- oder IPv6-Datenverkehr im LAN, einschließlich des Datenverkehrs zwischen anderen Computern im gleichen LAN-Segment. Alle erfassten Pakete (IPv4 oder IPv6, abhängig vom Socket) werden an den rohen Socket übermittelt. Diese Option erfasst keine anderen Pakete (z. B. ARP-, IPX- und NetBEUI-Pakete) auf der Schnittstelle. Netmon verwendet den gleichen Modus für die Netzwerkschnittstelle, verwendet diese Option jedoch nicht, um Datenverkehr zu erfassen.
RCVALL_SOCKETLEVELONLY	Dieses Feature ist derzeit nicht implementiert, sodass das Festlegen dieser Option keine Auswirkungen hat.
RCVALL_IPLEVEL	Aktivieren Sie diese Option, damit ein IPv4- oder IPv6-Socket alle Pakete auf IP-Ebene im Netzwerk empfängt. Diese Option aktiviert keinen promiskten Modus für die Netzwerkschnittstelle Karte. Diese Option wirkt sich nur auf die Paketverarbeitung auf IP-Ebene aus. Die NIC empfängt weiterhin nur Pakete, die an ihre konfigurierten Unicast- und Multicastadressen weitergeleitet werden. Ein Socket mit aktivierter Option empfängt jedoch nicht nur Pakete, die an bestimmte IP-Adressen weitergeleitet werden, sondern alle IPv4- oder IPv6-Pakete, die die NIC empfängt. Diese Option erfasst keine anderen Pakete (z. B. ARP-, IPX- und NetBEUI-Pakete), die auf der Schnittstelle empfangen werden.

Ausführlichere Informationen finden Sie in der referenz SIO_RCVALL .

SIO_RCVALL wird unter Windows 2000 und höher unterstützt.

SIO_RELEASE_PORT_RESERVATION (Opcodeeinstellung: I, T==3)

Gibt eine Laufzeitreservierung für einen Block von TCP- oder UDP-Ports frei. Die freizugebende Laufzeitreservierung muss vom Ausgabeprozess mithilfe der SIO_ACQUIRE_PORT_RESERVATION IOCTL abgerufen worden sein.

Ausführlichere Informationen finden Sie in der referenz SIO_RELEASE_PORT_RESERVATION .

SIO_RELEASE_PORT_RESERVATION wird unter Windows Vista und höheren Versionen des Betriebssystems unterstützt.

SIO_ROUTING_INTERFACE_CHANGE (opcode-Einstellung: I, T==1)

Um Benachrichtigungen über eine Routingschnittstellenänderung zu erhalten, die verwendet werden soll, um die Remoteadresse im Eingabepuffer zu erreichen (als Sockaddr-Struktur angegeben). Nach Abschluss dieser IOCTL werden keine Ausgabeinformationen zur neuen Routingschnittstelle bereitgestellt. die Vervollständigung gibt lediglich an, dass sich die Routingschnittstelle für ein bestimmtes Ziel geändert hat und mithilfe der SIO_ROUTING_INTERFACE_QUERY IOCTL abgefragt werden sollte.

Es wird davon ausgegangen (obwohl nicht erforderlich), dass die Anwendung überlappende E/A verwendet, um über die Änderung der Routingschnittstelle informiert zu werden, bis SIO_ROUTING_INTERFACE_CHANGE Anforderung abgeschlossen wird. Wenn die SIO_ROUTING_INTERFACE_CHANGE IOCTL auf einem nicht blockierenden Socket ausgestellt wird, wobei die Parameter lpOverlapped und lpCompletionRoutine auf NULL festgelegt sind), wird sie sofort mit dem Fehler WSAEWOULDBLOCK abgeschlossen, und der Windows Socket SPI-Client kann dann mit einem Aufruf von LPWSPEventSelect oder LPWSPAsyncSelect mit der in der Netzwerkereignisbitmaske festgelegten FD_ROUTING_INTERFACE_CHANGE Bit auf das Routing von Änderungsereignissen warten.

Es wird erkannt, dass Routinginformationen in den meisten Fällen stabil bleiben, sodass die Anforderung, dass die Anwendung mehrere ausstehende IOCTLs beibehalten muss, um Benachrichtigungen über alle Ziele zu erhalten, an denen sie interessiert ist, und dass der Dienstanbieter diese Benachrichtigungsanforderungen nachverfolgt, eine erhebliche Menge von Systemressourcen beansprucht. Diese Situation kann vermieden werden, indem die Bedeutung der Eingabeparameter erweitert und die Anforderungen des Dienstanbieters wie folgt gelockert werden:

Der Windows Sockets SPI-Client kann eine protokollfamilienspezifische Feldhalteradresse angeben (die gleiche wie im Bindungsaufruf beim Anfordern einer Bindung an eine beliebige verfügbare Adresse), um Benachrichtigungen über Routingänderungen anzufordern. Dadurch kann der Windows Sockets SPI-Client nur eine SIO_ROUTING_INTERFACE_CHANGE für alle Sockets und Ziele, die er besitzt, beibehalten und dann SIO_ROUTING_INTERFACE_QUERY verwenden, um die tatsächlichen Routinginformationen abzurufen.

Der Dienstanbieter kann sich dafür entscheiden, die vom Windows Sockets SPI-Client im Eingabepuffer des SIO_ROUTING_INTERFACE_CHANGE bereitgestellten Informationen zu ignorieren (als ob der Windows Sockets SPI-Client eine Feldhalteradresse angegeben hat) und das SIO_ROUTING_INTERFACE_CHANGE IOCTL- oder Signal-FD_ROUTING_INTERFACE_CHANGE-Ereignis im Fall einer Änderung der Routinginformationen (nicht nur die Route zu dem im Eingabepuffer angegebenen Ziel) abschließen.

SIO_ROUTING_INTERFACE_QUERY (Opcodeeinstellung: I, O, T==1)

Um die Adresse der lokalen Schnittstelle (dargestellt als sockaddr-Struktur ) abzurufen, die zum Senden an die im Eingabepuffer angegebene Remoteadresse (als sockaddr) verwendet werden soll. Remote-Multicastadressen können im Eingabepuffer übermittelt werden, um die Adresse der bevorzugten Schnittstelle für die Multicastübertragung abzurufen. In jedem Fall kann die zurückgegebene Schnittstellenadresse von der Anwendung in einer nachfolgenden Bindungsanforderung verwendet werden.

Beachten Sie, dass Routen geändert werden können. Daher können Windows Socket SPI-Clients nicht darauf vertrauen, dass die von SIO_ROUTING_INTERFACE_QUERY zurückgegebenen Informationen persistent sind. SPI-Clients können sich für das Routing von Änderungsbenachrichtigungen mithilfe der SIO_ROUTING_INTERFACE_CHANGE IOCTL registrieren, die Benachrichtigungen entweder überlappende E/A oder ein FD_ROUTING_INTERFACE_CHANGE-Ereignis bereitstellt. Die folgende Abfolge von Aktionen kann verwendet werden, um sicherzustellen, dass der Windows Socket SPI-Client immer aktuelle Routingschnittstelleninformationen für ein bestimmtes Ziel enthält:

Problem SIO_ROUTING_INTERFACE_CHANGE IOCTL.
Problem SIO_ROUTING_INTERFACE_QUERY IOCTL.
Wenn SIO_ROUTING_INTERFACE_CHANGE IOCTL den WinSock SPI-Client über Routingänderungen benachrichtigt (entweder durch überlappende E/A oder durch Signalisierung FD_ROUTING_INTERFACE_CHANGE Ereignisses), sollte die gesamte Abfolge von Aktionen wiederholt werden.

Wenn der Ausgabepuffer nicht groß genug ist, um die Schnittstellenadresse zu enthalten, wird SOCKET_ERROR als Ergebnis dieser IOCTL zurückgegeben, und WSAGetLastError gibt WSAEFAULT zurück. Die erforderliche Größe des Ausgabepuffers wird in diesem Fall in lpcbBytesReturned zurückgegeben. Beachten Sie, dass der WSAEFAULT-Fehlercode auch zurückgegeben wird, wenn der Parameter lpvInBuffer, lpvOutBuffer oder lpcbBytesReturned nicht vollständig in einem gültigen Teil des Benutzeradressraums enthalten ist.

Wenn die im Eingabepuffer angegebene Zieladresse nicht über eine der verfügbaren Schnittstellen erreicht werden kann, wird SOCKET_ERROR als Ergebnis dieser IOCTL zurückgegeben und WSAGetLastError gibt WSAENETUNREACH oder sogar WSAENETDOWN zurück, wenn die gesamte Netzwerkkonnektivität verloren geht.

SIO_SET_COMPATIBILITY_MODE (Opcodeeinstellung: I, T==3)

Fordert an, wie der Netzwerkstapel bestimmte Verhaltensweisen behandeln soll, für die sich die Standardweise der Behandlung des Verhaltens von Windows-Versionen unterscheiden kann. Die Argumentstruktur für SIO_SET_COMPATIBILITY_MODE wird in der WSA_COMPATIBILITY_MODE-Struktur angegeben, die in der Headerdatei "Mswsockdef.h " definiert ist. Diese Struktur ist wie folgt definiert:

} WSA_COMPATIBILITY_MODE, *PWSA_COMPATIBILITY_MODE;

Der im BehaviorId-Member angegebene Wert gibt das angeforderte Verhalten an. Der im TargetOsVersion-Member angegebene Wert gibt die Windows-Version an, die für das Verhalten angefordert wird.

Das BehaviorId-Element kann einer der Werte aus dem WSA_COMPATIBILITY_BEHAVIOR_ID Enumerationstyp sein, der in der Headerdatei "Mswsockdef.h " definiert ist. Die möglichen Werte für den BehaviorId-Member sind wie folgt:

Begriff	BESCHREIBUNG
WsaBehaviorAll	Dies entspricht dem Anfordern aller möglichen kompatiblen Verhaltensweisen, die für WSA_COMPATIBILITY_BEHAVIOR_ID definiert sind.
WsaBehaviorReceiveBuffering	Wenn der TargetOsVersion-Member auf einen Wert für Windows Vista oder höher festgelegt ist, sind Reduzierungen der TCP-Empfangspuffergröße für diesen Socket mithilfe der Option SO_RCVBUF Socket zulässig, auch nachdem eine TCP-Verbindung hergestellt wurde. Wenn der TargetOsVersion-Member auf einen Wert vor Windows Vista festgelegt ist, sind Reduzierungen der TCP-Empfangspuffergröße für diesen Socket mithilfe der Option SO_RCVBUF Socket nach der Verbindungsherstellung nicht zulässig.
WsaBehaviorAutoTuning	Wenn der TargetOsVersion-Member auf einen Wert für Windows Vista oder höher festgelegt ist, wird die automatische Optimierung des Empfangsfensters aktiviert, und der TCP-Fensterskalierungsfaktor wird vom Standardwert 8 auf 2 reduziert. Wenn TargetOsVersion auf einen Wert vor Windows Vista festgelegt ist, ist die automatische Optimierung des Empfangsfensters deaktiviert. Die TCP-Fensterskalierungsoption ist ebenfalls deaktiviert, und die maximale Größe des Empfangsfensters ist auf 65.535 Bytes beschränkt. Die TCP-Fensterskalierungsoption kann nicht für die Verbindung ausgehandelt werden, auch wenn die SO_RCVBUF Socketoption für diesen Socket aufgerufen wurde, wobei ein Wert größer als 65.535 Bytes angegeben wurde, bevor die Verbindung hergestellt wurde.

Ausführlichere Informationen finden Sie in der referenz SIO_SET_COMPATIBILITY_MODE .

SIO_SET_COMPATIBILITY_MODE wird unter Windows Vista und höher unterstützt.

SIO_SET_GROUP_QOS (Opcodeeinstellung: I, T==1)

Reserviert.

SIO_SET_QOS (Opcodeeinstellung: I, T==1)

Ordnen Sie die bereitgestellte QOS-Struktur dem Socket zu. Es ist kein Ausgabepuffer erforderlich, die QOS-Struktur wird aus dem Eingabepuffer abgerufen. Der WSAENOPROTOOPT-Fehlercode wird für Dienstanbieter angegeben, die die Servicequalität nicht unterstützen.

SIO_TRANSLATE_HANDLE (Opcodeeinstellung: I, O, T==1)

Um ein entsprechendes Handle für Sockets abzurufen, das im Kontext einer Begleitschnittstelle gültig ist (z. B. TH_NETDEV und TH_TAPI). Eine Manifestkonstante, die die Begleitschnittstelle sowie alle anderen erforderlichen Parameter identifiziert, werden im Eingabepuffer angegeben. Das entsprechende Handle ist nach Abschluss dieser Funktion im Ausgabepuffer verfügbar. Weitere Details finden Sie im entsprechenden Abschnitt des Windows Sockets 2-Protocol-Specific Anhangs und/oder der Dokumentation für die jeweilige Begleitschnittstelle. Der WSAENOPROTOOPT-Fehlercode wird für Dienstanbieter angegeben, die diese IOCTL für die angegebene Begleitschnittstelle nicht unterstützen. Diese IOCTL ruft das Handle ab, das mithilfe von SIO_TRANSLATE_HANDLE zugeordnet ist.

Es wird empfohlen, com anstelle dieser IOCTL zu verwenden, um andere Schnittstellen zu ermitteln und nachzuverfolgen, die möglicherweise von einem Socket unterstützt werden. Diese IOCTL ist aufgrund der Abwärtskompatibilität mit Systemen vorhanden, bei denen COM nicht verfügbar ist oder aus einem anderen Grund nicht verwendet werden kann.

SIO_UDP_CONNRESET (opcode-Einstellung: I, T==3)

Windows XP: Steuert, ob UDP-PORT_UNREACHABLE Nachrichten gemeldet werden. Legen Sie auf TRUE fest, um die Berichterstellung zu aktivieren. Legen Sie auf FALSE fest, um die Berichterstellung zu deaktivieren.

Beim Aufruf mit einem überlappenden Socket muss der lpOverlapped-Parameter für die Dauer des überlappenden Vorgangs gültig sein.

Wenn der lpCompletionRoutine-ParameterNULL ist, signalisiert der Dienstanbieter das hEvent-Member von lpOverlapped , wenn der überlappende Vorgang abgeschlossen wird, wenn er ein gültiges Ereignisobjekthandle enthält. Der Windows Sockets SPI-Client kann LPWSPGetOverlappedResult verwenden, um das Ereignisobjekt abzufragen oder darauf zu warten.

Wenn lpCompletionRoutine nicht NULL ist, wird der hEvent-Member ignoriert und kann vom Windows Sockets SPI-Client verwendet werden, um Kontextinformationen an die Vervollständigungsroutine zu übergeben. Ein Client, der eine lpCompletionRoutine ohne NULL übergibt und später WSAGetOverlappedResult für dieselbe überlappende E/A-Anforderung aufruft, legt den fWait-Parameter für diesen Aufruf von WSAGetOverlappedResult möglicherweise nicht auf TRUE fest. In diesem Fall ist die Verwendung des hEvent-Members nicht definiert, und der Versuch, auf das hEvent-Element zu warten, führt zu unvorhersehbaren Ergebnissen.

Es liegt in der Verantwortung des Dienstanbieters, den Aufruf der clientspezifischen Vervollständigungsroutine zu veranlassen, wenn der überlappende Vorgang abgeschlossen ist. Da die Vervollständigungsroutine im Kontext desselben Threads ausgeführt werden muss, der den überlappenden Vorgang initiiert hat, kann sie nicht direkt vom Dienstanbieter aufgerufen werden. Die WS2_32.DLL bietet einen Asynchronen Prozeduraufrufmechanismus (APC), um den Aufruf von Vervollständigungsroutinen zu erleichtern.

Ein Dienstanbieter veranlasst, dass eine Funktion im richtigen Thread- und Prozesskontext ausgeführt wird, indem WPUQueueApc aufgerufen wird. Diese Funktion kann aus jedem Prozess- und Threadkontext aufgerufen werden, auch aus einem anderen Kontext als dem Thread und prozess, der zum Initiieren des überlappenden Vorgangs verwendet wurde.

WPUQueueApc verwendet als Eingabeparameter einen Zeiger auf eine WSATHREADID-Struktur (die dem Anbieter über den lpThreadId-Eingabeparameter bereitgestellt wird), einen Zeiger auf eine aufzurufende APC-Funktion und einen 32-Bit-Kontextwert, der anschließend an die APC-Funktion übergeben wird. Da nur ein einzelner 32-Bit-Kontextwert verfügbar ist, kann die APC-Funktion selbst nicht die clientspezifische Vervollständigungsroutine sein. Der Dienstanbieter muss stattdessen einen Zeiger auf seine eigene APC-Funktion bereitstellen, die den angegebenen Kontextwert verwendet, um auf die erforderlichen Ergebnisinformationen für den überlappenden Vorgang zuzugreifen, und ruft dann die clientspezifische Vervollständigungsroutine auf.

Der Prototyp für die vom Client bereitgestellte Vervollständigungsroutine lautet wie folgt:

);

CompletionRoutine ist ein Platzhalter für eine vom Client bereitgestellte Funktion. DwError gibt die Vervollständigung status für den überlappenden Vorgang an, wie durch lpOverlapped angegeben. CbTransferred gibt die Anzahl der zurückgegebenen Bytes an. Derzeit sind keine Flagwerte definiert, und dwFlags ist 0. Diese Funktion gibt keinen Wert zurück.

Das Zurückgeben von dieser Funktion ermöglicht den Aufruf einer anderen ausstehenden Vervollständigungsroutine für diesen Socket. Die Vervollständigungsroutinen können in beliebiger Reihenfolge aufgerufen werden, allerdings nicht unbedingt in der reihenfolge, in der die überlappenden Vorgänge abgeschlossen werden.

Kompatibilität

Die IOCTL-Codes mit T == 0 sind eine Teilmenge der IOCTL-Codes, die in Berkeley-Sockets verwendet werden. Insbesondere gibt es keinen Befehl, der FIOASYNC entspricht.

Hinweis

Alle von einem bestimmten Thread initiierten E/A-Vorgänge werden abgebrochen, wenn dieser Thread beendet wird. Bei überlappenden Sockets können ausstehende asynchrone Vorgänge fehlschlagen, wenn der Thread geschlossen wird, bevor die Vorgänge abgeschlossen werden. Weitere Informationen finden Sie unter ExitThread .

Anforderungen


Unterstützte Mindestversion (Client)	Windows 2000 Professional [nur Desktop-Apps]
Unterstützte Mindestversion (Server)	Windows 2000 Server [nur Desktop-Apps]
Kopfzeile	ws2spi.h

Weitere Informationen

LPWSPIOCTL-Rückruffunktion (ws2spi.h)

Syntax

Parameter

Rückgabewert

Hinweise

Kompatibilität

Anforderungen

Weitere Informationen

Feedback

Feedback

Zusätzliche Ressourcen