[Comm] Re: Как retrain приводит к "сговору" NTP, DNS и прочих серверов
Oleg N. Kayunov
=?iso-8859-1?q?okayunov_=CE=C1_mtu-net=2Eru?=
Ср Окт 23 07:23:40 MSD 2002
Henri Bourbon wrote:
>On 20 Oct 2002 3:53, Oleg N. Kayunov wrote:
>
>>Заметил странную вещь. Для синхронизации использую ntpdate (свой
>>ntp-сервер отключаю) при dial-up-е. В соотв. скрипте у меня прописано
>>что-то около двух десятков ntp-серверов (начиная с Московских,
>>ест-нно). Если не удаётся синхронизация с одним скрипт идёт к
>>следующему и т.д. В большинстве случаев синхронизация удаётся с
>>первого же сервера. И ладно.
>>
>
>>Странность в следующем - если синхронизация таки не удаётся с первым
>>же сервером (какой-то из zenon-ов), то она, в подавляющем большинстве
>>случаев, не удаётся и со всеми остальными.
>>
>
>Олег, у меня была догадка, в чем ваша проблема, и когда вы пожаловались
>*еще и на DNS*, то эта догадка стала больше похожей на правду. Все дело
>в отстойности модемного соединения и потере пакетов во время ретрейнов.
>Если при отсылке UDP-пакета (а NTP, как и DNS, использует в качестве
>протокола транспортного уровня именно UDP) происходит ретрейн (наиболее
>вероятная и неприятная вещь), либо пакет пропадет по каким угодно другим
>причинам, то никто не будет жаловаться на пропажу пакета либо передавать
>его повторно. ntpdate просто скажет "no server suitable for
>synchronization found", а ping скажет "unknown host".
>
Ваша гипотеза представляется мне вполне реалистичной и впервый
момент показалось, что она описывает и мой случай. Но потом я понял, что
вряд-ли это относится конкретно к моему случаю.
Причина в том, что у меня постоянно (на всё время коннекта) включён
звук модема. А ретрейн, ИМХО, на слух резко отличается от того
стандартного шипения, которое характерно для коннекта на
высокоскоростных протоколах.. И мне (ИМХО-же) доводилось слышать эту
процедуру - когда кто-то подымал во время коннекта трубку на
параллельном телефоне, так что я могу опознать на слух наличие сбоя в
соединении.
Так вот, во время описанных мною сбоев такого рода сбоев я не замечал.
Похоже причина (в данном конкретном случае) в чём-то другом.
>
>
>Ни протокол NTP, ни конкретные NTP-серверы, ни какие-то другие проблемы
>на серверной стороне тут ни при чем.
>
>Полагаю, при наличии минимальной изобретательности и желания вы легко
>можете проверить (не)правильность моей версии происходящего.
>
Ретропроверка, похоже, не подтверждает эту версию.
Но я буду обращать на это внимание далее.
--
== В действительности все обстоит совершенно иначе чем на самом деле. ==
BR, Oleg N. Kayunov.
Подробная информация о списке рассылки community