Реализация Bittorrent в java && нуждается в некоторой информации о поведении рой

Я разрабатываю клиент BitTorrent на Java. Я знаю, что в Интернете много библиотек, но я ничего не могу поделать; Я хочу своего. Во всяком случае, я заметил некоторые странные поведения, и, возможно, вы, ребята, знаете что-то, что мне не хватает:

  • Около 80% всех сверстников, с которыми я пытаюсь подключиться, приводят к неудачным соединениям (ошибки socketTimeOut или "не могут подключаться" ). Очевидно, список сверстников получен от трекеров. Я также случайно опробовал некоторые IP-адреса, пытаясь их отследить; пинг обычно выполняется.
  • Когда я подключаюсь:
    • Отключение 50% после HandShake,
    • на 30% Я заметил странное поведение: я получаю Handshake, я получаю битфилд (у них есть все части), меня обстреливают сообщения +20 Have (я проверил индекс части, который они уже упоминали об этом в BitField), затем они отбрасывают соединение, что странно.

(Для всех статистических данных цифры неточны.)

Некоторые вопросы BitTorrent:

ОБНОВЛЕНИЕ # 4: im отрезать некоторые вопросы из-за рассмотрения найденного ответа

  • Это был вопрос "80% -ный вопрос с вопросом о подключении": Что может быть причиной того, что мой 80% не смог подключить тариф? Это не может быть неудачей, в том смысле, что у каждого клиента, с которым я пытался связаться, больше не было места для меня. Я слушаю 6881, но тестирую и другие порты. Вчера у меня был большой успех, куча подключений (такой же код, несколько изменений на прошлой неделе), сообщения Piece начали течь... так что мой код не совсем бесполезен.Дел >

  • Перед тем, как закрыть, торрент-клиент отправит последнее сообщение трекеру с помощью event=stopped, чтобы он обновил свою внутреннюю базу данных с информацией о свертке, чтобы он не отправлял в качестве ответа список с бесполезным одноранговым узлом Информация? Или просто они должны... потому что действительно кажется, что я получаю мертвых сверстников.

  • Является ли порядок полученных сверстников какой-либо важностью? Может быть, процент завершения... или действительно случайный.
  • Кроме того, время от времени я получаю одноранговый узел с портом 0, что делает мой конструктор Socket исключением. Что означает порт 0? Могу ли я связаться с ним на любом порту?
  • Может ли мой PeerId (который я посылаю в Handshake или объявить себя на трекер) влияет, если торрент-клиент, с которым я пытаюсь общаться, продолжит запущенное соединение? Что означает, если я ложусь и скажу, что я клиент Azureus, используя "-AZ2060-" в качестве своего идентификатора?
  • Это была "возможность наличия штукатурки на вопрос о сверстниках": Является ли доступность моей штуки сверстниками? Я пытаюсь подключиться, и я посылаю пустое поле бит (у меня нет фрагментов, [length: 1][Id = 5][payload: {}]); кажется, что они отправляют битфилд, я отправляю битфил.. (некоторые посылают, как сумасшедшие, имеют сообщения), они понимают, что я беден, они бросают меня.. некоторые перетаскивают соединение после рукопожатия. (Как грубо.)
  • Есть ли преимущество использования классического интервала порта: 6881 - 6889?
  • Это был "список проблем с равными людьми": У клиентов торрента хранится список неверных сверстников (например, черный список)? Иногда, найдя хорошего партнера, я постоянно использовал его информацию в своих тестах, но было принято только 1/3 соединения. Иногда 10 минут должны были пройти, чтобы иметь успешную связь.Дел >

UPDATE # 1: кажется, что соединения с & mu; Torrent-клиентами ведут себя в вышеупомянутом шаблоне (BITFIELD, HAVE bombardment, close connection). Я тестировал локально с кучей bitTorrent-клиентов (& mu; Torrent, BitTorrent, Vuze, BitCommet, Deluge) и только заметил этот шаблон на & mu; Torrent. В остальном общение было прекрасным (HS, BITFIELD, UNCHOCE и счастливое разделение). Теперь этот & mu; Torrent, вероятно, самый популярный клиент BitTorrent (началось 6/8 соединений, было и mu; Torrent), поэтому & hellip; любые идеи?

ОБНОВЛЕНИЕ # 2: В терминах сохранения "bad list," это выглядит так (и на самом деле имеет смысл сделать это). Например, с & mu; Torrent, я заметил следующие интервалы без соединения (30 с, 1 мин, 1 мин 30 с, 2 мин..). Под "no-connect" в среднем, после того, как предыдущее соединение закончилось, за x секунды не было принято нового соединения.

ОБНОВЛЕНИЕ № 3: Это сообщение об ошибке сообщения HAVE могло быть так называемым "ленивым битовым полем" (было проведено несколько тестов, каждая часть, упомянутая в HAVE, отсутствовала в BITFIELD). Я вижу, что & mu; Torrent и BitTorrent используют этот подход.

Еще одно заключение. Некоторые клиенты более ограничительны с точки зрения соблюдения спецификаций BitTorrent и будут закрывать соединение, если нарушаете правило. Пример:Я заметил с BitTorrent и BitTornado, что, если вы отправляете сообщение с битовым полем, но не имеете частей, они закрывают соединение (no pieces = empty bitfield.., но спецификации говорят: "Это необязательно, и его не нужно отправлять, если клиент не имеет частей" ), в то время как другие закрывают соединение, если вы отправляете какой-либо тип сообщения, прежде чем отправлять сообщение UNCHOKE (даже НЕ ЗАИНТЕРЕСОВАНО).

ОБНОВЛЕНИЕ # 4: Поскольку им в основном интересовался первый вопрос (что могло быть причиной того, что мои 80% не смогли подключить тариф?.. нападающие вопросы более чем вероятно понравились), вот несколько объяснений, почему иногда соединения были неуспешными:

1), если я запустил соединение с одноранговым узлом вскоре после остановки предыдущего соединения (путем остановки - я имею в виду закрытый сокет): сверстник с другой стороны не знает до следующего чтения/записи.

Подробнее: - Я заметил это несколько раз, это более очевидно после окончания загрузки. Если я закрываю соединение, он не поймет это, пока не попытается отправить новый KEEP_ALIVE (~ 2 минуты). Но если я закрою время в обмене REQUEST-PIECE, сверстница быстро выполнит preety. В первом сценарии после закрытия соединения я все еще присутствую на вкладке uTorrent peer. Если я загляну внутрь вкладки журнала, примерно через 2 минуты, он поймет, что меня нет.

2) кажется, что uTorrent видит, что мое сообщение BITFIELD повреждено (& очевидное должно закрыть соединение после получения его) (это не всегда происходит. Также я проверил и перепроверял, msg в порядке, а с другим клиентом BT не было таких проблемы)..

Подробнее: - если я заглянул внутрь вкладку logor uTorrent, он отобразит "Disconnected: Bad packet" сразу после отправки битового поля - Я планирую попробовать реализацию lazzy bitfield, возможно, я смогу избежать этого (также я вижу, что большинство клиентов BT делают это)

3) (более чем вероятно связано С# 1), когда uTorrent не позволяет мне повторно подключаться, я вижу на вкладке logger: "Отключить: уже есть равное соединение (отключение дополнительного подключения)". В настоящее время я выбираю случайный локальный порт при инициализации нового соединения (это было реализовано в большинстве BT-клиентов), но это не обманет его, он все еще видит, что он уже присутствует в своем "списке сверстников" (возможно, это соответствует ip). Buuut: in 30% тестов, тот же сценарий, он позволяет мне снова подключиться:).. У меня нет объяснений, почему еще

4) еще одна вещь: кажется, что "слушатель для входящих связей" все еще жив после того, как вы закрываете торрент в uTorrent (близким я подразумеваю: правый клик + остановка). Эта означает, что я все еще могу начать соединение, отправьте HANDSHAKE.. после этого я отключен (он не возвращается HANDSHAKE). Сообщение в uTorrent logger: "Отключить: нет такого торрента: 80FF40A75A3B907C0869B798781D97938CE146AE", эта длинная строка - это мой хэш-информация... видел это во время тестирования с другими клиентами BT.

Дополнительная информация:

  • сценарии с uTorrent типа полной загрузки/частичной загрузки и полной загрузки являются успешными, а частичной загрузки - не так много. Вероятно, из-за # 2
  • Я все еще получаю с uTorrent, что bitField + имеет бомбардировку + закрыть соединение.. как я помню тот же самый msg на вкладке logger "Disconnected: Bad packet".. возможно, из-за # 2
  • Помимо uTorrent, я тестировал с помощью: BitTorrent, BitTornado, BitCommet, qBitTorrent, FlashGet (общение было в порядке) и с Vuze, FrostWire, Shareaza (с этими парнями это было супер нормально).
  • не все клиенты ведут себя одинаково. Пример: FlashGet и uTorrent (& BitCommet?) не отключайте до тех пор, пока вы не отправите ЗАИНТЕРЕСОВАНО.., в то время как другие, похоже, после BITFIELD.. в этом смысле я планирую как-то относиться к клиентам по-разному (я действительно думаю, что это необходимо). Вероятно, угадайте их имя из битового поля (есть только 2 соглашения об именах) и начинайте оттуда.. у меня уже есть что-то реализованое, вот как я знаю, что я подключился к клиент типа uTorrent..

Ответы

Ответ 1

Хорошо, у меня есть ответ для вас, но я должен предупредить вас, что я сам никогда не писал клиент-бит-торрент, и некоторые ответы могут быть не точными на 100%, все, что я написал, - это мое понимание глобального представления о том, как бит-торрент-работа. Поэтому я прошу прощения, если я потратил впустую ваше время, но я все еще думаю, что вы можете узнать о сути того, о чем вы спрашиваете, из моего ответа.

• Что может быть причиной того, что мой 80% не смог подключить тариф?

Очень сложно объяснить в одном линейном объяснении, но: - бит-идеал торрент-тит-4-тат.. если ты не даешь/сиськи, ты не получаешь тат.. ЕСЛИ вы только начали загружаться, и в этом случае вы можете получить "пожертвование", чтобы начать с... ИЛИ с другой стороны - специализированная машина для посева. В этом случае он может проверить, является ли вы дарителем или просто владельцем... ИЛИ многие в настоящее время загружают это... ИЛИ (заполните свою идею..) Итак, вы видите, что есть много и действительно очень умных механизмов, чтобы убедиться, что рой может быть проворным и эффективным, и хотя некоторые из них можно проследить на вашей машине, большинство из них на самом деле не могут даже контролироваться вашей машиной, по крайней мере, контроль.

• Скачали ли торрент-клиенты перед закрытием последнее сообщение для трекера с event = stop, чтобы он обновил свою внутреннюю базу данных с информацией о сверстке, чтобы он не отправил в качестве ответа список с бесполезной информацией сверстников? Или просто они должны... потому что действительно кажется, что я получаю мертвых сверстников.

  • Это зависит от кода клиента - некоторые могут сделать что-то не... (продолжайте читать)

• Является ли порядок полученных сверстников какой-либо важности? Может быть, процент завершения... или действительно случайный.

  • Это зависит от кода сервера - некоторые могут сделать что-то не... (продолжайте читать)

Хорошо, обратите внимание на эти две примечания (продолжайте читать). Вы должны иметь в виду, что в сети P2P нет полномочий строго привязывать клиентов или даже серверы к поддержанию протокола к письму, даже если протокол утверждает что-то, что должно быть сделано - это не означает, что каждый клиент будет реализовывать его или действовать на нем или при его отсутствии.

• Кроме того, время от времени я получаю одноранговый узел с портом 0, что делает мой конструктор Socket исключение. Что означает порт 0? Могу ли я связаться с ним на любом порту?

  • Порт 0 - это подстановочный знак, если вы подключаетесь к нему - он автоматически подключит вас к следующему доступному порту. (некоторые говорят, что следующий доступный порт выше 1023 - но я никогда не тестировал это)

• Может ли мой PeerId (который я отправляю в Handshake или объявить себя трекеру) влияет, если торрент-клиент, с которым я пытаюсь общаться, продолжит запущенное соединение? Что означает, если я ложусь и скажу, что я клиент Azureus, используя "-AZ2060-" в качестве своего идентификатора?

Он подумает, что вы Azureus, и если другие Azureuses способствуют соединению с Azureuses в соответствии с этим (и что большой, если есть), вы получите от него выгоду.

• Охватывает ли моя часть возможность сверстников? Я пытаюсь подключиться, и я отправляю пустое поле (у меня нет частей, [длина: 1] [Id = 5] [полезная нагрузка: {}]); кажется, что они отправляют битфилд, я отправляю битфил.. (некоторые посылают, как сумасшедшие, имеют сообщения), они понимают, что я беден, они бросают меня.. некоторые перетаскивают соединение после рукопожатия. (Как грубо.)

  • возможно..

• Существует ли преимущество использования классического интервала порта: 6881 - 6889?

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

• Предоставляют ли торрент-клиенты внутренне список плохих сверстников (например, черный список)? Иногда, найдя хорошего партнера, я постоянно использовал его информацию в своих тестах, но было принято только 1/3 соединения. Иногда 10 минут должны были пройти, чтобы иметь успешное соединение снова.

  • Зависит от кода клиента.

Резюме

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