Вишукування в області DHT спочатку були мотивовані зокрема пірінговимі системами, такими, як Napster, Gnutella, Freenet, які використовували розподілені в інтернеті ресурси для створення одного єдиного додатка. Зокрема вони використовували розширену пропускну здатність і обсяг жорсткого диска для надання сервісу поширення файлів. Ці системи різняться тим, як вони знаходили дані бенкетів, хоча:
Napster мав центральний індексний сервер: кожен вузол, після приєднання, повинен відправити список локально зберігаються файлів на сервер, який повинен провести пошук і направити запит до вузлів, що містить результати. Цей центральний компонент робив систему, вразливу для атак і позовів.
Gnutella і схожі мережі рушили до моделі лавинних запитів - в основному, кожен пошук привів би до повідомлення, переданому на будь-яку машину в мережі. Уникаючи централізованого відмови, цей метод був значно менш ефективним ніж Napster.
Нарешті, Freenet був також повністю розподіленим, але маршрутизація працює на базі евристичного ключа, в якому кожен файл має асоційований з ним ключ, а файли зі схожими ключами мали тенденцію до об'єднання в кластери на схожому наборі вузлів. Запит, ймовірно, прямував таким кластерам без потреби опитувати всіх бенкетів. Однак, Freenet не міг гарантувати, що дані будуть знайдені.
DHT використовують маршрутизацію на базі більш структурованого ключа, щоб досягти децентралізації Gnutella і Freenet, а також ефективності і гарантованих результатів Napster. Один з недоліків в тому, що, як Freenet, DHT підтримує тільки пошук за точним збігом, а не за ключовими словами, хоча ці можливості можуть нашаровуватися поверх DHT.
DHT характеризується наступними властивостями:
децентралізація: форма системи колективних вузлів без координації;
розширюваність: система буде однаково ефективно функціонувати при тисячах або мільйонах вузлів;
відмовостійкість: система буде однаково надійна (в певному сенсі) з вузлами постійно підключаються, отключающимися і видають помилки.
Ключова методика досягнення мети полягає в тому, що будь-який вузол повинен скоординуватися тільки з декількома вузлами в системі - як правило, О (logn), де n - кількість учасників (дивись нижче) - так, щоб тільки обмежений обсяг роботи був зроблений для кожного зміни кількості учасників.
Деякі DHT-проекти прагнуть забезпечити захист від шкідливих користувачів і дозволяти учасникам залишатися анонімними, хоча це менше поширене, ніж у багатьох інших P2P-системах (особливо при поширенні файлів); см. анонімні P2P.
Нарешті, DHT доводиться мати справу з більш традиційними розподіленими системами, такими, як розподіл навантаження, цілісність даних і продуктивність (зокрема гарантуючи, що операції, такі як маршрутизація і зберігання даних або пошук завершуються швидко).
І DHT і PEX фактично виконують основну функцію трекера - допомагають учасникам файлообміну дізнатися один про одного. Вони можуть:
Допомогти учасникам швидше знайти один одного
Наприклад, на роздачі є пір X з недоступним портом. До роздачі підключається пір Z, який сам почати з'єднання з X не може і змушений чекати, поки Х про нього дізнається сам. Х тільки що звертався до трекера і в наступний раз збирається це зробити через годину.
Знизити навантаження на трекер
Підтримати учасників разом в періоди недоступності трекера
PEX дозволяє декілька уповільнити процес розпаду рою учасників, а DHT дозволяє повністю замінити трекер, тобто навіть підключатися до роздачі новим учасникам.
DHT дозволяє роздавати взагалі без трекера
За участю в trackerless-роздачах БТ клієнти набувають певну схожість з eMule, що використовує мережу KAD.
На публічних (відкритих) трекерах, де кожен бажаючий може скачати торрент і брати участь в роздачі, DHT і PEX служать на благо всіх учасників.
Тоді розробники клієнтів запропонували новий ключ всередині торрент файлу: private. Якщо він дорівнює 1, то клієнт зобов'язаний для цього торрента автоматично відключати DHT / PEX незалежно від бажання користувача. Такий торрент називають Secure Torrent.
Практично всі сучасні приватні трекери самі примусово вставляють private: 1 в усі торренти, що викладаються на трекері, а також забороняють кілька застарілих версій клієнтів, що підтримують DHT або PEX, але ще не знають про private key. Користувачі трекера просто не можуть на роздачах використовувати DHT / PEX, і проблеми немає.
Відзначимо, що присутність private key змінює infohash торрента, тому вирізати його з торрент файлу марно - інші клієнти змінений торрент все одно не визнають.
Всі ваші торренти - з приватних трекерів
Якщо при цьому в клієнті дозволити DHT, то вийде, що клієнт підключається до DHT мережі, витрачає на це трафік, допомагає іншим клієнтам знайти потрібних їм бенкетів, але ні на одній роздачі DHT для себе не використовує. Якщо серед інших джерел на роздачі немає нікого з включеним DHT, DHT краще відключити. Чи відключати DHT якщо останнім на роздачі є - ваш вибір. З одного боку це ризик втрати трафіку на службовий, з іншого можливість докачати дані в разі збою трекера.
Ви завантажуєте роздачу з публічного трекера
Якщо трекер повертає вам багато пірів і їх вистачає для досягнення гарної швидкості скачування, то DHT / PEX вам працює на прогрес. Його варто включити (і в клієнті і у властивостях роздачі), це може допомогти знайти більше джерел і швидше підключати до них в процесі роздачі, генеруючи запити не тільки на трекер (корисно в клієнтах з повільним оновленням статистики (офіційний, μTorrent і ін.)
Ви завантажуєте роздачу з приватного трекера без примусового private key
Можливість використання на роздачах DHT / PEX на цих трекерах віддана на розсуд роздає (творцеві торрента).
Дана ситуація повністю залежить від творця торрента (він же, як правило, і ініціативний сидер). Якщо він сам з якихось причин не використовує DHT, то включеного DHT на роздачі ви навряд чи знайдете.
DHT і статистика
Цей розділ стосується лише приватних трекерів, на яких private key в торренти примусово вставляєте, і на деяких роздачах (в залежності від того, вставив чи роздає сам в торрент private key) можна використовувати DHT і PEX.
Часто зустрічається думка, що включений в клієнті DHT впливає на облік статистики клієнта трекером, наприклад «роздавав через DHT, значить статистика йшла повз трекера». Це не вірно.
Тобто «роздавав через DHT» фактично означає «про деякі (або про всіх) бенкетах отримав інформацію по DHT, і ймовірно деякі бенкети теж знайшли мене через DHT»
Клієнт рапортує трекеру сумарні дані про об'єми ним завантаженого і відданого всім бенкетів, з якими він спілкувався, незалежно від того, дізнався клієнт про окремі бенкетах через трекер, DHT або PEX, або той бенкет взагалі почав з'єднання сам. Тобто навіть якщо через DHT / PEX на роздачі з'являться «ліві» користувачі (що не звертаються до трекера), клієнт все одно повідомить на трекер все, що у них скачав і віддав.
Правильний облік статистики залежить тільки від стану трекера: працює трекер - статистика враховується, не працює - не враховується. Тільки в разі тривало непрацюючого трекера DHT / PEX може грати непряму роль, не даючи поступово згаснути файлообміну на такій «роздачі без урахування статистики».
Механізм роботи DHT
Реалізація розподіленої мережі в БТ клієнтах заснована на варіанті DHT, званому Kademlia. А взагалі кажучи, DHT (Distributed hash table) означає децентралізовану розподілену систему для об'єднання великої кількості постійно зникаючих вузлів і ефективної передачі повідомлень між ними. На основі DHT структур будують різні складніші системи, такі як P2P файлообмін, кооперативне веб кешування, DNS сервіси і т. П.
DHT використовує UDP протокол. БТ клієнти слухають той же UDP номер порту, який вони використовують для вхідних з'єднань TCP. Якщо ви активно використовуєте DHT, то відкриття цього UDP порту для доступу зовні бажано, але не обов'язково - DHT буде працювати і так.
Кожен підключений БТ клієнт є в DHT мережі окремим вузлом. У нього є свій унікальний ID (ідентифікатор), випадково обираний з того ж 160-бітного простору, що і infohash'и торрентів.
Кожен вузол зберігає таблицю маршрутизації, що містить контактну інформацію про багато «найближчих» до нього вузлів, і про декілька далеких. «Близькість» двох вузлів обчислюється з «подібності» їх ID, і не має ніякого відношення до їх географічної близькості.
_________________
Про виправлення пишіть в ЛС