Compartilhar via


código de controle SIO_LOOPBACK_FAST_PATH

Importante O SIO_LOOPBACK_FAST_PATH foi preterido e não é recomendável ser usado em seu código.

O código de controle de E/S do soquete SIO_LOOPBACK_FAST_PATH permite que um aplicativo WSK configure um soquete TCP para operações mais rápidas na interface de loopback.

Para usar esse IOCTL, um aplicativo WSK chama a função WskControlSocket com os parâmetros a seguir.

Parâmetro Valor

RequestType

WskIoctl

ControlCode

SIO_LOOPBACK_FAST_PATH

Level

0

InputSize

O tamanho, em bytes, do buffer de entrada.

Inputbuffer

Um ponteiro para o buffer de entrada. Esse parâmetro contém um ponteiro para um valor booliano que indica se o soquete deve ser configurado para operações de loopback rápido.

OutputSize

0

OutputBuffer

NULL

OutputSizeReturned

NULL

Irp

Um ponteiro para um IRP.

Um aplicativo pode usar o SIO_LOOPBACK_FAST_PATH IOCTL para melhorar o desempenho das operações de loopback em um soquete TCP. Essa IOCTL solicita que a pilha TCP/IP use um caminho rápido especial para operações de loopback nesse soquete. O SIO_LOOPBACK_FAST_PATH IOCTL só pode ser usado com soquetes TCP. Esse IOCTL deve ser usado em ambos os lados da sessão de loopback. O caminho rápido de loopback TCP tem suporte usando a interface de loopback IPv4 ou IPv6.

O soquete que planeja iniciar a solicitação de conexão deve aplicar esse IOCTL antes de fazer a solicitação de conexão. O soquete que está escutando a solicitação de conexão deve aplicar esse IOCTL antes de aceitar a conexão.

Depois que um aplicativo estabelece a conexão em uma interface de loopback usando o caminho rápido, todos os pacotes para o tempo de vida da conexão devem usar o caminho rápido.

Aplicar SIO_LOOPBACK_FAST_PATH a um soquete que será conectado a um caminho não loopback não terá efeito.

Essa otimização de loopback TCP resulta em pacotes que fluem por TL (Camada de Transporte) em vez do loopback tradicional por meio da Camada de Rede. Essa otimização melhora a latência de pacotes de loopback. Depois que um aplicativo optar por uma configuração de nível de conexão para usar o caminho rápido de loopback, todos os pacotes seguirão o caminho de loopback. Para comunicações de loopback, o congestionamento e a queda de pacotes não são esperados. A noção de controle de congestionamento e entrega confiável no TCP será desnecessária. Isso, no entanto, não é verdadeiro para o controle de fluxo. Sem o controle de fluxo, o remetente pode sobrecarregar o buffer de recebimento, levando a um comportamento de loopback TCP incorreto. O controle de fluxo no caminho de loopback otimizado para TCP é mantido colocando solicitações de envio em uma fila. Quando o buffer de recebimento estiver cheio, a pilha TCP/IP garantirá que os envios não serão concluídos até que a fila seja atendida, mantendo o controle de fluxo.

Conexões de loopback de caminho rápido TCP na presença de um texto explicativo da Plataforma de Filtragem do Windows (WFP) para dados de conexão devem tomar o caminho lento não otimizado para loopback. Portanto, os filtros WFP impedirão que esse novo caminho rápido de loopback seja usado. Quando um filtro WFP estiver habilitado, o sistema usará o caminho lento mesmo que o SIO_LOOPBACK_FAST_PATH IOCTL tenha sido definido. Isso ocorre porque os aplicativos no modo de usuário têm a funcionalidade de segurança completa do WFP.

Por padrão, SIO_LOOPBACK_FAST_PATH está desabilitado.

Há suporte apenas para um subconjunto das opções de soquete TCP/IP quando o SIO_LOOPBACK_FAST_PATH IOCTL é usado para habilitar o caminho rápido de loopback em um soquete. A lista de opções com suporte inclui o seguinte:

Um aplicativo WSK deve especificar um ponteiro para um IRP e uma rotina de conclusão ao chamar a função WskControlSocket para esse tipo de solicitação. O aplicativo não deve liberar o buffer até que o subsistema WSK tenha concluído o IRP. Quando ele conclui o IRP, o subsistema invoca a rotina de conclusão. Na rotina de conclusão, o aplicativo deve marcar o status IRP e liberar todos os recursos alocados anteriormente para a solicitação.

Para obter mais informações sobre o tratamento de IRP do WSK, consulte Usando IRPs com funções de kernel winsock.

Ao concluir o IRP, o subsistema definirá Irp-IoStatus.Status como STATUS_SUCCESS se a solicitação for bem-sucedida>. Caso contrário, Irp-IoStatus.Status> será definido como STATUS_INVALID_BUFFER_SIZE ou STATUS_NOT_SUPPORTED se a chamada não for bem-sucedida.

Retornar valor

Requisitos

Cliente mínimo com suporte

Windows 8

Servidor mínimo com suporte

Windows Server 2012

Cabeçalho

Mstcpip.h

IRQL

PASSIVE_LEVEL

Confira também

SIO_LOOPBACK_FAST_PATH (SDK)

Usando IRPs com funções de kernel Winsock