= Сообщение: 1192 из 5336 ========================================= RU.HUSKY =
От : Pavel Gulchouck 2:463/68 24 Jun 15 11:06:20
Кому : Ivan Agarkov 24 Jun 15 11:06:20
Тема : Многозадачность HPT, связка с binkd
FGHI : area://RU.HUSKY?msgid=2:463/68+558a6c34
На : area://RU.HUSKY?msgid=2:5020/849.1+5586cd5c
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Hi Ivan!
21 Jun 15, Ivan Agarkov ==> Pavel Gulchouck:
IA> Pavel Gulchouck писал(а) Ivan Agarkov в 10:08 21 июн 15
PG>> Как минимум, в некоторых случаях тоссер оставляет часть почты не
PG>> запакованной (либо из-за наличия bsy на линка, либо когда файликов pkt
PG>> слишком много), и если запускать тоссер не по крону, а по событиям,
PG>> есть риск либо получить большие задержки почты, либо сильно усложнить
PG>> скрипт, сделать его зависимым от внутренней структуры hpt, и получить
PG>> риск работающего в бесконечном цикле тоссера. Запуск по крону проще и
PG>> надёжнее. Холостой запуск (при отсутствии почты в incoming)
PG>> практически не потребляет ресурсов.
IA> Мне, как дитю Интернета, всегда была глубоко неприятна задержка между отправкой сообщения и его доставкой, поэтому я всеми
IA> силами пытаюсь этого избежать. Кстати, чисто теоретически: а что мешает интегрировать binkd и husky на уровне событий? Это
IA> ведь одна из самых распространенных связок софта в настоящее время. Достаточно ведь реализовать daemon mode для husky и
IA> реализовать отправку простейших команд на 127.0.0.1 ( растоссь почту, отправь почту, etc )
Я проблему вижу в том, что принципиально ты таким способом скорость доставки не увеличишь. Приближению к секундам (или даже миллисекундам) между приёмом сообщения и его отправкой даунлинкам, как это есть в INN, мешают bsy, pkt, arcmail... Что и неудивительно, ведь вся эта схема оптимизирована под диалап, где основным критичным ресурсом является не скорость прохождения сообщения, а время занятости телефонной линии. Чтобы оптимизировать под интернет (с возможностью хоть постоянных соединений между линками), заботясь о времени доставки сообщений, нужно переделать очень многое: обмен сообщениями, а не пакетами; обработка непосредственно после приёма (отправка на пайп тоссеру?); экспорт сообщения линку, с которым активна сессия (отправка на пайп мейлеру?) и т.д. Эволюционным путём, т.е. мелкими последовательными улучшениями, боюсь, этого не достичь, и получится как возвратный гортанный нерв у жирафа, который идёт от гортани к головному мозгу, по пути огибая аорту, т.е. проходит через всю шею дважды (туда и обратно) без возможности это оптимизировать. :)
IA> И да, если мне сейчас комьюнити дружно предложит прислать патчи - ну, пришлю наверное :-)
IA> Если это конечно кому-то надо.
Daemon mode для hpt было бы интересно. Хотя, с другой стороны, много ли на этом выиграется? Запуск hpt (загрузка в память и динамическая линковка) вряд ли дольше миллисекунды, это пренебрежимо мало по сравнению с временем распаковки и запаковки arcmail.
Наверное, было бы хорошо сделать рескан binkd по сигналу, а ещё - если бы hpt писал в файл список узлов, для которых появилась новая почта, а binkd при рескане читал информацию из этого файла (при его наличии), а не ресканил весь большой BSO. Примерно как голдед формирует список арий, которые нужно сканировать, и hpt сканирует только их, а не всё подряд.
Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5
* Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
|
