search

arvidn / libtorrent

an efficient feature complete C++ bittorrent implementation
http://libtorrent.org
Other
5.26k stars 997 forks source link

support more encodings in tracker responses to save bandwidth #7680

Open scratchmex opened 5 months ago

scratchmex commented 5 months ago

Is there any intention to support more encodings (compression algos) in the tracker responses apart from chunked and gzip? Like zstd or brotli. The purpose of this is to save bandwidth in the trackers.

I am not aware if the bittorrent spec speaks about the supported encodings but to my understanding this is dictated by http and the request header accept-encoding so the client decides which one it will support

libtorrent version (or branch): latest platform/architecture: all compiler and compiler version: N/A

SemiAccurate commented 5 months ago

If your intention is to save bandwidth, there isn't really much better that you can do than gzip, practically speaking. zstd is slightly better, brotli slightly worse. But where these newer generation of compressors shine is in the speed of compression/decompression, not improvements in compression ratio.

But are you sure you want to keep using lib torrent? It is - for all intents and purposes - no longer maintained. Development has effectively stopped. You'd be better served by looking elsewhere for your torrenting needs going forward (unless you have a legacy dependency on it) which will save you the time and hassle of having to switch at a later date.

Roardom commented 5 months ago

According to https://github.com/WhatCD/Ocelot/blob/972c8d6659a27faa2730b353c2389c2b563a2cd7/worker.cpp#L727-L733, even gzip doesn't offer much bandwidth savings.

Same thing was noticed here: https://github.com/anniemaybytes/chihaya/blob/87d1dae429c1751eea7456b97fe9e3c6aedfd954/README.md#L50-L51

ValeZAA commented 2 weeks ago

Brotli needs to be supported by trackers. Is it? It takes a lot of resources too.