On Monday 13 September 2004 12:22, F�lix Hauri wrote: > On Mon, Sep 13, 2004 at 11:44:43AM +0200, Magnus wrote: > > je ne pense pas que ce soit li� � leur impl�mentation de > > TCP/IP. En fait, lors de la d�connexion, M$ "tue" > > l'interface. Linux ne le fait pas nativemement; si tu > > installes un prog du type de ifplugd avec un timeout de 2 > > sec, tu verras le m�me comportement que M$. > > M$ effectue l'�quivalent de # ifconfig <interface> down. > > timeout !? > Ce n'est pas tr�s ``TCP''!?
TCP a un timeout de r�ception d'un ACK pour un paquet. Apr�s �a, il consid�re que le paquet est perdu et le r��met. Sauf erreur il a aussi un nombre d'essais avant de signaler une erreur � l'application. Je ne suis pas du tout expert, mais je pense que ce timeout et nombre d'essais max peut changer en fonction de l'impl�mentation (ou du param�trage ?) de TCP. Il serait alors normal que si aucune donn�e n'est transmise, la coupure ne soit pas d�tect�e (pas d'erreur de transmission). Et peut-�tre que Linux n'a ici pas de nombre d'essais maximum (donc jamais d'erreur signal�e)... > > Lors de la reconnexion, il recr�e l'interface compl�tement > > (si DHCP, il refait la requ�te, il me semble.) > > Dans tous les cas, je ne pense pas que cela aille si loin, > car si je tire le c�ble dix secondes mais que je ne tape > rien pendant ces dix secondes, puis que je rebranche le > c�ble AVANT de taper qqch, alors tout va bien. > > Il me semble que si l'interface IP �tait kill�, alors telnet > le serait imm�diatement aussi... Ca d�pend de la gestion. Si les couches r�seau sont bien s�par�es, un arr�t momentan� du r�seau ne devrait pas d�ranger tcp/ip. Une fois reconnect�, avec la m�me IP, les paquets avec le m�me tuple (ip et port des deux bouts plus le protocole) seront transmits au m�me socket (s'il existe toujours) et TCP n'y aura vu que du feu. Christian _______________________________________________ gull mailing list [EMAIL PROTECTED] http://lists.alphanet.ch/mailman/listinfo/gull
