Replies (15)

  • @schors, Я могу поотвечать на вопросы но картинки рисовать не готов
  • @blacklion, я не хочу учить спецификацию. мне бы вот её, но понятным языком. грубо говоря — я всё о своём, хочу сделать приватную сетку
  • @schors, когда пойму — конечно буду RFC пользоваться
  • @schors, Там вся спецификация 2 или 3 страницы.
  • @schors, И, да, он такой простой. DHT вот чутка посложнее
  • @blacklion, хорошо. а работа с трекером? и торрент файлы — это отдельно?
  • @blacklion, ты хочешь сказать, что btsync без DHT — на раз два делается?
  • @schors, Отдельно формат торрент-файла (и всего вообще обмена в протоколе). Он тоже очень простой. Работа с трекером — ещё пара страниц
  • @schors, Хорошо — нет, не на раз-два. Протокол простой, но хорошо (эффективно) сделать сложно.
  • @blacklion, вот у меня и нет картинки в голове :(
  • @schors, Для этого не нужна спека.
  • @blacklion, Если брать современную реализацию со всеми костылями, то в две страцницы никак не уложишься.
  • @schors, "Работа с трекером" состоит из одного HTTP GET-запроса (либо двух UDP-пакетов), где мы сообщаем серверу свой порт и хэш нужного торрента, а он отвечает списком пиров, которые раздают или получают этот торрент. Далее мы перебираем все пиры, сообщая друг другу сколько кусков файла у нас есть (количество и хэши кусков файла находятся в torrent-файле), говорим interested мы в этих кусках или uninterested, можем сделать request нужно куска и получить в ответ нужный piece, и сказать "have", когда кусок успешно получен. Метаданные в торрент-файле и запросах к трекеру кодируются в формат типдлина:данныеконец(если это список, иначе конец не нужен), P2P-сообщения — это пакет вида длина:тип:данные. Получаем pieces, сверяем хэши, складываем хорошие, выбрасываем плохие и отключаем плохих пиров. Что тут может быть непонятного?
    (прочитал спецификацию первый раз только что)
  • @blacklion, Одна дополнительная команда PORT, ответ на которой мы добавляем в список пиров, вот это сложность-то!
  • @vt, А добавлять куда-то ее нужно еще.