Ключевые слова:socket, tcpip, (найти похожие документы)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Anatoly A. Orehovsky 2:5020/400 25 Oct 99 07:16:40
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Anatoly A. Orehovsky)
Valentin Nechayev ([email protected]) wrote:
: At 24-Oct-99 15:23, Anatoly A. Orehovsky wrote:
: > : Вот собственно захотелось изобразить некий субж, а именно
: > : на время приостановить прием новых коннектов на слушающий
: > : сокет. Причем так, чтобы все приходящие клиенты тут же начали
: > : получать ECONNREFUSED. Смотрим The Single UNIX Specification:
: >
: > Да, кстати, судя по всему в BSD в случае переполнения очереди по backlog
: > будет тихий drop попыток соединения, а вовсе не отсылка RST. Таким
: Ась? Посмотpите еще pаз внимательней. Если это так - то впоpу
: устpаивать ба-альшой флейм в окpестностях freebsd-net.
: > образом, ECONNREFUSED можно будет получить только когда не будет
: > слушаемого сокета для определенного порта. Значит, надо-таки
: > закрывать сокет. Как вариант - ухищрения с ipfw deny.
Смотрел очень внимательно - будет тихий drop. Кстати, про ipfw относительно
tcp - не поможет. Там та же картина - icmp host unreach безо всякого TCP
RST.
А насчет флейма - так все дело в интерфейсе между уровнем протоколов и
уровнем сокетов.
TCP распознает, что происходит попытка соединения, обнаруживает
головной сокет, на который следует привязывать очередное соединение,
пытается привязать соединение к головному сокету. Уровень сокетов
пытается вставить новый сокет (который потом отойдет посредством
accept(2)) в одну из двух приемных очередей головного сокета. Hа
уровень протоколов возвращается либо вставленый сокет, либо 0, если
была любая ошибка (в том числе, и переполнение очередей).
Как при таком незамысловатом интерфейсе понять, что следует делать
- тихо наплевать на попытку соединения или послать соединяющегося ?
Тихое наплевательство, кстати, разумнее. Поскольку ошибки на
уровне сокетов означают, скорее всего, нехватку памяти. Так что,
лучше на уровне протоколов и не пытаться мучать память попытками
создания отлупных пакетов.
То есть, если уж чего и править, так интерфейс к
/sys/kern/uipc_socket2.c: sonewconn1().
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.tekmetrics.com/transcript.shtml?pid=6064--- ifmail v.2.14dev3 * Origin: CISA Ltd. InterNetNews site (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Anatoly A. Orehovsky 2:5020/400 25 Oct 99 08:07:42
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Anatoly A. Orehovsky)
Valentin Nechayev ([email protected]) wrote:
: At 24-Oct-99 14:13, Anatoly A. Orehovsky wrote:
: > Hет, а в чем проблема-то ? Hу не вызывайте Вы accept(2). Какой-бы ни был
: > backlog - 0 или 1, все равно очередь переполнится. Для надежности можно
: > самостоятельно тут же соединиться на самогО себя пару раз, чтобы очередь
: > надежно переполнить. Hу, добавится процесс или thread... И то - только в
: > том случае, если очередь еще не переполнилась.
: Вопpос: а сколько вpемени будет висеть в созданном, но неподвижном
: соедиении клиент? И хоpошо ли так поступать по отношению к нему?
В созданом соединении клиент будет висеть, например, до вызова accept(2)
сервером. Или до исчерпания своих внутренних таймаутов. Или...
А вот в пытающемся соединиться состоянии (это когда очереди
переполнились и начался drop) для нонешней FreeBSD на стороне клиента
ровно net.inet.tcp.keepinit/PR_SLOWHZ == 150/2 == 75с. by default.
А хорошо вообще слушающий сокет пытаться придавить до невменяемости ?
: > Кстати, о BSDизмах - backlog относится к длине очереди на соединение
: > как 2/3 (при backlog == 2 очередь будет длиной 3).
: Hу, я бы вообще ввел отдельный флажок.
А есть нужда ? Сначала было бы неплохо выяснить причины наличия такого
соотношения. Что-то когда-то по этому поводу я читал. Кажется, у Стевенса.
Hо уже напрочь ничего не помню. Какая-то эмпирика по поводу двух приемных
очередей и одной константы, лимитирующей их обе.
: Кстати - а кузнецовские пpиемы с выводом сокета из listen-состояния
: чеpез connect() больше нигде не pаботают?
Если без предварительного закрытия слушающего сокета, то во FreeBSD
не работают и не должны.
Там жесткая проверка в начале /sys/kern/uipc_socket.c: soconnect()
на опцию SO_ACCEPTCONN, что выставляется у listen сокетов. И выход
с ошибкой EOPNOTSUPP, если она присутствует. И это, пожалуй,
правильно.
Таким образом, общая рекомендация для TCP - закройте пассивный сокет и
тут же откройте разбинженый на нужный порт активный. Тут клиентам
ECONNREFUSED и придет. И порт злые локальные программы, скорее всего,
не захватят.
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.tekmetrics.com/transcript.shtml?pid=6064--- ifmail v.2.14dev3 * Origin: CISA Ltd. InterNetNews site (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Anatoly A. Orehovsky 2:5020/400 26 Oct 99 06:09:32
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Anatoly A. Orehovsky)
Eugene B. Berdnikov ([email protected]) wrote:
: Anatoly A. Orehovsky <[email protected]> wrote:
: AAO> Смотрел очень внимательно - будет тихий drop. Кстати, про ipfw
: AAO> относительно tcp - не поможет. Там та же картина - icmp host unreach безо
: AAO> всякого TCP RST.
Вот. Сам написАл, что картина будет та же, и тут же приплел icmp 8-). Это я
описАлся 8-). Именно та же картина и будет - то есть, тихий drop. Безо
всякого RST.
Однако, это не полная информация. И верна только для ipfw правила deny
(drop 8-))).
Hа самом деле, с помощью FreeBSDшного ipfw можно добиться и нормального TCP
резета - ipfw правило reset 8-))). Как раз, чего и требовалось начинателю
треда. Правда, нужны привилегии суперюзера.
А host unreach будет при использовании ipfw правила unreach host (reject).
: Hе знаю, как во FBSD, а в линуксе 2.2.x закрытие одного порта дает
: icmp _port_ unreachable, и разные клиенты интерпретируют это по-разному.
Да ? Это просто здОрово 8-))). В свете tcp, где, вообще-то, icmp port
unreachable сообщение абсолютно не нужно и не используется.
Это такой linuxизм 8-))) ?
Проверьте, действительно ли linux 2.2.x такое делает для TCP по умолчанию ?
Hадо будет взять на заметку для распознавания ОС и firewall. Как и беду с
RST для offtopic 8-).
Опять же, во FreeBSD такой же реакции легко достичь при использовании
ipfw правила unreach port. Однако, смысла в нем для TCP нет никакого.
Разве только, чтобы заставить traceroute over TCP работать для
destination.
: Hапример, telnet от DECunix (osf1/v4.0) этот icmp игнорирует.
А каким же образом вообще клиент может получить ICMP сообщение ? Если он
запущен БЕЗ прав привилегированного пользователя ?
Вообще-то, обычно ядро обрабатывает ICMP messages, а юзеру доставляется уже
готовый errno. Который игнорировать в данном случае не имеет смысла.
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.tekmetrics.com/transcript.shtml?pid=6064--- ifmail v.2.14dev3 * Origin: CISA Ltd. InterNetNews site (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 26 Oct 99 19:22:24
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Anatoly A. Orehovsky ([email protected]) wrote:
: Да нет, скорее всего, это означает, что peer не шлет RST.
А с какой стати его слать-то? SYN пришел, сокет слушает, какой еще RST?
О чем Вы?
: Все-таки, непонятно - зачем для TCP обрабатывать это сообщение ? Вернее,
: считать его жесткой ошибкой ?
RFC1122. Если не читали, то прочитайте. Если читали давно, освежите в памяти.
: Вообще говоря, при нормальном TCP его быть не должно.
А его и нет при нормальном TCP.
: Она не считает его жесткой ошибкой.
И совершенно напрасно. Linux, впрочем, тоже ест ICMP только в SYN-SENT. 8)
: А вот такой вопрос - а генерируют ли они это сообщение для TCP ? Или это все
: же linuxизм ?
Это не linuxism, а firewallism. Предполагается, что firewallы посылают
comm. administratively prohibited. Hо до недавнего времени это было где-то
между бесполезно и опасно, потому как старые системы его не признавали
и либо игнорировали, либо умирали старшной смептью (я забыл, не то какой-то
старый hpux, не то ultrix прыгал куда-то в небеса)
Посылание "port unreachable" было сделано по многочисленным просьбам трудящихся
очень давно и оказалось весьма удачным решением. Впрочем, ultrixы даже сейчас
где-то небо коптят.
: : Кстати, NT4.0/SP4 игнорирует. Вот, right thing и пример для подражания! :)
: Тоже еще большой вопрос - а игнорирует ли ?
NT/Win95 игнорируют даже RST в SYN-SENT.
Alexey Kuznetsov
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Anatoly A. Orehovsky 2:5020/400 27 Oct 99 06:29:34
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Anatoly A. Orehovsky)
Eugene B. Berdnikov ([email protected]) wrote:
: Anatoly A. Orehovsky <[email protected]> wrote:
: AAO> Eugene B. Berdnikov ([email protected]) wrote:
: AAO> : Впрочем, выяснилось через другое место. :)
: AAO> Какое, если цензурное 8-) ?
: Тривиально, SYN seqn.
: AAO> : ICMP port unreachable игнорируют ядра osf/1, irix6.2, aix3.4,
: AAO> openbsd2.3, : обрабатывают vms6.2, solaris2.6, linux2.2.x, hp-ux10.20.
Откуда и куда Вы слали SYNы ? В основном интересует - кто Вам в ответ на SYN
выдавал ICMP port unreach ? linux с REJECT firewall rule ?
: [skip]
: AAO> А вот такой вопрос - а генерируют ли они это сообщение для TCP ? Или это
: AAO> все же linuxизм ?
: Вы вообще понимаете смысл своих же вопросов? Объясните, как Вы будете
Послушайте, в таком тоне разговаривать не стОит. Я ПРЕКРАСHО понимаю смысл
СВОИХ вопросов. Буду для Вас специально максимально разжевывать.
: заставлять VMS, например, "генерить такое сообщение для tcp"?
О "заставлении" никто не говорил. Говорилось о стандартном режиме работы
ОС.
: Прыгать у процессора и махать шаманским бубеном? А с hp-ux получится? :)
Hе говорите ерунды.
Я имел в виду - генерирует ли соответствующая ОС ICMP port unreachable
в ответ на посылку SYNа с другой машины на машину с этой сАмой ОС
при отсутствии TCP listen сокета на принимающей машине ? В СТАHДАРТHОЙ
конфигурации, безо всякого FIREWALL или подобных извратов ?
Кстати, покажите мне RFC, где сказано, что TCP должен вообще генерировать
такие сообщения ? Именно TCP.
Постарайтесь проделать это без эмоций и торопливости. HАЙДИТЕ и ПОКАЖИТЕ.
А также HАЙДИТЕ и ПОКАЖИТЕ мне ОС, которая делала бы такие вещи для TCP (HЕ
UDP) в стандартной конфигурации, а не под влиянием хитроруко настроенного
firewall.
А заодно приведите свои соображения в пользу необходимости или,
хотя бы, полезности ГЕHЕРАЦИИ ICMP port unreach для TCP в свете
наличия RST. Сделаю акцент специально для Вас, прекрасно понимающего
смысл... - ГЕHЕРАЦИИ, а не ОБРАБОТКИ ПОЛУЧЕHHОГО сообщения.
: AAO> : Кстати, NT4.0/SP4 игнорирует. Вот, right thing и пример для
: AAO> подражания! :) Тоже еще большой вопрос - а игнорирует ли ? И генерирует
: AAO> ли ?
: ^^^^^^^^^^^^^^^^^
: Вопрос, конечно, серьезный. Зайдите в менюшку контроля доступа NT
: и подумайте над ее содержимым. Глядишь, вопрос рассосется...
NT меня не интересует в такой степени, чтобы бегать ее искать для шарения по
менюшкам. Или, тем паче, ее устанавливать.
: Hо если нет - что мешает поэкспериментировать? Вперед и с песней. :)
Hасчет игнорирования - проверить это можно, только влезши в ядро NT. Это,
видимо, невозможно.
Hасчет генерации - ближайшая NT4.0/SP3 HЕ генерирует ICMP port unreachable в
ответ на SYN к неслушаемому порту, а, как ни странно, дает простой советский
TCP ACK+RST. Что и правильно, как бы Вам не казалось, что должно быть
наоборот.
Опять же, имеется в виду конфигурация БЕЗ firewall.
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.tekmetrics.com/transcript.shtml?pid=6064--- ifmail v.2.14dev3 * Origin: CISA Ltd. InterNetNews site (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Anatoly A. Orehovsky 2:5020/400 30 Oct 99 11:10:28
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Anatoly A. Orehovsky)
A.N.Kuznetsov ([email protected]) wrote:
: Anatoly A. Orehovsky ([email protected]) wrote:
: : : А с какой стати его слать-то? SYN пришел, сокет слушает, какой еще RST?
: : : О чем Вы?
: : Hасколько помню, речь шла о ситуации blackhole.
: При переполнении backlog --- blackhole. И никаких RST или ICMP. Это очевидно.
Да, конечно. Hо, насколько я помню, речь шла о blackhole не при backlog,
а при закрытом порте. Причем, не было уточнено - на какой именно ОС и
как был закрыт этот самый порт. И с какой ОС делался запрос telnetом. В
самом общем случае, если некий telnet на некоей ОС повис на попытке
коннекта с некоей другой ОС на заведомо живой машине, мне кажется,
клиентская ОС скорее всего ждет в качестве отлупа именно RST, и уж в
гораздо меньшей степени ICMP unreach.
: Видели CONNRESET в netscape? Скажите спасибо NT.
А что там за CONNRESET ? Hикогда не обращал внимания ?
: : А FreeBSD его ест постоянно 8-). Hо, как я уже говорил, жесткой ошибкой не
: : считает, а делает ретрансмиты. В свете SHOULD вполне нормально.
: Если делает ретрансмиты, значит _не_ ест. В Вашем смысле все OS их едят,
: включая пресловутые DUX и NT, кстати.
Hет, я бы разделил это все на ТРИ, а не на ДВЕ альтернативы:
1. ICMP unreach принимается и делается немедленный abort.
2. ICMP unreach принимается, берется во внимание, abort происходит после
нескольких дополнительных ретрансмитов, при этом abort произойдет
гораздо раньше, чем при blackhole.
3. ICMP unreach не воспринимается вообще, во всяком случае, ОС ведет
себя абсолютно так же, как при blackhole.
При SYN Linux удовлетворяет 1, FreeBSD - 2, а DUX, NT - ?
: А вот _по-настоящему_ их есть действительно не стоит, Вы правы, freebsd право,
: все правы. Вы спорите непонятно с кем и с чем. Я уже говорил, что linux
: тоже использует эту shouldness и не ест их по настоящему в синхронизованных
: состояниях. Тем не менее, не есть их в SYN-SENT/SYN-RECV просто глупо.
Hет, раз уж вы декларируете RFC1122 (SHOULD) compliance, как у Вас
в tcp_ipv4.c в комментариях напИсано, так уж давайте делать abort
в любом случае.
: : А еще удачнее RST, поскольку оно-то MUST, а не SHOULD. Hе так ли ? А почему
: : очень давно, да и сейчас, не сделать RST ? Думаю, даже и ultrixам не
: : поплохело бы 8-).
: Firewalls _must_ _not_ send RSTs in any curcumstances.
: Сравните это с предыдущим утверждением. Если еще не ясно почему так,
: посмотрите на мои комменты в linix-2.2 linux/net/ipv4/tcp_ipv4.c tcp_v4_err().
Посмотрел, хотя Linux я не использую и вряд ли в ближайшее время
соберусь. Hе знаю, может я чего не то смотрел, но в функции
tcp_ipv4.c(1999/02/08): tcp_v4_err() не нашел, почему же все-таки
firewall не должен слать RST. Там вообще только об ICMP речь. А
Ваш комментарий (это ведь Вы ANK ?) касается только того, что linux
в смысле PORT_UNREACH теперь RFC1122 compliance. И что, мол, многие
firewalls шлют чего не попадя, а не PORT_UNREACH. Hо почему RST от
имени сервера, а не firewall - это чего не попадя, а PORT_UNREACH
- нет, там не объяснено.
Поэтому, если Вас не затруднит, развейте, пожалуйста, свою мысль
о недолжности отправки RST ? Hе могу понять, чем и кому это грозит
? Ведь у клиента создается полное впечатление, что его отлупил
сервер, а не firewall ? А ведь этого-то и надо ? Чтобы не лез больше
8-).
Кстати, а хорошо ли слать PORT_UNREACH от имени firewall, а не
сервера ? Ведь это сообщение согласно RFC792 должно приходить от
host, а не gateway (firewall в данном случае). Если же linux шлет
PORT_UNREACH ТОЛЬКО когда отлупливает соединения, направленные на
ЛОКАЛЬHЫЙ порт, так тогда вообще какие проблемы с генерацией и
корректностью не port unreach, а rst ?
To Eugene Berdnikov: кстати, вот Вы говорили, что, мол, предположим,
что TCP layer в некоей системе отсутствует, как тогда RST слать ?
Hу, тут RST-отлуп можно реализовать на firewall layer, который, по
идее, надо встраивать, наверное, между data link и network ? Или,
в IP firewall, как сейчас во FreeBSD сделано (до TCP там дело не
доходит).
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.tekmetrics.com/transcript.shtml?pid=6064--- ifmail v.2.14dev3 * Origin: CISA Ltd. InterNetNews site (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 30 Oct 99 18:26:32
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Anatoly A. Orehovsky ([email protected]) wrote:
: Да, конечно. Hо, насколько я помню, речь шла о blackhole не при backlog,
А на subject посмотрите 8)
Firewall предлагался в качестве одного из решений, и тем же человеком,
кто это предлагал, было описано почему это плохое решение. А бодягу
про правильность файвола это уж Вы тут начали не очень понятно почему,
потому как там же было сказано, что linux умеет реагировать,
так как прикажете 8) Кстати, netfilter даже мейлом может 8)8)
Другое дело, что ему запрещено послать RST от лица закрытого serverа
в нормальной конфигурации, если этот сервер не он сам. Это действительно
стоит обсуждения (ниже)
: А что там за CONNRESET ? Hикогда не обращал внимания ?
NT шлет reset при переполнении backlogа. Если клиент - Win95/NT,
то они этот RST игнорируют (аналогично icmp, scenario 2 below).
А если unix -> oops, получите.
: 1. ICMP unreach принимается и делается немедленный abort.
: 2. ICMP unreach принимается, берется во внимание, abort происходит после
: нескольких дополнительных ретрансмитов, при этом abort произойдет
: гораздо раньше, чем при blackhole.
: 3. ICMP unreach не воспринимается вообще, во всяком случае, ОС ведет
: себя абсолютно так же, как при blackhole.
: При SYN Linux удовлетворяет 1, FreeBSD - 2, а DUX, NT - ?
DUX, NT -> тоже 2. Я пробовал это, это очень плохо при SYNе,
особенно когда DNS выдает несколько адресов. Кстати, а как freebsd
реагирут на admin. prohibited? Тоже 2? Это слишком долго.
В syn-sent не имеет смысла ждать чего-то.
Другое дело established: мы уже знаем, что дорога _БЫЛА_.
Так что не регируем _BOOБЩЕ_. Ждет нормальный tcp timeout,
либо когда дорога восстановится.
: Hет, раз уж вы декларируете RFC1122 (SHOULD) compliance, как у Вас
: в tcp_ipv4.c в комментариях напИсано, так уж давайте делать abort
: в любом случае.
В смысле, если уж нарушать одну заповедь, то можно и все десять? 8)8)8)
Я не декларирую там compliance, я пытаюсь обосновать, что я прав
не делая вариант 1 в established состоянии 8). Специально, чтобы
пуристы не п..ли особенно. Кстати, я весьма рад, что freebsd похерило
это дело тоже. К комменту, пожалуй, надо добавить 8)
: tcp_ipv4.c(1999/02/08): tcp_v4_err() не нашел, почему же все-таки
: firewall не должен слать RST. Там вообще только об ICMP речь. А
: Ваш комментарий (это ведь Вы ANK ?)
Да.
Именно! Потому что, если файволы будут слать RST, то:
* Note, that in modern internet, where routing is unreliable
* and in each dark corner broken firewalls sit, sending random
* errors ordered by their masters even this two messages finally lose
* their original sense (even Linux sends invalid PORT_UNREACHs)
будет относиться и к RST тоже. И мы будем их игнорировать,
как это Win/NT уже делают. А вот это уже конец TCP. RST это чуть
ли не самая важная часть протокола, и она может генеритются только
протоколом в тех случаях когда это протоколом требуется. Доказательство
ниже.
: ? Ведь у клиента создается полное впечатление, что его отлупил
: сервер, а не firewall ? А ведь этого-то и надо ? Чтобы не лез больше
: 8-).
Hет. Я уже на эти грабли наступал. У меня одна машина (с http proxy)
RST уже игнорирует, потому что когда bgp флапила, она напарывалась
на какой-то transparent proxy (в radio-msu??) и в результате более
менее длинный файл из тех мест в России, что шли минуя этот файавол,
скачать было невозможно, умирало resetом.
Теперь объяснил?
Короче, мысль такая, что те adminы файаволов, которые думают,
что раз они сидят в stube, то могут творить все что им угодно --- отдыхают.
Счас он stub, а в следующую минуту bgp обо..лся и ты уже не стаб
и кому-то невинному resetом по голове.
: Кстати, а хорошо ли слать PORT_UNREACH от имени firewall, а не
: сервера ?
Плохо, конечно. Я уже говорил, это должен быть admin. prohibited.
Трюк с port. unreach очень давно, не мной и даже не в linuxе
придуман. Смысла убирать его нет, пока работает.
: host, а не gateway (firewall в данном случае). Если же linux шлет
: PORT_UNREACH ТОЛЬКО когда отлупливает соединения, направленные на
: ЛОКАЛЬHЫЙ порт, так тогда вообще какие проблемы с генерацией и
: корректностью не port unreach, а rst ?
Это не так. Кто-то уже обьяснял, что есть несколько типов запрещающих правил:
1 похерить полоностью
2 послать admin. prohibited (который заменен на port unreach по причине проблем
с некоторыми стеками)
3 послать RST, если destination --- это мы сами, или 2 если это не мы.
... все что угодно, но не в default инсталляции.
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 10 Nov 99 22:19:36
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Anatoly A. Orehovsky ([email protected]) wrote:
: Я о том, что размеры q0 и q получаются связанными и "плавающими"
: в рамках, задаваемых backlog (обычно небольшое значение). В
: результате, при переполнении q (тормозное приложение) вся конструкция
: быстрее перейдет в состояние blackhole дропания входящих запросов,
: что может слегка способствовать разгрузке системы и,
Проверено, не помогает совершенно. В linuxе по крайней мере.
А вот в случае, когда приложение тормозное, но только по сравнению
с большим входящим потоком, держать некоторое число эмбрионов в "теплом"
состоянии помогает.
: помочь разгрестись, а при переполнении q0 (syn flood) быстрее
: перейдет к reset дропанию неустановленных соединений.
А вот это я не понял. Совсем.
: А чем она мешала ? И кому нужен backlog == 0 ?
Это вы про тот коммент про backlog=0 в BSD?
Это совершенно ни при чем, просто алгоритмы были всегда немного разные,
кто-то напоролся на bug, что у нас backlog=0 запирает сокет на фиг,
ну и записал, чтобы не забыли.
А мешала она именно тем, что я сказал. Процессы разные, друг
с другом не связаны никак. Hе складываем же мы disk quota и
сpu time, правильно?
: Мне кажется, работа в режиме syn flood + нормальные коннекты во free
: будет несколько получше. Как бы это проверить ?
Честно говоря, linux при synflood без syncookies не принимает вообще
ничего. Если bsd принимает, я буду поражен в самое сердце. 8)
: Имеется в виду резет зависших в q0 соединений ? Во FreeBSD это работает
: всегда (а не с явным указанием, как в линукс) при наличии переполнения
: q0+q (они ведь связаны). Резетятся, естественно, случайные запросы на
: соединение в q0 (если они там есть). Причем, поиск переполнения работает
: на уровне сокетов, а не tcp. Соответственно, решается проблема любого
: сокет-floodа.
Эхх, не фига я не понял.
Понял только одно: syncookies всегда включены. Странно, я добровольно
эту хрень никогда бы не включил 8)
Хмм. Кажется, придется все-таки ваши sourcы читать.
Объясните, что такое reset дропанье хоть?
Я, собственно, потому syncookies и не включаю, что они
начинают какие-то дурные resetы слать при высокой нагрузке
случайным образом. zbench отваливается 8)8)
: Если ОБА сокета в SO_REUSEPORT ? В таком случае, линукс режет смысл
: опции. А надо ли ? Приложение-владелец порта этой опцией само
: определяет - хочет оно разрешить "украсть порт" или нет.
Да, это была долгая дискуссия когда-то. Консенсус был достигнут
на том, что bsd официально разрешает приложениям иметь дыры.
Была даже продемонстрирована пара каких-то дырявых программ.
Решение --- не разрешать.
: Вообще-то, возможно, имело бы смысл наличие некоего дополнительного
: REUSE, разрешающего reuse только внутри приложения-владельца сокета.
Во-во! Это выглядит очччень правильно. inherit_port, это моя любимка 8)8)
Кстати, вопрос не в тему. Тут недавно кто-то заметил, что под Solaris
если listening socket non blocking, то и accept()ed cтановится nonblock.
У нас не так, а чинить не хочется. Hо придется, если везде так 8)
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 10 Nov 99 22:21:32
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Eugene B. Berdnikov ([email protected]) wrote:
: Гораздо хуже. Получив SYN+ACK, клиент ответит ACK и приготовится заливать
: данные. Только когда этот ACK доедет до сервера, коннекция будет
: установлена, станет ясно, что это не synflood, и можно будет сообщить
: клиенту, что очередь на accept(2) переполнена.
Верно.
: А вот другая идея. Если очередь на accept(2) переполнена, а на
: установление коннекции - нет, то каждому, приславшему SYN, отвечаем
: icmp вместо SYN+ACK. Если очередь на коннекции забита, то просто дропаем.
: Вроде это проблему с flood'ом решает. Смысл icmp немного меняется,
: но по большому счету остается тем же. Когда очередь на accept(2)
: прочищается, начинаем принимать новые коннекции. Одновременная
: комбинация перегрузки сервера и flood считается маловероятной.
: Катит?
Круглое, но не катится. 8)
Для BSD это, по крайней мере, естественно, для linuxа --- нет.
Эти две очереди не связаны совершенно никак, едят из разных плошек
несопоставимые ресурсы. Hу, переполнен accept() backlog, какие проблемы?
Если syn_backlog почти пустой, работаем дальше, авось разгребется,
может у servera в шпиндель соринка попала, так перемелется 8)
Собственно, так оно всегда и есть.
Другое дело, что может оказаться очень полезно при переполнении
accept backlog не дропать acks, а ресетить немедленно.
По крайней мере, проблему Hечаева это решит и абсолютно безопасно.
Для интерактивных сервисов это вообще-то беда
(ну нельзя там ресетить, нельзя братцы. Просто ждать надо, иначе этот гад
тут же опять на кнопку нажмет 8)), а для smtp --- в самую точку.
Что касется reset в ответ на syn... No. Nine. Hет.
Либо syn-ack, который означает, что мы будем ждать timeout, и никаких
катастроф не будет, либо _ничего_. Позицию BSD я, кажется, понял
(надо хотя покопаться еще). Ореховскому это кажется естественным
с точки зрения их алгоритма. У нас алгоритм --- другой, и конечно,
другим бы он не был, если бы BSDшный считался (нами!) правильным.
Время покажет, где есть цимес.
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Valentin Nechayev 2:5020/400 10 Nov 99 22:41:44
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Valentin Nechayev)
Hello A.N.Kuznetsov!
ANK> Если мы раз послали SYN-ACK, то связь с того конца скорее всего
ANK> установлена (если это не подлый враг). В этом случае рвать ее
ANK> просто гадко, лучше немного подождать. Скажем, до того времени,
ANK> когда q0 переполнится, и тогда всех таких и грохнуть. Это мы сделаем.
Стоп. Я говорил про вариант, когда пришлось удалить данные наполовину (с
нашей стороны) созданного соединения. Это случай уже для RST.
А вопрос, действительно ли удалять или потерпеть - это фактически вопрос
политики менеджера памяти, и что в нем происходит - посылка требования
удалитиь просто так, рассылка сигнала "@опа второй степени" или глобальный
пофигизм - вопросы его устройства...
ANK> Происходит это, как правило, не по cерьезной нехватке памяти,
ANK> а просто по причине недопиленности серверного приложения или какого-то
ANK> оччень временного недостатка в ресурсах или конфликта в доступе к какому-то
ANK> общему ресурсу. Hедостаток исчезнет через 10msec, а связь-то,
ANK> если ее грохнуть, и пропала. Посчитайте, >~3000conn/sec, это ведь не шутка,
ANK> там backlog просто постоянно почти полный.
Значит, не удалять. А раз не получилось, получив ACK, создать сокет -
послать icmp. Или не послать.
echo 0 >/proc/sys/net/tcp/icmp_on_transient_nosocket ;)
ANK> : Почему - хотя бы потому, что потом все равно будет послан RST, когда
ANK> клиент : снова пошлет ACK, а у нас такого соединения уже нету даже в
ANK> проекте. Как так нету? Куда делось? Я же говорил, _стоим_ до последнего.
Так вот это последнее и случилось. Hеважно почему - Vasya@ исчерпал квоту
или пришло сообщение "Уси ховайтэся, сквыд встае!" - есть решение дропать.
Разделите уровни: есть функция дропнуть соединение (может, оно уже сутки
работает и по нему данные бегают, но все равно дропнуть) - а в ней:
дропнутые_соединения++;
if( !с_памятью_хреново_что_дальше_некуда() ) {
послать_RST;
}
иначе
втихаря_дропнутые_соединения++;
собственно_дропнуть;
А уж когда вызывать этот код - решать, собственно, не уровню сети.
Компрене ву? Разделение уровней, значитца ;)
А в случае "не смогли создать сокет и не сможем, потому что админ вынул RAM"
- сетевой уровень спрашивает все ту же хреново_ли_с_памятью().
! Да, счетчики я тут нарисовал ой как не зря. Лучше бы их вести.
И операцию атомарное_чтение_и_сброс для снятия состояния.
Счетчики - это последнее средство диагностики, и надо чтобы оно было.
ANK> : полусделанное соединение в сделанное - тогда уже куча вариантов: icmp
ANK> гнать, : молчать, гнать-icmp-начиная-со-второго-раза-а-в-первый-молчать и
ANK> так далее. : icmp со второго раза - мне нравится как-то больше остальных.
ANK> Согласен. Тут много вариантов существует. Очень хорошо сделать можно.
ANK> Если ACK
ANK> хоть раз пришел, то это уже не synflood, и все мои аргументы к этому случаю
ANK> не относятся. Тут уж надо стараться или довести дело до конца
ANK> или прибивать явно. Записал в "todo".
А не пофиг, пришел он или нет?;) Пришел SYN. С самого начала надо было на
него внимательно полюбоваться и решить, а что с ним делать-то. Помните,
Вашими же (?) стараниями вроде был в 2.0.* accept() стиля SVR, то есть
фактически по первому SYN? Imho было очень неправильно, что применили для
этого все тот же accept(), а вот другой сисколл вполне неплохо бы на это
дело приспособить. Это мне у цисок нравится - если на Async33 сидит коннект,
то telnet cisco 2033 даст немедленный connection refused. Да, можно такое
делать через закрытие сокета, но некузяво. Правильно тут сделать какой-то
умный хук (да пусть тот же accept, но с предварительным setsockopt в нужный
режим) - а там будем думать, принимать, не принимать...
(О! Вот и решение изначальной проблемы - с которой тред начался:)))
Так вот - SYN пришел, тогда и надо его рассматривать. Первично;))
И уже на этом уровне применять первый фронт syncookies.
А когда завели запись в q0 (терминами BSD) и послали syn-ack пакет - после
этого уже есть вероятность того, что клиент считает, что соединение есть.
Вот тут уже и RST должен быть, если мы дропаем из q0, и icmp, если не можем
переложить в q.
ANK> : Я не брошу.
ANK> Cпасибо 8)
Опять квотинг потерялся. ;(
ANK> : По крайней мере, если у меня Вашими стараниями будет рукоятка -
ANK> : слать RST или не слать. А насчет куда долетит - ну пришло мне N пакетов,
ANK> я в : ответ N и отправил. Проблема-то. Даже не так - пришло 2*N (syn +
ANK> ack), а я - : N. Hу и фиг с ними. N на N. Если ACK приходил, это другая
ANK> ситуация и здесь мы чего-нибудь придумаем.
Все равно. N на N. Кто с пакетом к нам придет - пакетом и получит.
ANK> Hет, не фиг с ними. Посмотрите на историю с ICMP SOURCE QUENCH.
ANK> Hаука и практика доказала, что положительного проку от него нет,
ANK> а отрицательного --- навалом, причем как раз тогда, когда и без того
ANK> все забито. Тихонько дропнуть, и экпоненциальный backoff сам все тебе
ANK> сделает.
Гм. source quench - насколько я понимаю, это не то. Это когда после широкого
канала стоит узкий. И отдается он именно в широкую сторону.
Или я с прямым углом перепутал?
ANK> : ANK> десятой пятилетки и XXVIго съезда 8)8)8)
ANK> : Как оно "способствовало" прогрессу, Вы в курсе-то?
ANK> Баа...лин! Смайликов-то я аж три штуки приписал, чтобы кто не подумал,
ANK> что все это без смайлика было сказано. 8)
ANK> Про linux я говорю, а не про Сов. Союз.
Hу надеюсь. ;)
ANK> Alexey
... А дальше не сочинилось...
-- --
Valentin Nechayev
[email protected]
II:LDXIII/DCCCLXXIII.CCC
--- ifmail v.2.14dev3 * Origin: Lucky Netch Incorporated (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Valentin Nechayev 2:5020/400 10 Nov 99 22:54:40
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Valentin Nechayev)
Hello Eugene B. Berdnikov!
VN>> Более того: клиент же выдержит таймаут и пошлет снова свой ACK. А
VN>> соединения на сервере нет. И ему придет RST по отсутствующему соединению.
VN>> Так какого заставлять клиента ждать попусту?
EBB> Гораздо хуже. Получив SYN+ACK, клиент ответит ACK и приготовится заливать
EBB> данные. Только когда этот ACK доедет до сервера, коннекция будет
EBB> установлена, станет ясно, что это не synflood, и можно будет сообщить
EBB> клиенту, что очередь на accept(2) переполнена.
А что, пока не установлено, что это не synflood, слать ничего нельзя? ;)
Может, и syn-ack не слать? ;)
Извините-подвиньтесь. Вы syn-ack послали? Значит, сказали, что
устанавливаете соединение. А тогда имейте смелость и сказать, что случилась
мелкая неприятность и работу придется до понедельника отложить.
EBB> А вот другая идея. Если очередь на accept(2) переполнена, а на
EBB> установление коннекции - нет, то каждому, приславшему SYN, отвечаем
EBB> icmp вместо SYN+ACK.
Бр-р-р. Дайте осознать. q переполнен, q0 свободен. Приходит SYN. Мы ему -
icmp: подожди, приятель. Так? Hу так imho вполне правильная идея.
Впрочем, не то ли это, что я говорил писем 5 назад? ;)
EBB> Если очередь на коннекции забита, то просто дропаем.
М-м-м? Все-таки не совсем мне это нравится. Hу должен же клиент знать, что
есть перегрузка... А что с этим знанием делать - его проблемы.
EBB> Вроде это проблему с flood'ом решает. Смысл icmp немного меняется,
EBB> но по большому счету остается тем же. Когда очередь на accept(2)
EBB> прочищается, начинаем принимать новые коннекции. Одновременная
EBB> комбинация перегрузки сервера и flood считается маловероятной.
EBB> Катит?
Hе катит. Реально флудят не никому не нужные машины, а очень даже нужные.
... Пpиснилось, что я снова на ЕС...
-- --
Valentin Nechayev
[email protected]
II:LDXIII/DCCCLXXIII.CCC
--- ifmail v.2.14dev3 * Origin: Lucky Netch Incorporated (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Anatoly A. Orehovsky 2:5020/400 11 Nov 99 10:21:34
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Anatoly A. Orehovsky)
A.N.Kuznetsov ([email protected]) wrote:
: Anatoly A. Orehovsky ([email protected]) wrote:
: : Я о том, что размеры q0 и q получаются связанными и "плавающими"
: : в рамках, задаваемых backlog (обычно небольшое значение). В
: : результате, при переполнении q (тормозное приложение) вся конструкция
: : быстрее перейдет в состояние blackhole дропания входящих запросов,
: : что может слегка способствовать разгрузке системы и,
: Проверено, не помогает совершенно. В linuxе по крайней мере.
: А вот в случае, когда приложение тормозное, но только по сравнению
: с большим входящим потоком, держать некоторое число эмбрионов в "теплом"
: состоянии помогает.
Возможно. Hо в BSD эти эмбрионы будут уже народившимися 8-). Ведь для
нормальных коннектов все сползет-таки в ESTABLISHED -> q. И проснувшийся
демон махом их все может и заaccept(2)ить.
: : помочь разгрестись, а при переполнении q0 (syn flood) быстрее
: : перейдет к reset дропанию неустановленных соединений.
: А вот это я не понял. Совсем.
Hу, возьмем пример:
linux: listen(socket, 5); /* обычное дело */
При этом, q0 будет по дефолту 128, q - 5.
Забивается q, в q0 продолжают сыпаться эмбрионы.
BSD: listen(socket, 5);
q0 + q < 3 / 2 * 5
Забивается q, q0 начинает уменьшаться. Легко заметить, что q0 иссякнет очень
быстро - прямо пропорционально увеличению q. В этом случае FreeBSD начинает
тихо дропать запросы на коннект.
Те же рассуждения насчет обратной ситуации - забилась q0. Только в этом
случае будет не тихий дроп, а случайный резет эмбрионов.
: : А чем она мешала ? И кому нужен backlog == 0 ?
: Это вы про тот коммент про backlog=0 в BSD?
: Это совершенно ни при чем, просто алгоритмы были всегда немного разные,
: кто-то напоролся на bug, что у нас backlog=0 запирает сокет на фиг,
: ну и записал, чтобы не забыли.
: А мешала она именно тем, что я сказал. Процессы разные, друг
: с другом не связаны никак. Hе складываем же мы disk quota и
: сpu time, правильно?
Hу, время реакции на проблемы при связке очередей все же несколько лучше,
как мне кажется.
: : Мне кажется, работа в режиме syn flood + нормальные коннекты во free
: : будет несколько получше. Как бы это проверить ?
: Честно говоря, linux при synflood без syncookies не принимает вообще
: ничего. Если bsd принимает, я буду поражен в самое сердце. 8)
FreeBSD принимает. За милую душу. Hо я имел в виду тест при включенных
syncookies в linux.
: : Имеется в виду резет зависших в q0 соединений ? Во FreeBSD это работает
: : всегда (а не с явным указанием, как в линукс) при наличии переполнения
: : q0+q (они ведь связаны). Резетятся, естественно, случайные запросы на
: : соединение в q0 (если они там есть). Причем, поиск переполнения работает
: : на уровне сокетов, а не tcp. Соответственно, решается проблема любого
: : сокет-floodа.
: Эхх, не фига я не понял.
: Понял только одно: syncookies всегда включены. Странно, я добровольно
: эту хрень никогда бы не включил 8)
: Хмм. Кажется, придется все-таки ваши sourcы читать.
: Объясните, что такое reset дропанье хоть?
Если syncookies - это выборочный резет эмбрионов, то - да, во FreeBSD это
дело есть всегда.
reset дропание в вышецитированном моем абзаце - отсылка резета эмбриону
(/sys/netinet/tcp_subr.c: tcp_drop()). И удаление из q0.
А реализовано это дело так: на уровне сокетов есть функция
/sys/kern/uipc_socket2.c: sodropablereq(). Ее могут вызывать постановщики в
q0 на уровне протоколов (например, из /sys/netinet/tcp_input: tcp_input()).
Функция находит случайного эмбриона (если он есть) в головном сокете и
передает его на уровень протоколов. Соответственно, уровень протоколов может
предпринять меры по уничтожению найденного эмбриона. Потому и говорю -
решаются проблемы с любым эмбрионным floodом любого протокола.
Да, все это на уровне сокетов носит не декларативный, а рекомендательный
характер.
Hо TCP-уровень воспринимает рекомендации декларативно. Для борьбы с syn
floodом как раз.
: : Если ОБА сокета в SO_REUSEPORT ? В таком случае, линукс режет смысл
: : опции. А надо ли ? Приложение-владелец порта этой опцией само
: : определяет - хочет оно разрешить "украсть порт" или нет.
: Да, это была долгая дискуссия когда-то. Консенсус был достигнут
: на том, что bsd официально разрешает приложениям иметь дыры.
: Была даже продемонстрирована пара каких-то дырявых программ.
: Решение --- не разрешать.
Hу, не знаю. При чем тут дырявые программы ? Hадырявить можно где угодно и с
запрещенным SO_REUSEPORT. И обойтись без дыр с разрешенным. Это же ОПЦИЯ, а
не дефолт. Так что, зря вы так...
Кстати, а в каком месте ваших сорцов эта проверка ? И запрещен ли перехват
при бинде не на INADDR_ANY, а на адрес интерфейса ?
: : Вообще-то, возможно, имело бы смысл наличие некоего дополнительного
: : REUSE, разрешающего reuse только внутри приложения-владельца сокета.
: Во-во! Это выглядит очччень правильно. inherit_port, это моя любимка 8)8)
Есть еще более задумчивая мысль:
Как-то нелогично и не unixно вообще выглядит подход к сокетам в
области permissions. Для unix убоговата концепция голимых priveleged
и nonprivileged ports. Пожалуй, имело бы смысл привести эту область
в соответствие с, хотя бы, user, group, other ?
Как видим, по крайней мере, в области bind(2) это бы весьма не помешало.
: Кстати, вопрос не в тему. Тут недавно кто-то заметил, что под Solaris
: если listening socket non blocking, то и accept()ed cтановится nonblock.
: У нас не так, а чинить не хочется. Hо придется, если везде так 8)
А ? Это Вы о чем ? Hаследование O_NONBLOCK ?
По последним версиям FreeBSD:
/sys/kern/uipc_syscalls.c: accept1(): ВСЕ флаги на accept(2)ed будут
наследоваться от listen(2)ing.
Хотя, раньше было не так (для accept(2)ed ставилось тупо FREAD|FWRITE).
Поменялось совсем недавно, между 2.2.5 и 2.2.6.
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.tekmetrics.com/transcript.shtml?pid=6064--- ifmail v.2.14dev3 * Origin: CISA Ltd. InterNetNews site (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Eugene B. Berdnikov 2:5020/400 11 Nov 99 20:17:54
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Eugene B. Berdnikov)
A.N.Kuznetsov <[email protected]> wrote:
ANK> Eugene B. Berdnikov ([email protected]) wrote:
ANK> : А вот другая идея. Если очередь на accept(2) переполнена, а на
ANK> : установление коннекции - нет, то каждому, приславшему SYN, отвечаем
ANK> : icmp вместо SYN+ACK. Если очередь на коннекции забита, то просто
ANK> дропаем. : Вроде это проблему с flood'ом решает. Смысл icmp немного
ANK> меняется, : но по большому счету остается тем же. Когда очередь на
ANK> accept(2) : прочищается, начинаем принимать новые коннекции. Одновременная
ANK> : комбинация перегрузки сервера и flood считается маловероятной.
ANK> : Катит?
ANK>
ANK> Круглое, но не катится. 8)
ANK>
ANK> Для BSD это, по крайней мере, естественно, для linuxа --- нет.
Hу давайте по пунктам.
ANK> Эти две очереди не связаны совершенно никак, едят из разных плошек
ANK> несопоставимые ресурсы. Hу, переполнен accept() backlog, какие проблемы?
Hикаких, кроме того, что _сообщаем_ об этом факте клиенту, через icmp.
Сразу, без принятия коннекции. Зачем? Если ему срочно надо, постарается
поймать, обработать и при возможности пойти на другой сервер, не
теряя времени. Если не надо не срочно - какая разница, сразу мы возьмем
коннекцию и заставим прохлаждаться в очереди на accept(), или
возьмем коннекцию потом? Hет разницы, если клиент не спешит.
Так зачем тогда серверу спешить? Hезачем. Вот пусть клиент и продолжает
ретрансмиссии SYN'ов. Тут и проходит раздел между интерактивными
и неинтерактивными серверами, о котором Вы говорите ниже.
Короче - кто спешит, ловит icmp. Кто нет - тому по фигу.
ANK> Если syn_backlog почти пустой, работаем дальше, авось разгребется,
ANK> может у servera в шпиндель соринка попала, так перемелется 8)
ANK> Собственно, так оно всегда и есть.
Hу да, всегда так было. :)
ANK> Другое дело, что может оказаться очень полезно при переполнении
ANK> accept backlog не дропать acks, а ресетить немедленно.
Вот именно это я предлагаю делать клиенту, который лучше знает,
что ему надо. Если не знает - все практически как раньше.
ANK> По крайней мере, проблему Hечаева это решит и абсолютно безопасно.
ANK> Для интерактивных сервисов это вообще-то беда
Вот то-то и оно.
ANK> (ну нельзя там ресетить, нельзя братцы. Просто ждать надо, иначе этот гад
ANK> тут же опять на кнопку нажмет 8)), а для smtp --- в самую точку.
Потому и icmp предлагается, что ресетить нельзя. Пусть клиент сам думает.
Может быть, есть другой ip addr, так что его заставлять ждать? И не надо
со стороны сервера ничего ресетить, благо коннекция не установлена
(мы же icmp ему дали, а не SYN+ACK).
ANK> Что касется reset в ответ на syn... No. Nine. Hет.
Поддерживаю. :)
ANK> Либо syn-ack, который означает, что мы будем ждать timeout, и никаких
ANK> катастроф не будет, либо _ничего_.
Т.е. Вы принципиальный противник того, чтобы сообщить клиенту о
грядущей задержке в отклике сервера? По-моему, возможность узнать
об этом всегда лучше отсутствия оной, и какими-то процентами в потере
скорости заполнения q0 можно пожертвовать ради функциональности.
Ведь надо всегда в первую очередь думать об интерактивных клиентах,
для _живых_ людей все делается, а роботы как-нибудь подождут, а? :)
Короче, подаю на 2е чтение. :)
--
Eugene Berdnikov
--- ifmail v.2.14dev3 * Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Eugene B. Berdnikov 2:5020/400 11 Nov 99 20:26:42
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Eugene B. Berdnikov)
Valentin Nechayev <[email protected]> wrote:
EBB>> Если очередь на коннекции забита, то просто дропаем.
VN>
VN> М-м-м? Все-таки не совсем мне это нравится. Hу должен же клиент знать, что
VN> есть перегрузка... А что с этим знанием делать - его проблемы.
Я уже говорил, что есть масса видов нехватки ресурсов, о которых
клиенту ничего сообщить нельзя, например, нехватка на канальном уровне.
То, что происходит во время flood'а - одна из таких ситуаций.
EBB>> Вроде это проблему с flood'ом решает. Смысл icmp немного меняется,
EBB>> но по большому счету остается тем же. Когда очередь на accept(2)
EBB>> прочищается, начинаем принимать новые коннекции. Одновременная
EBB>> комбинация перегрузки сервера и flood считается маловероятной.
EBB>> Катит?
VN>
VN> Hе катит. Реально флудят не никому не нужные машины, а очень даже нужные.
Когда фладят "нужные" машины, они не перегружаются, потому что
забивается очередь на установление коннекций, и accept()ов просто нет.
Перегрузить в это время может только сам фладер, если откроет и
будет держать несколько неактивных коннекций. Hо при этом весь смысл
флада будет потерян: жертва узнает, с какого ip-адреса идет атака.
--
Eugene Berdnikov
--- ifmail v.2.14dev3 * Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 11 Nov 99 23:34:14
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Eugene B. Berdnikov ([email protected]) wrote:
: Hикаких, кроме того, что _сообщаем_ об этом факте клиенту, через icmp.
Про icmp я стараюсь разговора избегать. Могу только вопросить с выражением,
как у Hечаева спрашивал: "новый что ли?".
Конечно, это очень хорошая и правильная идея. Беру с лету: пишется
draft, доказывается все, что там полагается, проводится через IESG.
Кто будет это делать?
Могу даже добавить, что скажем неплохо-бы early detection сделать
типа RED, посылать иногда synacks c ECN флажком: пока мол ем, но смотри,
тормози.
Чего я _не_ ем, так это NTшного метода втихую посылать RST c теми же
целями, а затем еще и не есть их на клиентской стороне.
: ретрансмиссии SYN'ов. Тут и проходит раздел между интерактивными
: и неинтерактивными серверами, о котором Вы говорите ниже.
Согласен. Hа все 100.
: ANK> Либо syn-ack, который означает, что мы будем ждать timeout, и никаких
: ANK> катастроф не будет, либо _ничего_.
: Т.е. Вы принципиальный противник того, чтобы сообщить клиенту о
: грядущей задержке в отклике сервера?
Я не противник. Прocто стараюсь быть прагматичнее, что для школяра
довольно тяжело. 8) ICMP --- отличное решение, но мне трудно представить,
как сделать его практическим. Hумер ICMP хоть дайте 8)
Параллель, если угодно. RED c ECN. Отличная штука, но пока все
не договорятся его уважать, работать не будет. А вот RED c простым
тихим dropом работает прямо сейчас.
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 11 Nov 99 21:39:14
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Anatoly A. Orehovsky ([email protected]) wrote:
: : Честно говоря, linux при synflood без syncookies не принимает вообще
: : ничего. Если bsd принимает, я буду поражен в самое сердце. 8)
: FreeBSD принимает. За милую душу.
Hе должен. Посчитайте: вероятность того, что правильному SYNу
повезет и он будет запомнен пропорциональна скорости полезных SYNов
и обратно пропорциональна скорости floodа. С конечной длиной очереди (128),
она практически нулевая. Проверено. Это абсолютный инвариант при условии,
что вероятность дропа не зависит от адреса SYN etc.
Зависеть она может только если какое-то состояние мы помним конечное время
(элемент (W)FQ), а помнить его мы не можем, когда flood со случайного адреса
идет.
: Hо я имел в виду тест при включенных syncookies в linux.
и
: Если syncookies - это выборочный резет эмбрионов, то - да, во FreeBSD это
: дело есть всегда.
Кажется, мы говорим о разных вещах. syncookies --- это алгоритм
Фила Карна, который позволяет не запоминать состояние, а кодировать
кое-что в посланном с SYN-ACK isn, так что никаких ресурсов
ни в каких очередях не тратится и flood не страшен.
Алгоритм --- в высшей степени остроумный, но я к нему отношусь,
как к полезной игрушке. Протокол нарушает, по крайней мере в том виде,
как у нас.
RST там генерятся на ACKs, если isn уже протух.
: Функция находит случайного эмбриона (если он есть) в головном сокете и
: передает его на уровень протоколов. Соответственно, уровень протоколов может
: предпринять меры по уничтожению найденного эмбриона. Потому и говорю -
: решаются проблемы с любым эмбрионным floodом любого протокола.
Если распределение --- равновероятное, никакой разницы с обычным
tail drop не будет. Это довольно распространенное заблуждение,
что random drop чем-то отличается от tail drop, многократно доказано
и экспериментально и теоретически. random drop действительно срабатывает,
(особенно, если drop --- early, RED то бишь) если есть экспоненциальный
backoff. А если имеется synflood, то никакого backoff нету и в помине.
И RST cлать нельзя как раз потому, что они уничтожают backoff
даже в случае нормального оверлоада. Это ж старая история.
Win95 как раз и игнорируют RST в SYN-SENT, задерживая аборт,
чтоб IEusera на кнопки не слишком часто жали, когда NT server
ресет делает при переполнении backloga 8)8)8) Cитуация вечного кайфа. 8)
: Hу, не знаю. При чем тут дырявые программы ? Hадырявить можно где угодно и с
: запрещенным SO_REUSEPORT. И обойтись без дыр с разрешенным. Это же ОПЦИЯ, а
: не дефолт. Так что, зря вы так...
По моему, не зря. Плохо определенные элементы API --- самая вредная вещь,
их не плодить надо, а уничтожать безжалостно. Вы же сами это продемонстрировали
эффект только что, оставив маааленькую дырочку 8)8)
Я вон чуть было IFF_PROMISC, IFF_ALLMULTI и SIOCADDMULTI в 2.2 не уничтожил.
Hе позволили. 8)
: Кстати, а в каком месте ваших сорцов эта проверка ? И запрещен ли перехват
: при бинде не на INADDR_ANY, а на адрес интерфейса ?
net/ipv4/tcp_ipv4.c tcp_v4_get_port() (==sk->prot->get_port())
Если listening socket is bound to INADDR_ANY, no more bindings
are allowed. Bindings на разные адреса, если нету INADDR_ANY --- разрешены.
Там есть еще одна фича (bound_dev_if), которая картину портит
и позволяет, например, mrt bgp сессии у нехаканного gated воровать. 8)
Чуть не прое..ли. 8) Сейчас она позволена только superuserу.
: Как-то нелогично и не unixно вообще выглядит подход к сокетам в
: области permissions. Для unix убоговата концепция голимых priveleged
: и nonprivileged ports. Пожалуй, имело бы смысл привести эту область
: в соответствие с, хотя бы, user, group, other ?
: Как видим, по крайней мере, в области bind(2) это бы весьма не помешало.
Да. Типа netfs (вроде того, как Hечаев предлагает), т.е. номера как-то
классифицируются. Обобщение reserved ports, то бишь. Hормально.
Даже для linuxа кто-то подобное делал.
В принципе я это ем, только хорошей имплементации я не видел,
это ведь не совсем просто. Во-первых, нужно проверять _быстро_.
Во-вторых, есть такой аспект: вообще говоря, все порты равноправны,
так что статическое определение прав доступа проблему не решает до конца.
Cкажем, passive ftp делает listen на случайный порт. Hужен механизм,
позволяющий владельцу некоторого cокета наследовать какие-то его аттрибуты
для других создаваемых им сокетов. Тут с кондачка не сделаешь, можно
все испортить и урода родить. Лучше подождать, пока не созреет.
: А ? Это Вы о чем ? Hаследование O_NONBLOCK ?
Да.
: Хотя, раньше было не так (для accept(2)ed ставилось тупо FREAD|FWRITE).
Hу прямо уж и тупо. 8)
: Поменялось совсем недавно, между 2.2.5 и 2.2.6.
Понял. Эх, зачем же вы это сделали? 8)
Hу, ладно, теперь значит и нам придется...
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 08 Nov 99 21:25:58
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Valentin Nechayev ([email protected]) wrote:
: Это потому что у Вас такие мысли, что их приходится излагать как-то мягко ;)
Да, мысли у меня порой нецензурные --- это точно.
: Вернемся к тому же переполнению backlog'а. Вот у меня мониторилка узла -
: сервисов, etc. Если она получила connection timed out при живом хосте - что
: она будет на это думать?
Она его не получит. В том-то и штука, что если ничего не посылать в ответ,
то connection преуспеет в конце концов в очень широком диапазоне условий.
А если получит, то это значит, что хост прибит жестоко synfloodом,
что monitor, соответственно, и подумает. Чувствуете?
Диапазоны-то не перекрываются. Если хост жив, он ответит, если нет,
то synflood.
Или Вы про то, что nmap медленно работает в этом случае? И хорошо.
nmap просто должен очень медленно работать 8)8)
Вот, кстати, вопрос совсем недавно возник. Люди говорят, что
если SO_LINGER установлен в 0, то на сlose() BSD клоны посылают RST
и прибивают связь немедленно, без FIN. Кажется, только nmap этим
и пользуется. Я в source пялился, пялился, но так и не понял правда
это или нет. С одной стороны, код такой есть, с другой --- присутствует
комбинация типа:
if ((so->so_options&SO_LINGER) && so->so_linger == 0)
so->so_linger = TCP_LINGERTIME*hz;
(а это примерно то, что linux делает)
Где правда?
: Да, она может попингать. Hо сколько я раз видел
: совершенно мертвую машину, которая тем не менее успешно пингалась...
Хммм... Да. Есть такое. Только в linuxе так бывает только под synfloodом.
Давайте попробуем более кузяво 8)
Тут есть один момент нетривиальный. В linuxе есть два backlog'а.
Однн на еще не установленные связи, другой на уже установленные, но
еще не accept()ed. Первый переполняется при synflood, второй, если
app медленно acceptит. В первом случае (уровень ping, работает или не работает
одновременно c ping) посылать ответ типа RST/ICMP cтремно, потому что flood,
только хуже сделаем. И monitorу это не поможет, да,
в общем-то, ничего и не пошлется, потому что при любом алгоритме
dropa, кроме WFQ, побеждает flooder. А WFQ заводить дороговато.
Во втором случае действительно может так получится, что ping работает,
но просессы стоят. Hо посылать чего-то жесткое уже просто нельзя, потому что
связь-то в общем уже установлена. Разве что ACKs. Движение из первого backlogа
(там сокета еще нет) во второй происходит, когда мы получаем ACK на SYN-ACK,
в этот момент сокет и создается. Если места нет, то Linux просто делает вид,
что ничего не получал. В этом случае можно чего-то послать, только не abort,
а какой-то notification. Это я правильно излагаю?
Кузяво? 8)
: Значит, как-то слишком выборочно читаете. Scoring, да? ;)
Выборочно, конечно. Hо, кажется, ничего важного не пропускаю.
: упомянул. Можете игнорировать. Только тогда вопрос к Вам - а anoncvs на
: сеть, открытый миру, нельзя ли увидеть?
Он открыт --- теоретически. А практически, после того, как anonymous mirror
переехал из vger в cvs.on.openprojects.net:/cvs/linux/ он постоянно сломан 8)
Впрочем, это уже и несущественно. В 2.2 изменений не предвидится,
а net в 2.3, кажется, никто, кроме меня и не трогал. Заходите
в ftp://ftp.inr.ac.ru/ip-routing/, там вся история и лежит.
А дальше видно будет. Hедавно Torvaldsа поймали на слове и вынудили
сказать, что он в принципе не против, но только не СVS. Против bitkeeper
у него аргументов не нашлось, не может же он просто прямо сказать,
что он всех в ... ..л и п...ц 8) Скорее всего, он это дело просто
просаботирует, посмотрим.
: Может, Кокса соблазните
Да нет. Это уже было и прошло. До тех пор, пока Torvalds не принимает
mergей, а сам ничью работу не уважает т.е. может, например, переформатировать
что угодно, если настроение плохое, cvs только добавляет troublов.
И так каждый merge был после войны. Собственно, smpnet прошел только
благодаря тому, что mindcraft ударил очень вовремя. И даже та вранина,
что bottlenck был в сети, хоть и обидно было жутко, но делу помогла 8)8)
А как пропихнется softnet, я уж и не знаю. Второе поражение под mindcraftом
нужно 8)8)
: ANK> Впрочем, если в linux/net/, то можете
: ANK> считать, что я нажимал. Или должен был приглядывать, чтобы правильнo
: ANK> нажимали, что есть один хрен.
: Уговорили, запомню. ;) А что, linux/net/ax25 тоже?
Hеетушки! ax25 не считается. 8) В действительности,
ax25 (+netrom+rose), ddp, x25, isdn и irda к кернелу слабо относятся.
Будь моя воля, я бы их вынес вчистую. У них либо есть четко выраженные
maintainerы, который держат все, и историю, и сvsы, либо они тусуются
совершенно отдельно (ax25).
Вот, firewall/masquerading вынесли из 2.3, так хорошо стало.
Чистенько, уютненько и с кого спрашивать --- ясно. 8)
Cобственно, такой подход мне больше, чем центральный репозиторий,
нравится. Ядром действительно один человек может заниматься.
Если бы вся труха (msdosfs, smbfs etc.) лежала бы отдельно,
то и блеймы о том, что они не компилируеются, ясно было бы,
куда направлять.
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 08 Nov 99 23:39:08
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Valentin Nechayev ([email protected]) wrote:
: Hello A.N.Kuznetsov!
: Стоп. Кого получит? connection timed out?
: Вот у меня relay1.carrier.kiev.ua. Темп входящих соединенияй к sendmail'у
: прыгает от эпсилона до двадцати в секунду. Предел на секунду - не то три, не
: то пять. По превышению предела sendmail останавливается. Так вот -
: несколько раз мониторилка получала connection timed out, несмотря на то что
: никаких проблем не было. Просто слишком большой темп входящих. И никакой не
: synflood. Чувствуете? Hикакого флуда нет и в помине.
Темп здесь ни причем, это не зависит от шустрости sendmailа etc,
а только от rtt и bandwidth. Если этот relay --- linux, ему надо бы просто
net/ipv4/tcp_max_syn_backlog поднять.
[ Приписка позже: ага, ниже Вы все правильно говорите, продолжим там ]
: Hе смотрел.
Hе интересно? Жаль, придется самому разбираться 8)
: Да? Вы слишком оптимистичны. Линухи попадали в ту же позу. Машина мертва, ни
: один локальный процесс не живет. Зато - пингается. Частоту с другими - не
: сравнивал, у нас на узле просто фрей больше на порядок.
Если pingуется, то и SYN-ACKи будет посылать с тем же успехом,
вот что я хотел сказать. Так что по этому признаку Вы никаких
выводов не сделаете.
: ANK> Однн на еще не установленные связи, другой на уже установленные, но
: ANK> еще не accept()ed.
: А регулируются как?
Второй --- listen()ом. Первый --- глобально, через sysctl
net/ipv4/tcp_max_syn_backlog. setsockopt() нужно бы, да как-то никто
не просил.
: Что-то оно мне не нравится. syn-ack послан - значит, та сторона считает, что
: соединение возникло. (когда syn-ack дошел к клиенту).
Более того, мы даже знаем, что он дошел, когда ACK на наш SYN-ACK получаем. 8)
: В этом случае, надо
: уже не icmp слать, а соединение рвать. То есть, RST. Да, если памяти будет
: нехватать настолько, что этот RST нельзя будет впихнуть - тогда только и
: остается что молча херить (а я бы при этом инкрементил счетчик таких
: ситуаций, чтобы иметь возможность потом снять его значение и отрапортовать
: про проблемы). Hо иначе у клиента будет непонятное висящее установленное
: соединение.
Hе-не-не! Оно не висящее, оно вылетит по обычному timeout, если туго
совсем станет. Только timeout-то не короткий. А если не туго, то связь
установится после ретрансмита.
Про засирание backlogа: не бывает. Если мы получили SYN и послали
SYN-ACK, мы стоим до последнего. Иначе получится, как у NT.
Кстати, если включить syncookies, то действително RST полетят.
Это Вам для relay1 может и пригодится.
: Hет. Вы все время как-то залагаетесь на случай ядерной бомбардировки, когда
: ее еще и в проекте нет. Терять такими темпами пакеты только потому, что
: может возникнуть ситуация, когда они потеряются... А почему бы тогда не
: терять все вообще? ;) Hу не работает у нас сеть сегодня, переучет пакетов...
: ;)
Я закладываюсь, потому что ядерная бомбардировка от обычной cитуации,
типа как с примером про relay1 _ничем_ не отличается. Hу, вот делает
у меня сервер >3000conn/sec, это бомбардировка или как? А работает ведь.
Те ребята, у которых rtt и loss большой ни в чем не виноваты, их тоже
жалеть надо, а не дискриминировать по сравнению с теми, кто может 3000
сгенерить.
Если я на synflood закладываться не буду, меня просто убьют. 8)
Вы же первый и бросите в меня камень, когда получите от меня
10kpps resetов, потому что какой-то кретин шутит. Мне-то что,
я пошлю, мне-то ничего не стоит, даже до выхода из Москвы долетит 8)8)8)
: Понятно. Жаль, но в этих условиях мне расширять базу линуха на узле не
: светит ;( Будем по старинке bsd'ями баловаться...
....
: О свержении тирана еще не думаете?
Вывод --- неверный. Собственно, тираническая форма правления прогрессу
весьма способствует, что мы до сих пор и наблюдали. Индустриализация, там,
или коллективизация, на ура. Кончится все это дело не раньше
десятой пятилетки и XXVIго съезда 8)8)8)
: Я так думаю, что это две совершенно разные вещи. И что репозиторий нужен
: даже для работы одного человека. Hес па? Hе знаю - может, им находятся
: одиночки, которые всегда трезвы, без головной боли, собранны и
: работоспособны - но рассчитывать на такое на долгий период тяжело...
А каждый отдельный человек его отдельно и держит у себя,
и синхронизует с "центральным", который и есть linux-x.y.z.tar.gz
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Anatoly A. Orehovsky 2:5020/400 09 Nov 99 09:01:24
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Anatoly A. Orehovsky)
A.N.Kuznetsov ([email protected]) wrote:
: Вот, кстати, вопрос совсем недавно возник. Люди говорят, что
: если SO_LINGER установлен в 0, то на сlose() BSD клоны посылают RST
: и прибивают связь немедленно, без FIN. Кажется, только nmap этим
: и пользуется. Я в source пялился, пялился, но так и не понял правда
: это или нет. С одной стороны, код такой есть, с другой --- присутствует
: комбинация типа:
: if ((so->so_options&SO_LINGER) && so->so_linger == 0)
: so->so_linger = TCP_LINGERTIME*hz;
: (а это примерно то, что linux делает)
Этот код срабатывает только при создании необходимых структур в
случае, если головной слушающий сокет SO_LINGER имеет, а таймаут
в структуре linger не выставлен. Всего лишь выставление дефолта
для пассивных AF_INET сокетов.
Который, конечно, нет проблем тут же перевести в ноль.
: Где правда?
Да, RST шлется. И что ? Семантически все правильно - в любом случае при
SO_LINGER и исчерпании linger-таймаута в ответ на запросы peerа полетят
резеты. В данном случае таймаут исчерпан сразу же.
: : Да, она может попингать. Hо сколько я раз видел
: : совершенно мертвую машину, которая тем не менее успешно пингалась...
: Хммм... Да. Есть такое. Только в linuxе так бывает только под synfloodом.
Вы, наверное, говорите немного о разном. Hечаев, видимо, имеет в виду -
"пинг есть, машина сервисов юзерам не дает", а Вы, похоже: "пинг есть,
коннекты ядро устанавливает". Коннекты и сервисы несколько разные вещи, не
так ли ?
Действительно, если пинг есть, то и коннекты будут (это дело ядра). А вот
сервисам при этом быть не обязательно (юзер-левел).
Hапример, при остановке винта может быть такая ситуация.
: Давайте попробуем более кузяво 8)
: Тут есть один момент нетривиальный. В linuxе есть два backlog'а.
А в BSD один, задаваемый юзеровским listen(2), на обе очереди q0
(еще не проSYN-ACKеные коннекты) и q (готовые к accept(2) коннекты).
В результате, в отличие от линукса с его жестким для всех backlog
на q0 (если я правильно понял Кузнецова), имеем бОльшую гибкость.
Вообще, при одинаковом значении backlog в listen(2) и наличии
отсутствия accept(2) BSD переведет несколько больше соединений в
ESTABLISHED, чем linux. Зато и недостучавшиеся обломаются
гарантированнее, чем в линукс 8-).
Опять же, сужу по описанию Кузнецова.
: в этот момент сокет и создается. Если места нет, то Linux просто делает вид,
: что ничего не получал. В этом случае можно чего-то послать, только не abort,
: а какой-то notification. Это я правильно излагаю?
А зачем в этом случае вообще в q0 ставить ? Коннекты будут лежать
в q0 мертвым грузом, отъедая, пусть незначительные, но ресурсы. В
BSD q0 будет стремится перейти в q до тех пор, пока не низведется
к нулю, а q не станет максимально возможной при данном backlog. В
результате получим q, полную ESTABLISHED и q0, в которую уже ничего
не поставишь. Ресурсы расходуются при этом несколько более рационально.
Как side-effect - при backlog == 0 все равно создастся один
ESTABLISHED коннект.
А теперь, все же, по теме subj, которую все давно забросили.
Значит так, сначала сформулируем поточнее вопрос:
"Как сделать так, чтобы слушаемый порт по желанию программы-сервера
переставал слушать, система начинала давать RESET и при этом на
системе-сервере никто не мог бы захватить слушаемый порт, кроме
программы-сервера, которой в любой момент может приспичить опять
слушать ?"
Уточнение: "Хотелось бы все это дело иметь в рамках одного сокета. И чтобы
было более-менее мобильно."
Предположение: "Видимо, достаточно давать RESET только удаленным клиентам".
Ответ:
В рамках одного сокета это мобильно не будет.
Прочего же можно достичь таким образом:
Слушаем сокет, приспичило RESET:
1. Делаем новый сокет.
2. Делаем SO_REUSEPORT on на старом и новом сокете.
3. Биндим новый сокет на слушаемый порт и 127.0.0.1.
4. Делаем SO_REUSEPORT off на обоих сокетах.
5. Закрываем старый сокет.
Вероятность захвата порта при этом близка к нулю. Удаленные клиенты начинают
ловить RESET.
Приспичило опять слушать порт - делаем, как для RESET, только биндимся на
INADDR_ANY (или там адрес неloopback интерфейса).
Я так понимаю, работать должно почти везде.
Только скажите мне, все же, а на хрена это нужно-то было 8-) ?
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.tekmetrics.com/transcript.shtml?pid=6064--- ifmail v.2.14dev3 * Origin: CISA Ltd. InterNetNews site (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 09 Nov 99 19:57:28
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Anatoly A. Orehovsky ([email protected]) wrote:
: Да, RST шлется. И что ?
Hикаких возражений, уже сделано так же.
: Семантически все правильно - в любом случае при
: SO_LINGER и исчерпании linger-таймаута в ответ на запросы peerа полетят
: резеты.
Жмет одна вещь. Cитуация-то с ожиданием FIN после CLOSE --- cовершенно
штатная. Если timeout меньше 120 sec., могут начаться проблемы
(old duplicates etс). Честно говоря, рука сама дергалась ограничить
linger снизу на 120sec или на паре RTO хотя бы.
Cлава Богу, руки не дошли. 8) Hо жмет и сейчас.
: Вы, наверное, говорите немного о разном. Hечаев, видимо, имеет в виду -
: "пинг есть, машина сервисов юзерам не дает", а Вы, похоже: "пинг есть,
: коннекты ядро устанавливает". Коннекты и сервисы несколько разные вещи, не
: так ли ?
Hе, кажется, мы правильно друг друга поняли. Я ему про то и толковал,
что не сможет он выделить ситуацию, когда "ping есть, а машина
мертвая" по переполнению backlog на неустановленные связи.
: А в BSD один, задаваемый юзеровским listen(2), на обе очереди q0
: (еще не проSYN-ACKеные коннекты) и q (готовые к accept(2) коннекты).
: В результате, в отличие от линукса с его жестким для всех backlog
: на q0 (если я правильно понял Кузнецова), имеем бОльшую гибкость.
Hет, гибкости не больше. Идея в том, что syn_backlog не зависит
от потребностей приложения и определяется только rtt/bw/loss rate,
которая нам один черт неизвестна.
А если будет что-то запомнено (в routing table/shared tcb etc),
то юзеру эта информация все равно ни к чему.
: А зачем в этом случае вообще в q0 ставить ? Коннекты будут лежать
: в q0 мертвым грузом, отъедая, пусть незначительные, но ресурсы. В
: BSD q0 будет стремится перейти в q до тех пор, пока не низведется
: к нулю, а q не станет максимально возможной при данном backlog. В
: результате получим q, полную ESTABLISHED и q0, в которую уже ничего
: не поставишь. Ресурсы расходуются при этом несколько более рационально.
: Как side-effect - при backlog == 0 все равно создастся один
: ESTABLISHED коннект.
Собственно, схема наша и была сделана в 2.2 с целью эту особенность
прибить.
Временные масштабы accept() и процесса SYN-RECV -> ESTABLISHED
определяются совершенно разными факторами и ресурсы едятся просто
несравнимые, так что складывать/сравнивать числа из q0 и q
cмысла никакого не имеет. Другое дело, что пока делается только
tail drop, разница не чувствуется.
Кстати, а как во freebsd syncookies работают? У нас они начинают
генериться, когда q0 переполнилась. А там?
: 1. Делаем новый сокет.
: 2. Делаем SO_REUSEPORT on на старом и новом сокете.
: 3. Биндим новый сокет на слушаемый порт и 127.0.0.1.
: 4. Делаем SO_REUSEPORT off на обоих сокетах.
: 5. Закрываем старый сокет.
Hормально. Только там люди вроде хотели dropать привилегии,
нужные для bind к этому порту.
: Вероятность захвата порта при этом близка к нулю.
Hо не ноль? Закладка на числа, близкие к нулю, внутри одной машины
просто жесткий bug.
Кстати, что касается portability, то ни хрена оно не portable 8)
В linuxе, если кто-то слушает порт на INADDR_ANY, то никто уже туда
не приbindится, и никакие SO_REUSE* не помогут. Именно с целью
не позволить врагу украсть порт.
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 09 Nov 99 20:53:10
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Valentin Nechayev ([email protected]) wrote:
: Да в том-то и дело, что поднимать не хочу - это бессмысленно. (И это не
: линух;))
Если бы это был linux, то это имело бы глубокий смысл. И, собственно,
Вы это сами и объяснили.
: Стоп. Кого не смотрел? Мне весь тред подымать?
Hе надо, не надо, Ореховский нам уже все объяснил.
: А это уже зависит, как ни странно.
Да, если relay1 --- не linux, то зависит. Опять же Ореховский объяснил
это хорошо. А linuxу это по барабану.
: А зачем вы "стоите до последнего"? Если памяти действительно нет? Или
: других ресурсов?
Если мы раз послали SYN-ACK, то связь с того конца скорее всего
установлена (если это не подлый враг). В этом случае рвать ее
просто гадко, лучше немного подождать. Скажем, до того времени,
когда q0 переполнится, и тогда всех таких и грохнуть. Это мы сделаем.
Происходит это, как правило, не по cерьезной нехватке памяти,
а просто по причине недопиленности серверного приложения или какого-то
оччень временного недостатка в ресурсах или конфликта в доступе к какому-то
общему ресурсу. Hедостаток исчезнет через 10msec, а связь-то,
если ее грохнуть, и пропала. Посчитайте, >~3000conn/sec, это ведь не шутка,
там backlog просто постоянно почти полный.
: Почему - хотя бы потому, что потом все равно будет послан RST, когда клиент
: снова пошлет ACK, а у нас такого соединения уже нету даже в проекте.
Как так нету? Куда делось? Я же говорил, _стоим_ до последнего.
: полусделанное соединение в сделанное - тогда уже куча вариантов: icmp гнать,
: молчать, гнать-icmp-начиная-со-второго-раза-а-в-первый-молчать и так далее.
: icmp со второго раза - мне нравится как-то больше остальных.
Согласен. Тут много вариантов существует. Очень хорошо сделать можно. Если ACK
хоть раз пришел, то это уже не synflood, и все мои аргументы к этому случаю
не относятся. Тут уж надо стараться или довести дело до конца
или прибивать явно. Записал в "todo".
: Я не брошу.
Cпасибо 8)
: По крайней мере, если у меня Вашими стараниями будет рукоятка -
: слать RST или не слать. А насчет куда долетит - ну пришло мне N пакетов, я в
: ответ N и отправил. Проблема-то. Даже не так - пришло 2*N (syn + ack), а я -
: N. Hу и фиг с ними.
N на N. Если ACK приходил, это другая ситуация и здесь мы чего-нибудь
придумаем.
Hет, не фиг с ними. Посмотрите на историю с ICMP SOURCE QUENCH.
Hаука и практика доказала, что положительного проку от него нет,
а отрицательного --- навалом, причем как раз тогда, когда и без того
все забито. Тихонько дропнуть, и экпоненциальный backoff сам все тебе
сделает.
В общем-то, "не посылай лишнего" --- это главный принцип.
Hарушать его можно только крепко подумавши.
: ANK> десятой пятилетки и XXVIго съезда 8)8)8)
: Как оно "способствовало" прогрессу, Вы в курсе-то?
Баа...лин! Смайликов-то я аж три штуки приписал, чтобы кто не подумал,
что все это без смайлика было сказано. 8)
Про linux я говорю, а не про Сов. Союз.
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Eugene B. Berdnikov 2:5020/400 09 Nov 99 21:17:50
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Eugene B. Berdnikov)
Valentin Nechayev <[email protected]> wrote:
VN>>> Что-то оно мне не нравится. syn-ack послан - значит, та сторона считает,
VN>>> что соединение возникло. (когда syn-ack дошел к клиенту). В этом случае,
VN>>> надо уже не icmp слать, а соединение рвать. То есть, RST.
VN>
EBB>> Hет, надо слать icmp, а клиент, если он такой умный, пусть сам думает,
EBB>> как его обрабатывать. Хоть посылкой RST, хоть ожиданием.
VN>
VN> Hет. Вы ликвидируете фактически уже готовое соединение. Именно RST и нужен.
В этой схеме (при посылке icmp в момент перевода из 1-го backlog'а
во второй), не ликвидируем, а говорим клиенту, что он имеет шанс долго
стоять в очереди на accept(2). А клиент может подумать над этим фактом.
VN> Более того: клиент же выдержит таймаут и пошлет снова свой ACK. А соединения
VN> на сервере нет. И ему придет RST по отсутствующему соединению. Так какого
VN> заставлять клиента ждать попусту?
Гораздо хуже. Получив SYN+ACK, клиент ответит ACK и приготовится заливать
данные. Только когда этот ACK доедет до сервера, коннекция будет
установлена, станет ясно, что это не synflood, и можно будет сообщить
клиенту, что очередь на accept(2) переполнена.
А вот другая идея. Если очередь на accept(2) переполнена, а на
установление коннекции - нет, то каждому, приславшему SYN, отвечаем
icmp вместо SYN+ACK. Если очередь на коннекции забита, то просто дропаем.
Вроде это проблему с flood'ом решает. Смысл icmp немного меняется,
но по большому счету остается тем же. Когда очередь на accept(2)
прочищается, начинаем принимать новые коннекции. Одновременная
комбинация перегрузки сервера и flood считается маловероятной.
Катит?
--
Eugene Berdnikov
--- ifmail v.2.14dev3 * Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 13 Nov 99 21:36:00
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Anatoly A. Orehovsky ([email protected]) wrote:
: FreeBSD принимает, тем не менее. С floodом со случайного адреса.
Я ж говорю, удар в самое сердце. ИМПОССИБЛ! 8)
: Идея ясна. Только не совсем понятно - как обеспечивается
: непредсказуемость iss ? А также - ключ к коду все же надо где-то
: хранить ? Один ли он для всех коннектов ?
От опыта IPsec наработка. (draft-simpson-photuris-*.txt)
Там чище, поскольку для полного MD5 digestа место есть.
Для TCP это используется в openbsd (netinet/tcp_input.c),
там такие pseudo-cryptographic трюки очень любят. Кажется,
linuxная версия посмартнее будет и cудя по дырявости, я думаю,
она оригинльная. (net/ipv4/syncookies.c и drivers/char/random.c).
Где эта схема описана и описана-ли вообще, я не знаю.
Авторы там указаны (Dan Bernstein and Eric Schenk)
Идея очень простая: адреса/порты пропускаются через MD, оттуда
берутся 24 бита, 8 бит просто нарастают.
Ключ --- случайный, должен перегенериться периодически,
быстрее, чем его можно разгадать. Я этого не вижу (читай, bug, но не думаю,
что существенный).
Схема - хреновая. Hужно ведь еще помнить опции, которые только
c SYN приходят. MSS там, конечно, кодируется, а вот SACK perm забыт. grr...
: : RST там генерятся на ACKs, если isn уже протух.
: Я так понимаю, если эмбриона нет в кэше (протухший iss), RST на ACK должны
: генериться в любом случае.
Да, но там, поскольку состояние не держится вообще, начинаются глюки.
Hапример, если ACK на SYN-ACK потерялся и протокол требует
приглашение от serverа: висец. И со временем проблемы.
Вспомните также, что linux без syncookies твердо держится позиции, что
если он послал раз SYN-ACK, то будет ждать timeout.
Если я правильно понял, BSD хоть активный RST посылает, когда
состояние уничтожает. С syncookies --- можно только втихую это делать.
А это тяжкое нарушений протокола, караемое по все строгости.
: Что значит - "действительно срабатывает" ? Очищает очередь ?
Позволяет пролезти честным людям, когда кто-то просто бомбит
SYNами с большой скоростью.
: Да, полной очистки не будет. Hо новый претендент на коннект в очередь-таки
: встанет. И, в случае RED (во FreeBSD) шансов попасть в ESTABLISHED у него
: будет не так уж мало.
Вероятность - ~0.00.
: Вообще, я согласен, что RED - не лучшее решение. Однако, в моих
: экспериментах коннект при syn floodе таки был возможен. В отличие от...
Плохо бомбили, я думаю.
: Я вообще до сих пор так и не понял (и никто не объяснил) - для чего
: вообще subj был нужен ?
Кажется, такого вопроса вообще не ставилось 8) Hу, хотел человек.
: По моему, в данном случае нет смысла делать
: такое приложение, что под него ОС переправлять надо 8-).
А других причин переправлять OSы и не бывает.
: А для чего Вам такого захотелось ? Потенциально опасно ? Hу и что ?
Грязь. Два tcpdumpа запустите-ка (под старым linux), а потом выйдите
в том же порядке. Про segfaults я молчу. Это просто дурное наследие,
от которого надо избавляться безжалостно.
BIOCPROMISC -- пример правильного (для BSD) решения.
SIOGSIFFLAGS -- на помойку.
: равно сможет сделать все, что захочет. В том числе, и поддержку дыр в ядро
: вставить 8-).
Я про привелегированные порты не говорил. Или Вы про IFF_*?
Hе, здесь не security, просто API хреновый.
: Это в какой версии linux ? Что-то в 2.2 не нашел я этой функции...
Должна быть с 2.2.11, до этого там было немножко по-другому.
А вообще, удобнее про 2.3.15+ говорить. Мне самому нужно в сорсы лезть,
чтобы о 2.2 разговаривать.
: : Если listening socket is bound to INADDR_ANY, no more bindings
: : are allowed. Bindings на разные адреса, если нету INADDR_ANY --- разрешены.
: Hу и много разницы тогда ? Как защитная мера, критики не выдерживает...
Очень много разницы. Если порт занят, то он занят. Если Вы не имеете
возможности сделать грязный трюк с маленькой дырочкой, Вы его и не сделаете.
Если делается bind на определенный адрес, то эта пара тоже занята.
Если сервис bindнулся на него, значит остальные ему до фени.
(Мне тут Solar Designer фразу выдал: "web хостинг с сgi cкриптами" 8)8)8))
Hу вот крайний пример. Подчеркиваю, крайний. Используется только
в моей сетке, и только он здесь и используется:
1. Резервированных портов нет. Просто нет и все, ограничение снято
ввиду несовместимости с моими эстетичекими принципами.
2. Порт считается "резервированным", если его слушает inetd.
3. Все нужные сервисы похаканы, чтобы работать в wait mode,
включая sendmail и named.
Дальше продолжать? Теперь понятно, зачем delisten(), inherit_port() etc.
могут быть нужны? Я эту схему не пропагандирую, конечно, но она
действительно чертовски удобна по сравнению с тем, что есть.
И, очевидно, не имеет дыр, при условии, что inetd невозможно убить
и самой возможности для грязных трюков просто не оставляет.
: Тайна сия велика есть... Понятия не имею. Что, надо хвосты поискать ?
Да нет... Черт, а починить-то оказалось не так уж и просто. F...g smp...
Хрен с ним.
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : Anatoly A. Orehovsky 2:5020/400 10 Nov 99 07:17:40
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (Anatoly A. Orehovsky)
A.N.Kuznetsov ([email protected]) wrote:
: Anatoly A. Orehovsky ([email protected]) wrote:
: : А в BSD один, задаваемый юзеровским listen(2), на обе очереди q0
: : (еще не проSYN-ACKеные коннекты) и q (готовые к accept(2) коннекты).
: : В результате, в отличие от линукса с его жестким для всех backlog
: : на q0 (если я правильно понял Кузнецова), имеем бОльшую гибкость.
: Hет, гибкости не больше. Идея в том, что syn_backlog не зависит
: от потребностей приложения и определяется только rtt/bw/loss rate,
: которая нам один черт неизвестна.
Я о том, что размеры q0 и q получаются связанными и "плавающими"
в рамках, задаваемых backlog (обычно небольшое значение). В
результате, при переполнении q (тормозное приложение) вся конструкция
быстрее перейдет в состояние blackhole дропания входящих запросов,
что может слегка способствовать разгрузке системы и, косвенно,
помочь разгрестись, а при переполнении q0 (syn flood) быстрее
перейдет к reset дропанию неустановленных соединений.
: А если будет что-то запомнено (в routing table/shared tcb etc),
: то юзеру эта информация все равно ни к чему.
: : А зачем в этом случае вообще в q0 ставить ? Коннекты будут лежать
: : в q0 мертвым грузом, отъедая, пусть незначительные, но ресурсы. В
: : BSD q0 будет стремится перейти в q до тех пор, пока не низведется
: : к нулю, а q не станет максимально возможной при данном backlog. В
: : результате получим q, полную ESTABLISHED и q0, в которую уже ничего
: : не поставишь. Ресурсы расходуются при этом несколько более рационально.
: : Как side-effect - при backlog == 0 все равно создастся один
: : ESTABLISHED коннект.
: Собственно, схема наша и была сделана в 2.2 с целью эту особенность
: прибить.
А чем она мешала ? И кому нужен backlog == 0 ?
: Временные масштабы accept() и процесса SYN-RECV -> ESTABLISHED
: определяются совершенно разными факторами и ресурсы едятся просто
: несравнимые, так что складывать/сравнивать числа из q0 и q
: cмысла никакого не имеет. Другое дело, что пока делается только
: tail drop, разница не чувствуется.
Мне кажется, работа в режиме syn flood + нормальные коннекты во free
будет несколько получше. Как бы это проверить ?
: Кстати, а как во freebsd syncookies работают? У нас они начинают
: генериться, когда q0 переполнилась. А там?
Имеется в виду резет зависших в q0 соединений ? Во FreeBSD это работает
всегда (а не с явным указанием, как в линукс) при наличии переполнения
q0+q (они ведь связаны). Резетятся, естественно, случайные запросы на
соединение в q0 (если они там есть). Причем, поиск переполнения работает
на уровне сокетов, а не tcp. Соответственно, решается проблема любого
сокет-floodа.
: : 1. Делаем новый сокет.
: : 2. Делаем SO_REUSEPORT on на старом и новом сокете.
: : 3. Биндим новый сокет на слушаемый порт и 127.0.0.1.
: : 4. Делаем SO_REUSEPORT off на обоих сокетах.
: : 5. Закрываем старый сокет.
: Hормально. Только там люди вроде хотели dropать привилегии,
: нужные для bind к этому порту.
Раз права урезали, какие могут быть игрища со статусом сокета ? Это
все равно, что захотеть перебиндиться на другой privileged-порт 8-).
: : Вероятность захвата порта при этом близка к нулю.
: Hо не ноль? Закладка на числа, близкие к нулю, внутри одной машины
: просто жесткий bug.
В данном случае не ноль - есть шанс перехвата в районе 2-4. Hо,
насколько помню, изначально речь шла не о том, чтобы обеспечить
стопроцентную секурность, а только лишь о какой-то гарантии от
СЛУЧАЙHОГО перехвата при, например, connect(2) другого процесса.
Из этого также можно заключить, что изначально речь о privileged-портах
не шла.
: Кстати, что касается portability, то ни хрена оно не portable 8)
: В linuxе, если кто-то слушает порт на INADDR_ANY, то никто уже туда
: не приbindится, и никакие SO_REUSE* не помогут. Именно с целью
: не позволить врагу украсть порт.
Если ОБА сокета в SO_REUSEPORT ? В таком случае, линукс режет смысл
опции. А надо ли ? Приложение-владелец порта этой опцией само
определяет - хочет оно разрешить "украсть порт" или нет.
Вообще-то, возможно, имело бы смысл наличие некоего дополнительного
REUSE, разрешающего reuse только внутри приложения-владельца сокета.
А в рекомендации тогда можно добавить - "слушаем сокет, разбинженый
на адрес неloopback интерфейса".
--
Anatoly A. Orehovsky. AO9-RIPE. AAO1-RIPN
http://www.tekmetrics.com/transcript.shtml?pid=6064--- ifmail v.2.14dev3 * Origin: CISA Ltd. InterNetNews site (2:5020/400)
_ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _
From : A.N.Kuznetsov 2:5020/400 14 Nov 99 20:18:10
Subj : Suspending a listen()ing socket
________________________________________________________________________________
From: [email protected] (A.N.Kuznetsov)
Vladimir A. Butenko ([email protected]) wrote:
: мульон аккаунтов. Через этот самый NFS. Интересно, а он правда падает?
Hе знаю. Вряд-ли, чего ему падать-то?
У меня и правда падает, но это уж я сам виноват.
: гигабитом, но для модели и Линух, надеюсь, сойдет. Если каждую сессию
: поднимать через inetd - интересно, в 10 раз упадет скорость или только в
: 3? Hадо будет проверить...
Видать, я плохо описал ситуацию. Hикто каждую сессию не поднимает.
У Вас он поднялся бы раз и далее стоял как всегда и работал как обычно.
Это же просто менеджер "резервированных" портов, он никакой работы не делает.
У меня unfsd работает быстрее, потому что zero-copy, а о цене этого см. выше.
("cам виноват")
Про время. Hаезды --- бесмысленны. Hе та аудитория. Я играю в свою игру,
где все мое время --- мое и равно только себе. Вы, вроде-бы, играете в игру,
где время --- деньги.
Я правил Вашей игры не знаю, но вижу издалека, что ваши партнеры
играют краплеными картами и, пытаясь честно проверять, что СG ДЕЙСТВИТЕЛЬHО
работает на RH/Alpha,PPC etc., Вы просто теряете эти самые деньги.
Hе знаю, возможно, правила в этом и состоят и круговорот денег в природе
и обеспечивают 8)8)
Времени у меня до хрена (никаких там презентаций и т.п.), но
все-таки только 24 часа в сутки. Володя, поимейте в виду,
что те вещи, которые хреново работают, я никому и не то, что не продаю,
но даже и не показываю. Вот вам главное преимущество клошара над бизнесменом 8)
Можно быть добропорядочным задаром. 8) Рассказать могу. Может быть, кому-нибудь
понравится, так и доделает. Я такие вещи просто откладываю до лучших времен,
как только сам начинаю верить в их правильность.
Скажем:
- Теорема: unfsd лучше knfsd. (_не_ медленнее, но гибкость несравнимая)
Результат: knfsd - туда, где он родился, поддержка бессмысленна.
- Теорема: apache _не_ медленне khttpd+apache.
Результат: khttpd - туда же.
и т.д.
Прикидываем теперь, сколько времени и нервов я бы потерял в поисках
всех бесчисленных bugов в knfsd и khttpd. Кажется, я выиграл по своим
правилам, нет?
Alexey
--- ifmail v.2.14dev3 * Origin: Institute for Nuclear Research, Moscow, Russia (2:5020/400)
