Кинофорум

нельзя-ли сделать что-бы "магнитные ссылки/Magnet-URI" как для ютуби/youtube тд форматировались/превращались в ссылку как обычный адрес URL для более удобного скачивания сэмплов?

сори конечно, но сказать честно качать сэмплы с файл-хостингов и вводить коды да ещё на 50кб/с желания не возникает.. да и в комментах выглядит это как-то дико.. может добавите в форме "добавить торрент/закачать фильм" поле для ввода "магнитной ссылки/Magnet-URI" что-бы было проще как-бы с этим.. и к тому-же магнитную ссылку гораздо проще создать - создав торрент на том-же компе где и находится раздача и загрузка сэмпла намного быстрее..

создание магнитной ссылки:

1. создаём торрент для сэмпла как для раздачи только без указания торрент трекера (поле трекеры должно быть пустым).
2. ставим галки на "Включить DHT", "обмен пирами", и на "поиск локальных пиров".
3. в клиенте правой клавишей мыши по раздаче с сэмплом и выберите "Копировать Magnet-URI".
4. ссылку можно теперь вставить либо в комментарий, либо в форму раздачи на трекере(если такая появится)..

FAQ

в торрент-клиенте должны быть разрешены входящие соединения.

данный способ не проверялся на динамическом/сером ай-пи/IP адресе..

• Ответить
• Редактировать
• Вырезать
• Отменить выбор
• Удалить
• Сообщить о нарушении Правил

Вот именно. Только хотел написать про серые IP, а потом только увидел последнюю строчку.

А т.к. многие раздающие имеют как раз "серые" IP, то для других владельцев "серых" адресов такие ссылки будут недоступны. Разве что если оба в одной "серой" зоне и включен поиск локальных.

Про "белые"-динамические не знаю. Скорее всего кое-как будет работать через DHT. А вот обмен пирами тут как бы и не при чем - он для ускорения поиска новых пиров/сидов при трекерной раздаче.

• Ответить
• Редактировать
• Вырезать
• Отменить выбор
• Удалить
• Сообщить о нарушении Правил

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

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

кое-как не будет работать если фаервол/firewall настроен правильно.. но все естественно обычно закрывают всё входящие соединения поэтому и работает всё кое-как..

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

• Ответить
• Редактировать
• Вырезать
• Отменить выбор
• Удалить
• Сообщить о нарушении Правил

Кгхм ...

Впервые слышу, что при DHT или PEX осуществляется обмен данными через кого-то. Это всего лишь механизмы поиска пиров/сидов помимо трекера. Поиска, а не использования их как релеев для перекачки данных через них.

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

Про механизм работы PEX рассказано в http://www.kinokopilka.pro/forum_topics/10902. DHT тоже помогает находить сидов/пиров с аналогичными раздачами, даже если раздача оформлена на другом трекере или безтрекерная.

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

Кроме того, локальные адреса, найденные по поиску локальных пиров, не передаются по DHT и PEX, кроме как так же внутри локальной сети.

Даже если путем этих механизмов одному пользователю с "серым" IP удалось бы найти другого пользователя с "серым" IP, но в другой локалке, то соединиться им бы не удалось, т.к. "серые" адреса видны только внутри локальных сетей.

Единственный способ соединения пользователей с "серыми" адресми из разных зон - создание teredo-туннеля. Но это не всегда срабатывает из-за особенностей сетевого оборудования.

По поводу Teredo: http://www.kinokopilka.pro/forum_topics/11514

• Ответить
• Редактировать
• Вырезать
• Отменить выбор
• Удалить
• Сообщить о нарушении Правил

цитата:
Впервые слышу, что при DHT или PEX осуществляется обмен данными через кого-то. Это всего лишь механизмы поиска пиров/сидов помимо трекера. Поиска, а не использования их как релеев для перекачки данных через них.

непосредственно самой перекачки файла и нет..

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

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

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

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

цитата:
Про механизм работы PEX рассказано в http://www.kinokopilka.pro/forum_topics/10902. DHT тоже помогает находить сидов/пиров с аналогичными раздачами, даже если раздача оформлена на другом трекере или безтрекерная.

ну вот мы хоть в чём-то нашли компромисс.

цитата:
Поиск локальных пиров вообще тупо сканит локальную сеть мультикастными запросами по всем портам на предмет работы по bt-протоколу. Поэтому создает значительный сетевой флуд. Во
избежание этого на более-менее крупных локальных коммутаторах и маршрутизаторах такие запросы блокируются. А на простых мелких могут вообще не поддерживаться.

в вычислительных технологиях вообще нет нечего тупого... бывает лишь устаревшее и новое, сложное и простое.. и не что не сканирует порты - похожее на скан вытворяют неправильно настроенные клиенты, через одно место настроенными портами.. разрешая то что надо запрещать, и запрещая то что надо разрешать(например как входящие по 0-1023 портам надо запрещать, а юзверь вместо этого ставит тупо любой 0, либо что ещё хуже путает с адресом отправления и назначения в итоге обращения не к тем портам)... некто нечего не блокирует в основном, а забивают канал сами клиенты, путём не правильной настройки самого приложения (например разрешают протокол uTP, входящие и исходящие соединения по UDP).. UDP это вообще отдельная тема - данный протокол нормально реализован на мой взгляд лишь в Linux, а из-за того что большинство на Windows сами понимаете что..

цитата:
Кроме того, локальные адреса, найденные по поиску локальных пиров, не передаются по DHT и PEX, кроме как так же внутри локальной сети.

вот для этого и нужен включенный обмен пирами и кроме того ненужно что-бы локальные адреса передавались по DHT достаточно и локальной сети..

цитата:
Даже если путем этих механизмов одному пользователю с "серым" IP удалось бы найти другого пользователя с "серым" IP, но в другой локалке, то соединиться им бы не удалось, т.к. "серые" адреса видны только внутри локальных сетей.

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

цитата:
Единственный способ соединения пользователей с "серыми" адресми из разных зон - создание teredo-туннеля. Но это не всегда срабатывает из-за особенностей сетевого оборудования.

По поводу Teredo: http://www.kinokopilka.pro/forum_topics/11514

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

чуть позже постараюсь найти вам более компетентную информацию для ознакомления..

• Ответить
• Редактировать
• Вырезать
• Отменить выбор
• Удалить
• Сообщить о нарушении Правил

Что-то я не понимаю. То Вы говорите, что "непосредственно самой перекачки файла и нет", то утверждаете, что через такой якобы шлюз происходит входящее соединение.

Если уж соединение произошло через какой-то шлюз, то через что пойдет затем основной трафик? Через какой шлюз? Не через основные же шлюзы "серых" зон туннель будет проброшен. Нет у DHT такой функции проброса туннелей. Следовательно, эти два "серых" клиента должны будут использовать этот самый внешний "белый" клиент как шлюз/релей/прокси для основного трафика ...

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

При включенном DHT действительно происходит активный обмен трафиком (кстати, по UDP-протоколу). В том числе происходят активные подключения в обе стороны. DHT-клиенты активно обмениваются хешами раздач, поисковыми запросами и ответами на них. Это служебный трафик. Если включить DHT, PEX и поиск локальных пиров, то он может достигать 30% от полезного. Поэтому и возникает ощущение утечки трафика.

По поводу запрета мультикаста ...

Достаточно на свичах отключить поддержку IGMP-протокола или запроетить мультикаст по той группе адресов, которую использует uTorrent. Что собственно и делают часто для снижения флуда.

Не понял фразы "по вашему так клиентов с внешними адресами просто-таки не существует в природе". Ну существуют. Ну и что? Вы упорно продолжаете упорствовать в своем заблуждении, что такие клиенты могут выступать в роли гипотетических шлюзов для соединения двух клиентов из "серых" зон?

Да если бы это было действительно так, то не существовало бы проблемы соединения клиентов с "серыми" адресами. Все бы могли соединиться со всеми. А так иногда получается у меня: сидов почти десяток, а качать не могу - у всех "серые" адреса, как и у меня.
И разработчикам uTorrent не надо было бы внедрять в клиент поддержку IPv6/Teredo.

• Ответить
• Редактировать
• Вырезать
• Отменить выбор
• Удалить
• Сообщить о нарушении Правил

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

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

сами подумайте если белый клиент знает что есть серый в локальной сети(поиском тем-же мультикастом) которого не видно. по запросу серого - может передать например о наличии такой-то части хэша(или о том что у него есть такой-то файл(не сам файл)) клиенту в глобальной сети,dht и попросить входящий ответ принять через белого - как это возможно по вашему? дальше просто белый передает порт ответа допустим по которому серый должен отвечать тд - всё(и тоже самое только наоборот)... и главное не какого трафа.. разве что служебная передача данных..

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

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

в нашей сети IGMP работает, по крайне мере у нас нечего не блокируется.. смысл блокировать IGMP если этот протокол используют не только битторент? и потом IPv4 лучше реализован под windows чем IPv6 о чём я уже писал ранее..

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

• Ответить
• Редактировать
• Вырезать
• Отменить выбор
• Удалить
• Сообщить о нарушении Правил

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

причинами по невозможности передаче такого рода взаимного обмена:

со стороны клиента с белым/внешним ай-пи/IP

1. отключён поиск локальных (по умолчанию).
2. закрыт или неправильно настроен порт для входящих/исходящих соединений.
3. блокируется IGMP локально в сети UDP.

со стороны клиента с серым/внутренним ай-пи/IP

1. отключён поиск локальных (по умолчанию).
2. закрыт или неправильно настроен порт для входящих/исходящих соединений.
3. блокируется IGMP локально в сети UDP.

при этом всём достаточно что-бы хотя-бы что-либо у одного из клиентов работало не верно...

• Ответить
• Редактировать
• Вырезать
• Отменить выбор
• Удалить
• Сообщить о нарушении Правил