Re: Niespodziewany koniec projektu AutoPatcher

Autor: Radosław Sokół <rsokol_at_magsoft.com.pl>
Data: Mon 03 Sep 2007 - 10:10:27 MET DST
Message-ID: <2007090308103900@grush.one.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed

Lawrens Hammond pisze:
> Przeszkadza, bo cholernie zajmuje czas, gdy takich badań trzeba zrobić
> ileś-tam. Przy 1-2 ujdzie, powyżej jest to cholernie upierdliwe.

Ale tego nie ominiesz bo administrator routera wyciął ICMP.

>> Po pingach *nic* nigdy nie widać. Jakiekolwiek analizy
>
> Ee... serio?

Serio.

Ruch ICMP bardzo często jest traktowany zupełnie inaczej
niż TCP czy nawet UDP, bo w przypadku WANu ma on znikome
znaczenie, a szczególnie takie bajery jak ICMP ECHO, wyko-
rzystywane przez ping/tracert w Windows. Router zawsze
będzie dawał większy priorytet normalnemu ruchowi; w
sytuacji skrajnej pakiety ICMP mogą być w ogóle *likwidowane*,
jeżeli router jest na granicy przepustowości łącz. Efekt:
odpowiedzi na pakiety ICMP będą bardzo powolne lub wręcz
ich nie będzie, a mimo to realny transfer będzie *szybki*.

I w drugą stronę: ponieważ wielu początkujących użytkowników
uważa pingi za wyrocznię, niektórzy administratorzy (szcze-
gólnie sieci osiedlowych) wydzielają specjalne pasmo na
pingi, żeby uciszyć niekumatych krzykaczy którzy narzekają
"że nie mogą grać w Quake bo pingi są za długie". Sieć może
wtedy działać nawet koszmarnie, jak jeden z drugim puszczą
P2P bez ograniczeń, ale pingi będą króciutkie...

> Ciekawe... bo mnie czasem potrafią jednak coś ujawnić. Tylko oczywiście,

*Coś* ujawnią, ale sensowne wnioski na ich podstawie wyciągać
jest bardzo trudno.

ICMP ma jak największy sens w LANie, gdzie działa bardzo
skutecznie jako narzędzie diagnostyczne nie podlegające
ograniczeniom nakładanym przez routery.

> Jednak przyglądając się czasom odpowiedzi, nawet laik powie, gdzie jest
> jakiś problem z ruchem. Trzeba, jak pisałem, między wierszami pewne
> rzeczy przeczytać.

Nie problem z ruchem ale *kształtowanie* ruchu. Co wynika
z tego, co napisałem na początku postu.

Co najwyżej z *braku* odpowiedzi na ICMP można czasem wysnuć
wniosek, że łącze całkiem padło, ale tylko jeśli wiemy, że
kiedyś dany router/serwer odpowiadał na pingi i nic się nie
zmieniło w jego konfiguracji (bo wycięcie ICMP to zazwyczaj
jeden wpis w konfiguracji routera).

> Oczywiście, że samo działanie po ICMP nie wszystko powie. Zależy to
> przecież też od tego, co przekażą i jak serwery po drodze, jak gdzieś
> operator zatka ruch ICMP, to wiadomo, jak się ma to dalej.

Ale wiesz, że równie dobrze pakiety mogą iść różnymi trasami
w każdą ze stron (tracert pokaże tylko w jedną!), albo wręcz
ICMP może iść innymi łączami, niż TCP czy UDP?

-- 
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Administrator, Politechnika Śląska    |
\................... Microsoft MVP ......................../
Received on Mon Sep 3 10:20:06 2007

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Mon 03 Sep 2007 - 10:42:03 MET DST