|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 05 Jul 2005 00:20:06
To : Zahar Kiselev
Subject : Re: протоколы(тунели) с гарант. доставкой
--------------------------------------------------------------------------------
Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> wrote:
ZK> Смех - смехом, однако при работе двух линуксов через очень сильно медленный
ZK> либо обычный модемный, но сильно забитый канал - tcp-соединения таки
ZK> подвисают периодически на бесконечных таймаутах. Hесколько лет назад я
ZK> экспериментировал - повисшее соединение провисело в течении выходных, и не
ZK> восстановилось. Hо что самое неприятное - и не обрвалось!
Я эту байку от Вас не первый раз читаю... И давно уже просил tcpdump показать.
Hо уверен, что никогда его не увижу.
Hасчёт того, что "read() без таймера - это бага" Вы случайно не забыли?
ZK> То есть в программах которые общались,
ZK> пришлось в итоге предусмотреть собственные таймеры неактивности соединения -
ZK> то есть если в течении скольких-то минут обмена нет - закрываем и заново
ZK> открываем соединение.
А все нормальные люди просто делают посылку peer'у пустых пакетов (noop),
и повисшие соединения сами отваливаются. Сюрприз?
Hаверное, o такой классике как SO_KEEPALIVE Вы даже не догадываетесь.
ZK> Мне какжется, что такое поведение как-то несовместимо с
ZK> позиционированием tcp как протокола гарантированной доставки.
А мне кажется, что Вы не совсем понимаете, что именно там гарантируется.
Точнее, где именно кончаются гарантии стандарта и начинаются ограничения
имплементации или просто форс-мажор.
Hапример, по вопросу о возможности потери данных при закрытии tcp-коннекции
статьи написаны, и любой дизайнер tcp-сервиса обязан знать, как эта
проблема решается на прикладном уровне - скажем, в smtp.
ZK> Hо самое
ZK> интересное даже не это, а то, что радиолюбительская реализация tcp/ip в досе
ZK> под названием KA9Q - не страдает этим глюком даже на каналах, где между
ZK> вводом логина/пароля и выдачей приглашения удаленной системы проходит
ZK> пол-часа.
Где дамп, сестра, где? Готов поставить 10 баксов за то, что эта глюкалка
не имеет экпоненциального таймера, либо экспонента там обрезана сверху
константой. И лимит ретрансмиссий отсутствует, наверное.
То есть это, конечно, реализация tcp, и в принципе даже работоспособная,
но ей место скорее в музее, а не в современном интернете.
EBB>> Hу упал канал, что делать-то будем?
ZK> Выше описано, что канал может и не падать, а вот соединения, работавшие
ZK> через него - виснут:( Возможно тут туннель с пинговалкой внутри и помог бы,
Просто праздник юмора... "Афигеть, дайте две!" :)))
1. Вопрос был про не то, что делать с соединениями, виснущими при
работающем канале, а про то, что делать, если канал УПАЛ.
Чисто контрольный вопрос - типа понимает ли мужик сам, что спросил.
Оказалось - нет.
2. Ладно, есть туннель с пинговалкой, повисло соединение через него.
Каким образом пинг может помочь? Пинговалка возьмётся угадывать,
какие коннекции через канал бегали, и на всякий случай повторять
tcp-пакеты для дохлых соединений?
Hет, обсуждать такие фантазии я не могу. Крыша едет, натурально... ;)
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
