SIO_LOOPBACK_FAST_PATH Steuerelementcode

Wichtig Die SIO_LOOPBACK_FAST_PATH ist veraltet und wird nicht empfohlen, in Ihrem Code zu verwenden.

Der SIO_LOOPBACK_FAST_PATH Socket-E/A-Steuerungscode ermöglicht es einer WSK-Anwendung, einen TCP-Socket für schnellere Vorgänge auf der Loopbackschnittstelle zu konfigurieren.

Um diese IOCTL zu verwenden, ruft eine WSK-Anwendung die WskControlSocket Funktion mit den folgenden Parametern auf.

Eine Anwendung kann die SIO_LOOPBACK_FAST_PATH IOCTL verwenden, um die Leistung von Loopbackvorgängen in einem TCP-Socket zu verbessern. Diese IOCTL fordert an, dass der TCP/IP-Stapel einen speziellen schnellen Pfad für Loopbackvorgänge in diesem 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.

Der Socket, der die Verbindungsanforderung initiieren soll, muss diese IOCTL anwenden, bevor die Verbindungsanforderung ausgeführt wird. Der Socket, der auf die Verbindungsanforderung lauscht, muss diese IOCTL anwenden, bevor die Verbindung akzeptiert wird.

Sobald eine Anwendung die Verbindung auf einer Loopbackschnittstelle mithilfe des schnellen Pfads herstellt, müssen alle Pakete für die Lebensdauer der Verbindung den schnellen Pfad verwenden.

Das Anwenden von SIO_LOOPBACK_FAST_PATH auf einen Socket, der mit einem Nicht-Loopbackpfad verbunden wird, hat keine Auswirkung.

Diese TCP-Loopbackoptimierung führt zu Paketen, die über Transport Layer (TL) statt der herkömmlichen Loopbacks über Network Layer fließen. Diese Optimierung verbessert die Latenz für Loopbackpakete. Sobald sich eine Anwendung für eine Einstellung auf Verbindungsebene für die Verwendung des loopback-schnellen Pfads anmeldet, folgen alle Pakete dem Loopbackpfad. Für Loopbackkommunikation werden Staus und Paketabbruch nicht erwartet. Das Konzept der Überlastungskontrolle und der zuverlässigen Übermittlung in TCP ist unnötig. Dies gilt jedoch nicht für die Ablaufsteuerung. Ohne Ablaufsteuerung kann der Absender den Empfangspuffer überfordern, was zu fehlerhaftem TCP-Loopbackverhalten führt. Die Ablaufsteuerung im tcp-optimierten Loopbackpfad wird beibehalten, indem Sendeanforderungen in einer Warteschlange platziert werden. Wenn der Empfangspuffer voll ist, garantiert der TCP/IP-Stapel, dass die Gesendete erst abgeschlossen werden, wenn die Warteschlange gewartet wird und die Ablaufsteuerung beibehalten wird.

TCP-Loopbackverbindungen für schnelle Pfade in Anwesenheit einer Windows-Filterplattform -Legende (WFP) für Verbindungsdaten müssen den nicht optimierten langsamen Pfad für Loopback verwenden. Daher verhindern WFP-Filter, dass dieser neue loopbackschnelle Pfad verwendet wird. Wenn ein WFP-Filter aktiviert ist, verwendet das System den langsamen Pfad, auch wenn die SIO_LOOPBACK_FAST_PATH IOCTL festgelegt wurde. Dies ensues, dass Anwendungen im Benutzermodus über die vollständige WFP-Sicherheitsfunktion verfügen.

Standardmäßig ist SIO_LOOPBACK_FAST_PATH deaktiviert.

Es werden nur eine Teilmenge der TCP/IP-Socketoptionen unterstützt, wenn die SIO_LOOPBACK_FAST_PATH IOCTL verwendet wird, um den loopbackschnellen Pfad in einem Socket zu aktivieren. Die Liste der unterstützten Optionen umfasst Folgendes:

• IP_TTL
• IP_UNICAST_IF
• IPV6_UNICAST_HOPS
• IPV6_UNICAST_IF
• IPV6_V6ONLY
• SO_CONDITIONAL_ACCEPT
• SO_EXCLUSIVEADDRUSE
• SO_PORT_SCALABILITY
• SO_RCVBUF
• SO_REUSEADDR
• TCP_BSDURGENT

Eine WSK-Anwendung muss beim Aufrufen der WskControlSocket--Funktion für diesen Anforderungstyp einen Zeiger auf eine IRP und eine Abschlussroutine angeben. Die Anwendung darf den Puffer erst freigeben, wenn das WSK-Subsystem das IRP abgeschlossen hat. Nach Abschluss des IRP ruft das Subsystem die Abschlussroutine auf. In der Abschlussroutine muss die Anwendung den IRP-Status überprüfen und alle Ressourcen freigeben, die sie zuvor für die Anforderung zugewiesen hatten.

Weitere Informationen zur WSK IRP-Behandlung finden Sie unter Verwenden von IRPs mit Winsock Kernel Functions.

Nach Abschluss des IRP legt das Subsystem Irp->IoStatus.Status auf STATUS_SUCCESS fest, wenn die Anforderung erfolgreich ist. Andernfalls wird Irp->IoStatus.Status- auf STATUS_INVALID_BUFFER_SIZE oder STATUS_NOT_SUPPORTED festgelegt, wenn der Anruf nicht erfolgreich ist.

Rückgabewert

Anforderungen

Siehe auch

SIO_LOOPBACK_FAST_PATH (SDK)

Verwenden von IRPs mit Winsock-Kernelfunktionen