code de contrôle SIO_LOOPBACK_FAST_PATH
Important La SIO_LOOPBACK_FAST_PATH est déconseillée et n’est pas recommandée pour être utilisée dans votre code.
Le code de contrôle d’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 les opérations de bouclage rapides. |
OutputSize |
0 |
OutputBuffer |
NULL |
OutputSizeReturned |
NULL |
Irp |
Pointeur vers un IRP. |
Une application peut utiliser la SIO_LOOPBACK_FAST_PATH IOCTL pour améliorer les performances des opérations de bouclage sur un socket TCP. Cette 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é sur les 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 cette IOCTL avant d’effectuer la demande de connexion. Le socket qui écoute la demande de connexion doit appliquer cette iocTL avant d’accepter la connexion.
Une fois qu’une application établit la connexion sur une interface de bouclage à l’aide du chemin 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 de non-bouclage n’aura aucun effet.
Cette optimisation de bouclage TCP entraîne 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 de paquets ne sont pas attendues. La notion de contrôle de congestion et de livraison fiable dans TCP sera inutile. Cela n’est toutefois 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 termineront pas tant que la file d’attente n’est pas mise en service, en conservant le contrôle de flux.
Les connexions de bouclage de chemin rapide TCP en présence d’une légende de plateforme de filtrage Windows (PAM) pour les données de connexion doivent prendre le chemin lent non optimisé pour la bouclage. Ainsi, les filtres PAM empêchent l’utilisation de ce nouveau chemin rapide de bouclage rapide. Lorsqu’un filtre PAM est activé, le système utilise le chemin lent même si la SIO_LOOPBACK_FAST_PATH IOCTL a été définie. Cela résulte 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ée.
Seuls un sous-ensemble des options de socket TCP/IP sont prises en charge lorsque la SIO_LOOPBACK_FAST_PATH IOCTL est utilisée 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é, le sous-système appelle la routine d’achèvement. Dans la routine d’achèvement, l’application doit vérifier l’état 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 d’IRPs avec Winsock Kernel Functions.
Lorsque vous terminez l’IRP, le sous-système définit Irp->IoStatus.Status sur STATUS_SUCCESS si la requête réussit. Sinon, Irp->IoStatus.Status sera défini sur STATUS_INVALID_BUFFER_SIZE ou STATUS_NOT_SUPPORTED si l’appel n’a pas réussi.
Valeur de retour
Exigences
Client minimum pris en charge |
Windows 8 |
Serveur minimum pris en charge |
Windows Server 2012 |
En-tête |
Mstcpip.h |
IRQL |
PASSIVE_LEVEL |