= Сообщение: 2033 из 2457 =================================== RU.FTN.DEVELOP =
От : Alexey Vissarionov 2:5020/545 09 Jan 22 09:18:18
Кому : Nil A 09 Jan 22 09:18:18
Тема : Фидодевелопмент - давайте обсуждать тут, а не по .pr и .nextgen
FGHI : area://RU.FTN.DEVELOP?msgid=2:5020/545+61da7e32
На : area://RU.FTN.DEVELOP?msgid=2:5015/46+61d8bdc9
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5015/46+61ea125e
==============================================================================
Доброго времени суток, Nil!
08 Jan 2022 01:01:34, ты -> мне:
NA>>> Или вот binkd, например. Не знаю, были ли уже в то время
NA>>> библиотеки libevent, libev, libuv (это уже новее),
AV>> Может, тебе еще и epoll() во всякие смешные системы портировать? :-)
NA> Подобная библиотека как раз и создана решать задачу трансляции
NA> высокоуровневых асинхронных вызовов во что-то доступно в ОС,
NA> например, старый добрый select(2), с его ограничениями, разумеется.
Ну и нахрен он такой нужен? Ладно, на фидошный мылер нагрузка никакая, да и справлялись же как-то во времена модемных каналов и мегабайтов ОЗУ...
NA> Как пример, Libuv вообще делает асинхронными дисковые операции,
NA> которые на epoll() не повесишь,
С чего бы вдруг? Дескриптор - он в любом случае дескриптор, а что там за ним - известно только ядру.
NA> и всё это эмулируется через пул-воркертредов.
Еще и треды... epoll тем и хорош, что все дескрипторы обрабатываются в одном потоке.
NA>>> но куча кода для кросс-платформенной работы с сокетами могла бы
NA>>> уйти.
AV>> Куда и зачем?
NA> Вместо того, чтобы пытаться поддержать разные асинхронные сокеты
NA> на разных ОС, в виде развесистых #ifdef, можно сфокусировать своё
NA> внимание, непосредственно, на имплементации binkp протокола,
NA> причём, используя высокоуровневые scatter-gather IO.
Протокол уже доведен до функциональной полноты. А привязывать его эталонную реализацию к каким-то библиотекам лучше не надо.
NA>>> Ещё там какие-то предупреждения по поводу тредов, надо пользоваться
NA>>> форками,
AV>> Треды совершенно точно фпень, а с момента появления epoll() -
AV>> напомню, это произошло в ядре 2.6 и glibc 2.3 где-то в 2004 году - и
AV>> форкаться нужды нет.
NA> (a) на сегодняшний день epoll() не используется в коде binkp
Там не те нагрузки...
NA> (б) epoll() реализован только в Linux, а хочется запускать там, где
NA> это делается через kqueue(),
А зачем?
NA> или через Windows IOCP,
Вот разве что...
NA> и т.д.
А больше живых систем и не осталось.
NA>>> Можно, например, научить binkd читать fidoconfig, ведь там линки
NA>>> с паролями уже есть, только добавить секцию бинк-специфичных
NA>>> опций.
AV>> Каких?
NA> Все настройки из binkd.conf не относящиеся к линкам, и не
NA> дублирующиеся в fidoconfig - их можно поместить как if
NA> "[module]"=="bink"
Зачем? Единственное, что может иметь хоть какой-то смысл - использовать fidoconfig в качестве password-файла. А информацию о способах соединения получать напрямую из нодлиста.
NA>>> А так что ещё допиливать? Добавить по-взрослому рейт-лимиты,
NA>>> чтобы противостоять натиску DDoS?
AV>> Нахрена это userspace-приложению?
NA> Тут скорее не приложение, а демон.
Да хоть жопа с ручкой... работает в userspace - значит, приложение.
NA> При ограниченности ресурсов, можно сфокусироваться на обслуживании
NA> легитимных клиентов, и меньше ресурсов тратить на ботов. Да,
NA> юзерспейс приложение также может добавлять правила для ядерного
NA> фильтра,
Кто его туда пустит?
NA> чтобы зловред трафик отшибать сразу там, но все решения принимаются в
NA> самом юзерспейс-демоне.
Если флуд дошел до приложения, принимать решения уже поздно.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Чужие темплейты читают только ламеры с IQ<64
--- /bin/vi
* Origin: ::1 (2:5020/545)
|
