URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 119980
[ Назад ]

Исходное сообщение
"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."

Отправлено opennews , 06-Мрт-20 10:35 
В опубликованной две недели назад ветке BIND 9.16.0 выявлена серьёзная ошибка, приводящая к исчерпанию лимита на число TCP-соединений. В BIND 9.16 была предложена новая сетевая подсистема, переведённая на механизм асинхронной обработки запросов на основе библиотеки libuv.  Из-за ошибки в данной подсистеме счётчик активных TCP-соединений при некоторых условиях не уменьшается, что приводит к нарастающему расхождению его значения с фактическим числом соединений. Через какое-то время значение счётчика может достигнуть установленного лимита на число клиентских соединений и новые запросы по TCP перестанут приниматься (запросы по UDP продолжат обрабатываться)...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52490


Содержание

Сообщения в этом обсуждении
"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено Аноним , 06-Мрт-20 10:35 
Зачем соединяться с BINDом по TCP, если можно по UDP?

"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено null , 06-Мрт-20 10:41 
по UDP не всё можно просунуть

"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено Аноним , 06-Мрт-20 16:28 
Вроде бы современный DNS-сервер с легкостью посылает фрагментированные пакеты любой длины. Хотя стандарт требует вписываться в 512 байт при использовании UDP.

"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено vantoo , 08-Мрт-20 17:11 
> Хотя стандарт требует вписываться в 512 байт при использовании UDP.

508


"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено Аноним , 06-Мрт-20 10:50 
https://www.opennet.ru/opennews/art.shtml?num=51102#dnsflag

"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено Аноним , 06-Мрт-20 11:17 
А ещё в нём память течёт. Пришлось вернуть 9.11.

"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено Michael Shigorin , 07-Мрт-20 01:00 
См. тж. версии bind на http://distrowatch.com/alt -- и патчи, вдруг да пригодятся: http://packages.altlinux.org/bind

"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено Gogi , 06-Мрт-20 13:33 
> ...переведённая на механизм асинхронной обработки

ВОТ где зло!

Настоящий инженер не будет по натуре синхронную вещь коверкать в асинхронную. Ну а если таки испортили - получите весь ворох проблем.

Нет никакой проблемы в синхронных вещах. Ты соединился - всё, это твой канал, ты в нём работаешь. Любой прочитанный байт - твой. Все остальные сетевые прибулы - форкайтесь рядышком и сидите на своих каналах. Это же простейшая, идеальная схема!


"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено Аноним , 06-Мрт-20 14:31 
> простейшая

Да.
> идеальная

Нет.


"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено йо ж , 06-Мрт-20 16:55 
Осталось избавиться от ненужных многопоточности и многозадачности, а на уровне железа - от мультиядерности процессоров.

"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено крок , 07-Мрт-20 14:31 
Унылый троль, бинд занялся проблемой 10к, которой другие занимались 20 лет назад. Форкатся на каждый чих - сами таким уг пользуйтесь!

"Ошибка в BIND 9.16, приводящая к нарушению обработки TCP-сое..."
Отправлено Ordu , 08-Мрт-20 10:53 
> Настоящий инженер не будет по натуре синхронную вещь коверкать в асинхронную.

Сетевой ввод/вывод -- это по природе асинхронная вещь. Есть костыли, которые позволяют работать с ней как с синхронной -- fork, pthreads, юзерспейс потоки, но юзерспейс потоки почему-то непопулярны в сишечке, а fork с pthreads кладут систему, когда соединений много.