Winsock-IOCTLs

In diesem Abschnitt werden Die Eingabe-/Ausgabesteuerelemente (IOCTLs) von Winsock Socket für verschiedene Editionen von Windows-Betriebssystemen beschrieben. Verwenden Sie die WSAIoctl - oder WSPIoctl-Funktion , um eine Winsock-IOCTL auszuweisen, um den Modus eines Sockets, das Transportprotokoll oder das Kommunikationssubsystem zu steuern.

Einige Winsock-IOCTLs erfordern mehr Erklärungen, als diese Tabelle vermitteln kann. solche Optionen enthalten Links zu zusätzlichen Themen.

Es ist möglich, ein Codierungsschema zu übernehmen, das die derzeit definierten ioctlsocket-Opcodes beibewahrt und gleichzeitig eine bequeme Möglichkeit zum Partitionieren des Opcode-Bezeichnerbereichs in so weit bietet, wie der dwIoControlCode-Parameter jetzt eine 32-Bit-Entität ist. Der dwIoControlCode-Parameter wurde so entwickelt, dass beim Hinzufügen neuer Steuercodes Protokoll- und Herstellerunabhängigkeit gewährleistet wird, während die Abwärtskompatibilität mit den Windows Sockets 1.1- und Unix-Steuercodes beibehalten wird. Der dwIoControlCode-Parameter weist die folgende Form auf.

I O V T Anbieter/Adressfamilie Code
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

Hinweis

Die in der Tabelle angezeigten Bits im dwIoControlCode-Parameter müssen vertikal von oben nach unten nach Spalte gelesen werden. Das bit links ist also Bit 31, das nächste Bit ist Bit 30, und das ganz rechtsste Bit ist Bit 0.

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. Steuerungscodes mit Eingabe- und Ausgabepuffern, die sowohl E als auch O festlegen.

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

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

0 Die IOCTL ist ein Standardmäßiger Unix IOCTL-Code, wie bei FIONREAD und FIONBIO.

1 Die IOCTL ist ein generischer IOCTL-Code für Windows Sockets 2. Neue IOCTL-Codes, die für Windows Sockets 2 definiert sind, verfügen über T == 1.

2 Die IOCTL gilt nur für eine bestimmte Adressfamilie.

3 Die IOCTL gilt nur für den Anbieter eines bestimmten Anbieters, wie bei IOC_VENDOR. Dieser Typ ermöglicht es Unternehmen, eine Anbieternummer zuzuweisen, die im Parameter Vendor/Address family angezeigt wird. Anschließend kann der Anbieter neue IOCTLs speziell für diesen Anbieter definieren, ohne die IOCTL bei einem Clearinghouse registrieren zu müssen, wodurch anbieterflexibilität und Datenschutz gewährleistet werden.

Anbieter/Adressfamilie Eine 11-Bit-Menge, die den Anbieter definiert, der den Code besitzt (wenn T == 3) oder die Adressfamilie enthält, auf die der Code angewendet wird (wenn T == 2). Wenn es sich um einen Unix IOCTL-Code (T == 0) handelt, hat dieser Parameter den gleichen Wert wie der Code unter Unix. Wenn es sich um eine generische Windows Sockets 2 IOCTL (T == 1) handelt, kann dieser Parameter als Erweiterung des Codeparameters verwendet werden, um zusätzliche Codewerte bereitzustellen.

Code Die 16-Bit-Menge, die den spezifischen IOCTL-Code für den Vorgang enthält.

Unix IOCTL-Codes

Die folgenden Unix IOCTL-Codes (Befehle) werden unterstützt.

FIONBIO

Aktivieren oder deaktivieren Sie den nicht blockierenden Modus für Sockets. Der Parameter lpvInBuffer zeigt auf eine Nichtsigned long (QoS), die ungleich null ist, wenn der nicht blockierende Modus aktiviert werden soll, und auf null, wenn er deaktiviert werden soll. Wenn ein Socket erstellt wird, wird er im Blockierungsmodus ausgeführt (d. a. der nicht blockierende Modus ist deaktiviert). Dies ist konsistent mit BSD-Sockets.

Die WSAAsyncSelect - oder WSAEventSelect-Routine legt einen Socket automatisch auf den nicht blockierenden Modus fest. Wenn WSAAsyncSelect oder WSAEventSelect für einen Socket ausgestellt wurde, schlägt jeder Versuch, WSAIoctl zu verwenden, um den Socket wieder auf den Blockierungsmodus festzulegen, mit WSAEINVAL fehl. Um den Socket wieder auf den Blockierungsmodus festzulegen, muss eine Anwendung zuerst WSAAsyncSelect deaktivieren, indem WSAAsyncSelect mit dem lEvent-Parameter gleich 0 aufgerufen wird, oder WSAEventSelect durch Aufrufen von WSAEventSelect mit dem lNetworkEvents-Parameter gleich 0.

FIONREAD

Bestimmen Sie die Datenmenge, die atomar aus Sockets gelesen werden kann. Der lpvOutBuffer-Parameter zeigt auf eine Länge ohne Vorzeichen , in der WSAIoctl das Ergebnis speichert.

Wenn der im s-Parameter übergebene Socket streamorientiert ist (z. B. typisiert 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 im s-Parameter übergebene Socket nachrichtenorientiert ist (z. B. typisiert SOCK_DGRAM), gibt FIONREAD die Gesamtzahl der bytes zurück, die gelesen werden können, nicht die Größe des ersten Datagramms (Nachricht), das im Socket in die Warteschlange eingereiht wurde.

SIOCATMARK

Ermitteln Sie, ob alle OOB-Daten gelesen wurden. 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 darauf warten, gelesen zu werden, 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 der Der Markierung vorangehenden Daten ab. Die Anwendung sollte den SIOCATMARK-Vorgang verwenden, um zu bestimmen, ob eine vorhanden ist. Wenn den dringenden (Out-of-Band)-Daten normale Daten vorangehen, werden sie in der Reihenfolge empfangen. (Beachten Sie, dass recv-Vorgänge niemals OOB- und normale Daten im selben Aufruf mischen.) lpvOutBuffer zeigt auf eine BOOL, in der WSAIoctl das Ergebnis speichert.

Windows Sockets 2-Befehle

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 verwendet 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 zu 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: V, T==1)

Benachrichtigungen über Änderungen in der Liste der lokalen Transportadressen der Protokollfamilie des Sockets, an die die Anwendung 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 (wenn auch nicht erforderlich), dass die Anwendung überlappende E/A verwendet, um durch Abschluss SIO_ADDRESS_LIST_CHANGE Anforderung über Änderungen benachrichtigt zu werden. Wenn die SIO_ADDRESS_LIST_CHANGE IOCTL für einen nicht blockierenden Socket und ohne überlappende Parameter ausgegeben wird (lpOverlapped/ lpCompletionRoutine ist auf NULL festgelegt), wird sie sofort mit dem Fehler WSAEWOULDBLOCK abgeschlossen. Die Anwendung kann dann über einen Aufruf von WSAEventSelect oder WSAAsyncSelect mit FD_ADDRESS_LIST_CHANGE in der Netzwerkereignis-Bitmaske 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. Anwendungen können sich daher nicht darauf verlassen, dass die von SIO_ADDRESS_LIST_QUERY zurückgegebenen Informationen dauerhaft 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 vorsieht. 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 der Änderung der Adressliste benachrichtigt (entweder durch überlappende E/A oder durch Signalisierung FD_ADDRESS_LIST_CHANGE Ereignisses), sollte die gesamte Sequenz der Aktionen wiederholt werden.

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

SIO_APPLY_TRANSPORT_SETTING (Opcodeeinstellung: I, T==3)

Wendet eine Transporteinstellung auf einen Socket an. Die angewendete Transporteinstellung basiert auf dem im lpvInBuffer-Parameter übergebenen TRANSPORT_SETTING_ID.

Die einzige Transporteinstellung, die derzeit definiert wird, ist für die REAL_TIME_NOTIFICATION_CAPABILITY-Funktion auf einem TCP-Socket.

Wenn für den übergebenen TRANSPORT_SETTING_ID das Guid-Element auf REAL_TIME_NOTIFICATION_CAPABILITY festgelegt ist, ist dies eine Anforderung, Echtzeitbenachrichtigungseinstellungen für den TCP-Socket anzuwenden, der mit controlChannelTrigger verwendet wird, um Hintergrundnetzwerkbenachrichtigungen in einer Windows Store-App zu empfangen.

Ausführlichere Informationen finden Sie in der referenz SIO_APPLY_TRANSPORT_SETTING . SIO_APPLY_TRANSPORT_SETTING wird auf Windows 8, Windows Server 2012 und höher unterstützt.

SIO_ASSOCIATE_HANDLE (opcode-Einstellung: 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. Ausführliche Informationen zu einer bestimmten Begleitschnittstelle finden Sie im entsprechenden Abschnitt in Winsock-Anhängen . 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 z. B. verwendet werden, wenn ein bestimmter Anbieter (1) viele zusätzliche Steuerelemente für das Verhalten eines Sockets bereitstellt und (2) die Steuerelemente anbieterspezifisch genug sind, dass sie nicht vorhandenen Windows Socket-Funktionen zugeordnet werden oder in Zukunft wahrscheinlich definiert werden. Es wird empfohlen, das Component Object Model (COM) anstelle dieses IOCTL zu verwenden, um andere Schnittstellen zu ermitteln und nachzuverfolgen, die möglicherweise von einem Socket unterstützt werden. Diese IOCTL ist für die (umgekehrte) Kompatibilitä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 Bindungsfunktion 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 würde 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.

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_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.

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_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 Ablaufeinrichtung und dem Empfang einer RESV-Nachricht (weitere Informationen zur Übergangsphase finden Sie unter How the RSVP Service Invokes TC ) wird der mit einem RSVP-Fluss verknüpfte Datenverkehr basierend auf dem Diensttyp (BEST EFFORT, CONTROLLED LOAD oder GUARANTEED) geformt. Weitere Informationen finden Sie unter Verwenden von SIO_CHK_QOS im Abschnitt Quality of Service des Platform SDK.

SIO_CPU_AFFINITY (Opcodeeinstellung: I, T==3)

Ermöglicht die Portfreigabe und Die Empfangsanzeigeparallelisierung. Wenn Ihre Anwendung diese Socketoption verwendet, um Sockets verschiedenen Prozessoren zuzuordnen und die Sockets dann an dieselbe Adresse bindet, werden Empfangsanzeigen basierend auf dem RSS-Hash (Receive Side Scaling) auf die Sockets verteilt. Die RSS-Einstellungen ändern sich nicht, sodass jeder bestimmte Flow (lokaler Endpunkt, Remoteendpunktpaar) immer auf demselben Prozessor angegeben wird. Daher werden alle Pakete, die zu einem bestimmten Flow gehören, demselben Socket zugeordnet. Diese IOCTL muss vor der Bindung aufgerufen werden, andernfalls wird WSAEINVAL zurückgegeben. Der Eingabepuffer ist ein Prozessorindex (0-basiert) vom Typ USHORT. Das IOCTL ist mit SO_REUSEADDR und SO_REUSE_MULTICASTPORT nicht kompatibel. Nur für UDP-Sockets unterstützt.

Hinweis

Wenn Sie version 10.0.19041.0 (Windows 10, Version 2004) des Windows SDK als Ziel verwenden, verwenden Sie den Wert 0x98000015 anstelle des Namens SIO_CPU_AFFINITY.

SIO_ENABLE_CIRCULAR_QUEUEING (Opcodeeinstellung: V, T==1)

Gibt dem zugrunde liegenden nachrichtenorientierten Dienstanbieter an, dass eine neu eingetroffene Nachricht nie 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 mit unzuverlässigen, nachrichtenorientierten Protokollen verknüpft sind. Der WSAENOPROTOOPT-Fehlercode wird für Dienstanbieter angegeben, die diese IOCTL nicht unterstützen.

SIO_FIND_ROUTE (Opcodeeinstellung: O, T==1)

Bei der Ausstellung fordert diese IOCTL an, dass die Route an die 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 Sendewarteschlange, 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 sendto/ WSASendTo enthält. Diese IOCTL wird für IPv6-Sockets nicht unterstützt und gibt den WSAENOPROTOOPT-Fehlercode zurück.

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 einen Globally Unique Identifier (GUID), dessen 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, werden 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, I, T==1)

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

Rufen Sie die QOS-Struktur ab, die der Socketgruppe zugeordnet ist, zu der dieser Socket gehört. Der Eingabepuffer ist optional. Bei einigen Protokollen (z. B. RSVP) kann der Eingabepuffer verwendet werden, um eine Quality of Service-Anforderung zu qualifizieren. Die QOS-Struktur wird in den Ausgabepuffer kopiert. Wenn dieser Socket nicht zu einer geeigneten Socketgruppe gehört, werden die Elemente SendingFlowspec und ReceiveingFlowspec der zurückgegebenen QOS-Struktur auf NULL festgelegt. Der WSAENOPROTOOPT-Fehlercode wird für Dienstanbieter angegeben, die die Servicequalität nicht unterstützen.

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 wird unter Windows Me/98 und Windows NT 4.0 mit SP4 und höher unterstützt.

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)

Reserviert für die zukünftige Verwendung mit Sockets. Rufen Sie 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 Quality of Service-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.

Ein Absender darf SIO_GET_QOS erst aufrufen , wenn der Socket verbunden ist.

Ein Empfänger kann SIO_GET_QOS aufrufen, sobald er gebunden ist.

SIO_GET_TX_TIMESTAMP

Eine Socket-IOCTL, die zum Abrufen von Zeitstempeln für übertragene (TX)-Pakete verwendet wird. Nur für Datagrammsockets gültig.

Der SIO_GET_TX_TIMESTAMP Kontrollcode entfernt einen Sendezeitstempel aus der Sendezeitstempelwarteschlange eines Sockets. Aktivieren Sie zuerst den Zeitstempelempfang mithilfe der SIO_TIMESTAMPING Socket-IOCTL. Rufen Sie dann tx-Zeitstempel nach ID ab, indem Sie die WSAIoctl-Funktion (oder WSPIoctl) mit den folgenden Parametern aufrufen.

Für SIO_GET_TX_TIMESTAMP ist die Eingabe eine UINT32-Zeitstempel-ID , und die Ausgabe ist ein UINT64-Zeitstempelwert . Bei Erfolg ist der tx-Zeitstempel verfügbar und wird zurückgegeben. Wenn keine Sendezeitstempel verfügbar sind, gibt WSAGetLastErrorWSAEWOULDBLOCK zurück.

Hinweis

TX-Zeitstempel werden nicht unterstützt, wenn eine zusammengefakte Sendezeit über UDP_SEND_MSG_SIZE erfolgt.

Siehe auch Winsock-Zeitstempel.

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 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.

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 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. (Diese Ressource ist möglicherweise nur in Englisch verfügbar.)

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_LOOPBACK_FAST_PATH (Opcodeeinstellung: I, T==3)

Konfiguriert einen TCP-Socket für eine geringere Latenz und schnellere Vorgänge auf der Loopbackschnittstelle. Diese IOCTL fordert an, dass der TCP/IP-Stapel einen speziellen schnellen Pfad für Loopbackvorgänge für diesen Socket verwendet. Die SIO_LOOPBACK_FAST_PATH IOCTL kann nur mit TCP-Sockets verwendet werden. Diese IOCTL muss auf beiden Seiten der Loopbacksitzung verwendet werden. Der schnelle TCP-Loopbackpfad wird entweder über die IPv4- oder IPv6-Loopbackschnittstelle unterstützt. Standardmäßig ist SIO_LOOPBACK_FAST_PATH deaktiviert.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_LOOPBACK_FAST_PATH . SIO_LOOPBACK_FAST_PATH wird auf Windows 8, Windows Server 2012 und höher unterstützt.

SIO_MULTIPOINT_LOOPBACK (Opcodeeinstellung: V, 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 Lauschsocket auf der Loopbackschnittstelle übermittelt werden. Der Wert FALSE verhindert, dass Multicastdaten, die von einer Anwendung auf dem lokalen Computer gesendet werden, an einen Lauschsocket 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. Der Bereich ist als die Anzahl der abzudeckenden Routingnetzwerksegmente definiert. Ein Bereich von 0 (null) würde darauf hindeuten, dass die Multicastübertragung nicht über das Kabel platziert, sondern über Sockets innerhalb des lokalen Hosts verteilt werden könnte. Ein Bereichswert von 1 (Standard) gibt an, dass die Übertragung auf dem Kabel platziert wird, aber keine Router kreuzt. Werte mit einem höheren Bereich bestimmen die Anzahl der Router, die gekreuzt werden können. Beachten Sie, dass dies dem TTL-Parameter (Time-to-Live) im IP-Multicasting entspricht. Standardmäßig ist der Bereich 1.

SIO_QUERY_RSS_PROCESSOR_INFO (Opcodeeinstellung: O, T==1)

Fragt die Zuordnung zwischen einem Socket und einem RSS-Prozessorkern und einem NUMA-Knoten ab.

Die SIO_QUERY_RSS_PROCESSOR_INFO IOCTL gibt eine SOCKET_PROCESSOR_AFFINITY-Struktur zurück, die die PROCESSOR_NUMBER und die NUMA-Knoten-ID enthält. Die zurückgegebene PROCESSOR_NUMBER-Struktur enthält eine Gruppennummer und eine relative Prozessornummer innerhalb der Gruppe.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_QUERY_RSS_PROCESSOR_INFO . SIO_QUERY_RSS_PROCESSOR_INFO wird auf Windows 8, Windows Server 2012 und höher unterstützt.

SIO_QUERY_RSS_SCALABILITY_INFO (Opcodeeinstellung: O, T==3)

Abfragen von Auslagerungsschnittstellen für die RSS-Funktion (Receive-Side Scaling). Die für SIO_QUERY_RSS_SCALABILITY_INFO zurückgegebene Argumentstruktur wird in der RSS_SCALABILITY_INFO-Struktur angegeben, die in der Mstcpip.h-Headerdatei definiert ist. Diese Struktur ist wie folgt definiert:

// Scalability info for the transport
typedef struct _RSS_SCALABILITY_INFO {
   BOOLEAN RssEnabled;
} RSS_SCALABILITY_INFO, *PRSS_SCALABILITY_INFO;

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, verhindert, 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_TRANSPORT_SETTING (Opcodeeinstellung: I, T==3)

Fragt die Transporteinstellungen für einen Socket ab. Die abgefragte Transporteinstellung basiert auf der TRANSPORT_SETTING_ID , die im lpvInBuffer-Parameter übergeben wird.

Die einzige Transporteinstellung, die derzeit definiert wird, ist die REAL_TIME_NOTIFICATION_CAPABILITY-Funktion für einen TCP-Socket.

Wenn für die TRANSPORT_SETTING_ID das Guid-Element auf REAL_TIME_NOTIFICATION_CAPABILITY festgelegt ist, ist dies eine Anforderung zum Abfragen der Echtzeitbenachrichtigungseinstellungen für den TCP-Socket, der mit ControlChannelTrigger verwendet wird, um Hintergrundnetzwerkbenachrichtigungen in einer Windows Store-App zu empfangen. Wenn der WSAIoctl- oder WSPIoctl-Aufruf erfolgreich ist, gibt diese IOCTL eine REAL_TIME_NOTIFICATION_SETTING_OUTPUT-Struktur mit dem aktuellen status zurück.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_QUERY_TRANSPORT_SETTING . SIO_QUERY_TRANSPORT_SETTING wird auf Windows 8, Windows Server 2012 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 (Windows Filtering Platform, WFP) unterstützt die Überprüfung und Änderung des Netzwerkdatenverkehrs. Unter Windows Vista konzentriert sich WFP auf Szenarien, in denen der Hostcomputer der Kommunikationsendpunkt ist. Unter Windows Server 2008 gibt es jedoch Edgefirewallimplementierungen, die die WFP-Plattform nutzen möchten, um den Passthrough-Datenverkehr 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 Endpunkthandles der Transportebene vorhanden sein, das dem Zielendpunkt zugeordnet ist. Die Anwendung, die den Endpunkt erstellt hat, besitzt diese Endpunkte der Transportebene. Diese IOCTL wird verwendet, um die Zuordnung des Endpunkthandles der Transportebene bereitzustellen.

Wenn der Ausgabepuffer nicht groß genug für das Endpunkthandle ist ( 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_WFP_CONNECTION_REDIRECT_CONTEXT (Opcodeeinstellung: I, T==3)

Fragt den Umleitungskontext für einen Umleitungsdatensatz ab, der von einem WFP-Umleitungsdienst (Windows Filtering Platform) verwendet wird.

Die SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT IOCTL wird verwendet, um die Verbindungsnachverfolgung für umgeleitete Socketverbindungen bereitzustellen. Dieses WFP-Feature erleichtert die Nachverfolgung von Umleitungsdatensätzen von der anfänglichen Umleitung einer Verbindung bis zur endgültigen Verbindung mit dem Ziel.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT . SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT wird auf Windows 8, Windows Server 2012 und höher unterstützt.

SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS (Opcodeeinstellung: I, T==3)

Fragt den Umleitungsdatensatz für die akzeptierte TCP/IP-Verbindung zur Verwendung durch einen WFP-Umleitungsdienst (Windows Filtering Platform) ab.

Die SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS IOCTL wird verwendet, um eine nachzuverfolgende Verbindung für umgeleitete Socketverbindungen bereitzustellen. Dieses WFP-Feature erleichtert die Nachverfolgung von Umleitungsdatensätzen von der anfänglichen Umleitung einer Verbindung bis zur endgültigen Verbindung mit dem Ziel.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS . SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS wird auf Windows 8, Windows Server 2012 und höher unterstützt.

SIO_RCVALL (Opcodeeinstellung: I, T==3)

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

  • Ein IPv4-Socket, der erstellt wurde, wobei die Adressfamilie auf AF_INET, 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, 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 werden, was bedeutet, dass Sie keine Bindung an INADDR_ANY oder in6addr_any.

Unter Windows Server 2008 und früheren Versionen erfasst die Einstellung SIO_RCVALL IOCTL keine lokalen Pakete, die von einer Netzwerkschnittstelle gesendet wurden. Dies umfasste Pakete, die auf einer anderen Schnittstelle empfangen wurden 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 auf einer anderen Schnittstelle empfangen und dann die Netzwerkschnittstelle weitergeleitet haben, die mit SIO_RCVALL IOCTL an den Socket gebunden ist.

Das Festlegen dieser IOCTL erfordert Administratorrechte auf dem lokalen Computer.

Dieses Feature wird manchmal auch als Promiskuous-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. Mit dieser Option wird der Promiskuous-Modus auf der Netzwerkschnittstelle Karte (NIC) aktiviert, wenn die Netzwerkkarte den Promiskuous-Modus unterstützt. In einem LAN-Segment mit einem Netzwerkhub erfasst eine Netzwerkkarte, 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 (je nach Socket IPv4 oder IPv6) werden an den Rohsocket ü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 den promiskuous-Modus nicht auf der Netzwerkschnittstelle Karte. Diese Option wirkt sich nur auf die Paketverarbeitung auf IP-Ebene aus. Die NIC empfängt weiterhin nur Pakete, die an die 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.
Mit dieser Option werden keine anderen Pakete (z. B. ARP-, IPX- und NetBEUI-Pakete) erfasst, die auf der Schnittstelle empfangen werden.

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

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

SIO_RCVALL_IGMPMCAST (Opcodeeinstellung: I, T==3)

Ermöglicht einem Socket, den gesamten IGMP-Multicast-IP-Datenverkehr im Netzwerk zu empfangen, ohne anderen Multicast-IP-Datenverkehr zu empfangen. Das an die WSAIoctl-Funktion übergebene Sockethandle muss AF_INET Adressfamilie, SOCK_RAW Sockettyp und IPPROTO_IGMP Protokoll aufweisen. Der Socket muss auch an eine explizite lokale Schnittstelle gebunden sein, was bedeutet, dass Sie nicht an INADDR_ANY binden können.

Nachdem der Socket gebunden und die IOCTL festgelegt wurde, geben Aufrufe der WSARecv - oder recv-Funktionen Multicast-IP-Datagramme zurück, die die angegebene Schnittstelle durchlaufen. Beachten Sie, dass Sie einen ausreichend großen Puffer bereitstellen müssen. Das Festlegen dieser IOCTL erfordert Administratorrechte auf dem lokalen Computer.

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

SIO_RCVALL_MCAST (Opcodeeinstellung: I, T==3)

Ermöglicht einem Socket, den gesamten Multicast-IP-Datenverkehr im Netzwerk zu empfangen (d. h. alle IP-Pakete, die für IP-Adressen im Bereich von 224.0.0.0 bis 239.255.255.255 bestimmt sind). Das an die WSAIoctl-Funktion übergebene Sockethandle muss AF_INET Adressfamilie, SOCK_RAW Sockettyp und IPPROTO_UDP Protokoll aufweisen. Der Socket muss auch an eine explizite lokale Schnittstelle gebunden werden, was bedeutet, dass Sie keine Bindung an INADDR_ANY. Der Socket sollte an Port 0 gebunden werden.

Nachdem der Socket gebunden und die IOCTL festgelegt wurde, geben Aufrufe der WSARecv - oder recv-Funktionen Multicast-IP-Datagramme zurück, die die angegebene Schnittstelle durchlaufen. Beachten Sie, dass Sie einen ausreichend großen Puffer bereitstellen müssen. Das Festlegen dieser IOCTL erfordert Administratorrechte auf dem lokalen Computer.

SIO_RCVALL_MCAST 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 über den Ausgabeprozess mithilfe der SIO_ACQUIRE_PORT_RESERVATION IOCTL abgerufen worden sein.

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

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

SIO_ROUTING_INTERFACE_CHANGE (Opcodeeinstellung: I, T==1)

Um eine Benachrichtigung über eine Routingschnittstellenänderung zu erhalten, die verwendet werden soll, um die Remoteadresse im Eingabepuffer zu erreichen (angegeben als sockaddr-Struktur ). Nach Abschluss dieser IOCTL werden keine Ausgabeinformationen über die neue 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, dass die Anwendung überlappende E/A-Vorgänge verwendet, um über die Änderung der Routingschnittstelle bis zum Abschluss SIO_ROUTING_INTERFACE_CHANGE Anforderung benachrichtigt zu werden. 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 auch sofort und WSAEWOULDBLOCK als Fehler zurückgegeben, und die Anwendung kann dann auf das Weiterleiten von Änderungsereignissen durch Aufruf von WSAEventSelect oder WSAAsyncSelect mit FD_ROUTING_INTERFACE_CHANGE in der Netzwerkereignis-Bitmaske 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 zu allen Zielen zu erhalten, an denen sie interessiert ist, sowie der Dienstanbieter diese Benachrichtigungsanforderungen nachverfolgt, einen erheblichen Umfang von Systemressourcen beansprucht. Diese Situation kann vermieden werden, indem die Bedeutung der Eingabeparameter erweitert und die Anforderungen des Dienstanbieters wie folgt gelockert werden:

  • Die Anwendung kann eine protokollfamilienspezifische Wildcardadresse angeben (die gleiche wie beim Bindungsaufruf bei der Anforderung einer Bindung an eine beliebige verfügbare Adresse), um Benachrichtigungen über Routingänderungen anzufordern. Dies ermöglicht es der Anwendung, nur einen ausstehenden SIO_ROUTING_INTERFACE_CHANGE für alle Sockets und Ziele beizubehalten, über die sie verfügt, und dann SIO_ROUTING_INTERFACE_QUERY verwenden, um die tatsächlichen Routinginformationen abzurufen.
  • Ein Dienstanbieter hat die Möglichkeit, die von der Anwendung im Eingabepuffer des SIO_ROUTING_INTERFACE_CHANGE angegebenen Informationen zu ignorieren (als ob die Anwendung eine Wildcardadresse angegeben hat) und die SIO_ROUTING_INTERFACE_CHANGE IOCTL oder signalisiert FD_ROUTING_INTERFACE_CHANGE Ereignis bei einer Änderung der Routinginformationen abzuschließen (nicht nur die Route zum ziel, die im Eingabepuffer angegeben ist).

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

Zum Abrufen der Adresse der lokalen Schnittstelle (dargestellt als sockaddr-Struktur ), 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 bind()-Anforderung verwendet werden.

Beachten Sie, dass Routen änderungen vorbehalten sind. Anwendungen können sich daher nicht darauf verlassen, dass die von SIO_ROUTING_INTERFACE_QUERY zurückgegebenen Informationen dauerhaft sind. Anwendungen können sich für das Routing von Änderungsbenachrichtigungen über die SIO_ROUTING_INTERFACE_CHANGE IOCTL registrieren, die Benachrichtigungen entweder überlappende E/A- oder ein FD_ROUTING_INTERFACE_CHANGE-Ereignis ermöglicht. Die folgende Abfolge von Aktionen kann verwendet werden, um sicherzustellen, dass die Anwendung immer über aktuelle Routingschnittstelleninformationen für ein bestimmtes Ziel verfügt:

  • Problem SIO_ROUTING_INTERFACE_CHANGE IOCTL
  • Problem SIO_ROUTING_INTERFACE_QUERY IOCTL
  • Wenn SIO_ROUTING_INTERFACE_CHANGE IOCTL die Anwendung von Routingänderungen benachrichtigt (entweder durch überlappende E/A oder durch Signalisierung FD_ROUTING_INTERFACE_CHANGE Ereignisses), sollte die gesamte Sequenz der 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 Standardbehandlung 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 Mswsockdef.h-Headerdatei definiert ist. Diese Struktur ist wie folgt definiert:

/* Argument structure for SIO_SET_COMPATIBILITY_MODE */
typedef struct _WSA_COMPATIBILITY_MODE {
    WSA_COMPATIBILITY_BEHAVIOR_ID BehaviorId;
    ULONG TargetOsVersion;
} 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.

Der BehaviorId-Member kann einer der Werte aus dem WSA_COMPATIBILITY_BEHAVIOR_ID Enumerationstyp sein, der in der Mswsockdef.h-Headerdatei 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 das TargetOsVersion-Element auf einen Wert für Windows Vista oder höher festgelegt ist, sind Reduzierungen der TCP-Empfangspuffergröße für diesen Socket mithilfe der Socketoption SO_RCVBUF möglich, auch nachdem eine TCP-Verbindung hergestellt wurde.
Wenn das TargetOsVersion-Element auf einen Wert vor Windows Vista festgelegt ist, sind Reduzierungen der TCP-Empfangspuffergröße in diesem Socket mithilfe der Socketoption SO_RCVBUF nach verbindungsaufbau nicht zulässig.
WsaBehaviorAutoTuning
Wenn das TargetOsVersion-Element 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 Byte angegeben wurde, bevor die Verbindung hergestellt wurde.

Ausführlichere Informationen finden Sie in der Referenz zu 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_PRIORITY_HINT (Opcodeeinstellung: I, T==3)

Stellt einen Hinweis auf das zugrunde liegende Transportprotokoll bereit, um den Datenverkehr auf diesem Socket mit einer bestimmten Priorität zu behandeln. Der lpvInBuffer muss auf eine Variable vom Typ verweisen PRIORITY_HINT wobei cbInBuffer auf sizeof(PRIORITY_HINT) festgelegt ist. Die Parameter lpvOutBuffer und cbOutBuffer müssen NULL bzw. 0 sein. Die Tcp-Implementierung von Microsoft Windows unterstützt diese IOCTL ab Windows 10, Version 1809 (10.0; Build 17763) und höher wie folgt: Wenn der angeforderte Prioritätswert auf IoPriorityHintVeryLow festgelegt ist, verwendet TCP eine geänderte Version des LEDBAT-Algorithmus (definiert in RFC 6817), um die Rate des ausgehenden Datenverkehrs im Socket zu steuern. Der eingehende Datenverkehr wird von dieser IOCTL nicht beeinflusst. LEDBAT ist ein Scavenger-Algorithmus, und sein Ziel ist es, die Latenz niedrig zu halten und negative Auswirkungen auf den Datenverkehr mit normaler Priorität zu verhindern, indem er aus dem Weg geht, wenn Datenverkehr mit normaler Priorität vorhanden ist.

Siehe auch RFC 6817.

SIO_SET_PRIORITY_HINT wird auf Windows 10, Version 1809 (10.0; Build 17763) und höher.

SIO_SET_QOS (Opcodeeinstellung: I, T==1)

Ordnen Sie die angegebene 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_TCP_INITIAL_RTO (Opcodeeinstellung: I, T==3)

Steuert die anfänglichen (SYN/SYN+ACK)-Neuübertragungsmerkmale eines TCP-Sockets, indem RTO-Parameter (Initial Retransmission Timeout) konfiguriert werden. Die Konfigurationsparameter werden in einer TCP_INITIAL_RTO_PARAMETERS-Struktur angegeben.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_TCP_INITIAL_RTO . SIO_TCP_INITIAL_RTO wird auf Windows 8, Windows Server 2012 und höher unterstützt.

SIO_TIMESTAMPING

Eine Socket-IOCTL, die zum Konfigurieren des Empfangs von Sende-/Empfangszeitstempeln des Sockets verwendet wird. Nur für Datagrammsockets gültig. Der Eingabetyp für SIO_TIMESTAMPING ist die TIMESTAMPING_CONFIG-Struktur .

Siehe auch Winsock-Zeitstempel.

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

Um ein entsprechendes Handle für Sockets zu erhalten, das im Kontext einer Begleitschnittstelle gültig ist (z. B. TH_NETDEV und TH_TAPI). Im Eingabepuffer wird eine Manifestkonstante angegeben, die die Begleitschnittstelle zusammen mit allen anderen erforderlichen Parametern identifiziert. Das entsprechende Handle ist nach Abschluss dieser Funktion im Ausgabepuffer verfügbar. Ausführliche Informationen zu einer bestimmten Begleitschnittstelle finden Sie im entsprechenden Abschnitt in Winsock-Anhängen . 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, das Component Object Model (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 aus Gründen 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 (Opcodeeinstellung: 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.

SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS (Opcodeeinstellung: I, T==3)

Legt den Umleitungsdatensatz auf den neuen TCP-Socket fest, der für die Verbindung mit dem endgültigen Ziel zur Verwendung durch einen WFP-Umleitungsdienst (Windows Filtering Platform) verwendet wird.

Die SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS IOCTL wird als Teil der Verbindungsnachverfolgung für umgeleitete Socketverbindungen verwendet. Dieses WFP-Feature erleichtert die Nachverfolgung von Umleitungsdatensätzen von der anfänglichen Umleitung einer Verbindung bis zur endgültigen Verbindung mit dem Ziel.

Ausführlichere Informationen finden Sie in der Referenz zu SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS . SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS wird auf Windows 8, Windows Server 2012 und höher unterstützt.

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

Ruft die TCP-Statistiken für einen Socket ab. Die TCP-Statistiken werden in einer TCP_INFO_v0-Struktur bereitgestellt.

Im Gegensatz zum Abrufen von TCP-Statistiken mit der GetPerTcpConnectionEStats-Funktion erfordert das Abrufen von TCP-Statistiken mit diesem Steuercode nicht, dass der Benutzercode die TCP-Verbindungstabelle laden, speichern und filtern muss, und es sind keine erhöhten Berechtigungen erforderlich.

Weitere Informationen finden Sie unter SIO_TCP_INFO. SIO_TCP_INFO wird unter Windows 10, Version 1703, Windows Server 2016 und höher unterstützt.

Bemerkungen

Winsock Ioctls werden in einer Reihe verschiedener Headerdateien definiert. Dazu gehören die Headerdateien Winsock2.h, Mswsock.h und Mstcpip.h .

Im Microsoft Windows Software Development Kit (SDK), das für Windows Vista und höher veröffentlicht wurde, wurde die organization von Headerdateien geändert, und eine Reihe von Winsock Ioctls sind auch in den Headerdateien Ws2def.h, Ws2ipdef.h und Mswsockdef.h definiert. Die Ws2def.h-Headerdatei wird automatisch von der Winsock2.h-Headerdatei eingeschlossen. Die Ws2ipdef.h-Headerdatei wird automatisch von der Ws2tcpip.h-Headerdatei eingeschlossen. Die Headerdatei "Mswsockdef.h " wird automatisch in die Headerdatei "Mswsockdef.h " eingefügt.

Anforderungen

Anforderung Wert
Header
Winsock2.h;
Mstcpip.h;
mswsock.h;
Mswsockdef.h unter Windows Vista, Windows Server 2008 und Windows 7 (einschließlich Mswsock.h);
Ws2def.h unter Windows Vista, Windows Server 2008 und Windows 7 (einschließlich Winsock2.h);
Ws2ipdef.h unter Windows Vista, Windows Server 2008 und Windows 7 (einschließlich Ws2tcpip.h)