From 6c8849139fa0f975b5fa5291cdbd9148eda91a3f Mon Sep 17 00:00:00 2001 From: Vadim Ushakov Date: Tue, 23 Mar 2021 19:05:51 +0700 Subject: [PATCH] ZNE-ChangeLog/ChangeLog-0.8.0.md: typos --- ZNE-ChangeLog/ChangeLog-0.8.0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ZNE-ChangeLog/ChangeLog-0.8.0.md b/ZNE-ChangeLog/ChangeLog-0.8.0.md index 9925dbdc..59f0af55 100644 --- a/ZNE-ChangeLog/ChangeLog-0.8.0.md +++ b/ZNE-ChangeLog/ChangeLog-0.8.0.md @@ -6,8 +6,8 @@ * 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. -* The connection handling code had several bugs that were hidden by silently ignored exceptions. These were fixed, but some new ones may 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 connections check etc. +* 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. * The reannounce frequency is adjusted dynamically based on: * Activity. More activity ==> frequent announces.