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
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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