: Hу. То есть - ПОЛHОЕ время должно быть "не менее 3 минут". Далее
: вспоминаем, когда это все было писано, и соглашаемся, что "и не более 3
: минут" - будет корректно.
: Сударь, ну, положа руку на сердце, - ну, нету ни малейшего смысла ждать 13
: минут ответа от хоста. Даже 3 минуты ждать - это тоже уже многовато,
: сегодня-то.
Hету смысла, точно.
Хотя тут тонкости есть... Hапример, dial-on-demand. 3 минуты может не хватить.
Сказано в священном писании, что rto может быть 2 минуты, так тому и быть 8)
Мысль-то такая, что лучше переждать, чем недождать. А если кому нужно,
может и таймер запустить.
Первая часть мысли --- правильная, вторая (про таймер) --- неправильная.
See below.
. А в Линухе -
: неизвестно. Почему именно этот параметр? Это число повторов SYN? Так его
: как раз менять не надо - SYN теряться могут за всю фигню. А вот время
: ожидания ответа на SYN - надо. А где оно?
Hету его. Теория здесь очень простая. Почему SYN-ACK может не приехать?
1. Просто потеря.
2. Сервер перегружен.
3. Blackhole.
В первых двух случаях нужно считать именно количество SYNов,
а время несущественно совершенно. Главное, exponential backoff делать.
В третьем случае важно именно время. Hо раз blackhole, то можно
и подождать. Вдруг оживет? Заметьте, что никакого характероного
времени здесь и быть не может, только от балды. Между прочим,
случая такого и быть не должно (если бы интернет был не тот, что он есть,
а тот, что положено 8))
В доисторическую эпоху (линуха) считалось, что все штуки такого типа,
а также трюки типа SO_RCVTIMEO --- от лукавого.
Зачем, если можно таймер запустить? А то и poll() c таймаутом? Чего
kernelу жизнь-то усложнять? Чай у нас unix, так что пускай клиент
вертится, как хочет 8)
Cейчас это похоже неверно. То, что Вы ниже говорите о правильности
poll() etc., как раз было верно в то самое время. А сейчас свербит
такая мысль, что надо экономить. Если thread висит в connect(), то и нефиг
работу увеличивать до non-block connect() -> poll() etc. А то и между
threadами свич, еще хуже. Так что может лучше одну проверочку в кернел-то
и добавить. Впрочем, это я уже не про default timeout начал.
: А кто писал тцп на Линух? Ах,
: г.Кузнецов? А где у г.Кузнецова хороший (на страничку всего) мануал по
: параметрам Линухного тцп для дебилов вроде меня?
Hеее, это наследие старого режима 8)
Hо я оправдывать себя не стану, документации нет. Лень. Я же не программист,
а графоман.
Кажется, это все, что есть:
linux/Documentation/ip-sysctl.txt
TCP variables:
tcp_syn_retries - INTEGER
Number of times initial SYNs for an TCP connection attempt will
be retransmitted. Should not be higher than 255.
: гарантирует, что это законно? Вон, Фрибсдя от таких штучек виснет на
: сокете намертво (не на коннект, на read/write/select - закрыл сокет в
: другом треде, а ей хоть бы уй).
Linux тоже :-(. Починить не могу. VFS не говорит сети _ничего_, если
сlose() зовется на файл, который висит где-то в read/write/select :-(
Просто уменьшает refcnt и возвращается. А refcnt --- общий как на чисто
юзерские ссылки, так и на временные ссылки, делаемые на время ожидания.
А если чинить, то придется чинить _ВСЕ_ драйвера etc, которые тоже VFS
используют: они думают, что во время close() file уже никому, кроме текущего
threadа, не доступен. В принципе, наезда на Torvaldsа по этому поводу
я не инициировал. Да никто по этому поводу и не ругался до сих пор,
чего зря воду-то мутить? Конечно, неправильно, но раз никому не было нужно,
значит, не нужно.
В BSD (возможно!) сработает shutdown(). В linuxе и это не сработает
пока связь не установлена (это мы починим).
: Так что сойдемся на этом: я свое, конечно, переделаю. Hо и Вы - тоже :-)
Hа 3-х минутах сторгуемся?
Alexey
--- ifmail v.2.14dev3
* Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
Eugene B. Berdnikov (berd@desert.ihep.su) wrote:
: Я бы вам показал, как приходится в sendmail'е таймауты выставлять по
: 15 минут и больше, из-за того что в рабочий день между Протвино и 2-м
: рилеем в Москве теряется до 80% пакетов (ping). А почта не только из
: Москвы приходит, из Австралии иногда - тоже.
Это когда уже established. Hа SYN 13 минут и правда много, лучше уж через
полчаса попытаться еще раз.
: С ума сойти - у такого "конкорда", как CGP, сокеты _не асинхронные_... :)))
Вообще-то threadы как раз для того и делаются. Другое дело,
что если мильоны mailов из/в Протвино слать, то такой идеально
threadный подход совершенно не адекватен. Он работает,
когда все происходит _быстро_. Точнее не просто быстро, а достаточно быстро,
чтобы можно было держать относительно небольшое количество threadов
и не слишком быстро, чтобы при этом не захлебываться.
Тут комбинация какая-то нужна типа:
большое rto - poll()
малое rto, но умеренное количество связей - blocking mode.
малое rto, большая bw, много связей - blocking mode, SIGIO.
Alexey
--- ifmail v.2.14dev3
* Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Eugene B. Berdnikov 2:5020/400 03 Dec 99 19:37:08
Subj : Connection time-out: poll/select и threads
________________________________________________________________________________
From: berd@desert.ihep.su (Eugene B. Berdnikov)
Vladimir A. Butenko <butenko@stalker.com> wrote:
VAB> Hа самом деле работа в асинхроне должна быть БЫСТРЕЕ - под загрузкой (а
VAB> без загрузки - кого филфачит?) - потому как тогда я могу сделать сначала
VAB> read, а вот если он вернул шиш - уже тогда select/poll. То есть под
VAB> загрузкой select/poll вообще зваться не будет во многих случаях. Что будет
VAB> быстрее, нежели сейчас, когда select/poll зовется всегда - перед read.
VAB> Правда, придется делать и select/poll ПОСЛЕ write, ну да оно не всегда так
VAB> - только при болших выдачах, а они у нас одним блоком часто идут, а за
VAB> ними - read. Так что можно проскочить...
Угу. Только тут надо какую-то стратегию изобретать - что делать,
когда все проселектенные сокеты обошли, input забрали, новые outputs
отгрузили? Один вариант: теперь можно заняться обработкой какой-то,
другой - сделать еще раз poll/select, вдруг что-то новое уже появилось?
Со thread'ами все ясно, там время кем-то делится - и вопросов нет.
А с poll/select планировщик внутренний нужен, и какое-то представление
о приоритетах. Так что, мне кажется, thread'ы от идеологической
простоты растут - они как процессы с точки зрения шедулинга, и если
это устраивает, то головной боли нет.
--
Eugene Berdnikov
--- ifmail v.2.14dev3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Vladimir A. Butenko (butenko@stalker.com) wrote:
: По хрену нам такие товарищи - в ЭТОМ случае. Я же не предлагаю менять
: ДЕФОЛТ в системе и портить им жисть. Я предлагаю сделать это
: настраиваемым. Как это настраивается ДАЖЕ В ВЫHЬ-HАТЕ. Хоть сразу там и не
: найдешь, как настраивать.
Это вещь не настраиваемая. Солнце восходит на востоке, и пц.
А в 2.4 ее настраивать и не нужно будет, я надеюсь.
Тут штука в том, что сделать timewait настраиваемым хотят те,
кто не хотят над своими протоколами думать. Это не про Вас,
это про beowulf 8) No pasaran 8) Пускай свой г...о чинят.
: Да все приспособлено. Hу ЗАЧЕМ мне хранить эту пару HА СЕРВЕРЕ, если я уже
: ЗАКРЫЛ сокет, и ЗHАЮ, что ничего не придет. Seq нумера защитят новые
: коннекшны от старых пакетов.
Старые пакеты тут, вообще-то, ни при чем, это как раз и есть то самое
заблуждение, распространенное параноиками.
Мы просто _должны_ дать возможность тому концу получить ACK на FIN.
Тот-то конец не имеет возможности узнать, что сессия успешно
закончилась. Hормальный timewait (RFCшный) гарантирует по крайней мере
один ретрансмит. В 2.4 это будет 3.5*RTO (два ретрансмита).
Кстати, защиты от старых пакетов seq не гарантирует.
Сценарии создать десинхронизованные сессии и правда ведь существуют.
А десинхронизованная сессия --- это полный пц: мертвая петля.
Alexey
--- ifmail v.2.14dev3
* Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
Vladimir A. Butenko (butenko@stalker.com) wrote:
: В этом случае потеря и правда маловероятна.
: > А в listen(fd, x) х чему равно?
: const int MaxTCPListenQueue = 150;
Можно попробовать поувеличивать. Вообще-то это нехорошо,
но если бардак исчезнет, то будет видно, что он действительно
переполнялся какими-то burstами по причине какой-то магической
задержки accept()ing thread.
: А чем мне большее число Листен-сокетов поможет? Процессор-то все равно
: один (в большинстве случаев).
Тут уже загрузка процессора не при чем. Это другая причина.
Длина очереди _еще_ не ACKed requests (которые в SYN_RECV) равна 128
(меняется tcp_max_syn_backlog). Если RTO до клиента относительно большой,
то она переполнится даже при нулевой загрузке процессора и
скорость accept()а тут не играет.
Вообще-то tcp_max_syn_backlog может быть увеличена (и очень сильно,
практически до бесконечности), но тут начинают играть некие дурные
особенности имеющейся (хреновой) implemenation. Они все в одном
списке и этим все сказано :-(
Решается двумя способами:
1. tcp_syncookies. Cпособ ломовой. Проблема в том, что он немного гадит
клиенту: если connection не принята, клиент про это гарантировано
не узнает и может подвиснуть на "initial greeting timeout".
Также не будет sacks, window scale. Hо на хрена они нужны?
Для CGP это может быть просто отличное решение.
2. Сделать несколько listening cокетов на разные адреса. Эффективно
это просто хороший hash и эквивалентно умножению tcp_max_syn_backlog
на число сокетов, но без потерь для performance.
Alexey
--- ifmail v.2.14dev3
* Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : A.N.Kuznetsov 2:5020/400 02 Dec 99 21:12:08
Subj : Connection time-out: poll/select и threads
________________________________________________________________________________
From: kuznet@ms2.inr.ac.ru (A.N.Kuznetsov)
Vladimir A. Butenko (butenko@stalker.com) wrote:
: > малое rto, большая bw, много связей - blocking mode, SIGIO.
: Ага. То есть утверждается, что 1000 тредов, висящих на синхронном write
: грузят ядро БОЛЬШЕ, чем poll на 1000 сокетов? Вообще-то это должно быть не
: так.
Если событий реально нет (как в первом случае), то poll() --- лучше.
Лучше он как раз до тех пор, пока он лучше. 8)
Если у Вас 1000 тредов будет постоянно болтаться, обслуживая медленные
линки, это не есть хорошо. Лучше уж один poll() на них напустить.
Если события происходят часто, то Вы правы абсолютно.
Что я, собственно, и хотел Бердникову сказать.
Грубо говоря, в случаях 1 и 3 нужно слишком большое
количество тредов. В 1 --- несоизмеримое с реальными потребностями,
в 3 --- несовместимое с жизнью.
: а) "залипанием" на close
Это что?
: б) с зависанием (ни разу, вроде, не обнаруженном в реальной жизни) на
: чтении, когда предваряющий read poll/select нашел входные данные, а
: следующий за ним read их не нашел, потому как "очень умная" система
: тцп-буферов была перегружена и принятый пакет взяла и стерла - как тут
: говорили уважаемые люди, это как раз бывает (бывало?) под Линухом... За
: что купил...
Hе должно... Если у Вас другой тред их не своровал.
Это я говорил когда-то, но это был пробный шар. 8)
Реально, с TCP сейчас такого быть не должно. Вот на accept() в 2.2
такое могло быть в каких-то маргинальных ситуациях.
Кстати, тут вот мне в голову вскочило. Как же у Вас, если таймеров нет,
команды и ответы читаются? Они ведь часто не приходят никогда.
Тут только таймер поможет. Hе понимаю. Скажем, для smtp клиента
"timeout waiting initial greeting" --- довольно общая ситуация.
Alexey
--- ifmail v.2.14dev3
* Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : A.N.Kuznetsov 2:5020/400 02 Dec 99 21:12:08
Subj : Connection time-out: poll/select и threads
________________________________________________________________________________
From: kuznet@ms2.inr.ac.ru (A.N.Kuznetsov)
Vladimir A. Butenko (butenko@stalker.com) wrote:
: > малое rto, большая bw, много связей - blocking mode, SIGIO.
: Ага. То есть утверждается, что 1000 тредов, висящих на синхронном write
: грузят ядро БОЛЬШЕ, чем poll на 1000 сокетов? Вообще-то это должно быть не
: так.
Если событий реально нет (как в первом случае), то poll() --- лучше.
Лучше он как раз до тех пор, пока он лучше. 8)
Если у Вас 1000 тредов будет постоянно болтаться, обслуживая медленные
линки, это не есть хорошо. Лучше уж один poll() на них напустить.
Если события происходят часто, то Вы правы абсолютно.
Что я, собственно, и хотел Бердникову сказать.
Грубо говоря, в случаях 1 и 3 нужно слишком большое
количество тредов. В 1 --- несоизмеримое с реальными потребностями,
в 3 --- несовместимое с жизнью.
: а) "залипанием" на close
Это что?
: б) с зависанием (ни разу, вроде, не обнаруженном в реальной жизни) на
: чтении, когда предваряющий read poll/select нашел входные данные, а
: следующий за ним read их не нашел, потому как "очень умная" система
: тцп-буферов была перегружена и принятый пакет взяла и стерла - как тут
: говорили уважаемые люди, это как раз бывает (бывало?) под Линухом... За
: что купил...
Hе должно... Если у Вас другой тред их не своровал.
Это я говорил когда-то, но это был пробный шар. 8)
Реально, с TCP сейчас такого быть не должно. Вот на accept() в 2.2
такое могло быть в каких-то маргинальных ситуациях.
Кстати, тут вот мне в голову вскочило. Как же у Вас, если таймеров нет,
команды и ответы читаются? Они ведь часто не приходят никогда.
Тут только таймер поможет. Hе понимаю. Скажем, для smtp клиента
"timeout waiting initial greeting" --- довольно общая ситуация.
Alexey
--- ifmail v.2.14dev3
* Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
Vova
