SIO_LOOPBACK_FAST_PATH control code
Important The SIO_LOOPBACK_FAST_PATH is deprecated and is not recommended to be used in your code.
The SIO_LOOPBACK_FAST_PATH socket I/O control code allows a WSK application to configure a TCP socket for faster operations on the loopback interface.
To use this IOCTL, a WSK application calls the WskControlSocket function with the following parameters.
| Parameter | Value |
|---|---|
RequestType |
WskIoctl |
ControlCode |
SIO_LOOPBACK_FAST_PATH |
Level |
0 |
InputSize |
The size, in bytes, of the input buffer. |
InputBuffer |
A pointer to the input buffer. This parameter contains a pointer to a Boolean value that indicates if the socket should be configured for fast loopback operations. |
OutputSize |
0 |
OutputBuffer |
NULL |
OutputSizeReturned |
NULL |
Irp |
A pointer to an IRP. |
An application can use the SIO_LOOPBACK_FAST_PATH IOCTL to improve the performance of loopback operations on a TCP socket. This IOCTL requests that the TCP/IP stack use a special fast path for loopback operations on this socket. The SIO_LOOPBACK_FAST_PATH IOCTL can be used only with TCP sockets. This IOCTL must be used on both sides of the loopback session. The TCP loopback fast path is supported using either the IPv4 or IPv6 loopback interface.
The socket that plans to initiate the connection request must apply this IOCTL before making the connection request. The socket that is listening for the connection request must apply this IOCTL before accepting the connection.
Once an application establishes the connection on a loopback interface using the fast path, all packets for the lifetime of the connection must use the fast path.
Applying SIO_LOOPBACK_FAST_PATH to a socket which will be connected to a non-loopback path will have no effect.
This TCP loopback optimization results in packets that flow through Transport Layer (TL) instead of the traditional loopback through Network Layer. This optimization improves the latency for loopback packets. Once an applications opts in for a connection level setting to use the loopback fast path, all packets will follow the loopback path. For loopback communications, congestion and packet drop are not expected. The notion of congestion control and reliable delivery in TCP will be unnecessary. This, however, is not true for flow control. Without flow control, the sender can overwhelm the receive buffer, leading to erroneous TCP loopback behavior. The flow control in the TCP optimized loopback path is maintained by placing send requests in a queue. When the receive buffer is full, the TCP/IP stack guarantees that the sends won't complete until the queue is serviced, maintaining flow control.
TCP fast path loopback connections in the presence of a Windows Filtering Platform (WFP) callout for connection data must take the unoptimized slow path for loopback. So WFP filters will prevent this new loopback fast path from being used. When a WFP filter is enabled, the system will use the slow path even if the SIO_LOOPBACK_FAST_PATH IOCTL was set. This ensues that user-mode applications have the full WFP security capability.
By default, SIO_LOOPBACK_FAST_PATH is disabled.
Only a subset of the TCP/IP socket options are supported when the SIO_LOOPBACK_FAST_PATH IOCTL is used to enable the loopback fast path on a socket. The list of supported options includes the following:
- 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
A WSK application must specify a pointer to an IRP and a completion routine when calling the WskControlSocket function for this type of request. The application must not release the buffer till the WSK subsystem has completed the IRP. When it completes the IRP, the subsystem invokes the completion routine. In the completion routine, the application must check the IRP status and release all resources that it had previously allocated for the request.
For more information about WSK IRP handling, see Using IRPs with Winsock Kernel Functions.
When completing the IRP, the subsystem will set Irp->IoStatus.Status to STATUS_SUCCESS if the request is successful. Otherwise, Irp->IoStatus.Status will be set to STATUS_INVALID_BUFFER_SIZE or STATUS_NOT_SUPPORTED if the call is not successful.
Return value
Requirements
Minimum supported client |
Windows 8 |
Minimum supported server |
Windows Server 2012 |
Header |
Mstcpip.h |
IRQL |
PASSIVE_LEVEL |