BT9G LABS / DHT Deep Dive #11

BEP 10 Extension Protocol: как BitTorrent добавляет функции без потери совместимости

Extended handshake, динамические message ID и роль BEP 10 как основы для ut_metadata и PEX.

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

BT9G Labs / DHT Deep Dive #11. Почему расширения BitTorrent договариваются о возможностях на каждой отдельной Peer-сессии.

BEP 10 Extension Protocol: как BitTorrent добавляет функции без потери совместимости

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

  • Тема: BEP 10 Extension Protocol: как BitTorrent добавляет функции без потери совместимости
  • Ключевые слова: BEP 10, Extension Protocol, extended handshake, ut_metadata, BitTorrent
  • Для кого: backend-разработчики, исследователи протоколов, инженеры поисковых систем и разработчики BitTorrent-клиентов
  • Цель: Объяснить механизм достаточно точно, чтобы на его основе можно было принимать реальные архитектурные решения для краулинга, индексации и поиска.

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

Проблема совместимости

Долгоживущий протокол должен добавлять новые функции, не ломая старые клиенты. BEP 10 решает это через признак поддержки extension protocol в базовом handshake и отдельный extended handshake после установления соединения.

Новые возможности развиваются независимо, а базовый Peer Wire Protocol остается стабильным.

Extended handshake и динамические ID

Поле m отображает имена расширений на message ID, выбранные конкретным Peer. Там же могут находиться client version, listening port, metadata_size и другие данные. Числовой ID ut_metadata нельзя хардкодить глобально — его нужно читать для каждого соединения.

Это частая причина ошибок в самописных crawler.

Почему это важно индексатору

Magnet-based индексатор обычно зависит от BEP 9, а BEP 9 обнаруживается через BEP 10. Поэтому полезно иметь раздельные метрики: TCP/uTP connected, BitTorrent handshake OK, extension protocol supported, ut_metadata supported, Metadata completed.

Так можно увидеть, на каком именно этапе теряется успешность.

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

Base handshake
  reserved bit says: extension protocol supported
        |
        v
Extended handshake
  m = { "ut_metadata": 3, "ut_pex": 1 }
  metadata_size = 48321
        |
        v
Extended message 3 now means ut_metadata for this connection

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

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

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

  • Предполагать поддержку BEP 10 всеми Peer.
  • Хардкодить один message ID расширения для всех соединений.
  • Отправлять ut_metadata до extended handshake.
  • Смешивать unsupported extension и network failure в одну ошибку.

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

Источники

Следующая статья: Tracker vs DHT vs PEX: сравнение трех механизмов поиска Peer в BitTorrent →

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