C# soketasynceventargs para de disparar o evento concluído

Question

Eu notei um problema em que o evento. parece parar de disparar. O mesmo SAEA pode disparar corretamente e ser substituído na piscina várias vezes, mas, eventualmente, todas as instâncias param de disparar e, porque o código para substituí -las na piscina está no manipulador de eventos, a piscina esvazia.

o seguintes circunstâncias também são aparentemente verdadeiros:

1) Parece ocorrer apenas quando um soquete lateral do servidor envia dados para um dos clientes conectados. Quando a mesma classe está se conectando como cliente, ela não parece funcionar mal.

2) Parece ocorrer sob alta carga. A contagem de threads parece subir até que eventualmente o erro aconteça.

3) Um equipamento de teste sob estresse semelhante parece nunca funcionar. (São apenas 20 mensagens por segundo, e a plataforma de teste foi comprovada para 20k)

Não vou ser capaz de colar o código bastante complicado, mas aqui está um Descrição do meu código:

1) A principal inspiração é a seguinte: http://vadmyst.blogspot.ch/2008/05/sample-code-for-tcp-server-using.html. Ele mostra como conectar uma porta de conclusão usando um evento, como obter mensagens de tamanho diferente sobre a conexão TCP e assim por diante.

2) Eu tenho um tampão de byte no qual todas as Saeas têm uma peça, que não se sobrepõe.

3) Eu tenho um pool de objetos de SAEAs, com base em uma coleta de blocking. Isso joga se a piscina estiver vazia por muito tempo.

4) Como servidor, mantenho uma coleção de soquetes retornados da função AcceptAsync, indexada pelo terminal do cliente. Um único processo pode usar uma instância como servidor, bem como várias instâncias como clientes (formando uma web). Eles compartilham o buffer de dados e o pool de Saeas.

Eu percebo que é difícil explicar isso; Eu tenho depurado por um dia e noite inteiro. Apenas esperando que alguém tenha ouvido falar disso ou tenha perguntas ou sugestões úteis.

No momento, estou suspeitando de algum tipo de exaustão de fios, levando os Saeas a não poder chamar a conclusão. Como alternativa, algum tipo de problema de buffer no buffer de saída.

Answer 1

Então, outro dia de depuração e, finalmente, tenho uma explicação.

1) Os SAEAs não estavam disparando o evento concluído porque não conseguiram enviar mais. Isso é revelado pelo Wireshark devido ao esvaziamento da janela TCP. (TCP Zerowindow)

2) A janela do TCP estava esvaziando porque a camada de rede estava passando por um evento na pilha que demorou muito para concluir, ou seja, não há produtor/consumidor entre a camada de rede e a interface do usuário. Assim, o Network OP teria que esperar pelo desenho da tela antes de enviar o ACK.

3) O evento que demorou demais foi um empate em um manipulador de eventos na GUI. O equipamento de teste era uma janela do console (que resumia as mensagens recebidas), por isso não causou um problema com carga muito mais alta. É normal não redesenhar a tela em cada mensagem, mas isso estava acontecendo porque o projeto ainda não acabou. A taxa de redefinição teria sido consertada posteriormente.

4) A solução de curto prazo é simplesmente garantir que não haja GUIs segurando o show. Uma solução mais robusta pode ser criar um produtor/consumidor na camada de rede.