[s.lobanov]

' timestamp='1322244870' post='659414']

не вижу причин не добавить retracker.local/peerpolicy.xml.

 

Ну и как это файл в xbtt запихивать? Ковырять исходяки нет никакого желания, ставить nginx как frontend конечно можно, но не всегда нужно.

[[anp/hsw]]

Ну и как это файл в xbtt запихивать? Ковырять исходяки нет никакого желания, ставить nginx как frontend конечно можно, но не всегда нужно.

 

извините, не знал, что у кого-то xbtt голым задом выставлен - обычно на IP от retracker.local много чего висит, и фронтэнд всегда есть.

 

тогда остается peerpolicy.local/announce.xml, без вариантов. Мудрить много не стоит, формат имен достаточно устоялся, а существование всякого мусора в *.local думаю переживут все.

Изменено 25 ноября, 2011 пользователем [anp/hsw]

[s.lobanov]

' timestamp='1322245614' post='659418']

обычно на IP от retracker.local много чего висит, и фронтэнд всегда есть.

 

"Обычно" целиком и полностью зависит от масштаба оператора. У кого-то на одном сервере днс, база биллинга, там же что-то натится и шейпится, а у других на каждый чих свой сервер/виртуалка.

 

внешний IP и по нему имя домена он определяет, по всей видимости, после первого соединения с внешним пиром. При наличии связи только с трекером bep22 не отрабатывает даже при наличии внешнего IP на интерфейсе. И в хождении на какие нибудь whatismyip.com он не замечен.

 

Тоже так подумал(что узнаёт свой IP от внешнего пира), но есть маленькая проблема - если в пределах одного isp есть абоненты с серыми и белыми адресами и все они живут в одной таблице маршрутизации, то от такого пира не узнаешь свой внешний IP

 

P.S. Запихивать описание peer-policy в зону .torrent не надо, разработчики всяких dc++ обидятся и не будут использовать этот файл. .local более нейтрально

[st_re]

$ tail -10000 /www/retracker1.local/log/httpd-access.log | egrep| awk  '{printf $2 "\n";}' | sort | uniq -c
3581 retracker.XXXX.ru
913 retracker.home
5506 retracker.local

 

Первый это беп22.

 

2 s.lobanov для IP, даже серых, выдаваемых клиентам можно и обратку прописать, кстати.... просто снятый с интерфейса серый IP может оказаться вообще дома за рутером.

[grey_rat]

Просто не факт , что и через год выйдет FAQ от разработчиков utorrent с описанием применения isp.peer_policy_url через bep22

Поэтому и временный вариант может стать постоянным .

 

тогда остается peerpolicy.local/announce.xml, без вариантов

 

Ок , если никто не против , тогда осталось составить текст на английском языке с этой просьбой .

Может кто-нибудь из вас хорошо владеет иностранными языками ?

 

Есть ещё вариант связаться на форуме http://forum.utorrent.com/viewtopic.php?id=63921 с Algis ( он вроде тоже в этом давно заинтересован ) в плане составления текста на английском .

[[anp/hsw]]

Такой перевод покатит?

 

Hello!

We are from Russian ISP community and have some suggestions about peer policy usage:

Because of complicated network design of some ISP's usage of bep22 option will return unsatisfying results.

We offer to use http://peerpolicy.local/announce.xml as default isp.peer_policy_url variable.

If network design is not allowing to use bep22 correctly, this default will guarantee utorrent to access peer policy file on certain ISPs.

[grey_rat]

Только сверху ники разработчиков , что бы не проигнорировали :)

Firon , AdamK , DreadWingKnight , Ultima , Greg Hazel

Hello!

We are from Russian ISP community and ..............

 

Денёк подождём , наверно . Может ещё кто-нибудь здесь отпишится

[st_re]

Уу, а потом клиент поставит себе 8.8.8.8 в качестве DNS сервера и все Ваши задумки пойдут лесом... для SRV записи в домене это пофиг. Она будет и через 8.8.8.8 и прочие резалки порнушки, обсуждавшиеся уже тут не раз. Главное в самом utorrent уже все есть для выяснения, какой же там домен и какой надо сделать запрос для bep22.

[s.lobanov]

st_re

Недавно уже всплывала тема как завернуть 8.8.8.8 на свой dns(технически это тривиально, важен сам факт что это спросили)

 

Поделитесь рецептом как формируется SRV запись для ссылки на peer_policy

[st_re]

http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%82%D1%80%D0%B5%D0%BA%D0%B5%D1%80#bep22

 

$ dig srv _bittorrent-tracker._tcp.XXX.ru
;
_bittorrent-tracker._tcp.XXX.ru. 3600 IN SRV 5 0 8888 retracker.XXX.ru.
;

 

В итоге ретрекер будет

http://retracker.XXX.ru:8888/announce

 

поправить tracker на peerpolicy

 

Насчет завернуть. Кроме 8.8.8.8 есть еще пачка таких служб, где, к примеру, в DNS запросах фильтруют урлы парнушные. Всех заворачивать ? Я лично буду сильно ругаться, если мне вместо моего собственного DNS мастера на моем собственном хосте на внешнем хостинге, напоет Мойша ответит чей то кеш. Уж извините я отличу ответ от своего сервера и от чьего то кеша.

[s.lobanov]

http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%82%D1%80%D0%B5%D0%BA%D0%B5%D1%80#bep22

 

$ dig srv _bittorrent-tracker._tcp.XXX.ru
;
_bittorrent-tracker._tcp.XXX.ru. 3600 IN SRV 5 0 8888 retracker.XXX.ru.
;

 

В итоге ретрекер будет

http://retracker.XXX.ru:8888/announce

 

поправить tracker на peerpolicy

 

Это уже поддерживается uTorrent'ом или только Ваше предложение?

[st_re]

Я там, выше, в 29 посте, статистику по попаданию на локальный трекер приводил. Все что у меня там попадает на retraker.XXX.ru попадает именно так. Никаких действий по принуждению к включению в клиентах bep22 не проводилось. стандартные хомяки. Единственно что было сделано, в DNSе заведена запись srv _bittorrent-tracker._tcp.XXX.ru и запись А retracker.XXX.ru. (ну и на сервере где ретрекер сказали слушать на сотв порту имя retracker.XXX.ru.) Это работает несколько лет уже. Но до версии 3 нужно было включать в клиенте руками bep22: да, сейчас в версии 3 оно включено само.

 

Попросите сделать также для peerpolicy.

[[anp/hsw]]

На самом деле bep22 всем хороша, но не подходит в ряде случаев:

1. Когда провайдер не администрирует реверсную dns-зону (например сидит на сети /24, арендованой у магистрала, и его все устраивает) - конечно, может и попросить поправить зону, но от некоторых не дождешься.

2. Определяется неверный внешний адрес (как правильно уже сказали, в случае, если серые и белые IP находятся в одной таблице маршрутизации, причем, явление выходит за рамки одного провайдера - на большинстве городских IX серые адреса также котируются).

3. В случае, если у пользователя DNS-ом выставлен какой-нибудь публичный (и нужная srv не прописана), запрос по домену .local имеет вероятность пойти multicast'ом, и в итоге мы всетаки получим необходимые данные (у кого-то из хостов может быть настроен форвард из мультикаст днс в обычный, а то и у провайдера поднят необходимый сервис)

 

Ну и главное - внедрение peerpolicy.local также просто, как и retracker.local - не нужно больше ни с чем заморачиваться, зона уже создана, итд.

[grey_rat]

Попросите сделать также для peerpolicy.

В этом то вся и проблема , что им даже FAQ по тому что есть лень делать . По этой же причине хотя бы временным вариантом может служить http://peerpolicy.local/announce.xml "Их величествам" нужно будет всего лишь добавить эту строчку в utorrent .

В будущем когда секрет isp.bep22 будет разгадан можно будет так же попросить их убрать эту строчку (если в этом будет необходимость)

 

Если я правильно понимаю , сейчас есть выбор только между :

Просить юзеров вставлять в поле isp.peer_policy_url нужную ссылку в ручную

Вообще ничего не делать

Изменено 26 ноября, 2011 пользователем grey_rat

[st_re]

ну секрета там вроде нету никакого, в беп22 то

http://www.bittorrent.org/beps/bep_0022.html

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

 

На локал многие ругались еще когда рутрекер его вводил. Утверждалось, что в случае локального мака, юбунты и еще когото локал не ресолвится, ибо mDNS. Локал не ресолвится через некоторые варианты кеширущих DNS серверов, если тому не вправлять руками мозги. Такие сервера любят впихивать в линуксовые сборки для всяких блинков (к счастью производители пока в таком не замечены, но умельцев, ставящих себе альтернативные сборки, вагон. 99% из них не понимают того, что делают, им друг сказал что эта прошивка лучше). Варианты когда внутренний сервис был на сером адресе, а клиент туда никак не мог попасть, т.к. его прошивка, которую он туда влил, тупо вырезала из DNS ответов все 10.*.*.* и 192.168.*.* как будто там таких и не было никогда, я уже видел. Вариант, что провайдер поднимет у себя мультикаст ДНС идет лесом на первом же клиентском рутере. Да и как то весело будет, когда клиент какой вывалит туда "альтернативную" версии топологии... понятно, что ядреной войны не будет, но вы, по моему, не за то боретесь.

 

А если вдруг у провайдера IP от аплинка и он не может заставить аплинка сделать правильный реверс, то он точно так же как может сделать зону local, он может сделать свою обратную зону для своей сети на своих серверах. Да она не будет работать в случае 8.8.8.8 у клиента, но локал точно также не будет. Зато оно не конфликтует с описанным выше. Проблему сделать реверс внутри для своих серых адресов, уж если можно сделать локал, я тоже не вижу. Ведь проблема только в том, чтобы клиент, понявши что он ломится с IP х.х.х.х получил домен XXX.xx. Если у клиента ресолвер ваш, то отдайте там ему соответствующий PTR. Если внешний, то никакого локал у него не будет ресолвится точно так же как и обратной зоны для серых IP. Везде, где можно впихнуть локал, везде можно отработать все необходимое для bep22. Но далеко не везде где Local отваливается, у беп22 тоже будут проблемы.

 

просить что о прописать вручную точно не вариант. Попросить можно 5 человек. и то, 3 из них через месяц сменят ОС и не внесут снова те же настройки.

 

Кстати есть

http://www.bittorrent.org/beps/bep_0024.html

который помогает сообщить клиенту его IP со стороны трекера. Можно бы проверить что ваш ретрекер отдает то, что нужно клиенту.

 

И еще раз, беп22 описывает поиск локального ретрекера, но взять всю эту бадягу и тупо заменить трекер на полиси, то вот готовое описание нового протокола для поиска isp.peer_policy_url. Все единообразно с тем что уже сделано. не конфлитует со всякими там авахами (ссылки на которые, кстати, есть в bep лежащих на том же сервере. Ломать себе mDNS они точно не будут).

[Ivan_83]

В мелких коробках в 99% ставят dnsmasq, что вендоры что альтернатива.

 

Вендоры не включают в конфиге

 

stop-dns-rebind

domain-needed

bogus-priv

 

потому что им плевать на безопасность, лишь бы работало.

 

 

[st_re]

ну, на мой взгляд сильно спорно включение stop-dns-rebind и bogus-priv для массового потребителя. если бы оно хотябы вырезало только то, что действительно внутри ната. (т.е. если клиенту внутрь раздается 192.168.2.0/24 то ее и вырезать, а не все 10. 172.16-31 и 192.168 скопом). А в том виде больше зла. По любому это все хорошо, когда использующий понимает, что он делает и зачем.

[grey_rat]

Отправил сообщение на форум в ветку 3.1

http://forum.utorrent.com/viewtopic.php?pid=621170#p621170

 

К первоначальному варианту добавлено

Please show example of using bep22 option to show correct usage of isp.peer_policy_url with bep22, if client able to fill isp.peer_policy_url from bep22 lookups

 

ждём ответа ....

[[anp/hsw]]

There is no way to automatically set a peer policy. You need to inform your users to set it manually.

 

Приплыли. Боятся, что это самый легкий путь закрыть торренты (а так оно и есть).

[grey_rat]

Ну многим пользователям оно в любом случае пригодится особенно в локалке .

Планирую выйти на модераторов рутрэкера для создания темы типа "Увеличение скорости загрузки/раздачи в utorrent 3.х"

Там распишем что да как , ну и по провайдерам сылки (которые вы дадите) на isp.peer_policy_url опубликуем.

Так что в любом случае эта тема создана не зря :)

 

Если список будет подбивать обычный пользователь , объясните плиз что каждая строка означает и что можно писать , а что нельзя в файл ?

Например

<btpolicy version="1.0">

<revision>

2

</revision>

<oper>

Orionet

</oper>

<message>

Test rules

</message>

<ttl>

5

</ttl>

 

Без каких строчек можно обойтись и что означает цифра 5 в <ttl> ?

 

<iprange start="10.0.0.0" end="10.255.255.255" weight="9"/>

Если максимальное значение 10 , зачем ограничиваться 9 ? От каких чисел желательно двигаться и в каких промежутках (почему между 7 и 9 нет 8 ) ?

Изменено 28 ноября, 2011 пользователем grey_rat

[[anp/hsw]]

weight это просто приоритет, 7 или 8 не важно - здесь играет роль только "меньше-больше".

Что такое ttl - не знаю; как минимум без message можно обойтись.

[littlesavage]

Ну многим пользователям оно в любом случае пригодится особенно в локалке .

 

ttl - время между обновлениями. Аналогичен параметру ttl формата RSS. Правда, оно почему-то не работает. Файл всегда скачивается 1 раз в час.

 

Элементы oper, message, ttl не обязательные. Revision лучше оставить и увеличивать при кадом обновлении файла. Значения weight - от 0 до 10 без каких-либо ограничений. Можно использовать и 0, 8, 10 :)

Изменено 28 ноября, 2011 пользователем littlesavage

[grey_rat]

[anp/hsw] , littlesavage , спасибо :)

[vasiliy0]

' timestamp='1322450328' post='659888']

There is no way to automatically set a peer policy. You need to inform your users to set it manually.

 

Приплыли. Боятся, что это самый легкий путь закрыть торренты (а так оно и есть).

 

Через bep22 тоже можно гадостей понаделать, к примеру, если провайдерский ретрекер будет отдавать на любой торрент кучу мусорных IP.

А так, как изменение приоритета может сказаться? В политиках нет "запрещающих" стоимостей, всё равно клиент рано или поздно соединится с нужным ему пиром и скачает.

А еще utorrent может запрашивать reverse-dns у каждого потенциального IP, и в первую очередь соединяться с теми, у кого 2-й уровень dns совпадает со своим (хотя тут тоже, возможно, вой будет еще тот, dns-ки лопнут итд).

[Ivan_83]

А еще utorrent может запрашивать reverse-dns у каждого потенциального IP, и в первую очередь соединяться с теми, у кого 2-й уровень dns совпадает со своим (хотя тут тоже, возможно, вой будет еще тот, dns-ки лопнут итд).

 

Не лопнут, мизерная нагрузка.