BT9G LABS / DHT Deep Dive #09

Как Magnet link превращается в Metadata: полный путь через Peer и расширения BitTorrent

От InfoHash в Magnet до DHT peer discovery, BEP 10 negotiation и получения Metadata по BEP 9.

BT9G LabsОпубликовано 3 мин чтения

BT9G Labs / DHT Deep Dive #09. Разбираем, как URI с одним хешем в итоге превращается в список файлов, размеры и проверенный Torrent metadata.

Как Magnet link превращается в Metadata: полный путь через Peer и расширения BitTorrent

Краткое резюме

  • Тема: Как Magnet link превращается в Metadata: полный путь через Peer и расширения BitTorrent
  • Ключевые слова: Magnet link, Torrent Metadata, BEP 9, BEP 10, InfoHash
  • Для кого: backend-разработчики, исследователи протоколов, инженеры поисковых систем и разработчики BitTorrent-клиентов
  • Цель: Объяснить механизм достаточно точно, чтобы на его основе можно было принимать реальные архитектурные решения для краулинга, индексации и поиска.

Системная схема

Magnet намеренно неполон

Главная часть Magnet URI — content identifier, например xt=urn:btih:.... Дополнительные параметры могут содержать display name или Tracker, но обычно Magnet не несет полноценный info dictionary. Поэтому по одному URI нельзя надежно получить список файлов и размер контента.

Смысл Magnet в том, что он позволяет начать discovery по идентичности, а недостающие данные получить позже из сети.

Сначала нужны Peer candidates

Клиент получает endpoints через DHT, Tracker или другие источники, затем пытается подключиться и подтверждает нужный InfoHash в BitTorrent handshake. Не каждый endpoint жив, доступен или поддерживает нужные extensions, поэтому production scheduler обычно пробует несколько кандидатов.

get_peers сам по себе Metadata не передает.

BEP 10 → BEP 9 → проверка

После базового handshake расширенный handshake BEP 10 сообщает, поддерживает ли Peer ut_metadata, какой локальный message ID назначен расширению и, возможно, metadata_size. BEP 9 затем передает Metadata кусками.

После сборки байты нужно проверить против ожидаемого content identity. Только проверенный результат должен попасть в canonical store и поисковый индекс.

Эскиз реализации

magnet(infohash)
   -> discover peers
   -> BitTorrent handshake
   -> BEP 10 extended handshake
   -> ut_metadata requests
   -> assemble info dictionary
   -> hash(info dictionary) == expected infohash ?
   -> parse and index

Инженерные заметки BT9G Labs

Для индексатора уровня BT9G важнее не максимальное число событий, а правильное разделение идентичности контента, краткоживущих сетевых наблюдений, состояния сбора и поискового представления. Поля, полученные из DHT или от Peer, должны иметь источник и временную метку. Метрики стоит вести по этапам: discovery, соединение, handshake, поддержка расширений, получение Metadata, проверка, сохранение и индексация. Это позволяет видеть реальное узкое место системы, а не списывать все неудачи на «нестабильную сеть».

Типичные ошибки

  • Ожидать полный список файлов непосредственно в Magnet URI.
  • Считать get_peers Metadata API.
  • Хардкодить message ID для ut_metadata.
  • Индексировать Metadata без проверки хеша.

Связанные статьи BT9G Labs

Источники

Следующая статья: BEP 9 ut_metadata: как получать Torrent Metadata от Peer →

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