Existe um servidor de processamento de transações (TP-Server) ao qual meu aplicativo (Cliente) se conecta. Estamos vendo uma estranha seqüência de pacotes onde o TP-Server está enviando um pacote PUSH com dados de byte nulo (0), mas o número de seqüência deste pacote é incorreto; o número de sequência é o do último byte recebido.
Por favor, olhe os dados do TCP dump aqui link
172.250.10.10.13824 é o servidor TP.
172.11.105.5.49524 é o cliente.
"TP-Server" não está no meu controle, não tenho certeza de qual sistema operacional está sendo executado. "Cliente" é o meu aplicativo de pagamento em execução no Debian Squeeze.
Você pode ver que um dado de byte nulo é enviado pelo TP-Server no pacote abaixo.
20:52:34.472819 IP (tos 0x0, ttl 59, id 51820, offset 0, flags [DF], proto TCP (6), length 53)
172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0xe36f (correct), seq 1457045850:1457045851, ack 3097912286, win 17680, options [nop,nop,TS val 646012206 ecr 73190886], length 1
0x0000: 4500 0035 ca6c 4000 3b06 a941 acfa 0a0a E..5.l@.;..A....
0x0010: ac0b 6905 3600 c174 56d8 c15a b8a6 63de ..i.6..tV..Z..c.
0x0020: 8018 4510 e36f 0000 0101 080a 2681 5d2e ..E..o......&.].
0x0030: 045c cde6 00 .\...
O número de sequência dos dados de byte nulo acima está marcado como 1457045850. Mas o mesmo foi recebido muito antes, como mostrado abaixo.
20:50:22.506267 IP (tos 0x0, ttl 59, id 51817, offset 0, flags [DF], proto TCP (6), length 607)
172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0x6460 (correct), seq 1457045296:1457045851, ack 3097912253, win 17680, options [nop,nop,TS val 645999009 ecr 73187775], length 555
Para o número de seqüência incorreto, o cliente responde com um sinalizador de saca indicando o número de seqüência incorreto.
20:52:34.472864 IP (tos 0x0, ttl 64, id 1172, offset 0, flags [DF], proto TCP (6), length 64)
172.11.105.5.49524 > 172.250.10.10.13824: Flags [.], cksum 0x4501 (correct), seq 3097912286, ack 1457045851, win 2003, options [nop,nop,TS val 73220891 ecr 646012206,nop,nop,sack 1 {1457045850:1457045851}], length 0
Os mesmos dados de byte nulo são enviados repetidamente pelo TP-Server por mais 7 vezes com o mesmo número de sequência incorreto. E o cliente responde delicadamente de volta com o saco.
20:58:29.024492 IP (tos 0x0, ttl 59, id 51827, offset 0, flags [DF], proto TCP (6), length 53)
172.250.10.10.13824 > 172.11.105.5.49524: Flags [P.], cksum 0x04bf (correct), seq 1457045850:1457045851, ack 3097912308, win 17680, options [nop,nop,TS val 646047661 ecr 73277952], length 1
0x0000: 4500 0035 ca73 4000 3b06 a93a acfa 0a0a E..5.s@.;..:....
0x0010: ac0b 6905 3600 c174 56d8 c15a b8a6 63f4 ..i.6..tV..Z..c.
0x0020: 8018 4510 04bf 0000 0101 080a 2681 e7ad ..E.........&...
0x0030: 045e 2200 00 .^"..
20:58:29.024553 IP (tos 0x0, ttl 64, id 1179, offset 0, flags [DF], proto TCP (6), length 64)
172.11.105.5.49524 > 172.250.10.10.13824: Flags [.], cksum 0x602c (correct), seq 3097912308, ack 1457045851, win 2003, options [nop,nop,TS val 73309529 ecr 646047661,nop,nop,sack 1 {1457045850:1457045851}], length 0
No entanto, na oitava vez que o mesmo acontece, o Cliente para de dar um ack. O TP-Server continua enviando dados de byte nulo por mais 5 vezes, pois nenhum deles responde com ack. Esse comportamento está acontecendo no nível da pilha de rede e meu aplicativo cliente pobre não recebe nenhum erro de soquete e somente no tempo "21:18:59", ele recebeu um erro getocketopt: 110 (que eu acho que é ETIMED_OUT). Então, meu aplicativo cliente, esperou por mais algum tempo e tentou se reconectar às 21:21:38 (você pode ver os pacotes SYN). No entanto, o TP-Server não estava respondendo depois disso. Depois que o PC "Cliente" foi reinicializado após alguns minutos, o TP-Server aceitou novas conexões. Mas, os mesmos pacotes de byte nulo começam a reaparecer novamente. Às vezes, aconteceu que o Cliente tinha alguns pacotes de dados periódicos para serem enviados ao TP-Server em intervalos de 10 segundos e isso mantinha a conexão ativa, independentemente dos bytes nulos que ainda acontecem e do cliente respondendo com os pacotes. / p>
Minhas perguntas:
Qual é o motivo por trás desses bytes de dados nulos enviados com um número de seqüência incorreto?
Devo fazer alguma coisa sobre a pilha de rede debian para lidar com esse cenário para manter a conexão ativa?