From 9a758eaa220dc2f01c251da2edab9fdcf2ba514c Mon Sep 17 00:00:00 2001
From: Dmitry Zuikov <dzuikov@gmail.com>
Date: Mon, 27 Feb 2023 06:19:39 +0300
Subject: [PATCH] devlog

---
 docs/devlog.md             | 57 ++++++++++++++++++++++++++++++++++++++
 hbs2-peer/app/PeerTypes.hs |  7 +----
 2 files changed, 58 insertions(+), 6 deletions(-)

diff --git a/docs/devlog.md b/docs/devlog.md
index 77c8c302..8a536ccd 100644
--- a/docs/devlog.md
+++ b/docs/devlog.md
@@ -1,4 +1,61 @@
 
+## 2023-02-27
+
+В целом ясно, что нужно пересмотреть работу с очередью:
+скачивание огромных объемов при небольшом количестве
+пиров забивает её целиком, и другие каналы не будут
+синхронизированы, пока не будет выкачан большой объем
+данных. Это дорога к DDoS атаке и полной остановке
+сервиса --- можно рассылать огромные файлы и забивать
+очередь. Для борьбы с этим, кажется, необходима либо
+рандомизация очереди (как?), либо введение приоритетной
+очереди, и приоритет ставить в обратную зависимость от
+глубины (высоты) дерева и размера merkle-tree блока,
+либо же понижение приоритета выкачивания для "больших"
+пакетов.
+
+Вместе с тем, нам очевидно, нужен мониторинг скачивания
+референса/блока.
+
+Какое видится решение:
+
+Отдельная очередь на каждый fetch/announce. Качаем,
+порциями забрасывая пакеты в общую очередь и запоминая,
+что забросили. На каждый скачанный блок мы подписываемся
+на уведомление, кроме того, вешаем монитор.
+
+По уведомлению --- вычеркиваем блок.
+
+По монитору --- проверяем, сколько блоков осталось.
+
+Можно при анонсе/фетче парсить пришедший блок и
+запоминать число невыкачанных блоков. Тогда
+при каждом событии, что блок скачан - мы уменьшаем
+это число, что даёт нам возможность мониторить прогресс.
+
+Когда это число достигает 0, мы запускаем процессинг опять,
+удостовериваемся, что всё выкачано и если да --- то можем
+уведомить о том, что блок скачан (и удаляем процесс).
+
+
+FIXME: e5bd-download-stuck-on-big-volumes
+ Скачивание затыкается при большом объеме передаваемых
+ данных и длительном времени работы, т.е на медленном канале.
+ с чем конкретно это связано, пока что непонятно.
+ Кажется, что это может быть связано с потерей пакетов, т.е
+ очередь на скачивание пустеет, тогда как блоки еще не выкачаны.
+ Необходимо проверить это в первую очередь.
+
+ 1. Пока нет счётчиков, добавить trace в цикл работы с очередью
+ 2. Добавить debug на размер очереди (пустая/не пустая)
+
+ Возможно, происходящее связано с неатомарностью обновления
+ счётчиков/wip и самой очереди, хотя то, что закачка фактически
+ прекращается, а данные очевидно не выкачаны --- говорит нам
+ о потере самих блоков для скачивания. Куда они могут теряться
+ в принципе? Есть место в алгоритме, где блоки не возвращаются
+ в очередь?
+
 ## 2023-02-26
 
 TODO: block-shuffle
diff --git a/hbs2-peer/app/PeerTypes.hs b/hbs2-peer/app/PeerTypes.hs
index b6a945bc..6650fc4a 100644
--- a/hbs2-peer/app/PeerTypes.hs
+++ b/hbs2-peer/app/PeerTypes.hs
@@ -285,7 +285,7 @@ addDownload h = do
 
   notPostponed <- liftIO $ readTVarIO po <&> isNothing . HashMap.lookup h
 
-  if (doAdd && notPostponed && notHere) then do
+  when (doAdd && notPostponed && notHere) do
 
     q <- asks (view downloadQ)
     wip <- asks (view blockWip)
@@ -296,11 +296,6 @@ addDownload h = do
         writeTQueue q h
 
       Cache.insert wip h ()
-  else do
-      -- FIXME: wtf?
-      po <- asks (view peerPostponed)
-      liftIO $ atomically $ do
-        modifyTVar po $ HashMap.insert h ()
 
      -- | False -> do -- not hasSize -> do