Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usability roadmap ticket #6480

Closed
ichorid opened this issue Oct 21, 2021 · 0 comments
Closed

Usability roadmap ticket #6480

ichorid opened this issue Oct 21, 2021 · 0 comments
Assignees

Comments

@ichorid
Copy link
Contributor

ichorid commented Oct 21, 2021

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

@ichorid ichorid self-assigned this Oct 21, 2021
@ichorid ichorid closed this as completed Oct 21, 2021
@Tribler Tribler locked as resolved and limited conversation to collaborators Oct 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

1 participant