From f7ae1ffbc5a1edef20e99eef6e7440fa360f5b98 Mon Sep 17 00:00:00 2001 From: Dmitry Zuikov Date: Mon, 6 Feb 2023 04:50:52 +0300 Subject: [PATCH] devlog --- docs/devlog.md | 19 +++++++++++ docs/issues/block-download-loop | 33 ------------------- docs/issues/introduce-reference | 25 -------------- docs/issues/memory-leak-on-download | 11 ------- .../no-retry-after-sleep-on-queue-exhaustion | 8 ----- docs/issues/no-retry-stalled-blocks | 5 --- docs/issues/no-sweep-stalled-blocks | 19 ----------- 7 files changed, 19 insertions(+), 101 deletions(-) delete mode 100644 docs/issues/block-download-loop delete mode 100644 docs/issues/introduce-reference delete mode 100644 docs/issues/memory-leak-on-download delete mode 100644 docs/issues/no-retry-after-sleep-on-queue-exhaustion delete mode 100644 docs/issues/no-retry-stalled-blocks delete mode 100644 docs/issues/no-sweep-stalled-blocks diff --git a/docs/devlog.md b/docs/devlog.md index 55c46d60..2856d5ca 100644 --- a/docs/devlog.md +++ b/docs/devlog.md @@ -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 diff --git a/docs/issues/block-download-loop b/docs/issues/block-download-loop deleted file mode 100644 index c12e89f7..00000000 --- a/docs/issues/block-download-loop +++ /dev/null @@ -1,33 +0,0 @@ -title: block-download-loop -status: open - - -Качать блоки по 500 штук за раз идея была -красивая, но работает плохо даже на localhost. - -Вероятно, нужно качать пачками по N штук -и перезапрашивать отдельные чанки, а не блок -целиком. - -Так же, может быть можно качать блок сразу -от нескольких пиров. - -Соотношение in/out нужно как-то регулировать. - -Либо же решает сам передатчик, по скольку кусков -за раз посылать. - -Возможно, нужно ввести явную очередь на отправку -и посылать по N пакетов за раз, что бы не переполнять -очереди сокетов. - -Возможно, с этого стоит начать. - -Стоит так же отметить, что сейчас у нас по одному -сокету на пира, через которых идёт вообще весь трафик. - -Надо попробовать буферизовать отправку ответов. - - - - diff --git a/docs/issues/introduce-reference b/docs/issues/introduce-reference deleted file mode 100644 index dca7a9a2..00000000 --- a/docs/issues/introduce-reference +++ /dev/null @@ -1,25 +0,0 @@ -title: introduce-references -status: open - - -Ввести понятие "reference", которая по сути --- мутабельная -ссыка. - -Сразу же потребуется разграничние --- кто её может изменять, -варианты: никто, все, подписант изначальной ссылки. - -Вопрос: как хранить список подписантов (hashref на список ключей?) - -Вопрос: где и как задавать формат этой ссылки (ссылка на metadata? -ссылка на text-metadata?) - -Но как бы ни было, нужна ссылка. Ссылка == указатель на merkle tree. - -Merkle tree может быть непосредственно данных, или данных с метадатой. - -Метадата может сильно меняться в процессе, начиная с какого-то момента -хорошо бы, что бы это никак не затрагивало хранилище. - - - - diff --git a/docs/issues/memory-leak-on-download b/docs/issues/memory-leak-on-download deleted file mode 100644 index 1ba129a9..00000000 --- a/docs/issues/memory-leak-on-download +++ /dev/null @@ -1,11 +0,0 @@ -title: memory-leak-on-download -status: open - - -Выжирает огромное количество памяти при скачивании -и не отдаёт обратно. - -Возможно, это очереди. - -Возможно, накапливать чанки в памяти --- плохая -идея. diff --git a/docs/issues/no-retry-after-sleep-on-queue-exhaustion b/docs/issues/no-retry-after-sleep-on-queue-exhaustion deleted file mode 100644 index bd46952d..00000000 --- a/docs/issues/no-retry-after-sleep-on-queue-exhaustion +++ /dev/null @@ -1,8 +0,0 @@ -title: no-retry-after-sleep-on-queue-exhaustion -status: fixed - - -Когда в очереди слишком много блоков на скачивание и -мы уходим в sleep пока буфер не уменьшится, нужно -возвращать очередной блок обратно в очередь, иначе -не будет повторного скачивания. diff --git a/docs/issues/no-retry-stalled-blocks b/docs/issues/no-retry-stalled-blocks deleted file mode 100644 index 2790cf2d..00000000 --- a/docs/issues/no-retry-stalled-blocks +++ /dev/null @@ -1,5 +0,0 @@ -title: no-retry-stalled-blocks -status: fixed - -При использовании UDP почему-то не запрашиваются повторно -повисшие блоки. diff --git a/docs/issues/no-sweep-stalled-blocks b/docs/issues/no-sweep-stalled-blocks deleted file mode 100644 index 7470a89d..00000000 --- a/docs/issues/no-sweep-stalled-blocks +++ /dev/null @@ -1,19 +0,0 @@ -title: no-sweep-stalled-blocks -status: open - -В случае, если часть чанков не пришла или не была обработана -и блок завис в очереди --- этот блок никогда не убирается -из очереди. - -Нужен механизм наподобие LRU, когда в случае отсутствия активности -в течение времени блоки удаляются из всех очередей и отправляются -повторно выкачиваться. - -Вероятно, нужно убрать данные блока из СhunkWriter и держать -его в сессии (?). - -Вероятно, нужно добавить битовую карту пришедших блоков --- -это всего + ~ 68 байт при условии, что размер блока 256K. - - -