Довгі роздуми над ідеєю ретрекеров, а також практичний досвід використання оних призводять до невтішного висновку: незважаючи на всю привабливість цієї технології, дуже часто завантаження все одно йде не на максимально можливій швидкості.
Чому так відбувається?
А тому що з усіх, скажімо 1000 бенкетів, що беруть участь в поширенні торрента, клієнт коннектітся до перших, скажімо, 100 (ну або скільки там виставлено в настройках), і про інших забуває. Дуже часто з локальними бенкетами клієнт просто не встигає з'єднатися, і, не дивлячись на наявність ретрекера, скачування йде через інтернет.
Чи можна з цим щось зробити?
Я бачу кілька варіантів.
1. Переконати розробників торрент-клієнтів (того ж uTorrent) додати опцію пріоритету бенкетів з тієї ж підмережі, в якій перебуваєте ви. Ця ідея активно обговорюється на форумі uTorrent. запрошую всіх, хто знайомий з англійською, взяти участь в дискусії, тому що на даний момент розробники додавати таку опцію не хочуть.
2. Через ipfilter.dat блокувати всі IP, крім тих, які належать вашому провайдеру (приклад цього способу для Авангарду-СПб). На жаль, якщо на роздачі немає локальних бенкетів, скачування зупиниться зовсім, а міняти ipfilter.dat на льоту не дуже зручно. З іншого боку, цей спосіб дозволив мені збільшити швидкість скачування в 2-3 рази на деяких роздачах.
3. Відключати DHT і PEX, а також блокувати домени трекерів, якими ви користуєтеся, через hosts, щоб списки бенкетів приходили тільки з ретрекера. Як і в пункті 2, проблема в тому, що якщо на роздачі немає локальних бенкетів, гойдатися нічого не буде. Плюс накриється облік рейтингу на основному трекері.
4. Тримати два клієнта з різними настройками - один для локального трафіку, інший для інтернетівського. Незручно, але працює.
5. Взяти якийсь оперсорсний клієнт, типу Vuze (java) або Halite (C ++), і дописати потрібний функціонал самим (можливо, одночасно додавши опціональний патчінга торрентів прямо в клієнт). Добре, але чи багато хто стануть змінювати клієнт тільки через швидкість?
Колеги, чи є у кого-небудь інші ідеї вирішення цієї проблеми? На мій погляд, ця біда - головне обмеження, в яке впирається швидкість скачування при використанні ретрекеров на сьогоднішній день.
Також питання до присутніх тут розробникам на C ++ або Java: чи готовий хтось взятися за п. 5 або 6?