From 259e5a1ada6def235f446031e154ea30e8ff50f2 Mon Sep 17 00:00:00 2001
From: Sergey Matveev <stargrave@stargrave.org>
Date: Sun, 11 Jul 2021 22:18:35 +0300
Subject: [PATCH] =?utf8?q?NNCP=20=D0=B1=D0=B0=D0=B3=D0=B8=20=D0=B8=20?=
 =?utf8?q?=D0=BE=D0=BF=D1=82=D0=B8=D0=BC=D0=B8=D0=B7=D0=B0=D1=86=D0=B8?=
 =?utf8?q?=D0=B8?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit

http://lists.cypherpunks.ru/archive/nncp-devel/2107/0249.html
Один человек использует NNCP с Raspberry Pi и у него получилось
воспроизвести проблему с обрезанными пакетами и другой чертовщиной.
Выяснилось что 32-х битная система делает некорректные пакеты. Везде
старался делать int64 где может быть большой размер (например файла,
а не внутреннего буфера), но в самом важном месте, во время создания
шифрованного пакета -- был простой int, из-за которого могли получаться
или отрицательные значения размера или просто меньшие по размеру.
Поставил себе 32-х битную FreeBSD -- с новой версией всё исправилось.

Вообще я частенько про себя думаю что "ну кто ж будет то запускать и
использовать 32-бит софт на ПК"? Но RPi штука хорошо подходящая для NNCP
и распространённая в природе -- всё же не хочется забивать на подобную
платформу.

Ещё я начал было писать функциональные тесты на sharness, но забуксовал
на том, что конфиг в NNCP это Hjson, который хоть и может быть легко
преобразован в JSON, но как с ним работать то добавляя/удаляя/меняя
поля? jq (а точнее я сейчас использую gojq, jq удалил напрочь) позволит
прочитать поля, но не изменить что-то в дебрях внутри. Недавно узнал про
jo и gjo утилиты (40cb8a257f73cc02ea67ad7d50d6a5064ccda81b) и как раз к
месту пригодились и на них начал писать вот такие портянки:

    [...]
    idB=$(gojq .self.id $spoolB/cfg.json)
    exchpubB=$(gojq .self.exchpub $spoolB/cfg.json)
    signpubB=$(gojq .self.signpub $spoolB/cfg.json)

    cfgA=$(gjo \
        spool=$spoolA log=$spoolA/log \
        self=$(gjo id=$idA \
            exchpub=$exchpubA exchprv=$exchprvA \
            signpub=$signpubA signprv=$signprvA \
        ) \
        neigh=$(gjo \
            self=$(gjo id=$idA \
                exchpub=$exchpubA exchprv=$exchprvA \
                signpub=$signpubA signprv=$signprvA \
            ) \
            nodeB=$(gjo id=$idB \
                exchpub=$exchpubB exchprv=$exchprvB \
                signpub=$signpubB signprv=$signprvB \
            )
        )
    )

Вроде бы ужасно, но в принципе даже читаемо глазами вполне. Но до самого
теста дело всё равно так и не дошло, психанул, и добавил возможность
преобразовывать конфиг в директорию, полностью по аналогии что видел в
mlmmj (aac872add6b3defe52aef4d70dbb54a6fcddf973) где всё в виде простых
текстовых файлов, флаговых файлов и поддиректорий.
http://www.nncpgo.org/Configuration-directory.html
Это в тестах очень легко будет модифицировать. NNCP внутри себя может
сконвертировать эту директорию в JSON (точнее структуру аналогичную
после декодирования JSON), так же как и Hjson сначала конвертируется в
JSON. Ну и в принципе автоматизации это стало поддаваться, ибо мысль не
покидает о явном неудобстве списка подписантов multicast area
(ed3fd3765f912c43a16adf4f7032b851a447c695).

Плюс окончательно прооптимизировал реализацию MTH
(26d0fad8f0c8e523ec77c70dec244afc2c0e86e3). Старая осталась
исключительно как reference (можно вызвать через nncp-hash -force-fat).
А новая реализация значительно сократилась по коду, что меня удивило, и
потребляет только самый необходимый минимум памяти: как только
появляются элементы которые можно "схлопнуть" -- сразу хэшируются и
создают элемент более высокого уровня. И это применяется и к докачке тоже.
Думал что будет значительно всё сложнее, но нет.
-- 
2.48.1