You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During this journey, we identified a number of technical and scientific problems that block the Tribler project from reaching its goals. We tended not to tackle those in fear of bogging down our understaffed team, focusing on "low-hanging fruits" instead.
Gentlemen! 🚬
I inform you all the low-hanging fruits are gone. Only the hard ones remain. Here is the list.
BitTorrent uses Mainline DHT to find nodes that seed an infohash. Mainline DHT is susceptible to various types of attacks, including DDOS. To solve this problem, BitTorrent libraries use spam control methods, blocking peers that send too many requests. Different clients employ different criteria for detecting DDOS attempts. The problem is Tribler DHT requests are all sent through exit nodes, which may look like a single node to DHT peers, triggering spam control. The result is half-dead DHT performance and unreliable health info.
Slow tunnels performance
Our anonymous tunnels code is implemented in Python (though the crypto library is low level). Performance is very, very bad compared to VPNs: we do 5 MBytes/s at best and 0,5 MBytes average for an overseeded torrent on a fast modern PC, while a typical VPN (such as Wireguard) will use the whole bandwidth available to the host (about 20-80 MBytes/s). The reason is Python copies strings on slicing, resulting in useless waste of memory and CPU cycles. The solution is to implement a shim endpoint for IPv8 tunnels in a lower-level language.
Related to #143
Preface
Over the last few years, we successfully solved every major technical problem inherited from previous Tribler dev generations. We radically updated Tribler codebase, established a robust code architecture and brought code support up to industry standards. Also, we've cut down on every non-essential feature, focusing development on two things only: metadata delivery and anonymous downloads.
During this journey, we identified a number of technical and scientific problems that block the Tribler project from reaching its goals. We tended not to tackle those in fear of bogging down our understaffed team, focusing on "low-hanging fruits" instead.
Gentlemen! 🚬
I inform you all the low-hanging fruits are gone. Only the hard ones remain. Here is the list.
Long-standing unsolved technical problems
DHT calls blocked over tunnels
BitTorrent uses Mainline DHT to find nodes that seed an infohash. Mainline DHT is susceptible to various types of attacks, including DDOS. To solve this problem, BitTorrent libraries use spam control methods, blocking peers that send too many requests. Different clients employ different criteria for detecting DDOS attempts. The problem is Tribler DHT requests are all sent through exit nodes, which may look like a single node to DHT peers, triggering spam control. The result is half-dead DHT performance and unreliable health info.
Slow tunnels performance
Our anonymous tunnels code is implemented in Python (though the crypto library is low level). Performance is very, very bad compared to VPNs: we do 5 MBytes/s at best and 0,5 MBytes average for an overseeded torrent on a fast modern PC, while a typical VPN (such as Wireguard) will use the whole bandwidth available to the host (about 20-80 MBytes/s). The reason is Python copies strings on slicing, resulting in useless waste of memory and CPU cycles. The solution is to implement a shim endpoint for IPv8 tunnels in a lower-level language.
The problem is exacerbated by Libtorrent's bad performance when using uTP.
Hidden seeding is broken (and meaningless)
Receiving UDP over SOCKS is broken in Libtorrent
TBC
The text was updated successfully, but these errors were encountered: