hbs2/devlog.md at 7e3b17ae832f9d94f94edbb6ea2fce53defd6b8c

9.4 KiB

Raw Blame History

2023-02-12

TODO: peer-accept-block-announce-feature

Добавить конфиг
Добавить настройки приёма блоков и пингов
Добавить чёрный список узлов

2023-02-09

TODO: MerkleWrap-to-MerkleAnn-or-AnnMerke

($context (commit d81038140c795e1cf30cfa05e95630ca1e639427) (file hbs2-core/lib/HBS2/Data/Detect.hs 143) )

Заменить MerkleWrap на AnnotatedMerkle или MerkleAnn

Смысл --- Merkle дерево с аннотацией.

AnnRef, получается, более не нужны. Ссылка всегда ссылается на дерево, наверное, всегда аннотированное.

У ссылки, в свою очередь, есть ссылка на AccessControlBlock.

TODO: encryption-keys-into-credentials-file

дизайн данных:

data Credentials = Credentials SignKey [(KeyId, KeyMetadata, KeyPair)]

он же "keyring", это буквально связка ключей.

операции:

  hbs2 keyring list  <keyring-file>

показывает публичные ключи в связке и их типы и прочее

hbs2 keyring add-new [-n key-id] <keyring-file>

добавляет ключ

hbs2 keyring del -n key-id <keyring-file>

удаляет ключ

Этот же формат ключ можно использовать и самому пиру, т.к. ему тоже нужны будут потом ключи шифрования.

Единственное, пир должен знать какой ключ из связки использовать, но это может быть либо по умолчанию первый ключ, либо передавать как-то в конфиге или же аргументах.

2023-02-07

FIXME: suckless-conf

Настало время выдохнуть и сделать fixme, потому, что их становится слишком много.

FIXME: Более мудрый алгоритм для pokePostponed

Сейчас оно слишком часто просыпается и забрасывает блоки в общую очередь, что приводит к busyloop в blockDownloadLoop. Введение HasTimeLimits улучшило ситуацию, но не сильно. Алгоритм должен быть что-то наподобие:

Посмотрели, сколько раз блок процессировался подряд. Если больше, чем X - то (что?) в общем, выкинули обратно в postponed.

С другой стороны, может GetBlockSize можно рассылать из pokePostponed, и просыпаться, если пришёл размер нашего блока

2023-02-06

Ну а так, базовый PEX заработал

TODO: Добавлять пиров в KnownPeers только после того, как они пинганулись. Т.е пинговать пиров, если их еще нет. Не добавлять в KnownPeers до того, как ответили на пинг.

TODO: Научиться убирать дубликаты пиров.

Их можно распознать по PeerNonce, но непонятно, какой из пиров оставлять. Иначе это будет реально большая проблема при скачивании.

TODO: Убедиться, что subscribe на перманентное событие НИКОГДА не вызывается в рекурсии.

Проверить ВСЕ subscribe. Возможно, вставить проверки в рантайм. Возможно, ограничить число таких событий и ругаться в рантайме.

FIXME: При вычислении burst надо каким-то образом находить плато и не лезть выше него.

FIXME: Задержку в очередь пиров при рассылке GetBlockSize, что бы не спамить пиров, пока запрос не уехал в отстой. Надо для каждого пира поставить задержку в 0.5 defBlockInfoTimeout или наоборот, в 1 defBlockInfoTimeout. #medium #asap

FIXME: добавить peer-nonce в peer-data что бы можно было определять себя при пинге и вычеркивать из known-peers, что бы пакеты по кругу не гонять. #easy

2023-02-05

fixme

Багтрекеры не нужны. Нужно сделать утилиту fixme, которая будет вести список FIXME/TODO из файлов. Формат FIXME/TODO достаточно расслабленный, но с определёнными условностями (TBD).

Каждая такая запись привязывается к файлу/строчке/гитовому коммиту. Оттуда и берёт автора, и как-то трекает историю.

Изменения workflow делаются отдельными записями, можно еще с криптоподписью (взять тот же самый credentials).

Аттачменты и прочее --- добавлять хэш-ссылками на

объект hbs2/offgrid
git blob

Тогда, если по этому гитовому хэшу объект где-то находится (в т.ч. вообще в любом репозитории, у нас же может быть глобальный словарь sha1 <-> offgrid-hash) то - рисуем картинку или изображаем аттачмент.

Про PEX

Надо делать PEX. PEX очень простой:

  data PEXEntry e = PEXAdd (PeerAddr e)
                  | PEXDel (PeedAddr e)
                  | PEX

  data PEX e = PEXRequest  ???
             | PEXResponse ??? [PEXEntry]

На самом деле, кто тут судьи? Кто может нам сказать - добавить пира или удалить.

Только мы сами можем решать. Поэтому, PEX может быть редуцирован до:

data PEX e = PEXRequest ???
           | PEXInfo [PeerAddr e] (Maybe ???)


  A                       B
  +  -> PEXRequest    ->  +
  |                       |
  + <- PEXInfo xxx ??? <- +
  |                       |
  |                       |

Вопрос, сколько пиров за раз отдавать, как можно нас зафлудить битыми пакетами и т.д.

Информацию о пирах лучше сделать вообще отдельным протоколом, что бы не загромождать этот.

Тогда останется только

  data PEX e = PEXRequest ??? | PEXAnswer [PeerAddr e]

Оценочные суждения, что пир такой-то --- редиска и т.п. можно оставить за кадром. Там нужны пруфы или сеть доверия, для сети доверия надо хранить статистику пиров (что, кстати, можно).

То есть если пир, который у нас на хорошем счету, или его хороший пир говорят нам, что какой-то другой пир --- плохой, то этому можно верить.

Вопрос, база локальная или база глобальная. Вообще, это целая большая история и пока не до неё.

2023-02-03

FIXME: Перестаёт качать ближе к концу файла. После повторного анонса --- докачивает.

FIXME: Надо поднимать burst в процессе скачивания блоков

FIXME: Надо динамически повышать/понижать burst в процессе скачивания

NOTE: Почему вообще получается потеря пакетов? Такого не должно быть.

TODO: Нужно исследовать потерю чанков/блоков, и произвести сравнительные замеры при помощи iperf/netperf что бы понять, теряются ли вообще пакеты или нет.

2023-02-01

Вести баги это слишком формально и накладно, даже в упрощенном виде. Можно вести их в виде девлога.

FIXME: Обработка ошибок в асинхронном приложении. Async-и жрут исключения, даже, когда удаётся их перехватить и пробросить дальше. Например, если не удалось забиндиться на адрес, исключение стреляет, но код ошибки при выходе всё еще 0.

9.4 KiB Raw Blame History Unescape Escape