Разные peer_hash для одного сида в bb_bt_tracker

[sхс]

Версия TP

иная

Судя по логам при обновлении в торрент клиенте (реанонсировании) в announce.php отправляется сразу два запроса с разными info_hash

Спойлер: click

15.03.2024 16:18:16 IP: xx.xx.xx.xx STATUS: xxxxxxxxxx REQUEST: uk=xxxxxxxxxx info_hash=жOрІсq8Hа?{wB„gІRУЙШ peer_id=TIX0319-d4i3c7a4d2i7 port=15072 uploaded=0 downloaded=0 left=84391115 corrupt=0 key=9407B0B3 event=started numwant=100 compact=1 no_peer_id=1 info_hash_hex=e64ff0b2f1713848e03f7b77428467b252d3c9d8 peer_hash=43198d6472e86ab3d694eebd0169dc0a
15.03.2024 16:18:16 IP: xx.xx.xx.xx STATUS: xxxxxxxxxx REQUEST: uk=xxxxxxxxxx info_hash=+@‚рyђђ7b‡@ГZ<yМ0>л peer_id=TIX0319-d4i3c7a4d2i7 port=15072 uploaded=0 downloaded=0 left=84391115 corrupt=0 key=89CDF258 event=started numwant=100 compact=1 no_peer_id=1 info_hash_hex=2b4082f07990900337628740c35a3c79cc303eeb peer_hash=813f9301733d7c184f6e4e954e894b74

где
2b4082f07990900337628740c35a3c79cc303eeb 20битный хэш торрента
e64ff0b2f1713848e03f7b77428467b252d3c9d8 32 битный хэш торрента обрезанный до 20бит

Из-за чего получаем количество сидов в два раза больше чем имеется.

Сначала подумал избавиться от дублей в announce.php добавив info_hash_v2 в генерацию peer_hash
$peer_hash = md5( $info_hash_hex . $info_hash_v2_hex . $passkey . $ip . $port);

Но как это сделать если инфо хэши приходят двумя запросами от торрент-клиента

 

[sхс]

Причина отправки двух запросов клиентом

 

[kovalensky]

Вы пытаетесь внедрить BitTorrent v2 в 2.1.5?

Посмотрите на source код announce.php в ветке 2.4.*, логика v2 анонсов не простая.

 

[sхс]

Скорее в R600
Нет, вернее в базе храню info_hashv2, но регистрировать на трекере пока не могу. У меня поддерживаются форматы v1 и hybrid(v1+v2) от qbittorrent

Даже если нет поддержки v2, все равно обрезаный хэш v2 приходит от клиента

Я просто не нашел в коде новой версии движка как избавиться от дублей поэтому вывалил это

Если peer_hash формируется на основе одной из версий приходящей info_hash и тем самым порожадет дубли в базе, то не будет ли логичным включить оба info_hash в формирование peer_hash и не важно если какой-то из них будет пустым

 

[sхс]

В общем я это исправил в announce.php таким кодом. Но это еще один запрос к базе....

$info_hash_hex = bin2hex($info_hash);
//....
$sql="SELECT info_hash, info_hash2 FROM bb_bt_torrents
WHERE HEX(info_hash) = '$info_hash_hex'
OR HEX(info_hash2) LIKE '$info_hash_hex%'
LIMIT 1";

$row_info = DB()->fetch_row($sql);

if(isset($row_info['info_hash']) AND isset($row_info['info_hash2'])) {
    $info_hash_hex = bin2hex($row_info['info_hash']).bin2hex($row_info['info_hash2']);
}

// Peer unique id
$peer_hash = md5(
    $info_hash_hex . $passkey . $ip . $port
);

 

[kovalensky]

Вашу логику в коде не понял, но распишу как я избавлялся от дублей:
Если высылаются поочередно два инфо-хеша, мы записываем статистику в базу только одного запроса, так как они идентичны (тот же uploaded, downloaded, event и т.д.)
Я использую для этого переменную $hybrid_unrecord:

    if (!empty($row['info_hash']) && !empty($row['info_hash_v2'])) {
        $stat_protocol = match ($bb_cfg['tracker']['hybrid_stat_protocol']) {
            1 => $row['info_hash'],
            2 => substr($row['info_hash_v2'], 0, 20),
            default => $row['info_hash']
        };
        if ($info_hash !== $stat_protocol) {
            $hybrid_unrecord = true; // This allows us to announce only for one info-hash
        }
    }

Проверьте места где эта переменная используется.

Движок предусматривает по умолчанию запись статистики v1 запроса, версия меняется в config.php:

$bb_cfg['tracker'] = [
// ...
    'hybrid_stat_protocol' => 1, // For hybrid torrents there are two identical requests sent by clients, for counting stats we gotta choose one, you can change this to '2' in future, when v1 protocol is outdated
];

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

Please Login or Register to view hidden text.

и попытайтесь вникнуть в логику.

 

[sхс]

Логика такая: создается релиз и в базу в bb_bt_torrents вносится два значения info_hash и info_hash_v2 посредством функций
$info_hash = pack('H*', sha1(bencode($info)));
$info_hash2 = pack('H*', hash('sha256', bencode($info)));

а уже после смотрю в базу в bb_bt_tracker и вижу там два разных peer_hash на основе этих хэшей

    'hybrid_stat_protocol' => 1, // For hybrid torrents there are two identical requests sent by clients, for counting stats we gotta choose one, you can change this to '2' in future, when v1 protocol is outdated
    'disabled_v1_torrents' => false, // disallow registration of v1-only torrents, for future implementations where client will use v2 only and there won't be need for v1, thus relieving tracker
    'disabled_v2_torrents' => false // disallow registration of v2-only torrents

У меня сегодня выходной под пиво. Но попытаюсь понять.
Я так понял вы даете разрешение посредсвом конфига: либо то либо это.

А почему бы не реализовать распознование всех форматов, будь то 1,2 или гибрид и избавить рядового пользователя от этого конфига? Неизвестно когда v2 вступит в силу и вступит ли? Гибрид уже существует и им пользуются. v1 - еще не скоро от него откажутся, да и полного старых трекеров которые на нем.

 

[sхс]

По поводу дублей не понял как они ловятся.

Если высылаются поочередно два инфо-хеша, мы записываем статистику в базу только одного запроса

Вот это очень интересно, но я не понял как игнорируется второй запрос
Если peer_hash формируется на основе

Please Login or Register to view hidden text.

 

[kovalensky]

Буду писать в этой теме.

Вот это очень интересно, но я не понял как игнорируется второй запрос

В статистике пир отображается, если мы записали его данные в bb_bt_tracker, а мы в него записываем, только если переменная $hybrid_unrecord пуста.
Т.е.

Please Login or Register to view hidden text.

и

Please Login or Register to view hidden text.

, peer_hash здесь роли не играет.

Также оператор LIKE работает не всегда, он текстовый и конвертирует бинарную строку, а она может содержать неправильные последовательности байтов, которые влияют на результат.
SUBSTRING же таких конвертаций не делает. Случай такого торрента внизу.

А почему бы не реализовать распознавание всех форматов, будь то 1,2 или гибрид и избавить рядового пользователя от этого конфига?

Так и делается, регистриются оба формата, и оба принимаются анонсером, только если торрент гибридный, то в базу записываются данные одного формата, против дублей.
Директивы disabled_* для удобства и совместимости, если администратор решит запретить чистые v2, или v1 торренты в будущем.

 

[sхс]

LIKE работает не всегда

Не знаю как в sql, но в php substr работает очень даже некорректно. Поэтому изобрели mb_substr который тоже, порой, глючно работает. Да и если присмотреться у меня идёт проверка по hex формату (набор шестнадцатеричных символов) там скорее возникнет вопрос в скорости работы если like заменить на две проверки (точного соответствия и обрезанной строки)

В движке так
SUBSTRING(tor.info_hash_v2, 1, 20) IN ('$info_hashes_sql')";
У меня так
HEX(info_hash_v2) LIKE '$info_hash_hex%'

По прежнему считаю что $info_hash нельзя ни экранировать не прогонять через какие либо функции, сначала перевести в hex, а потом уже с ним работать

Не специалист по инъекциям, но даже если она будет, какой от нее толк если она будет в виде набора шестнадцатеричных символов..
...
INSERT
...
$values = "x'$info_hash_hex', x'$info_hash2_hex',