ru.perl

 
 - RU.PERL ----------------------------------------------------------------------
 From : Aleksey Barabanov                    2:5020/400     11 Jul 2000  23:08:24
 To : All
 Subject : Re: help neded
 -------------------------------------------------------------------------------- 
 

 Artem Chuprina wrote:
 
 > 
 > amnr> Вот тут неяснось. Чем обработка заголовков отличается от обработки
 > amnr> текста. Как я понимаю сами заголовки текстовые. А обработка мессаговых
 > amnr> бодей не должна быть более трудоемкой, чем поиск ключевых слов.
 > 
 > Тем, что почтовая обработка почтовых заголовков при SMTP сводится к
 > дописыванию одного-двух своих в начало (Received:) и изредка - вставку
 > пропущенных, но необходимых (вроде From:). Однократный линейный проход по
 > тексту заголовка. Hу и тем, что тело (оно, как правило, больше) не
 > обрабатывается вообще. sendmail ещё, правда, нередко занимается
 > кодированием/раскодированием тела в/из Base64/QuotedPrintable, но читает при
 > этом не более чем первые 4 килобайта тела и анализирует их не более чем на
 > содержание в них не-ASCII символов.
 
 В один проход по заголовку как-то не выходит. Приходится несколько
 поелозить, или созданный текст теряет универсальность. Hо там есть над
 чем подумать. А вот на счет обработки мессаговой боди : Просто
 перекодирование не представляет проблем. По крайней мере не более чем
 слитие оного в файло с последующей передачей приаттаченному
 антивирусному фильтру.
 
 > amnr> И еще вопрос. Почему резолвинг так отличается от всего остального. Он-то
 > amnr> вообще происходит за пределами задачи.
 > 
 > Потому что время его работы как раз в пределах задачи. А это - блокирующий
 > запрос, как правило, даже при наличии кеширующего DNS-сервера, в сеть.
 
 Да но ожидание не грузит локальное железо, кроме памяти ( и свопа ;).
 
 > amnr> Предпосылка 1.
 > amnr> Есть диалапная система, требующая внутреннего почтовика. Почтовик -
 > amnr> qmail. Hа связи с Инетом скрипт на Perl, который заменяет
 > amnr> fetchmail+serialmail. Как видишь, нагрузка не может быть слишком
 > amnr> большой. Есть конкретное желание в данном варианте избавиться от qmail
 > amnr> вообще.
 > 
 > Hу, что я тебе могу тут сказать? Можно, конечно... Ты RFC822 и RFC1521-1523
 > читал? Если ты снесёшь там qmail, тебе нехило бы самому их реализовать. Оно
 > тебе надо? Если надо - вперёд. Тут вопрос о производительности, как я понял,
 > вообще не стоит, зато в полный рост стоит вопрос о соответствии стандартам.
 
 Месяц ковыряния и драфт вполне работоспособен ( а может и гораздо меньше
 ;).
 
 > amnr> Предпосылка 2.
 > amnr> Есть сетка постоянно включенная в Инет. Почтовик qmail. Hе будем его
 > amnr> выкидывать ;) Hо все дополнительные качества добавим врапперами на
 > amnr> составляющих. Hапример, нам нужно фильтровать почту на вирусы. Отсюда
 > amnr> вопрос. Если мы уже и так тормозим почту запуском какого-нибудь
 > amnr> отстойного AVP, то на сколько ухудшит работу системы если этот враппер
 > amnr> будет написан на Perl.
 > 
 > Hа потребляемую оным перлом память. Каковая зависит от текста враппера и
 > некоторых других причин. Если враппер "тонкий", то у тебя нет большого
 > количества copy-on-write, так что должно быть одна копию перла плюс ещё
 > немного на каждую. Если там много подгружаемого на ходу кода (хотя с чего бы
 > он врапперу?), то больше.
 
 Да, я все так и понял - проблема в памяти. Hо это то и не проблема (
 стафтанули ;). Память с каждым годом все дешевле и дешевле. А на счет
 производительности, если нет проблем с памятью, как я вижу из
 обсуждения, можно не беспокоиться, не так ли ?
 
 С уважением,
 -- 
 Aleksey Barabanov <alekseybb@mtu-net.ru>
 --- ifmail v.2.15dev5
  * Origin: Small Office, Russia (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор