mirror of https://github.com/voidlizard/hbs2
276 lines
9.9 KiB
Markdown
276 lines
9.9 KiB
Markdown
|
||
## 2023-02-12
|
||
|
||
TODO: introduce-peer-config
|
||
|
||
1. На одном хосте может быть несколько пиров.
|
||
|
||
2. Конфиг пира --- это каталог.
|
||
|
||
3. Сторейдж --- это стейт, следовательно, конфиг
|
||
должен быть отдельно
|
||
|
||
4. Конфиг является в основном линейным, т.е изменение
|
||
может происходить дописыванием настроек в конец
|
||
|
||
|
||
TODO: introduce-peer-black-list
|
||
|
||
|
||
|
||
TODO: peer-accept-block-announce-feature
|
||
|
||
Смотреть, если пир в чёрном списке --- от отвергать от него
|
||
BlockAnnounce и handshake.
|
||
|
||
|
||
## 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).
|
||
|
||
Аттачменты и прочее --- добавлять хэш-ссылками на
|
||
|
||
1. объект hbs2/offgrid
|
||
2. 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.
|
||
|
||
|
||
|