4
правки
Изменения
Нет описания правки
Трекер представляет из себя HTTP/HTTPS сервис, который отвечает на HTTP GET запросы. Запрос включает информацию о файле и дополнительную статистическую информацию о торренте. Ответ на запрос содержит список пиров, участвующих в данном торренте.
Задача клиента --- получить от сервера информацию о пирах через HTTP соединение и далее, используя TCP соединение , связываться с пирами для получения/передечи передачи данных.Рассмотрим пример последовательности действий, следуя которой , можно создать примитивный BitTorrent клиент.
Для начала, можете найти в интернете любой .torrent файл. В таком файле содержится закодированая закодированная информация о торренте. В данном случае используется Bencoding кодирование про которое можно подробнее прочитать [https://wiki.theory.org/BitTorrentSpecification#Bencoding здесь], для этого, например , есть библиотека для питона bencode 3rd party library(pip install bencode).
Потребуется расшифровать и распарсить файл. Из всего, как минимум, понадобится часть announce url и info, в последней содержатся такие поля как piece length(длина кусочка), pieces(список хешей кусочков), paths и lengths для отдельных файлов (структура для торрента с отдельным файлом и несколькими может несколько различаться).
Далее, нужно сделать GET запрос серверу, используя announce url в формате ‘announce-url?param=value¶m=value&…’. Подробнее узнать про кодирование url можно [https://en.wikipedia.org/wiki/Percent-encoding здесь], а так же также можно воспользоваться питоновской библиотекой (pip install requests). О параметрах запроса можно узнать [https://wiki.theory.org/BitTorrentSpecification#Tracker_Request_Parameters тут].Примеры параметров: 'info_hash' - хеш info части разкодированого раскодированого torrent файла посчитаный посчитанный SHA1 алгоритмом, ‘peer_id’ - строка из 20 байтов, подроднее подробнее про формат [https://wiki.theory.org/BitTorrentSpecification#peer_id тут].
В ответ от сервера клиент получит закодированый список пиров. Используйте Benconde раскодировщик, чтобы в части peers найти список адресов в формате ip_address:port.
handshake: <pstrlen><pstr><reserved><info_hash><peer_id>
info_hash и peer_id уже встречались, а для текущей версии протокола 'pstrlen'=19, 'pstr'=BitTorrent protoco, 'Reserved' восьмибитовая строка.
От пира следует ожидать сообщение в аналогичном формате, и после этого проверить , соответствуют ли поля info_hash и peer_id ожидаемому, в случае несоответствия лучше сразу закрыть соединение.
Дальше существует 11 типов возможных сообщений: keep-alive, choke, unchoke, interested, not-interested, have, bitfield, request, piece, cancel, and port. Описание всех видов [https://wiki.theory.org/BitTorrentSpecification#Messages тут].
Сообщение состоит из 4 байтов задающих длину сообщения, 1 байт задает id сообщенясообщения(у сообщения вида Keep-alive этот бит пропускается), и хвост с дополнительной информацией.
* Сообщения типа Have говорят о наличии определенного кусочка у пира, номер кусочка задается 4 байтовым хвастомхвостом.
* Сообщение типа Bitfield может посылаться сразу после handshake и задавать множество имеющихся кусочков в виде битовой маски, размер которой(в битах) задается в первых 4 байтах сообщения. Данный вид сообщения может говорить не о всех кусочках, после этого пир может продолжать дополнять информацию сообщениями типа Have.
* Сообщения Interested/Not Interested говорят о том, что скачивающий пир хочет/не хочет получить опледеленный определенный кусочек.
* Сообщения Choke/Unchoke говорят о том, что раздающий пир не готов/готов отдать кусочек.
* Сообщение Request стоить посылать после того, как получили разрешение у пира(Unchoke) на конкретный кусочек, хвост у этого типа сообщения состоит за 4 байтов для номера кусочка, 4 байта для смещения внутри кусочка в байтах, и 4 байта для размера блоков, которыми вы хотите получать данные (обычно это 2^14).
