Tcp connection breaking, muito rápido para serial?

Question

Tenho tido dificuldades reais em fazer com que uma conexão tcp funcione com meu servidor da web. Eu acho que o problema pode ter algo a ver com a velocidade ou a ordem dos pacotes, já que a conexão parece começar bem, então falha depois de um tempo. Eu estou correndo todo esse tráfego através de um programa que eu escrevi e, em seguida, através de uma linha serial com o antigo protocolo SLIP. Eu encontrei quase nenhuma informação sobre como fazer conexões tcp mais lento, parece que todo mundo está tentando ir para o outro lado. Como se limita a velocidade de uma conexão tcp? Eu acho que eu preciso diminuir o valor que cada lado tenta enviar de cada vez e com que rapidez eles decidem reenviar.

Além disso, alguém sabe como eu poderia diminuir o tamanho da janela no meu computador com Windows 7? (agindo como o cliente tentando se conectar ao servidor), pois acho que isso pode ajudar a desacelerar as coisas. Eu tentei todos os valores do registro e eles parecem não ter efeito, eu desativei o escalonamento e a heurística, mas ele ainda usa uma janela de 65500.

Aqui estão algumas capturas do Wireshark do cliente e lado do servidor .

    

Answer 1

Na verdade, faço bastante testes de aplicativos em situações de alta latência devido aos negócios em que estou ... (testamos com uma variedade de links de latência de 200 - 1400ms)

Normalmente, eu configuro um roteador linux e uso tc para emular latência e perda de pacotes (e coisas assim) ... mas no Windows, eu nunca me preocupei em tentar. No entanto, encontrei algo que pode ser útil para o seu ambiente ...

link

Aparentemente, você pode adicionar latência, jitter, pacotes duplicados, etc ... para simular o que estiver procurando.

... o que foi dito ... Eu duvido seriamente que o pedido / velocidade causaria sérios problemas com a conectividade do tcp em uma plataforma Windows. A pilha de rede no Windows é bastante robusta contra pacotes fora de ordem ou perdidos. É mais provável que as conexões terminem devido à falta de acks ... ou terminem devido à inatividade. É mais provável que você não esteja permitindo que o Windows mantenha a sessão TCP ... e, em vez disso, tenha implementado seus próprios ACKs / SYNs / etc ... e não tenha implementado um tempo limite de falha segura.

Existem dispositivos de otimização de WAN que podem causar problemas em que a sessão TCP é mantida viva artificialmente, mas a sessão foi encerrada. (Os leitos de rios, por exemplo, podem causar isso.) Estes podem se tornar muito complicados para solucionar problemas ... mas das partes que posso coletar de suas capturas de pacotes ... é improvável que um leito de rio esteja em jogo aqui.

Como nota final. Por favor, não confie em pcaps truncados. se estiver usando tcpdump , não se esqueça de especificar -s 0 para capturar o pacote INTEIRO em vez de apenas um pacote abreviado.