Re: DUP

[Christoph Simon <ciccio@kiosknet.com.br>]

On 23 Jan 2003 09:07:56 -0200
Eduardo Marcel Macan <macan@colband.com.br> wrote:

> Preciso dar uma olhada de novo nos RFCs, faz tanto tempo...

Só uma parte da resposta está no RFC, o resto está no código do
ping. O Kov deu a resposta correcta. Embora a resposta dele foe muito
curta, é correcta na grande maioria dos casos.

> isso não quer dizer que dois computadores responderam...

é certo que existe uma situação extrema em que pode aparentar um DUP
sem que seja uma duplicação, mas é totalmente improvável que seja isso
o caso.

> cada pacote ECHO enviado vai com um número sequencial (aquele 
> icmp_seq na saída do ping) quando o computador remoto responde
> com o ECHO REPLY ele inclui na carga do pacote o número 
> sequencial do pacote que ele está respondendo.

Não. o número sequencial não vem na carga do pacote, senão no
cabeçalho. No caso de Linux e no caso de um ECHO_{REPLY), é
essencialmente assim:

	struct icmphdr
	{
	  unsigned char type;	/* ECHO ou ECHO_REPLY */
	  unsigned char code;	/* subcódigo, 0 */
	  unsigned short checksum;
	  unsigned short id;	/* p.ex., o PID */
	  unsigned short sequence; /* isso ainda não é a carga */
	};

Isto são os 8 bytes do ICMP. A continuação disso vem a carga que pode
ser de zero bytes. Fazem falta pelo menos 8 bytes para poder gravar a
hora e medir o tempo de resposta. O tamanho da carga (incluindo o
zero) pode ser pedido usando a opção -s no ping, que não poderá
mostrar os rtt's com um valor menor de 8.

> Por vários motivos , geralmente surtos de congestão de rede ou
> roteamento, você não tem como garantir que os pacotes vão chegar
> na sequeência correta, e nem mesmo que todos irão chegar, o computador
> remoto pode inclusive estar muito atarefado e demorar pra responder,
> etc. Um dos computadores pode escolher reenviar um pacote que julgava
> perdido e ambos chegam ao outro ponto, usando o mesmo número sequencial,
> lembre-se que ICMP não tem nenhuma garantia ou correção de erros no
> protocolo.

Pelo menos o ping tradicional mantem um bitfield bastante grande, em
que cada bit representa um número sequencial. O índice do bit seria
computado como o número sequencial modulo o número de bits neste
buffer. Se não falha a minha memória, dá para representar os pings de
mais ou menos um quarto de hora, assumindo uma freqüência de 1 ping
por segundo. Quando manda um ping, coloca o bit correspondente em 0,
se chegar uma resposta (pong), testa, se este bit está em zero e
coloca ele em 1. Se já estava em 1, quer dizer que já recebeu um pong
com um número sequencial (módulo o número de bits no bitfield), o que
representaria uma duplicação.

> Repare, aliás, que naquele momento em que aconteceu o DUP o Round Trip
> Time deu um salto de quase 300% ... provavelmente aconteceu o que
> eu carinhosamente chamo de "soluço" no seu link ou na rede do seu
> provedor :)
> 
> Assim acontece o que o ping marca com o DUP! , o fato de ter recebido
> duas respostas para aquele pacote enviado. O motivo... varia muito.

O motivo de um atrasso pode variar, mas não há muitas situações em que
o programa ping mostra um DUP sem que seja uma duplicação.

Para acontecer esta situação é preciso este cenario: Assumimos que bl
for o número de bits que cabem no bitfield e que é mandado um ping por
segundo. No tempo T1 mandamos um ping com o número sequencial seq, mas
não há resposta. Continuamos mandando pings até o T2 = (T1 + bl),
incrementando os números sequenciais cada vez. No tempo T2 teriamos um
número sequencial de seq + bl. Neste momento, tanto (seq módula bl)
como ((seq + bl) módula bl) vão dar o mesmo índice de bit no
bitfield. Como o pong não chegou ainda para o ping em T1, este bit
ainda está em zero. Pouco mais tarde, chega o pong do ping T1 e este
bit é colocado em 1. E antes de chegar a (T1 + 2 * bl), chega o pong
do ping que mandamos em T2. Neste instânte, o bit correspondente é 1 e
o programa vai ter a impressão de uma duplicação (referente ao ping de
T2; o ping de T1 vai ser considerado como pacote perdido), mesmo que
em realidade o único que aconteceu é que o ping em T1 demorou muito
(muito mesmo) em responder.

Assim está claro, que não é um problema de um incremento transitório
do ttl de um ping (300%), senão que é preciso um atrasso de pelo menos
bl segundos (128 bytes, 1024 bits?). Este método naturalmente depende
da implementação e não do protocolo. Mas no caso do ping padrão que
vem com a debian é assim. No final, na maioria dos casos, os programas
tentam dar indicações significativos. E se o programa diz DUP,
normalmente será que é uma duplicação. No que diz respeito a DUP's que
não são duplicações, também precisariamos um número equivalente de
pacotes perdidos para que seja esta caso.

-- 
Christoph Simon
ciccio@kiosknet.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
.