From d2b65c550c405237087b09ba2f84477fbac3f042 Mon Sep 17 00:00:00 2001 From: Vadim Ushakov Date: Wed, 20 Oct 2021 16:43:13 +0700 Subject: [PATCH] Minor fix in ChangeLog-0.8.0.md --- ZNE-ChangeLog/ChangeLog-0.8.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ZNE-ChangeLog/ChangeLog-0.8.0.md b/ZNE-ChangeLog/ChangeLog-0.8.0.md index 17266268..f662d353 100644 --- a/ZNE-ChangeLog/ChangeLog-0.8.0.md +++ b/ZNE-ChangeLog/ChangeLog-0.8.0.md @@ -7,7 +7,7 @@ * Added a few Onion v3 tracker addresses. * Reworked the algorithm of checking zite updates on startup / after the network outages / periodically. ZeroNet tries not to spam too many update queries at once in order to prevent network overload. (Which especially the issue when running over Tor.) At the same time, it tries to keep balance between frequent checks for frequently updating zites and ensuring that all the zites are checked in some reasonable time interval. Tests show that the full check cycle for a peer that hosts 800+ zites and is connected over Tor can take up to several hours. We cannot significantly reduce this time, since the Tor throughput is the bottleneck. Running more checks at once just results in more connections to fail. The other bottleneck is the HDD throughput. Increasing the parallelization doesn't help in this case as well. So the implemented solution **decreases** the concurency. * Improved the Internet outage detection and the recovery procedures after the Internet be back. ZeroNet "steps back" and schedules rechecking zites that were checked shortly before the Internet connection get lost. The network outage detection normally has some lag, so the recently checked zites are better to checked again. -* When the network is down, reduce the frequency of connection attempts to prevent overloading Tor with hanged connections. +* When the network is down, reduce the frequency of connection attempts to prevent overloading Tor with hanged connections. * The connection handling code had several bugs that were hidden by silently ignored exceptions. These were fixed, but some new ones might be introduced. * For each zite the activity rate is calculated based on the last modification time. The milestone values are 1 hour, 5 hours, 24 hours, 3 days and 7 days. The activity rate is used to scale frequency of various maintenance routines, including update checks, reannounces, dead connection checks etc. * The activity rate is also used to calculate the minimum preferred number of active connections per each zite.