libtorrent icon indicating copy to clipboard operation
libtorrent copied to clipboard

implement Tribler Onion Routing in libtorrent

Open milahu opened this issue 2 months ago • 0 comments

Tribler Onion Routing is based on UDP so it has better streaming performance than TCP-based onion routers like Tor or I2P

better streaming performance

it should also give better throughput performance in networks with high latency, NATs, moderate packet loss, many peers (similar: uTP vs TCP)

Anonymous Downloading and Streaming specifications

We have implemented the main parts of the Tor wire protocol within Tribler. Instead of the TCP protocol that Tor uses, we use the UDP protocol, in order to be able to do NAT traversal. We have created our own network using this Tor variant, our code is not compatible with normal Tor. We use UDP-based end-to-end congestion control. Having hop-by-hop congestion control is one of the key reasons why Tor is slow.

Hidden Services Specifications for anonymous seeding

Both the seeder and downloader use circuits while accessing the DHT, but with the current implementation the introduction point on itself knows which info hash is shared and what the rendezvous point will be. This is a known weakness in the protocol, but is to be solved later on in future work, when opportunistic encryption in a web of trust is reality.

Moving Tor to a datagram transport

Tor currently transports data over encrypted TLS tunnels between nodes, in turn carried by TCP. This has worked reasonably well, but recent research has shown that it might not be the best option, particularly for performance.

For example, when a packet gets dropped or corrupted on a link between two Tor nodes, TCP will cause the packet to be retransmitted eventually. However, in the meantime, all circuits passing through this pair of nodes will be stalled, not only the circuit corresponding to the packet which was dropped.

Also, Tor uses two levels of congestion control; TCP for hop-by-hop links, and a custom scheme for circuits. This might not be the right approach -- maybe these schemes aren't the right ones to use or maybe there should only be one level of congestion control.

There have been a variety of solutions proposed to fix one or both of these problems, Most end up sending data as datagrams in UDP packets, and Tor is responsible for managing congestion and recovering from packet loss, and so can (hopefully) do so in a more intelligent way. However, there are many options for what architecture to use, what building blocks to build these schemes from, and how to tweak the many parameters that result.

related

milahu avatar Oct 31 '25 10:10 milahu