oci/zeronet
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Various fixes in ChangeLog-0.8.0.md

Browse source
This commit is contained in:
Vadim Ushakov 2021-10-20 17:39:39 +07:00
parent 488fd4045e
commit 23ef37374b
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
ZNE-ChangeLog/ChangeLog-0.8.0.md
View file

@ -5,8 +5,8 @@
* Added support of Onion v3 addresses. Thanks to @anonymoose and @zeroseed. * Added support of Onion v3 addresses. Thanks to @anonymoose and @zeroseed.
* Added a few Onion v3 tracker addresses. * 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. * 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 do actually **decreases** the parallelization.
* 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. * 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 be 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. * 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. * 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.
@ -15,11 +15,11 @@
* Activity. More activity ==> frequent announces. * Activity. More activity ==> frequent announces.
* Peer count. More peers ==> rare announces. * Peer count. More peers ==> rare announces.
* Tracker count. More trackers ==> frequent announces to iterate over more trackers. * Tracker count. More trackers ==> frequent announces to iterate over more trackers.
* For owned zites, the activity rate doesn't drop below 0.6 to force more frequent checks. This, however, can be used to investigate which peer belongs to the zire owner. A new commnd line option `--expose_no_ownership` is introduced to disable that behavior. * For owned zites, the activity rate doesn't drop below 0.6 to force more frequent checks. This, however, can be used to investigate which peer belongs to the zite owner. A new commnd line option `--expose_no_ownership` is introduced to disable that behavior.
* When checking for updates, ZeroNet normally asks other peers for new data since the previous update. This however can result in losing some updates in specific conditions. To overcome this, ZeroNet now asks for the full site listing on every Nth update check. * When checking for updates, ZeroNet normally asks other peers for new data since the previous update. This however can result in losing some updates in specific conditions. To overcome this, ZeroNet now asks for the full site listing on every Nth update check.
* When asking a peer for updates, ZeroNet may see that the other peer has an older version of a file. In this case, ZeroNet sends back the notification of the new version available. The logic in 0.8.0 is generally the same, but some randomization is added which may help in distributing the "update waves" among peers. * When asking a peer for updates, ZeroNet may see that the other peer has an older version of a file. In this case, ZeroNet sends back the notification of the new version available. The logic in 0.8.0 is generally the same, but some randomization is added which may help in distributing the "update waves" among peers.
* ZeroNet now tries harder in delivering updates to more peers in the background. * ZeroNet now tries harder in delivering updates to more peers in the background.
* ZeroNet also make more efforts of searching the peers before publishing updates. * ZeroNet also makes more efforts of searching the peers before publishing updates.
**Other:** **Other:**
@ -49,12 +49,12 @@ Changes in the plugin:
* The default total tracker limit increased up to 20 from 5. This reduces the probability of accidental splitting the network into segments that operate with disjoint sets of trackers. * The default total tracker limit increased up to 20 from 5. This reduces the probability of accidental splitting the network into segments that operate with disjoint sets of trackers.
* The plugin now shares any types of trackers, working both on IP and Onion networks, not limiting solely to Zero-based IP trackers. * The plugin now shares any types of trackers, working both on IP and Onion networks, not limiting solely to Zero-based IP trackers.
* The plugin now takes into account not only the total number of known working trackers, but also does it on per protocol basis. The defaults are to keep 10 trackers for Zero protocol and 5 trackers per each other protocol. The available protocols are detected automatically. (For example, UDP is considered disabled, when working in the Tor-always mode.) The following protocols are recognized: `zero://` (Zero Tracker), `udp://` (UDP-based bitTorrent tracker), `http://` or `https://` (HTTP or HTTPS-based bitTorrent tracker; considered the same protocol). In case of new protocols implemented by third-party plugins, trackers are grouped automatically by the protocol prefix. * The plugin now takes into account not only the total number of known working trackers, but also does it on per protocol basis. The defaults are to keep 10 trackers for Zero protocol and 5 trackers per each other protocol. The available protocols are detected automatically. (For example, UDP is considered disabled, when working in the Tor-always mode.) The following protocols are recognized: `zero://` (Zero Tracker), `udp://` (UDP-based BitTorrent tracker), `http://` or `https://` (HTTP or HTTPS-based BitTorrent tracker; considered the same protocol). In case of new protocols implemented by third-party plugins, trackers are grouped automatically by the protocol prefix.
* Reworked the interaction of this plugin and the Zero tracker (`Bootstrapper`) plugin. Previously: `AnnounceShare` checks if `Bootstrapper` is running and adds its addresses to the list. Now: the tracker explicitly asks `TrackerShare` to add its addresses. * Reworked the interaction of this plugin and the Zero tracker (`Bootstrapper`) plugin. Previously: `AnnounceShare` checks if `Bootstrapper` is running and adds its addresses to the list. Now: `Bootstrapper` explicitly asks `TrackerShare` to add its addresses.
* The plugin allows adjustings the behaviour per each tracker entry with the following boolean fields: * The plugin allows adjusting the behaviour per each tracker entry with the following boolean fields:
* `my` — "My" trackers get never deleted on announce errors, but aren't saved between restarts. Designed to be used by tracker implementation plugins. `TrackerShare` acts more persistently in recommending "my" trackers to other peers. * `my` — "My" trackers get never deleted on announce errors, but aren't saved between restarts. Designed to be used by tracker implementation plugins. `TrackerShare` acts more persistently in recommending "my" trackers to other peers.
* `persistent` — "Persistent" trackers get never deleted, when unresponsive. * `persistent` — "Persistent" trackers get never deleted, when unresponsive.
* `private` — "Private" trackers are never exposed to other peer in response of the getTrackers command. * `private` — "Private" trackers are never exposed to other peers in response of the getTrackers command.
### TrackerZero ### TrackerZero
@ -74,6 +74,6 @@ Running over TOR doesn't seem to be stable so far. Any investigations and bug re
### TrackerList ### TrackerList
`TrackerZero` is a new plugin for fetching tracker lists. By default is list is fetched from [https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all_ip.txt](https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all_ip.txt). `TrackerList` is a new plugin for fetching tracker lists. By default is list is fetched from [https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all_ip.txt](https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all_ip.txt).
TODO: add support of fetching from ZeroNet URLs TODO: add support of fetching from ZeroNet URLs