Utrzymanie sesji TCP/IP

[Szarry]

Na temacie się nie znam jakoś specialnie, ale:
@Nikow, czy mógłbyś uchylić rąbka tajemnicy i napisać coś więcej o tym co robisz? Brzmi ciekawie.

[Nikow]

Szarry: Wybacz, niechciałbym.

elceef: Sprawdziłem stan łącza za pomocą 100 Echo-Requestów, około 40 Echo-Reply nie wróciło... Czasami to się zwiększa aż do 60% gubionych pakietów (gdy słucham muzyki ). Czy może być to przyczyną zrywania sesji TCP/IP?

[elceef]

ICMP echo-request ma za zadanie określić czy na łączach pomiędzy Twoim komputerem i hostem zdalnym występują problemy (w trzech pierwszych warstwach modelu OSI). TCP stosuje mechanizm retransmisji, aby radzić sobie w sytuacjach, gdy pakiety zostają "zagubione".

[Nikow]

Tak wiem, ale przy jakim procencie gubionych pakietów, retransmisja zawodzi?

[elceef]

Przy 100% ;-)
Zagubione pakiety nie są powodem do przerwania sesji TCP (przynajmniej nie wdziałem takiej implementacji). Przyczyną jest aplikacja (pomijam tutaj TCP keep-alive), która może zrywać połączenie jeśli uzna, że nowe dane nie nadchodzą i następuje timeout, w efekcie koniec połączenia.

Zrób prosty test. Utwórz długotrwałe połączenie TCP, na przykład sesję SSH. Następnie celowo zepsuj fizyczne połącznie, w taki sposób, aby system nie zauważył zmiany na interfejsie sieciowym. Za pomocą sniffera będziesz mógł obserwować jak system realizuje mechanizm retransmisji. Następnie po minucie napraw połączenie fizyczne i sprawdź co się stanie z sesją SSH. Nie zostanie przerwana i będziesz mógł ją kontynuować.
Dla pewności wyłącz też TCP keep-alive, ponieważ jeśli dobrze pamiętam, timer w Twoim systemie to tylko 120 sekund.

[Nikow]

Witam!
Dziękuje za odpowiedzi, wątek uważam za zakończony i proszę o zamknięcie go przez moderatorów.

Podsumowanie: Jałowa sesja TCP/IP nie zużywa łącza jeśli nie ma włączonego mechanizmu TCP Keep-Alive, który standardowo w systemach na jajku Linux 2.6.24-19 wynosi 7200 sekund, co jest równoznaczne 2 godzinom. Sesja SSH została utrzymana, lecz po wznowieniu łącza nie można było nic wysłać i odebrać żadnych danych. Dodatkowo zauważyłem że retransmisja zaczyna zawodzić po około 60% gubionych pakietów.

[elceef]

Nie zawodzi mechanizm retransmisji. Problem występuje na niższych warstwach modelu OSI. W zależności od implementacji pakiety będą wysyłane ponownie w określonych odstępach czasu (RFC nie opisuje dokładnie w jaki sposób pakiety powinny być retransmitowane).
W moim przypadku sesję SSH można było kontynuować. Poczekaj trochę dłużej, ewentualnie wyślij kilka znaków na konsolę zdalną.