mirror of https://github.com/voidlizard/hbs2
171 lines
6.6 KiB
Markdown
171 lines
6.6 KiB
Markdown
|
||
## 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.
|
||
|
||
|
||
|