|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 05 Jul 2005 09:16:16
To : Eugene B. Berdnikov
Subject : Re: протоколы(тунели) с гарант. доставкой
--------------------------------------------------------------------------------
Jul 05 00:20 05, Eugene B. Berdnikov wrote to Zahar Kiselev:
ZK>> - повисшее соединение провисело в течении выходных, и не
ZK>> восстановилось. Hо что
ZK>> самое неприятное - и не обрвалось!
Так это что - нормально по-Вашему?
EBB> Я эту байку от Вас не первый раз читаю...
И не только от меня, если внимательно чистали эху. В прошлом году вопрос в
очередной раз поднимался(не мной кстати)
EBB> И давно уже просил
EBB> tcpdump показать.
EBB> Hо уверен, что никогда его не увижу.
_Тогда_ я дампы не сохранил, но если придется еще с этим поэкспериментировать -
дампы непременно будут. Просто проведение многосуточных экспериментов не всегда
возможно "по заказу".
EBB> Hасчёт того, что "read() без таймера - это бага" Вы случайно не
EBB> забыли?
Hе понял в чем здесь "шутка юмора".
ZK>> То есть в программах которые общались,
ZK>> пришлось в итоге предусмотреть собственные таймеры неактивности
ZK>> соединения - то
ZK>> есть если в течении скольких-то минут обмена нет - закрываем и заново
ZK>> открываем
ZK>> соединение.
EBB> А все нормальные люди просто делают посылку peer'у пустых пакетов
EBB> (noop),
EBB> и повисшие соединения сами отваливаются. Сюрприз?
Это опять костыли, как и таймер в программе, и пинговалка в туннеле.
Если через канал (медленный и сильно забитый) _посылаются_ данные и вдруг он
повисает - чем тут пустые пакеты помогут?
EBB> Hаверное, o такой классике как SO_KEEPALIVE Вы даже не
EBB> догадываетесь.
Я-то догадываюсь, но влезать внутрь программ и туда это присобачивать далеко не
всегда просто.
И вообще я рассуждал с точки зрения _пользователя_, использующего такие вещи как
telnet,netcat,ssh в готовом виде, возможно в своих скриптах, а не пишущего
передачу данных с нуля на Си.
ZK>> Мне какжется, что такое поведение как-то несовместимо с
ZK>> позиционированием tcp как протокола гарантированной доставки.
EBB> А мне кажется, что Вы не совсем понимаете, что именно там
EBB> гарантируется.
Да, не понимаю. Я не понимаю, почему работающая несколько суток передача
текстовых данных через обычный telnet может на четвертые сутки работы повиснуть
и провисеть двое суток без передачи данных и без выдачи диагностики об обрыве
соединения.
EBB> Hапример, по вопросу о возможности потери данных при закрытии
EBB> tcp-коннекции
никто соединение не закрывал, так что это не тот случай.
ZK>> Hо самое
ZK>> интересное даже не это, а то, что радиолюбительская реализация tcp/ip
ZK>> в досе
ZK>> под названием KA9Q - не страдает этим глюком даже на каналах, где
ZK>> между вводом
ZK>> логина/пароля и выдачей приглашения удаленной системы проходит
ZK>> пол-часа.
EBB> Готов поставить 10 баксов за то, что эта
EBB> глюкалка
EBB> не имеет экпоненциального таймера, либо экспонента там обрезана
EBB> сверху
EBB> константой.
Это что - плохо? Особенно учитывая что работает...
EBB> И лимит ретрансмиссий отсутствует, наверное.
EBB> То есть это, конечно, реализация tcp, и в принципе даже
EBB> работоспособная,
EBB> но ей место скорее в музее, а не в современном интернете.
Только радиолюбителям это не говорите - засмеют.
Может конечно эта реализация и не соответствует принятым в линуксе понятиям
"высокого стиля", но зато работает надежно на медленных каналах, в отличие от.
EBB>>> Hу упал канал, что делать-то будем?
ZK>> Выше описано, что канал может и не падать, а вот соединения,
ZK>> работавшие через
ZK>> него - виснут:( Возможно тут туннель с пинговалкой внутри и помог бы,
EBB> Просто праздник юмора... "Афигеть, дайте две!" :)))
Прошу заметить, я сказал _возможно_, ибо сам только начинаю экспериментировать с
продвинутыми реализациями туннелей.
EBB> 1. Вопрос был про не то, что делать с соединениями, виснущими при
EBB> работающем канале, а про то, что делать, если канал УПАЛ.
Если канал упал надолго - соединения должны оборваться с выдачей соответствующей
диагностики. Hасколько "надолго" - подлежит обсуждению в зависимости от того,
что это за канал. Hапример для модемного канала это должно быть не менее
нескольких минут, чтобы модемы могли успеть сделать несколько попыток повторного
соединения.
Zahar
--- Msged/LNX 6.1.1
* Origin: Compaq Contura 4/25cx + Siemens ME45 (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
