mirror of https://github.com/voidlizard/hbs2
devlog
This commit is contained in:
Dmitry Zuikov
parent
e1a38aad49
commit
f7ae1ffbc5
|
|
@ -1,3 +1,22 @@
|
||||||
|
|
||||||
|
## 2023-02-06
|
||||||
|
|
||||||
|
FIXME: Задержку в очередь пиров при рассылке
|
||||||
|
GetBlockSize, что бы не спамить пиров,
|
||||||
|
пока запрос не уехал в отстой. Надо
|
||||||
|
для каждого пира поставить задержку
|
||||||
|
в 0.5 defBlockInfoTimeout или наоборот,
|
||||||
|
в 1 defBlockInfoTimeout.
|
||||||
|
#medium #asap
|
||||||
|
|
||||||
|
|
||||||
|
FIXME: добавить peer-nonce в peer-data
|
||||||
|
что бы можно было определять себя при пинге
|
||||||
|
и вычеркивать из known-peers, что бы пакеты
|
||||||
|
по кругу не гонять.
|
||||||
|
#easy
|
||||||
|
|
||||||
|
|
||||||
## 2023-02-05
|
## 2023-02-05
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,33 +0,0 @@
|
||||||
title: block-download-loop
|
|
||||||
status: open
|
|
||||||
|
|
||||||
|
|
||||||
Качать блоки по 500 штук за раз идея была
|
|
||||||
красивая, но работает плохо даже на localhost.
|
|
||||||
|
|
||||||
Вероятно, нужно качать пачками по N штук
|
|
||||||
и перезапрашивать отдельные чанки, а не блок
|
|
||||||
целиком.
|
|
||||||
|
|
||||||
Так же, может быть можно качать блок сразу
|
|
||||||
от нескольких пиров.
|
|
||||||
|
|
||||||
Соотношение in/out нужно как-то регулировать.
|
|
||||||
|
|
||||||
Либо же решает сам передатчик, по скольку кусков
|
|
||||||
за раз посылать.
|
|
||||||
|
|
||||||
Возможно, нужно ввести явную очередь на отправку
|
|
||||||
и посылать по N пакетов за раз, что бы не переполнять
|
|
||||||
очереди сокетов.
|
|
||||||
|
|
||||||
Возможно, с этого стоит начать.
|
|
||||||
|
|
||||||
Стоит так же отметить, что сейчас у нас по одному
|
|
||||||
сокету на пира, через которых идёт вообще весь трафик.
|
|
||||||
|
|
||||||
Надо попробовать буферизовать отправку ответов.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,25 +0,0 @@
|
||||||
title: introduce-references
|
|
||||||
status: open
|
|
||||||
|
|
||||||
|
|
||||||
Ввести понятие "reference", которая по сути --- мутабельная
|
|
||||||
ссыка.
|
|
||||||
|
|
||||||
Сразу же потребуется разграничние --- кто её может изменять,
|
|
||||||
варианты: никто, все, подписант изначальной ссылки.
|
|
||||||
|
|
||||||
Вопрос: как хранить список подписантов (hashref на список ключей?)
|
|
||||||
|
|
||||||
Вопрос: где и как задавать формат этой ссылки (ссылка на metadata?
|
|
||||||
ссылка на text-metadata?)
|
|
||||||
|
|
||||||
Но как бы ни было, нужна ссылка. Ссылка == указатель на merkle tree.
|
|
||||||
|
|
||||||
Merkle tree может быть непосредственно данных, или данных с метадатой.
|
|
||||||
|
|
||||||
Метадата может сильно меняться в процессе, начиная с какого-то момента
|
|
||||||
хорошо бы, что бы это никак не затрагивало хранилище.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,11 +0,0 @@
|
||||||
title: memory-leak-on-download
|
|
||||||
status: open
|
|
||||||
|
|
||||||
|
|
||||||
Выжирает огромное количество памяти при скачивании
|
|
||||||
и не отдаёт обратно.
|
|
||||||
|
|
||||||
Возможно, это очереди.
|
|
||||||
|
|
||||||
Возможно, накапливать чанки в памяти --- плохая
|
|
||||||
идея.
|
|
||||||
|
|
@ -1,8 +0,0 @@
|
||||||
title: no-retry-after-sleep-on-queue-exhaustion
|
|
||||||
status: fixed
|
|
||||||
|
|
||||||
|
|
||||||
Когда в очереди слишком много блоков на скачивание и
|
|
||||||
мы уходим в sleep пока буфер не уменьшится, нужно
|
|
||||||
возвращать очередной блок обратно в очередь, иначе
|
|
||||||
не будет повторного скачивания.
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
title: no-retry-stalled-blocks
|
|
||||||
status: fixed
|
|
||||||
|
|
||||||
При использовании UDP почему-то не запрашиваются повторно
|
|
||||||
повисшие блоки.
|
|
||||||
|
|
@ -1,19 +0,0 @@
|
||||||
title: no-sweep-stalled-blocks
|
|
||||||
status: open
|
|
||||||
|
|
||||||
В случае, если часть чанков не пришла или не была обработана
|
|
||||||
и блок завис в очереди --- этот блок никогда не убирается
|
|
||||||
из очереди.
|
|
||||||
|
|
||||||
Нужен механизм наподобие LRU, когда в случае отсутствия активности
|
|
||||||
в течение времени блоки удаляются из всех очередей и отправляются
|
|
||||||
повторно выкачиваться.
|
|
||||||
|
|
||||||
Вероятно, нужно убрать данные блока из СhunkWriter и держать
|
|
||||||
его в сессии (?).
|
|
||||||
|
|
||||||
Вероятно, нужно добавить битовую карту пришедших блоков ---
|
|
||||||
это всего + ~ 68 байт при условии, что размер блока 256K.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Loading…
Reference in New Issue