INFO: Evitar dados exibição no Winsock

Exibição de dados em Winsock significa que um aplicativo solicitações para a quantidade de dados de entrada aguardando para ser recebido sem realmente recebê-lo. Este é um remanescente do Winsock 1.1 compatibilidade com soquetes BSD UNIX. No Winsock, isso é feito com recv/WSARecv(..., MSG_PEEK) ou ioctlsocket(FIONREAD,...). Você deve evitar isso porque ele é altamente ineficiente, e ele assuntos um aplicativo a uma contagem de dados incorretos.

Implementação de soquete depende de tamanho fixo interno enviar e receber buffers são alocadas conforme necessário da memória de pool contíguo, não-paginável. O tamanho padrão desses buffers é 8 k cada. Dados de rede de entrada são colocados no buffer interno de recepção para o soquete.

Aplicativos Winsock que usam um dos métodos espiada, com recv/WSARecv(..., MSG_PEEK) ou ioctlsocket(FIONREAD,...), para obter a quantidade de dados no buffer de recepção é altamente ineficiente porque o sistema deve bloquear os dados e contá-lo. Como o sistema faz isso, é provável que a rede em tempo real ainda irá tentar preencher o buffer com mais dados. Exibição também não remove os dados, que permite que o buffer atingir seu limite de armazenamento. Como resultado, isso fecha para baixo a taxa de fluxo de dados de rede e faz todo o processo de transmissão de dados ineficiente.

Pesquisa em um soquete fluxo até que um determinado número de bytes ou uma "mensagem" chega é código inválido. Um soquete de fluxo, como TCP, não preserva os limites das mensagens porque ele fornece um fluxo de dados. Como tal, o maior tamanho de mensagem de um aplicativo pode nunca dependem é um byte de comprimento. Código que usa a exibição aguardar até que uma "mensagem" concluída chega nunca pode ter êxito nos protocolos baseados em fluxo no Winsock onde os dados straddles vários limites de buffer do sistema, devido às decisões de design. A operação de espiada reportará o número de bytes até o primeiro limite de buffer. Os bytes restantes em outros limites nunca podem ser relatados, resultando em uma contagem incorreta de dados para os algoritmos de código que dependem dos valores de espiada para ser preciso. Tentativas de espiada subseqüentes não irão revelar os dados "hidden", que ainda podem ser recebidos dos buffers de.

A implementação de soquete de protocolo baseado em fluxo melhor é drenar dados imediatamente na chegada no espaço de buffer alocado de aplicativo. Isso permite que os buffers de soquete permanecer aberto para uma taxa de fluxo de dados de rede estável como o aplicativo analisa os dados, resultando em muito melhor desempenho da rede.

Windows Sockets 2 API Specification, revisão 2.2.0, 10 de maio de 1996 Apêndice C, "A lista Lame" item 20 #, # 26.

Para obter informações adicionais, consulte o seguinte artigo na Base de dados de Conhecimento da Microsoft: