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.
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.
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?
http://nikowek.blogspot.com/
Zbrojne Ramię Pingwina!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++:++ a--- C+++ UL+++ P L+++ E--- W++ N++ o K- w--
O M- V- PS PE Y PGP++ t+ 5 X+ R tv- b++ DI- D-
G+ e- h! r% y?
------END GEEK CODE BLOCK------
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".
Tak wiem, ale przy jakim procencie gubionych pakietów, retransmisja zawodzi?
http://nikowek.blogspot.com/
Zbrojne Ramię Pingwina!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++:++ a--- C+++ UL+++ P L+++ E--- W++ N++ o K- w--
O M- V- PS PE Y PGP++ t+ 5 X+ R tv- b++ DI- D-
G+ e- h! r% y?
------END GEEK CODE BLOCK------
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.
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.
http://nikowek.blogspot.com/
Zbrojne Ramię Pingwina!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++:++ a--- C+++ UL+++ P L+++ E--- W++ N++ o K- w--
O M- V- PS PE Y PGP++ t+ 5 X+ R tv- b++ DI- D-
G+ e- h! r% y?
------END GEEK CODE BLOCK------
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ą.