From a0047cddb3b91ace87dc822ba2539e11f437d9f1 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Sat, 23 Jan 2021 23:46:13 +0300 Subject: [PATCH] =?utf8?q?=D0=97=D0=B0=D1=80=D0=B5=D0=BB=D0=B8=D0=B7=D0=B8?= =?utf8?q?=D0=BB=20NNCP=206.0.0?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit https://lists.cypherpunks.ru/pipermail/nncp-devel/2021-January/000198.html * Починил -autotoss работоспособность при работе nncp-daemon в режиме inetd. Точнее она и не ломалась -- почему то я её просто для этого режима не добавлял. Причин не было, просто тупил * Добавил опцию при которой nncp-caller может совершить вызов только если есть исходящие пакеты. Внезапно, оказалось что cronexpr библиотека, которую я использую для парсинга cron выражений -- без проблем поддерживает даже секундны! А это значит что, совмещая с when-tx-exists опцией, можно сделать autodialler -- который будет хоть ежесекундно проверять наличие новых пакетов и связываться для их отправки * Ну и наконец-то я осуществил своё ещё прошлогоднее желание о том, чтобы перевести логи в формат recfile-ов. Я популяризатор RFC 3339 формата структурированных логов: в ivi и на текущей работе. Но сейчас сам же от них отказываюсь. У меня нет полной уверенности в том что творю, ведь SD-structured логи честно являются одной строкой -- одной записью. Но в Python софте они не актуальны, ибо traceback-и выбрасываются на много строчек, что делает такой журнал нифига не валидным с точки зрения SD. recfile-ы же и гораздо легче парсятся, и уже есть инструментарий, и куда более человекочитаемы. А ведь логи в NNCP это всё же не совсем только журнал, но и штука по которой в теории предполагалось строить отчёты из серии сколько трафика мы обменяли с такой то нодой в этом месяце, построить графики какие-нибудь. Сам я это так и не осуществил, ибо потребностей не было, но с recfile-ами это уже существенно проще будет проделать -- 2.48.1