Я разрабатываю клиент 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..