Как стать автором
Обновить

Комментарии 61

Текст целиком не осилил, но µTorrent 2.0 скачал и скорость закачки\отдачи возросла ощутимо.
И вот настройки что вы указали подходят для любого соединения? У меня 512/1Мб.
указанные настройки стоит применять только в случае каких-то проблем, зная что именно они делают. принцип «не сломано — не чини» тут в силе
Тут еще заметил, теперь у закачанных торрентов, что на раздаче лежат, появился исходящий трафик. Немного 0.1-0.9кб\с, раньше его почти не было. Зато раздача заняла почти весь канал, раньше обычно 10%.
То что скачивалось уже 5 дней из-за малого числа сидов, теперь поперло и докачается за 4 часа, а до этого писало 3 дня.
про net.calc_overhead читайте
оно самое!
Я с 20/20 метров не почувствовал разницу, как были закачки и отдачи на максимальной пропускной ширине канала, так и оставались. Что я делаю не так? :)
Аналогично всё в ширину канала упирается, и зачем стремиться к большему :)
> Тут ещё есть такой момент, в котором я не уверен на 100%, но кажется что служебного трафика в uTP больше.

Сниффер поможет исследовать протокол. Если он не задукоментирован.
насколько я знаю, открытой документации пока нет, ибо протокол в процессе доработки и тестирование. видимо, как выйдет релиз 2.0 — откроют и доки, и со временем uTP появится и в альтернативных клиентах.
Если UDP не будет поддерживать пасскей то как будут работать закрытые torrents.ru, demonid.com? Все маломальски приличные трекеры закрыты, бухту в пример не беру т.к ее судьба до конца не ясна.
стоп-стоп-стоп. не надо путать UDP для обмена данными между пирами и UDP для трекера. это абсолютно разные вещи, никак друг с другом не связанные.
А трафик при использовании µTP протокола на закрытых трекерах нормально считается?
да. трекеру абсолютно без разницы по каким протоколам общаются клиенты друг с другом. TCP или UDP, IPv4 или IPv6, открыты порты или закрыты, и т.п.
демоноид работает с айпишником, а не с пасскеем
Ну и мудак значит этот демоноид, сидбокс в инете получается для него практически неприменим…
применим. зайди с сидбокса, хотя бы с lynx'а. а вообще для демоноида сидбокс нужен только тем, кто совсем не хочет раздавать. у меня с одной активной раздачи выкачивали так, что весь канал был забит. при указанных в договоре 256 килобитах в секунду у меня выкачивали раза в два-три быстрее
а вообще демоноид вам ничего не должен только потому, что у вас есть сидбокс. радуйтесь, что нахаляву качать может. на некоторых весьма уважаемых трекерах админы так и вовсе недолюбливают их. и по этой причине там и ратио держать легко и это выходит не точка обмена трафиком, а музыкальный клуб
За что спасибо? Трекеру наоборот имеет смысл поддерживать сидбоксы так как там народ практически с раздачи не уходит. Демоноид лично для меня херовый трекер по многим причинам, не только из-за этого. Конечно мы друг другу ничего не должны, потому я и ругаю его, а не требую с него деньги или отключить контроль ip;)
это смотря что ставит администрация в качестве цели
Нужен тем, у кого канал десятки мегабит на вход и меньше мегабита на исход. Как в прочем и другим людям с несимметричным каналом.
lynx во-первых означает что в качестве сидбокса надо как минимум ВДС (а не специализированный сервис в несколько раз дешевле при том-же дисковом пространстве), во-вторых, надо знать, что это вообще такое (не все юниксоиды, айтишники).

Канал забиваю на любом вменяемом трекере при правильном торренте (не том, где сидеров в 5 раз больше чем личеров).
мне бы ваши проблемы

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

не юниксоиды прекрасно настраивают внц по загтовленным для них мануалам

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

Найдете ВДС где за 10 баксов дают 100Гб честного места, а за 100$ 1Тб при гигабитном канале (на несколько человек) без каких-либо ограничений по трафику? Я очень сомневаюсь.

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

Я думаю что в демоноиде причина контроля по ip не потому что они против сидбоксов, скорее публичных сидбоксов просто небыло, создатели видимо просто не подумали, а сейчас уже неохота переделывать. Ну или че-то такое. Врядли бы они специально ограничивали сидбоксы.
Так делают только имбецилы (ибо объективных причин это делать просто нет, польза от того что юзеры трекера пользуются сидбоксом есть, а недостатков нет), врядли бы у имбецилов получился трекер с такой популярностью (ограничение доступа для уа и ру тоже сделали не потому что идиоты а потому что только там могли сохранить свои сервера в Киеве).
ну например есть сидбокс.орг.уа. однако там есть другие минусы

чтобы скачать себе фильм, сидбокс не нужен. а на файлообменниках не найдёшь столько всего, сколько есть на трекерах. в частности, хд/лузлессы

конечно, дело не в сидбоксах. есть ведь ещё и динамические айпишники. а «имбецилы» в администрации водятся на педросе — одном из самых уважаемых лузлесс-трекеров. раз вы не видите дальше собственного носа, разъясняю пользу от их политики ограничения сидбоксов (хотя и не запрещают явно)
итак, так как мало сидбоксов, которые чаще всего ратиодрочеры, пользователям с узким каналом легче держать рейтинг. благо, оверсидинг тоже ограничивается. так как пользователям легче держать рейтинг, они не станут выкладывать туда фейки, пиратки, оцифровки с сд-р и прочую подобную чушь, лишь бы удержать рейтинг. а деньги, сэкономленные на сидбоксе можно вложить в покупку лицензионных дисков, которые затем можно выложить на трекер. как итог, почти 100% качественного лузлесс-контента, каждый рип (неважно, сд ли это, винил, сасд или двд-а) сделан с рекомендуемыми настройками и в случае косяков не пройдёт или тут же будет удалён
>>ну например есть сидбокс.орг.уа. однако там есть другие минусы

Это че ВДС? Это как раз сервис который предоставляет только торрент за нормальные деньги. Никаких vlc туннелей с ним не сделать (и это правильно), потому демоноид с ним использовать нельзя. Я именно об этом и говорю, если вчитаться.

>>а на файлообменниках не найдёшь столько всего, сколько есть на трекерах. в частности, хд/лузлессы

То, что вы не знаете где брать, не означает что не найдешь. Но дело не в этом. А в том, что многие люди не сильно представляют как пользоваться торрентом или у них нет подходящего исходящего канала, потому они пользуются файлообменниками что раздают по http.

Ваш аргумент это просто «мне не нравится потому, что не нравится». Допустим, у меня канал 38М/512К. Я в принципе не смогу удержать рейтинг. В итоге в лучшем случае буду региться, получать ссылку на кучу торрентов, качать их без раздачи и забивать на аккаунт. Если просто зарегиться нельзя, то не буду вообще пользоваться. Какая от этого польза трекеру? А если у меня нормальный сидбокс, но я после скачивания, как минимум еще какое-то время буду качать к себе (это время обычно больше, чем время, которое на скачивание тратит сидбокс из-за канала).И все время, пока качаю себе остаюсь на раздаче. А если у меня много места, то я и после того как себе стяну останусь на раздаче и другие юзеры смогут у меня снянуть…
Набить себе рейтинг можно не только фейками а и просто скачивая популярные торренты и раздавая их постоянно на хорошем канале. И вообще фейки это не проблема сидбоксов. С тем-же успехом можно быстрых исходящий канал у юзеров банить, действие полностью аналогичное бану сидбоксов.
не нормальные деньги, это слишком дорого. я переплатив чуть больше брал себе полноценный вдс. в итоге оказалось лучше такого рода сидбоксов

вы просто не знаете, что я беру. найдите-ка мне, например, iskra во флаке на файлообменниках

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

действие не аналогичное. сидбоксеры скачают, поддрочат рейтинг и выкинут. а домашние пользователи оставят
Про TCP Rate Control. Он у меня работает только при неограниченной скорости. Если поставить ограничение больше ширины канала — сожрёт всё за милую душу. Даже не знаю, баг или фича.
Странно он вообще как-то работает. Скорость неограниченная, при отключенном загрузка 80 кб/с, при включенном 14 кб/с. Ничего лишнего типа браузеров, обновлений антивируса и т.д. не запущено.
А поможет ли bt.tcp_rate_control в случае, когда неограниченная по скорости закачка забивает весь входящий канал, и мешает торрентам отдаваться наружу?
Однако bt.tcp_rate_control работает не так как хотелось бы
Ай случайно отправил…
Он режет торентам скорость в самый ноль почти при любом использовании интернета, уж лучше я пока что выставлю ограничения, и буду качать/раздавать на чуть меньшей скорости чем имею зато параллельно со своим присутствием за компьютером…
можно попробовать net.utp_target_delay приподнять, с другими настройками поиграться, или на официальном форуме пожаловаться
При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.


(пардон, рано нажалось)

расскажите, автор, а что вы слышали про TCP slow start и TCP congestion?
Видимо вы тоже привыкли делать переход по ctrl+enter
Вот тут описаны какие проблемы TCP congestion решает uTP и как именно: www.bittorrent.org/beps/bep_0029.html
Transmission Control Protocol, или протокол управления потоком. Он удобен тем, что даёт использующей его программе гарантию, что данные дойдут до адресата целыми, полностью и в том порядке, в котором были отправлены.

Дело в том, что посылаемые через TCP-«трубу» данные в процессе разбиваются на куски («пакеты»), каждый из которых отправляется независимо. При этом один пакет может идти одним маршрутом, другой — другим, последний кусок может прийти первым, первый — вообще по дороге потеряться.

Простите, не понял.
Не дает он гарантию, короче. :)
если смотреть со стороны пользователя — гарантия даётся. если смотреть что при этом происходит — то все эти «разные маршруты», «перепосылки», «подтверждения получения» — всё это есть, но лежит на совести операцинной системы и от пользователя скрыто
А провайдеры ставят UDP траффик в приоритет — игры, voip.
Благодаря новой технологии надеюсь у нас останется возможность общаться и играть?
когда слухи о переходе торрента на UDP появились, появились опасения провайдеров как раз таких вот услуг.
внимание, вопрос. чем отличается µtp от udp? µtp — это какая-то специфическая реализация (если да, то неплохо бы описать отличия) или что?
µtp работает поверх UDP. А что оно из себя представляет, похоже, знают только его разработчики.
Because it is still being implemented, uTP protocol features are typically hidden or made obscure in the client user interfaces of the BitTorrent clients that support it. There is no open source uTP protocol codebase at this time, making this feature's support with other BitTorrent clients much less uniform.
wapedia.mobi/en/UDP_Torrent_Protocol
спасибо за ссыль
2.0 Beta пока не разрешён на закрытых трекерах.
На многих уже разрешена.
«При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.»

Описанное явление называется congestion. TCP собаку съел на борьбе с этими затыками/ лишними перепосылами. В каждой очередной версии ОС (что Windows, что Linux) что-нибудь подкручивают, чтобы TCP автоматически подстраивался под пропускную способность каналов. Можно сказать, что проблема эта в TCP решена весьма добротно. Неужели разработчики торрент-клиентов могут переплюнуть в этом разработчиков TCP/IP-стеков в ОС?
Так если грамотно разработать протокол можно просто обойтись без повторной пересылки уже доставленных частей. Например клиент отправляет список нужных ему частей, они высылаются (одна часть — одна датаграмма), далее не получив все, но уже некоторую долю, запрашивает еще и т.п., но из того, что не запрашивал ранее. И уже через некоторое время, когда уже точно известно, что пакеты именно потерялись, а не стоят где-то в очереди, повторно запрашивает недостающее. ИМХО тут порядок и гарантия доставки, которую обеспечивает TCP не важна. Хотя еще надо как-то контролировать объем посылаемых данных, что бы отправитель излишне не напрягался… Но дублирование доставленных пакетов то практически исключили :)
Так же как и в TCP, повторная передача будет нужна только при потере пакетов данных или пакетов подтверждений. По описанию ( www.bittorrent.org/beps/bep_0029.html ) видно, что потеря|непотеря тоже определяется по таймаутам (и вы пишете «через некоторое время»). Т.е. проблемы будут те же, что и в TCP, и решаются также. Порядок передачи действительно не важен (и это основное отличие от TCP), но есть «окна», и обрабатываются они последовательно, значит таки порядок всплывает обратно, просто чуть в другом месте.
Разработчики µTorrent опять занимаются изготовлением не совместимых ни с чем костылей.
Напоминает тактику MS: сначала внедряется своё расширение к протоколу (µTP), потом когда оно получает распространение, вырубаются стандартные средства (TCP)
эх, сколько в своё время было шуму когда уТ продался БитТорренту, все начали думать о переходе на альтернативные клиенты, и что? ничего страшного не случилось, всё утихло, все довольны. зачем снова разжигать огонь из ничего? речи о том чтобы перестать работать по TCP нигде даже не шло, как только протокол «устаканится» — разработчики обещали открыть документацию чтобы альтернативные клиенты тоже смогли его реализовать.
TCP Rate Control, отличная опция, но работает несколько странно. При отсуцтвии посторонней загрузки канала, скорость не выравнивается на максимум, а постоянно качает где-то в 30-40% канала.
Не совсем понял про net.calc_overhead, выходит его выключать особой надобности нет, ничего толком не меняет?
У вас у самого эта опция нормально работает? Можно поинтересоваться, как быстро падает и восстанавливается скорость в уторренте если вы начинаете активно серфить или смотреть потоковое видео?
падает очень быстро, где-то за пару секунд, восстанавливается дольше, там счёт скорее на десятки секунд идёт.

даже не знаю что посоветовать, можно попробовать поднять net.utp_target_delay или почитать официальный форум, если там решения не найдётся — описать там свою проблему
Мне кажется дело по крайней мере у меня может быть в том, что множество программ которым нужно совсем не много канала(месенджеры, различные авточекеры и т.п.) и это сбивает уторрент. Может и не это, но догадки.
чёрт знает. каналы у всех настолько разные, начиная от LAN/модемов, заканчивая всякими твиками например с помощью TCPOptimizer. влияет также максимальное число соединений в торренте (там есть общее, на торрент, и чисто на отдачу), их может быть стоит поднять
все круто конечно, вот тока пафосно называть нюDP то, что все и так делают через UDP — фуу.

второй аспект — рейт контролить должна ОС а не программы. В частности, в linux, можно в ядре отличать одни пакеты от других и расставлять им разный приоритет. В таком случае, если торрент что то там раздает и ты открываешь браузер — то пакеты браузера получают высшый приоритет сразу, ещё до своей отправки. Как следствие — интернет в браузере работает быстро СРАЗУ, а не пока сообразит. Разница как между АКПП и механикой =).
даже не вдаваясь в детали: голая винда этого не умеет. cFosSpeed стоит денег. так что смысл есть
Потестировал 2 beta и откатился на 1.8.4. Скорость была никакая.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации