code de contrôle SIO_LOOPBACK_FAST_PATH
ImportantL’SIO_LOOPBACK_FAST_PATH est déconseillé et il n’est pas recommandé d’utiliser dans votre code.
Le code de contrôle E/S du socket SIO_LOOPBACK_FAST_PATH permet à une application WSK de configurer un socket TCP pour des opérations plus rapides sur l’interface de bouclage.
Pour utiliser ce IOCTL, une application WSK appelle la fonction WskControlSocket avec les paramètres suivants.
| Paramètre | Valeur |
|---|---|
RequestType |
WskIoctl |
ControlCode |
SIO_LOOPBACK_FAST_PATH |
Niveau |
0 |
InputSize |
Taille, en octets, de la mémoire tampon d’entrée. |
InputBuffer |
Pointeur vers la mémoire tampon d’entrée. Ce paramètre contient un pointeur vers une valeur booléenne qui indique si le socket doit être configuré pour des opérations de bouclage rapide. |
OutputSize |
0 |
OutputBuffer |
NULL |
OutputSizeReturned |
NULL |
Irp |
Pointeur vers un IRP. |
Une application peut utiliser le SIO_LOOPBACK_FAST_PATH IOCTL pour améliorer les performances des opérations de bouclage sur un socket TCP. Ce IOCTL demande que la pile TCP/IP utilise un chemin d’accès rapide spécial pour les opérations de bouclage sur ce socket. Le SIO_LOOPBACK_FAST_PATH IOCTL ne peut être utilisé qu’avec des sockets TCP. Ce IOCTL doit être utilisé des deux côtés de la session de bouclage. Le chemin rapide de bouclage TCP est pris en charge à l’aide de l’interface de bouclage IPv4 ou IPv6.
Le socket qui prévoit d’initier la demande de connexion doit appliquer ce IOCTL avant d’effectuer la demande de connexion. Le socket qui écoute la demande de connexion doit appliquer ce IOCTL avant d’accepter la connexion.
Une fois qu’une application établit la connexion sur une interface de bouclage à l’aide du chemin d’accès rapide, tous les paquets pour la durée de vie de la connexion doivent utiliser le chemin rapide.
L’application de SIO_LOOPBACK_FAST_PATH à un socket qui sera connecté à un chemin d’accès non bouclage n’aura aucun effet.
Cette optimisation du bouclage TCP génère des paquets qui transitent par la couche de transport (TL) au lieu du bouclage traditionnel via la couche réseau. Cette optimisation améliore la latence des paquets de bouclage. Une fois qu’une application opte pour un paramètre de niveau de connexion pour utiliser le chemin rapide de bouclage, tous les paquets suivent le chemin de bouclage. Pour les communications de bouclage, la congestion et la suppression des paquets ne sont pas attendues. La notion de contrôle de la congestion et de livraison fiable dans TCP ne sera pas nécessaire. Toutefois, cela n’est pas vrai pour le contrôle de flux. Sans contrôle de flux, l’expéditeur peut surcharger la mémoire tampon de réception, ce qui entraîne un comportement de bouclage TCP erroné. Le contrôle de flux dans le chemin de bouclage optimisé TCP est conservé en plaçant les demandes d’envoi dans une file d’attente. Lorsque la mémoire tampon de réception est pleine, la pile TCP/IP garantit que les envois ne se terminent pas tant que la file d’attente n’est pas résolue, ce qui maintient le contrôle du flux.
Les connexions tcp de bouclage rapide en présence d’une légende de la plateforme de filtrage Windows (PAM) pour les données de connexion doivent prendre le chemin lent non optimisé pour le bouclage. Ainsi, les filtres PAM empêchent l’utilisation de ce nouveau chemin rapide de bouclage. Lorsqu’un filtre PAM est activé, le système utilise le chemin lent même si le SIO_LOOPBACK_FAST_PATH IOCTL a été défini. Cela s’ensuit que les applications en mode utilisateur disposent de la capacité de sécurité complète du PAM.
Par défaut, SIO_LOOPBACK_FAST_PATH est désactivé.
Seul un sous-ensemble des options de socket TCP/IP est pris en charge lorsque le SIO_LOOPBACK_FAST_PATH IOCTL est utilisé pour activer le chemin rapide de bouclage sur un socket. La liste des options prises en charge comprend les éléments suivants :
- 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
Une application WSK doit spécifier un pointeur vers un IRP et une routine d’achèvement lors de l’appel de la fonction WskControlSocket pour ce type de requête. L’application ne doit pas libérer la mémoire tampon tant que le sous-système WSK n’a pas terminé l’IRP. Une fois l’IRP terminée, le sous-système appelle la routine d’achèvement. Dans la routine d’achèvement, l’application doit case activée l’status IRP et libérer toutes les ressources qu’elle avait précédemment allouées pour la demande.
Pour plus d’informations sur la gestion des IRP WSK, consultez Utilisation des IRP avec des fonctions de noyau Winsock.
À la fin de l’IRP, le sous-système définit Irp-IoStatus.Status> sur STATUS_SUCCESS si la demande réussit. Sinon, Irp-IoStatus.Status> est défini sur STATUS_INVALID_BUFFER_SIZE ou STATUS_NOT_SUPPORTED si l’appel échoue.
Valeur retournée
Configuration requise
Client minimal pris en charge |
Windows 8 |
Serveur minimal pris en charge |
Windows Server 2012 |
En-tête |
Mstcpip.h |
IRQL |
PASSIVE_LEVEL |