Dht что такое. Описание работы DHT. Принцип работы протокола BitTorrent


Вот вы когда-нибудь думали о том, что стоит искать «криминальные» способы активации Windows 10? Могу вас обрадовать, об этом позаботилась компания Microsoft. Видимо они поняли, что бороться с хакерами, которые постоянно взламывали операционные системы компании, бессмысленно и сил нет. Поэтому компания пошла другим путем. Компания Microsoft в новой операционной системе Windows 10 сделала так, что ей можно пользоваться бесплатно, но конечно с некоторыми ограничениями. Компания из Рэдмонда позволяет любому пользователю загрузить Windows 10 бесплатно и установить систему без ключа продукта. Я хочу рассказать вам, как это сделать и дам некоторые советы, как обойти некоторые ограничения.

Как загрузить Windows 10 и установить ее без ключа активации?

Нам понадобится ISO-образ самой Windows 10.Вы можете загрузить его непосредственно от корпорации Майкрософт, и вам даже не нужен ключ продукта, чтобы загрузить копию системы https://www.microsoft.com/uk-ua/software-download/windows10 . Утилита Media Creation Tool поможет в этом.

Для создания носителя выбираем «Создать установочный носитель для другого компьютера» и жмем «Далее».

Выбираем язык, естественно Windows 10 Pro (гулять,так гулять) и архитектуру, желательно x64.

Затем выбираем носитель, на который будут записаны файлы установки. Если выберете ISO-файл, то потребуется указать место для его сохранения, если флешка - то выбрать соответствующее устройство. Все данные на флешке будут удалены. Через несколько минут у вас будет скачана официальная версия образа Windows 10.

Если готовы, то просто начните процесс установки. Следуя несложным подсказкам системы, вы установите Windows 10, как обычно. Одним из первых экранов, которые вы увидите, будет "Активация Windows", на котором вас попросят ввести ключ продукта. Тем не менее, можете просто нажать на опцию "у меня нет ключа продукта" в нижней части окна и Windows позволит продолжить процесс установки. Вам могут предложить ввести ключ продукта позднее в процессе установки, но вы пропускаете это действие.

Еще немного и Windows 10 успешно будет установлена на ваше устройство.

А что не так с этой Windows 10?

После того, как вы установили Windows 10 без ключа, она на самом деле не будет активирована. Тем не менее, особых ограничений в использовании неактивированной Windows 10 нет. Еще со времен Windows XP компания Microsoft использовала знаменитый инструмент для проверки подлинности ключа активации Windows Genuine Advantage (WGA). Похоже, что в Windows 10 компания отказалась от его использования и ограничилась только косметическими способами.

С начала вы почти не заметите. Все работает, всё обновляется, все устанавливается, работает. Со временем в правом нижнем углу вы увидите водяной знак-предупреждение о том, что нужно активировать вашу версию Windows 10. Убрать или вырезать его невозможно. Но многим она вряд ли будет мешать в работе и тем более отвлекать.

Если все же решите перейти в Параметры, то вас здесь встретит внизу надпись «Windows не активирована. Активируйте Windows».

Не думаю, что часто многие заглядывают сюда, и эта надпись как-то будет надоедать вам. Если же нажать на надпись, то поймете в чем суть второго ограничения не активированной Windows 10.

Оно касается возможности изменить интерфейс и внешний вид Рабочего стола и экрана блокировки. Вы не сможете сменить заставку Рабочего стола,

выбрать главный цвет системы и Панели задач. Все кнопки просто неактивны.

Также у вас не будет возможности изменять картинку Экрана Блокировки, установить параметры звука, настройки мыши и самовольно размещать значки на Рабочем столе. Иными словами система сама решит, какой ярлык и где можно разместить. Некоторые и вовсе нельзя даже создать, например Мой компьютер.

Как же тогда быть? Оказывается, решение проблемы есть и оно очень простое. Чтобы обойти эти запреты необходимо попросту отключить сетевое подключение к Интернету. Тогда вы получите доступ к Персонализации. Можете все поменять: обои, темы, загрузить своё изображение на Экране блокировки, изменить настройки звука и мышки, даже ярлыки размещать на своё усмотрение. Потом включаете Интернет и увидите, что система ничего исправлять не будет.

Но останется еще один способ изменить фоновый рисунок Рабочего стола. Для этого выбираете изображение из вашей коллекции в ПК,нажимаете на правую кнопку мыши, увидите привычную функцию «Сделать фоновым изображением рабочего стола». Эту возможность даже в не активированной Windows 10 не заблокировали.

Помимо этих ограничений ваша система будет нормально работать. Конечно же изредка будет вас просить ее активировать, не сможете отключить параметры конфиденциальности. Зато вы не заплатите ни копейки.

А если я все же хочу активировать свою Windows 10?

Возможно, что со временем вам захочется активировать понравившуюся Windows 10. Компания Microsoft и об этом позаботилась. Если заглянете в пункт Активация , то найдете здесь возможность либо ввести ключ продукта, если он у вас имеется, или попросту купить лицензионную версию Windows 10 в Магазине.

Кстати, лицензионная версия Windows Pro в Магазине сейчас стоит 4 599 грн. В Украине и 13 900 рублей в России.

Похоже, что желание максимально привлечь внимание к Windows 10 занимает особое место в стратегии Microsoft. Может они и правы, ибо, если не можешь победить врага (хакеров), возглавь его. У них это скорее всего неплохо получается.

Новый слух ходит по интернету. Тот, что про Раздел 7 (b) в Соглашении об использовании служб Microsoft. Там сказано:

Иногда для того, чтобы продолжать использовать Службы, вам необходимо будет обновлять программное обеспечение. Мы можем автоматически проверять вашу версию программного обеспечения и скачивать обновления программного обеспечения или изменения конфигурации, в том числе такие, которые не позволяют вам получить доступ к Службам, играть в пиратские игры или использовать неразрешенные периферийные устройства. Также, чтобы продолжать пользоваться Службами, от вас может потребоваться обновить программное обеспечение. Такие обновления регулируются настоящими Условиями, если их не сопровождают другие условия. В этом случае применяются такие другие условия. Microsoft не обязана предоставлять какие-либо обновления и не гарантирует поддержку версии системы, в которой программное обеспечение используется на условиях лицензии. Такие обновления могут быть несовместимы с программным обеспечением или службами третьих лиц. Вы можете отозвать свое согласие на получение будущих обновлений программного обеспечения в любое время путем удаления программного обеспечения.

Источником этой «истории», кажется, является на сайте Alphr, которая заявляет, что «Редмонд может отключить ваши пиратские игры и взломанные устройства», а также «Microsoft зашила DRM прямо в ядро Windows 10»
Что же это значит? Нет, убирайте ваши шапочки из фольги. Это не тянет на историю, особенно на новую.

Это не ново?

Ну, это написано прямо в самом верху:
Дата публикации: 4 июня, 2015 г.
Вступает в действие: 1 августа, 2015 г.

Что за соглашения, заявления и прочее?

Условия лицензионного соглашения с Microsoft : относится конкретно к Windows (10)
Заявление о конфиденциальности корпорации Майкрософт : относится ко всем продуктам Microsoft
Соглашение об использовании служб Microsoft : относится к тем продуктам, что описаны в Соглашении.

Применимо ли Соглашение об использовании служб Microsoft к Windows 10

Соглашение об использовании служб Microsoft не применимо к Windows 10
Это написано в Разделе 1.b (i) - Дополнительные условия Лицензионного соглашения с Microsoft, с которыми вы соглашаетесь во время установки Windows 10:
Некоторые приложения для Windows предоставляют доступ к веб-службам или зависят от веб-служб, при этом использование таких веб-служб иногда регулируется отдельными условиями и политиками конфиденциальности, например соглашением об использовании служб Microsoft, которое опубликовано на веб-сайте (aka.ms/msa). Вы можете просмотреть эти условия и политики в разделе условий использования службы или в настройках приложения (в соответствующих случаях). Службы могут быть недоступны в отдельных регионах.

А теперь сравните и посмотрите на разницу с Заявлением о конфиденциальности корпорации Майкрософт, о котором сказано в Разделе 3 - Конфиденциальность. Согласие на использование данных.
Ваша конфиденциальность важна для нас. Некоторые компоненты программного обеспечения предусматривают отправку или получение данных при их использовании. Многие из этих компонентов можно отключить в пользовательском интерфейсе или не использовать их вообще. Принимая условия настоящего соглашения и используя программное обеспечение, вы соглашаетесь с тем, что Microsoft может собирать, использовать и раскрывать сведения, как описано в Заявлении о конфиденциальности Microsoft (aka.ms/privacy), а также как может быть описано в пользовательском интерфейсе, связанном с компонентами программного обеспечения.

Соглашение об использовании служб Microsoft в самом конце приводит список сервисов, к которым применяются условия использования. В этом списке нет Windows 10.
Настоящие условия («Условия») регулируют использование потребительских продуктов, веб-сайтов и услуг Microsoft, список которых приведен здесь («Службы»). Многие из этих продуктов ранее регулировались отдельными условиями, имевшими различные наименования, например, «Условия использования Xbox Live» или «Условия использования Skype». Настоящие Условия заменяют собой эти отдельные условия. Вы принимаете настоящие Условия, создавая учетную запись Microsoft или учетную запись Skype, используя Службы или продолжая использовать Службы после того, как вы были уведомлены об изменении настоящих Условий.

Что же тогда значит Раздел 7 (b)?

Вот что я вижу в списке служб:

Я думаю, это ясно, что Раздел 7 (b) говорит о «пиратских играх» и «неразрешенных переферийных устройствах» потому что он был написан в отношении игровой платформы Microsoft и связанной интеллектуальной собственности на Xbox и Windows.

Довольно интересно, что текущий список сервисов даже не упоминает Windows Store, хотя него говорится в разделе 14 (b).

DHT в БитТорренте используется для нахождения новых участников файлообмена.

При подключении к DHT сети БТ клиент устанавливает соединения с несколькими другими клиентами (узлами сети) и сам становится очередным узлом этой сети.

Для поиска пиров клиент посылает своим соседям по сети infohash нужного ему торрент файла. Они спрашивают у своих соседей, а те у своих, и таким образом через некоторое время по возможности находят ему других участников раздачи этого торрента.

DHT есть в клиентах BitTorrent (официальный), µTorrent, BitSpirit, BitComet, а также (несовместимо со всеми остальными) в Azureus.

В более общем смысле DHT означает децентрализованную распределенную систему для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними. На основе DHT структур можно строить более сложные системы, такие как P2P файлообмен, кооперативное веб кеширование, DNS сервисы и т.п.

Реализация DHT в БТ основана на варианте DHT, называемом Kademlia, и использует UDP протокол.

PEX

PEX (Peer exchange) - это обмен списками пиров между участниками одной и той же БТ раздачи.

В то время как DHT фактически образует независимую от БТ протокола сеть, PEX гораздо проще - это дополнительные сообщения между уже соединенными по БТ протоколу клиентами.

PEX может быть только вспомогательным средством получения пиров, хотя бы потому, что не может помочь подключиться к раздаче новым участникам.

PEX есть в клиентах Azureus, BitComet, µTorrent и BitTornado, причем в каждом клиенте по-своему, поэтому PEX между собой пользуются только одинаковые клиенты.

Функции

    И DHT и PEX фактически выполняют основную функцию трекера - помогают участникам файлообмена узнать друг о друге. Они:
  • снижают нагрузку на трекер: некоторые клиенты, получая пиров через DHT или PEX, реже обращаются за списком пиров на трекер
  • поддерживают участников вместе в периоды, когда трекер временно недоступен

Кроме того, DHT может использоваться и как единственный источник информации о других участниках - если торрент файл сразу создавался без трекера (trackerless)

DHT/PEX и закрытые трекеры

На открытых трекерах, где каждый может скачать торрент и участвовать в раздаче, функции DHT и PEX служат на благо всего участников.

Закрытым трекерам в первую очередь важно, чтобы в раздачах могли участвовать только зарегистрированные пользователи, и чтобы они соблюдали определенные правила.

При первом обращении клиента закрытый трекер имеет возможность не допустить его к раздаче, просто не сообщая ему адреса других клиентов-участников. Поэтому для закрытого трекера важно, чтобы клиенты не получали эти адреса через DHT/PEX.

Private key

DHT и PEX появились в клиентах Azureus и BitComet примерно летом 2005 года. Администраторы многие закрытых трекеров были недовольны такой новой функциональностью, и поэтому стали запрещать на трекере эти новые версии клиентов.

Тогда разработчики клиентов предложили новый ключ внутри торрент файла: private. Если он равен 1, то клиент обязан для этого торрента автоматически отключать DHT/PEX независимо от желания пользователя.

Правильно настроенные закрытые трекеры сами принудительно вставляют private:1 во все торренты, выкладываемые на трекере, а также запрещают несколько устаревших версий клиентов (имеющих DHT или PEX, но еще не знающих про private key).

Пользователи трекера просто не могут на раздачах использовать DHT/PEX, и проблемы нет.

Заблуждение про статистику

Иногда встречается мнение, что включенный в клиенте DHT как-то влияет на учет статистики клиента, например "раздавал через DHT, значит статистика шла мимо трекера". Это неверно:

  1. клиент рапортует статистику только на трекер , через DHT/PEX вообще никакого подсчета статистики не ведется
  2. клиент рапортует трекеру суммарные данные об объемах им скачанного и отданного всем пирам, с которыми общался , независимо от того, узнал клиент об отдельных пирах через трекер, DHT или PEX, или тот пир вообще начал соединение сам. То есть даже если из-за DHT/PEX на раздаче появятся левые пользователи, клиент все равно сообщит на трекер все, что у них скачал и отдал.

Правильный учет статистики зависит только от состояния трекера: работает трекер - статистика учитывается, не работает - не учитывается. Только в случае длительно неработающего трекера DHT/PEX может играть косвенную роль, не давая постепенно затухнуть файлообмену на такой "раздаче без учета статистики".

  1. Кроме того, часто пользователи просто забывают, что на их закрытом трекере все торренты private, и следовательно DHT/PEX в раздачах в принципе не используется.

Отключать ли DHT

Безусловно отключать DHT стоит в следующих двух случаях:

1) Вы качаете с закрытого трекера с системой passkey, на котором администраторы не хотят или не умеют делать все торренты private. Дело в том, что через DHT пользователи могут узнать passkey других пользователей, и нечестные пользователи могут использовать чужие passkey для скачивания под чужой учетной записью.

2) Вы качаете только с правильных закрытых трекеров. Если при этом в клиенте разрешить DHT, то получится, что клиент подключается к DHT сети, тратит на это трафик, но ни на одной раздаче DHT не использует.

BitTorrent - (дословно «поток битов») - P2P-протокол, предназначенный для обмена файлами через интернет. BitTorrent был создан программистом Брэмом Коэном.

Терминология

Личер и его рой.

  • Анонс (announce) - обращение клиента к трекеру. При каждом анонсе клиент передаёт на трекер информацию об объёмах им скачанного и отданного, a трекер передаёт клиенту список адресов других клиентов. Обращение клиента к трекеру происходит через определённые интервалы времени, которые определяются настройками клиента и трекера.
  • Веб-сид - HTTP-сервер, который может использоваться как источник данных, выступая в роли сида.
  • Доступность (availability, distributed copies - распространённые копии) - количество полных копий файла, доступных клиенту. Каждый сид добавляет 1,0 к этому числу; личеры увеличивают доступность в зависимости от количества скачанного, которого нет у других личеров. К примеру, если на раздаче есть один сид и два личера, скачавшие по 50 % файла (скачанные части равны между собой), то доступность равна 1,50.
  • Заглохший (choked - заглохший, придушенный) - клиент, обмен данными с которым заглох. Либо его канал на выход забит полностью и он не может ничего передать (достиг max_uploads), либо он является сидом и ему ничего не нужно получать.
  • Заинтересованный (interested) - участник, желающий получить куски файла, имеющиеся у другого участника. Например, если у клиента А нет каких-то частей, которые есть у клиента Б, считается, что клиент А заинтересован в обмене с клиентом Б.
  • Индекс (index) - это список.torrent-файлов (обычно включающий описания и другую информацию), управляемый веб-сайтом (индексатором ) и доступный для поиска. Индексирующий сайт также может быть и трекером.
  • Лич , иногда личер (leech - пиявка) - пир, не имеющий пока всех сегментов, то есть продолжающий скачивание. Термин часто употребляется и в негативном смысле, который он имеет в других файлообменных сетях: пользователь, который отдаёт гораздо меньше, чем скачивает.
  • Отравленный торрент - ситуация, когда часть пиров раздаёт повреждённые сегменты.
  • Пир (peer - соучастник) - клиент, участвующий в раздаче.
  • Поскрестись , Scrape-запрос (scrape - скрести, царапать) - процесс, аналогичный анонсу , но клиент запрашивает только статистику торрента, информацию о подключённых клиентах и возможности с ними связаться для обмена.
  • Пренебрегающий (snubbed) - клиент, подключённый к получателю, но не посылавший ему данные уже более 60 секунд.
  • Раздача (seeding) - процесс распространения файла по протоколу BitTorrent.
  • Рейтинг (share ratio) - отношение отданного к скачанному.
  • Рой (swarm) - совокупность всех пиров, участвующих в раздаче.
  • Сегмент , Часть (part - часть) - все файлы для передачи делятся на небольшие куски - сегменты, которые, затем, передаются по сети в произвольном порядке для оптимизации обмена.
  • Сид , иногда сидер (seeder - сеятель) - пир, имеющий все сегменты распространяемого файла, то есть либо начальный распространитель файла, либо уже скачавший весь файл и оставшийся на раздаче.
  • Super seeding|Супер-сид - специальный режим раздачи в некоторых BitTorrent-клиентах, пытающийся минимизировать количество данных, которое отдаст раздающий до появления первого скачавшего. Суперсид предлагает каждому пиру скачать только один сегмент файла, которого ещё нет у других пиров. Затем сид не даёт этому пиру следующих сегментов, пока не получит от других пиров подтверждения, что они тоже получили этот сегмент. Таким образом, суперсид пытается избежать повторной отдачи одних и тех же сегментов, и старается отдавать сегменты только тем пирам, которые активно передают их другим.
  • Хеш (hash) - строка буквенно-цифровых символов в.torrent-файле, которую используют клиенты для проверки передаваемых данных. Каждая часть после получения сначала проверяется на совпадение хеша. Если проверка не удалась, данные отбрасываются и запрашиваются ещё раз.
  • Passkey - аутентификатор пользователя на неанонимных трекерах. Содержится в скачиваемом torrent-файле. Таким образом, если кто-то получит доступ к torrent-файлу (например, пользователь по неосторожности расшарил его), он сможет работать с трекером от имени этого пользователя. Трекер может изменить passkey по запросу пользователя, но при этом необходимо будет перескачать все прошлые torrent-файлы (или вручную отредактировать их), чтобы иметь возможность и дальше раздавать скачанные файлы.
  • URLанонса (announce URL) - адрес трекера, к которому клиент делает анонс. Во многих клиентах называется «Tracker URL». Может включать «passkey» - уникальный код, назначаемый трекером для аккаунта пользователя, помогающий идентифицировать его на трекере (добавляется к URL анонса в самом *.torrent-файле при скачивании).

Общие особенности

Отсутствие очередей на закачку.
- Файлы закачиваются небольшими сегментами; чем менее доступен сегмент, тем чаще он будет передаваться. Таким образом, присутствие в сети «сидера» с полным файлом для загрузки необязательно - система распределяет сегменты между «пирами», чтобы в последующем они могли обмениваться недостающими сегментами.
- Клиенты (peers) обмениваются сегментами непосредственно между собой, по принципу «ты - мне, я - тебе».
- Закачанные сегменты становятся немедленно доступны другим клиентам.
- Контролируется целостность каждого сегмента.
- В качестве объекта закачки могут выступать несколько файлов (например, содержимое каталога).

Протоколы и порты

Клиенты соединяются с трекером по протоколу TCP.

Клиенты соединяются друг с другом, используя протокол TCP.

Номера портов не фиксированы в спецификации протокола и могут изменяться при необходимости. Более того, в данный момент большинство трекеров используют обычный HTTP порт 80, а для клиентов рекомендуется выбрать случайный входящий порт.

DHT-сеть в BitTorrent-клиентах использует протокол UDP.

Подробнее про DHT

DHT

DHT (Distributed hash table) - это протокол, позволяющий битторрент клиентам находить друг друга без использования трекера.

Клиенты с поддержкой DHT образуют общую DHT сеть, и помогают друг другу найти участников одних и тех же раздач.

Поддержка DHT есть в клиентах Mainline , µTorrent , KTorrent , BitSpirit и BitComet . В Azureus есть собственная реализация DHT, то есть Azureus клиенты образуют свою собственную отдельную DHT сеть.

PEX

PEX (Peer exchange) - это расширение БТ протокола для обмена списками участников.

PEX реализуется как дополнительные сообщения между клиентами, уже соединёнными между собой для обмена сегментами файла по обычному БТ протоколу.

В отличие от трекера и DHT, PEX может быть только вспомогательным средством получения пиров, так как он не может помочь подключиться к раздаче новым пирам.

PEX есть в клиентах Azureus , BitComet , µTorrent и BitTornado , причем в каждом клиенте он реализован по-своему, поэтому PEX между собой могут пользоваться только одинаковые клиенты. Начиная с 3 версии Azureus (Vuze) может обмениваться PEX с uTorrent и BitTorrent.

Функции

И DHT и PEX фактически выполняют основную функцию трекера - помогают участникам файлообмена узнать друг о друге. Они могут:

1. Помочь участникам быстрее друг друга найти

Например, на раздаче есть пир X с недоступным портом. К раздаче подключается пир Z, который сам начать соединение к X не может, и вынужден ждать, пока Х о нём узнает сам. Х только что обращался к трекеру, и в следующий раз собирается это сделать через час.

Но вот пир Y в очередной раз обращается к трекеру и узнаёт про нового пира Z. При этом Y сам давно уже соединен и занимается файлообменом с X, поэтому он через PEX сообщает X адрес этого нового пира. Теперь X может начать соединение к Z.

2. Снизить нагрузку на трекер

Некоторые клиенты, например Azureus, получая адреса пиров через DHT или PEX, реже обращаются за списком пиров на трекер.

3. Поддержать участников вместе в периоды недоступности трекера

Известно, что если трекер является единственным источником информации о пирах, то при его неработоспособности раздача постепенно останавливается. Клиенты помнят уже известные списки адресов других пиров, но постепенно эти списки устаревают - некоторые пользователи отключаются от раздачи, у некоторых меняется IP адрес, а новые пользователи не могут подключиться к раздаче вообще.

PEX позволяет несколько замедлить процесс распадения роя участников, а DHT позволяет полностью заменить трекер, то есть даже подключаться к раздаче новым участникам.

4. DHT позволяет раздавать вообще без трекера

Такая раздача называется trackerless. Торрент для нее создается без адреса трекера, и клиенты друг друга находят через DHT сеть.

При участии в trackerless раздачах БТ клиенты приобретают определённое сходство с eMule, использующим сеть KAD.

Механизм работы DHT

Реализация распределеной сети в БТ клиентах основана на варианте DHT, называемом Kademlia. А вообще говоря, DHT (Distributed hash table) означает децентрализованную распределенную систему для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними. На основе DHT структур строят разные более сложные системы, такие как P2P файлообмен, кооперативное веб кеширование, DNS сервисы и т. п.

DHT использует UDP протокол. БТ клиенты слушают тот же UDP номер порта, который они используют для входящих TCP соединений. Если вы активно используете DHT, то открытие этого UDP порта для доступа снаружи желательнo, но не обязательно - DHT будет работать и так.

Каждый подключенный БТ клиент является в DHT сети отдельным узлом. У него есть свой уникальный ID (идентификатор), случайно выбираемый из того же 160-битного пространства, что и infohash’ы торрентов.

Каждый узел хранит таблицу маршрутизации, содержащую контактную информацию о многих «ближайших» к нему узлах, и о нескольких более далеких. «Близость» двух узлов вычисляется из «сходства» их ID, и не имеет никакого отношения к их географической близости. Когда узел хочет найти пиров для какой-то раздачи, он сравнивает infohash этой раздачи с ID известных ему узлов, и затем посылает запрос тому узлу, чей ID наиболее похож на этот infohash. Тот узел возвращает ему адрес узла, чей ID ещё ближе к infohash торрента.

Тогда наш узел посылает запрос тому новому узлу, и получает от него адрес следующего узла, чей ID ещё более похож на infohash торрента.

Таким образом, запросы от клиентов, участвующих в раздаче торрента с определённым infohash, постепенно стекаются к узлам, чьи ID наиболее похожи на этот infohash. Эти узлы помнят предыдущие запросы, и всем следующим запрашивающим узлам вернут адреса предыдущих пиров с той же раздачи.

Private key

На публичных (открытых) трекерах, где каждый желающий может скачать торрент и участвовать в раздаче, DHT и PEX служат на благо всех участников.

Частным (закрытым) трекерам в первую очередь важно, чтобы в раздачах могли участвовать только зарегистрированные пользователи, и чтобы они соблюдали определённые правила. При первом обращении клиента частный трекер имеет возможность не допустить его к раздаче, просто не сообщая ему адреса других клиентов-участников. Поэтому для закрытого трекера важно, чтобы клиенты не получали эти адреса через DHT/PEX.

DHT и PEX появились в клиентах Azureus и BitComet примерно летом 2005 года. Администраторы многих частных трекеров были недовольны такой новой функциональностью, и поэтому стали запрещать на трекере эти новые версии клиентов.

Тогда разработчики клиентов предложили новый ключ внутри торрент файла: private. Если он равен 1, то клиент обязан для этого торрента автоматически отключать DHT/PEX независимо от желания пользователя. Такой торрент называют Secure Torrent.

Практически все современные частные трекеры сами принудительно вставляют private:1 во все торренты, выкладываемые на трекере, а также запрещают несколько устаревших версий клиентов, поддерживающих DHT или PEX, но еще не знающих про private key. Пользователи трекера просто не могут на раздачах использовать DHT/PEX, и проблемы нет.

Отметим, что присутствие private key изменяет infohash торрента, поэтому выреза́ть его из торрент файла бесполезно - другие клиенты изменённый торрент всё равно не признают.

Пользоваться ли?

  • Все ваши торренты - с частных трекеров.

Если при этом в клиенте разрешить DHT, то получится, что клиент подключается к DHT сети, тратит на это трафик, помогает другим клиентам найти нужных им пиров, но ни на одной раздаче DHT для себя не использует. Если вы не хотите тратить лишний трафик, то видимо лучше DHT в клиенте отключить.

  • Вы качаете раздачу с публичного трекера

Если трекер возвращает вам много пиров и их достаточно для достижения хорошей скорости скачивания, то DHT/PEX вам вероятно не нужно. Если нет, то стоит попробовать их включить (и в клиенте и в свойствах раздачи), это может помочь найти больше источников.

  • Вы качаете раздачу с частного трекера без принудительного private key

Из крупных русскоязычных трекеров на конец 2006 года это торрентс.ру. Возможность использования на раздачах DHT/PEX на этих трекерах отдана на откуп раздающему (создателю торрента).

Вообще говоря, такая ситуация не может быть признана нормальной, особенно на трекерах с системой passkey. Дело в том, что в клиентах BitComet и Azureus через DHT пользователи могут узнать passkey других пользователей, и нечестные пользователи могут использовать чужие passkey для скачивания под чужой учетной записью. Поэтому по крайней мере в этих клиентах на таких трекерах рекомендуется DHT выключить.

DHT и статистика

Этот раздел касается только частных трекеров, на которых private key в торренты принудительно не вставляется, и на некоторых раздачах (в зависимости от того, вставил ли раздающий сам в торрент private key) можно использовать DHT и PEX.

Часто встречается мнение, что включенный в клиенте DHT влияет на учет статистики клиента трекером, например «раздавал через DHT, значит статистика шла мимо трекера». Это неверно.

Во-первых, DHT/PEX используется только для получения адресов пиров. Ни файлообмена, ни какого-либо учета статистики по ним не ведётся. Клиент рапортует статистику скачанного и отданного только на трекер.

То есть «раздавал через DHT» фактически означает «о некоторых (или о всех) пирах получил информацию по DHT, и вероятно некоторые пиры тоже нашли меня через DHT»

Во-вторых, хотя клиенты обычно и знают, откуда ими получены адреса пиров, ни один клиент не разделяет трафик на «полученный/отданный DHT пирам» и «полученный/отданный пирам, полученным от трекера». Даже при желании это было бы клиенту сделать затруднительно - некоторые пиры могут быть получены и от трекера и через DHT или PEX, и часто клиент не знает, как его адрес получил пир, сам начинающий к нему соединение.

Клиент рапортует трекеру суммарные данные об объемах им скачанного и отданного всем пирам, с которыми он общался, независимо от того, узнал клиент об отдельных пирах через трекер, DHT или PEX, или тот пир вообще начал соединение сам. То есть даже если из-за DHT/PEX на раздаче появятся «левые» пользователи (не обращающиеся к трекеру), клиент все равно сообщит на трекер все, что у них скачал и отдал.

Правильный учет статистики зависит только от состояния трекера: работает трекер - статистика учитывается, не работает - не учитывается. Только в случае длительно неработающего трекера DHT/PEX может играть косвенную роль, не давая постепенно затухнуть файлообмену на такой «раздаче без учета статистики».

Файл метаданных

Для каждого распространяемого файла создаётся файл метаданных с расширением.torrent, который содержит следующую информацию:

  • URL трекера;
  • общую информацию о закачиваемом файле (имя, длину и пр.);
  • контрольные суммы (точнее, хэш-суммы SHA1) сегментов закачиваемого файла.

Файлы метаданных могут распространяться через любые каналы связи - например, они (или ссылки на них) могут выкладываться на веб-серверах, размещаться на домашних страницах пользователей сети, рассылаться по электронной почте, публиковаться в блогах или новостных лентах RSS.

Клиент начинает закачку, получив каким-либо образом файл с метаданными, в котором есть ссылка на трекер.

Трекер

Трекер (англ. tracker) - специализированный сервер, работающий по протоколу HTTP. Трекер нужен для того, чтобы клиенты могли найти друг друга. Фактически, на трекере хранятся IP-адреса, входящие порты клиентов и хэш-суммы, уникальным образом идентифицирующие объекты, участвующие в закачках. По стандарту, имена файлов на трекере не хранятся, и узнать их по хэш-суммам нельзя. Однако на практике трекер часто помимо своей основной функции выполняет и функцию небольшого веб-сервера. Такой сервер хранит файлы метаданных и описания распространяемых файлов, предоставляет статистику закачек по разным файлам, показывает текущее количество подключенных пиров и пр.

Подробнее про трекер

BitTorrent трекер

BitTorrent трекер - веб-сервер, осуществляющий координацию BitTorrent клиентов.
Координация клиентов - основная функция BitTorrent трекера - обработка запросов клиентов.
Каждый клиент периодически обращается к трекеру с запросом, в котором указаны:

  • info_hash - уникальный хеш торрент файла
  • port - TCP порт, на котором клиент ждёт соединений от других клиентов
  • количество данных, которыми клиент успел обменяться с другими клиентами
  • и некоторая другая информация.

Такое обращение представляет собой обычный GET HTTP запрос, в котором информация закодирована с помощью специального протокола Bencode.

Если в BitTorrent клиенте открыто несколько активных торрент файлов, то для каждого используется отдельный запрос, никак не связанный с другими. Интервалы между запросами по каждому отдельно взятому торренту зависят от настроек клиента и обычно составляют от 30 до 60 минут.

BitTorrent трекер, используя info_hash, составляет списки IP адресов и портов участвующих в каждой отдельной раздаче клиентов. Каждому клиенту в ответ на очередной запрос трекер возвращает такой список, и клиент использует его для установления соединений с другими клиентами.

Роль трекера

Таким образом, трекер «связывает» клиентов друг с другом, но напрямую не участвует в обмене данными раздаваемых файлов. Более того, в принципе трекер может работать, не имея никакой информации об этих файлах, поскольку клиенты сообщают ему только info_hash.

Трекер считается «слабым» местом системы BitTorrent, поскольку при его отключении новые клиенты просто не могут друг друга «найти». При этом уже участвующие в раздаче клиенты могут некоторое время продолжать файлообмен, постепенно теряя тех, кто отключился или у кого поменялся динамический IP адрес.

Для разрешения этой проблемы могут использоваться резервные трекеры или специальный бестрекерный протокол DHT.

Дополнительные функции

Большинство реализаций трекеров, кроме координации клиентов, также имеют дополнительные функции, доступные пользователям с браузерами через обычный веб-сервер, часто с другим адресом или портом, чем у интерфейса для запросов клиентов.

Так, практически все трекеры отображают статистику раздач, то есть количества сидов и пиров на каждой раздаче, общие объёмы переданных между клиентами данных и другую доступную им информацию.

Часто трекеры используются для хранения торрент-файлов и их описаний.

Частные трекеры

Частный (англ. private) трекер - это трекер, ограничивающий доступ пользователям, обычно требованием регистрации учётной записи.

Одной из причин появления частных трекеров является ассиметричность пользовательских каналов доступа к Интернет. Средний пользователь за время скачивания торрента успевает отдать другим пользователям незначительную по объёму часть данных, при этом многие пользователи после получения нужного файла сразу закрывают торрент клиент. В результате доступность торрента снижается, и на первоначальных распространителей файла ложится неоправданно большая нагрузка.

Как правило, частные трекеры записывают статистику каждого пользователя по количеству «скачанного» и «отданного» другим пользователям, и требуют поддержания некоторого минимального отношения этих двух величин. Как результат, доступность и скорость скачивания торрентов на частном трекере обычно выше, чем на открытом.

Для опознания запросов от клиента (программы) пользователя трекер либо использует IP адрес пользователя либо уникальный для каждого пользователя passkey, добавляемый трекером в announce URL торрент файла при скачивании пользователем.

Реализации трекеров

Существуют разные реализации трекеров, например как отдельный веб-сервер, в виде модуля для стороннего HTTP сервера (например Apache), или в виде движка сайта, написанного например на PHP или JSP.

Работа без трекера

В новых версиях протокола были разработаны бестрекерные (англ. trackerless) системы, которые решают некоторые из предыдущих проблем. Отказ трекера в таких системах не приводит к автоматическому отказу всей сети.

Начиная с версии 4.2.0 официального клиента, в нем реализована функция бестрекерной работы, базирующаяся на протоколе Kademlia. В таких системах трекер доступен децентрально, на клиентах, в форме распределенной хеш-таблицы.

На данный момент еще не все клиенты используют совместимый друг с другом протокол. Совместимы между собой BitComet, µTorrent, KTorrent и официальный клиент BitTorrent. Azureus также имеет режим бестреккерной работы, но его реализация отличается от официальной, вследствие чего он не может работать через DHT с вышеперечисленными клиентами.

Принцип работы протокола BitTorrent

Перед началом закачки, клиент подсоединяется к трекеру, сообщает ему свой адрес и хэш-сумму запрашиваемого файла, на что в ответ, клиент получает адреса других клиентов, скачивающих или раздающих этот же файл. Далее клиент периодически информирует трекер о своем прогрессе и получает обновленный список адресов.

Клиенты соединяются друг с другом и обмениваются сегментами файлов без непосредственного участия трекера. Для эффективной работы сети BitTorrent необходимо, чтобы как можно больше клиентов были способны принимать входящие соединения. Неправильная настройка NAT или файрвола могут этому помешать.

При соединении клиенты сразу обмениваются информацией об имеющихся у них сегментах. Клиент, желающий скачать сегмент, посылает запрос, и если второй клиент готов отдавать, получает этот сегмент. После этого клиент проверяет контрольную сумму сегмента и оповещает всех присоединенных пиров о наличии у него этого сегмента.

Каждый клиент имеет возможность временно блокировать отдачу другому клиенту (англ. choke). Это делается для более эффективного использования канала отдачи. Кроме того, при выборе - кого разблокировать, предпочтение отдается пирам, которые сами передали этому клиенту много сегментов. Таким образом, пиры с хорошими скоростями отдачи поощряют друг друга по принципу «ты - мне, я - тебе».

Super seeding (cупер-сид)

Супер-сид (англ. super seeding) - метод, реализованный в тех клиентах BitTorrent, авторы которых пытаются минимизировать объем данных до первого завершения загрузки пира. Метод был задуман Джоном Хофманом и впервые был осуществлен в клиенте «BitTornado» в середине 2003 г.

Супер-сид является изменением в поведении сидеров и не может быть осуществлен без нарушения протокола BitTorrent. Тем не менее, это не утверждается ни разработчиком протокола, Брэмом Коэном, ни в официальном клиенте.

Супер-сид действует, когда имеется только один сидер. Фактически, он заставляет пользователей делиться скачанными данными. Клиент, отдавший одному участнику какую-либо часть файла, прекращает передачу данных до тех пор, пока не обнаружит в сети вторую копию этой части. Поскольку многие участники не имеют возможности или не желают делать доступными для других скачанные данные, общая скорость отдачи падает. В обычном режиме же, в отличие от супер-сид, каждый всегда получает запрошенную информацию, если она имеется, поэтому в нем средняя скорость передачи данных выше.

Супер-сид эффективен при раздачах с большим количеством качающих. При небольшой группе людей (2-3 человека) их клиенты в силу разных причин могут отказаться устанавливать связь друг с другом. В этом случае включенный супер-сид заставит клиентов ждать, пока данные станут доступны. Когда число качающих велико (10-20 человек), достаточно отдать каждую часть файла только один раз, тогда клиенты смогут обменяться ею между собой, и каждый из них получит файл целиком.

Программы-клиенты

Кроссплатформенные:

  • aria2 - поддерживает HTTP, FTP, BitTorrent; файлы Metalink 3.0
  • Azureus - написан на языке Java, поэтому является кроссплатформенным;
  • BitTornado - кроссплатформенный клиент, написанный на языке Python;
  • FoxTorrent - расширение для браузера Mozilla Firefox, реализующее функции клиента BitTorrent;
  • mlDonkey - кроссплатформенный клиент;
  • Браузер Opera поддерживает закачку торрентов, начиная с версии 9.0, но его торрент-клиент несовместим со многими трекерами.
  • TorrentFlux - написан на PHP, работает на удаленном Web‐сервере как PHP‐скрипт, позволяя не держать свой компьютер включенным постоянно, но при этом качать и раздавать торренты.

Для UNIX-подобных систем:

  • BTPD - консольный клиент для Unix/GNU+Linux, написанный на C++; работает в режиме демона;
  • CTorrent - консольный клиент для Unix/GNU+Linux, прекративший развитие в 2004 году;
  • Deluge - клиент для GNU/Linux, написанный на языке Python; использует GTK;
  • KTorrent - использует библиотеку Qt; работает в среде KDE;
  • rTorrent - консольный клиент для UNIX/GNU+Linux, написанный на C++; использует библиотеки ncurses и libTorrent;
  • Transmission - клиент для Mac OS X, FreeBSD, OpenBSD, NetBSD, GNU/Linux и BeOS, использующий GTK.

Для Microsoft Windows и Windows NT:

  • BitComet;
  • FlashGet;
  • GetRight.
  • Shareaza - поддерживает работу с несколькими файлообменными сетями, в том числе и BitTorrent
  • XTorrent;
  • BitRocket.

») - это класс децентрализованных распределённых систем, которые обеспечивают поисковый сервис, похожий по принципу работы на таблицу хешей, и имеют структуру: (имя, значение), хранящиеся в DHT, а каждый участвующий узел может рационально искать значение, ассоциированное с данным именем. Ответственность за поддержку связи между именем и значением распределяется между узлами, таким образом изменение набора участников является причиной минимального количества разрывов. Это позволяет DHT легко масштабироваться и постоянно отслеживать добавление/удаление узлов и ошибки в их работе.

DHT - это инфраструктура, которая может быть использована для построения многих комплексных сервисов, таких как распределенные файловые системы, пиринговое распространение файлов и системы распространения контента, кооперативный web-кэш, многоадресная доставка (multicast), anycast, сервис доменных имен и система мгновенных сообщений. Основные распределенные сети, которые используют DHT, включают в себя BitTorrent , сеть eDonkey network , YaCy и Coral Content Distribution Network .

История

Изыскания в области DHT изначально были мотивированы в частности пиринговыми системами, такими, как Napster , Gnutella , Freenet , которые использовали распределенные в интернете ресурсы для создания одного единственного приложения. В частности они использовали расширенную пропускную способность и объем жесткого диска для предоставления сервиса распространения файлов. Эти системы различаются тем, как они находили данные пиров:

  • Napster имел центральный индексный сервер: каждый узел, после присоединения, должен отправить список локально хранящихся файлов на сервер, который должен произвести поиск и направить запрос к узлам, содержащий результаты. Этот центральный компонент делал систему уязвимой для атак и рисков.
  • Gnutella и похожие сети двинулись к модели лавинных запросов - в основном, каждый поиск привел бы к сообщению, передаваемому на любую машину в сети. Избегая централизованного отказа, этот метод был значительно менее эффективным чем Napster .
  • Наконец, Freenet был также полностью распределенным, но маршрутизация работает на базе эвристического ключа, в котором каждый файл имеет ассоциированный с ним ключ, а файлы с похожими ключами имели тенденцию к объединению в кластеры на похожем наборе узлов. Запрос, вероятно, направлялся таким кластерам без надобности опрашивать всех пиров. Однако, Freenet не мог гарантировать, что данные будут найдены.

DHT используют маршрутизацию на базе более структурированного ключа, чтобы достигнуть децентрализации Gnutella и Freenet , а также эффективности и гарантируемых результатов Napster . Один из недочетов в том, что, как Freenet , DHT поддерживает только поиск по точному совпадению, а не по ключевым словам, хотя эти возможности могут наслаиваться поверх DHT.

Свойства

DHT характеризуется следующими свойствами:

  • децентрализация: форма системы коллективных узлов без координации;
  • расширяемость: система будет одинаково эффективно функционировать при тысячах или миллионах узлов;
  • отказоустойчивость: система будет одинаково надежна (в некотором смысле) с узлами постоянно подключающимися, отключающимися и выдающими ошибки.

Ключевая методика достижения цели заключается в том, что любой узел должен скоординироваться только с несколькими узлами в системе - как правило, О (logn ), где n - количество участников (смотри ниже) - так, чтобы только ограниченный объем работы был сделан для каждого изменения количества участников.

Некоторые DHT-проекты стремятся обеспечить защиту от вредоносных пользователей и позволять участникам оставаться анонимными, хотя это меньше распространено, чем во многих других P2P-системах (особенно при распространении файлов); см. анонимные P2P.

Наконец, DHT приходится иметь дело с более традиционными распределенными системами, такими, как распределение нагрузки, целостность данных и производительность (в частности гарантируя, что операции, такие как маршрутизация и хранение данных или поиск завершаются быстро).

Структура

Структура DHT может быть разбита на несколько основных компонентов. Она основывается на абстрактном пространстве ключей (keyspace), таком как набор 160-битных строк (количество бит может варьироваться). Схема разбиения пространства ключей распределяет принадлежность ключей среди участвующих узлов. Затем оверлейная сеть соединяет узлы помогая найти владельца любого ключа в пространстве ключей.

Когда все компоненты на месте, типичное использование DHT для хранения и выдачи информации происходит следующим образом: Предположим keyspace составляет 160-битные строки. Чтобы сохранить файл с данным именем и информацией в DHT, находится SHA1 хеш от имени файла, из которого формируется 160-битный ключ k, после чего формируется сообщение put(k, data) и посылается любому участвующему узлу в DHT. Послание идёт от одного узла к другому через оверлейную сеть до тех пор, пока она не достигнет единственного узла, ответственного за ключ k, в соответствии со схемой разбиения keyspace, где хранится пара (k, data). Любой другой клиент может получить содержание файла сделав ключ (k), получив хеш имени файла, для того, чтобы найти данные, связанные с ключом, послав сообщение get(k) . Сообщение снова пройдёт через оверлей к узлу, ответственному за ключ, который ответит, что нужные данные есть в наличии.

Компоненты разбиения пространства ключей и оверлейной сети описаны ниже с целью представления основных идей обычных для большинства DHT систем. Многие разработки отличаются в деталях.

Разбиение пространства ключей

Многие DHT используют некоторые варианты постоянного хеширования для отображения ключей в узлы. Этот способ включает в себя функция δ(k 1 ,k 2) которая определяет абстрактное понятие расстояния между ключами k 1 и k 2 , что не относится к географическому расстоянию и сетевой задержке. Каждый узел представляет собой единичный ключ названный идентификатором(ID). Узел с ID j владеет всеми ключами для которых i самый ближайший ID, измеряемый с δ .

Пример." Chord DHT рассматривает ключи как точки на окружности и δ(k 1 ,k 2) есть расстояние, которое проходится по часовой стрелке окружности от ключа k 1 к k 2 . Таким образом круг пространства ключей разделён на смежные сегменты, чьи концы являются идентификаторами узлов. Если i 1 и i 2 смежные ID, то узел с ID i 2 содержит все ключи, которые находятся между i 1 и i 2 .

Согласованное хеширование имеет основное свойство: удаление или прибавление только одного набора ключей, принадлежащих узлам смежных ID, не влияет на другие узлы.

DHT и BitTorrent

И DHT и PEX фактически выполняют основную функцию BitTorrent-трекера - помогают участникам файлообмена узнать друг о друге. Они могут:

  • Помочь участникам быстрее найти друг друга
    Например, на раздаче есть пир X с недоступным портом. К раздаче подключается пир Z, который сам начать соединение с X не может и вынужден ждать, пока Х о нём узнает сам. Х только что обращался к трекеру и в следующий раз собирается это сделать через час.
    Но вот пир Y в очередной раз обращается к трекеру и узнаёт про нового пира Z. При этом Y сам давно уже соединён и занимается файлообменом с X, поэтому он через PEX сообщает X адрес этого нового пира. Теперь X может начать соединение к Z.
  • Снизить нагрузку на трекер
    Получая адреса пиров через DHT или PEX, клиенты реже обращаются к трекеру, тем самым снижая нагрузку.
  • Поддержать раздачу в периоды недоступности трекера
    Если трекер является единственным источником информации о пирах, то при его неработоспособности раздача постепенно остановится. Используя PEX , клиенты могут обмениваться друг с другом информацией о пирах, с которыми у них были сеансы связи, тем самым замедляя процесс остановки раздачи. DHT же позволяет полностью заменить трекер.
  • DHT позволяет раздавать без трекера
    Такая раздача называется trackerless . Торрент для неё создаётся без адреса трекера и клиенты находят друг друга через DHT. При участии в trackerless-раздачах BitTorrent-клиенты приобретают определённое сходство с eMule , использующим сеть Kad .

Private key

В публичных (открытых) трекерах, где каждый желающий может скачать торрент и участвовать в раздаче, DHT и PEX служат на благо всех участников.

Частным (закрытым) трекерам в первую очередь важно, чтобы в раздачах могли участвовать только зарегистрированные пользователи, и чтобы они соблюдали определённые правила. При первом обращении клиента частный трекер имеет возможность не допустить его к раздаче, просто не сообщая ему адреса других клиентов-участников. Поэтому для закрытого трекера важно, чтобы клиенты не получали эти адреса через DHT/PEX.

DHT и PEX появились в клиентах Azureus и BitComet примерно летом 2005 года. Администраторы многих частных трекеров были недовольны такой новой функциональностью, и поэтому стали запрещать на трекере эти новые версии клиентов.

Тогда разработчики клиентов предложили новый ключ внутри торрент файла: private . Если он равен 1, то клиент обязан для этого торрента автоматически отключать DHT/PEX независимо от желания пользователя. Такой торрент называют Secure Torrent.

Практически все современные частные трекеры сами принудительно вставляют private:1 во все торренты, выкладываемые на трекере, а также запрещают несколько устаревших версий клиентов, поддерживающих DHT или PEX, но ещё не знающих про private key . Пользователи трекера просто не могут на раздачах использовать DHT/PEX, и проблемы нет.

Отметим, что присутствие private key изменяет infohash торрента, поэтому выреза́ть его из торрент-файла бесполезно - другие клиенты изменённый торрент всё равно не признают.

Стоит так же отметить, что ранее, когда коммерческие трекеры так же активно отдавали свои торренты для скачивания, но авторизация анонса требовала PassKey, сеть DHT использовалась для воровства PassKey у пользователей. Данное явление нисколько не затрагивает уязвимости в DHT, просто результаты генератора пасскеев (атака перебором - brute force) проверялись трассированием через DHT. Непосредственное воровство пароля не осуществляется через DHT, а сегодня, когда на всех коммерческих трекерах требуются инвайты и прочее, доступа у сторонних лиц к файлу торрента нет, а на трекерах с обыкновенной регистрацией у каждого есть свой пасскей и он может выполнять валидацию запросами на трекер, средствами HTTP, а не DHT.

DHT и статистика

Этот раздел касается только закрытых трекеров, на которых private key в торренты принудительно не вставляется , и на некоторых раздачах (в зависимости от того, вставил ли раздающий сам в торрент private key ) можно использовать DHT и PEX.

Часто встречается мнение, что включённый в клиенте DHT влияет на учёт статистики клиента трекером, например «раздавал через DHT, значит статистика шла мимо трекера». Это неверно.

Во-первых, DHT/PEX используется только для получения адресов пиров. Ни файлообмена, ни какого-либо учёта статистики по ним не ведётся. Клиент рапортует статистику скачанного и отданного только на трекер.

То есть «раздавал через DHT» фактически означает «о некоторых (или о всех) пирах получил информацию по DHT, и вероятно некоторые пиры тоже нашли меня через DHT»

Во-вторых, хотя клиенты обычно и знают, откуда ими получены адреса пиров, ни один клиент не разделяет трафик на «полученный/отданный DHT пирам» и «полученный/отданный пирам, полученным от трекера». Даже при желании это было бы клиенту сделать затруднительно - некоторые пиры могут быть получены и от трекера и через DHT или PEX, и часто клиент не знает, как его адрес получил пир, сам начинающий к нему соединение.

Клиент рапортует трекеру суммарные данные об объёмах им скачанного и отданного всем пирам, с которыми он общался , независимо от того, узнал клиент об отдельных пирах через трекер, DHT или PEX, или тот пир вообще начал соединение сам. То есть даже если из-за DHT/PEX на раздаче появятся «левые» пользователи (не обращающиеся к трекеру), клиент всё равно сообщит на трекер всё, что у них скачал и отдал.

Правильный учёт статистики зависит только от состояния трекера: работает трекер - статистика учитывается, не работает - не учитывается. Только в случае длительно неработающего трекера DHT/PEX может играть косвенную роль, не давая постепенно затухнуть файлообмену на такой «раздаче без учёта статистики».

Механизм работы DHT

Реализация распределенной сети в BitTorrent-клиентах основана на варианте DHT, называемом Kademlia . А вообще говоря, DHT (Distributed hash table) означает децентрализованную распределенную систему для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними. На основе структур DHT строят разные более сложные системы, такие как файлообмен P2P, кооперативное веб-кеширование, службы DNS и т. п.

DHT использует протокол UDP . Клиенты BitTorrent «слушают» тот же номер порта UDP, который они используют для входящих TCP -соединений. Если вы активно используете DHT, то открытие этого UDP-порта для доступа снаружи желательнo, но не обязательно - DHT будет работать и так.

Каждый подключённый клиент является в сети DHT отдельным узлом. У него есть свой уникальный ID (идентификатор), случайно выбираемый из того же 160-битного пространства, что и infohash’и торрентов.

Каждый узел хранит таблицу маршрутизации, содержащую контактную информацию о многих «ближайших» к нему узлах, и о нескольких более далёких. «Близость» двух узлов вычисляется из «сходства» их ID, и не имеет никакого отношения к их географической близости.

Когда узел хочет найти пиров для раздачи, он сравнивает infohash этой раздачи с ID известных ему узлов, и затем посылает запрос тому узлу, чей ID наиболее похож на этот infohash. Тот узел возвращает ему адрес узла, чей ID ещё ближе к infohash торрента.

Тогда наш узел посылает запрос тому новому узлу, и получает от него адрес следующего узла, чей ID ещё более похож на infohash торрента.

Таким образом, запросы от клиентов, участвующих в раздаче торрента с определённым infohash, постепенно стекаются к узлам, чьи ID наиболее похожи на этот infohash. Эти узлы помнят предыдущие запросы, и всем следующим запрашивающим узлам вернут адреса предыдущих пиров с той же раздачи.

Недостатки

  1. Существует несколько не совместимых между собой протоколов которые обслуживают различные сети.
  2. Работа клиента как DHT узла создает большую нагрузку на роутер .

Ссылки

  • Описание DHT протокола (Перевод)(рус.)
  • Описание DHT протокола на сайте Bittorrent.org(англ.)



Top