Пользователь
0,0
рейтинг
30 августа 2009 в 16:03

Администрирование → Про µTP в новых версиях µTorrent: что это, как, зачем?

Традиционно большинство P2P-приложений использовало TCP для обмена данными. Про то, что µTorrent начинает использовать новый протокол, основанный на UDP, на хабре уже упоминали (раз, два). В данном посте новый протокол µTP описан подробнее, в том числе его тюнинг и возможность отключения. Подробности описаны таким образом, чтобы было понятно далёким от сетевых протоколов людям.

Update: Официальная документация на протокол: www.bittorrent.org/beps/bep_0029.html

Пара слов про TCP и UDP. Первый расшифровывается как Transmission Control Protocol, или протокол управления потоком. Он удобен тем, что даёт использующей его программе гарантию, что данные дойдут до адресата целыми, полностью и в том порядке, в котором были отправлены. Его использование требует предварительной установки соединения и его закрытия в конце. Этакое создание «трубы» через которую будет идти обмен данными. UDP же не предоставляет никаких гарантий что данные дойдут, или что дойдут в правильном порядке. Он только позволяет переслать небольшой блок данных (датаграмму) от одного адреса другому. Вся работа по проверке доставки, и при необходимости — повторной посылке, ложится на саму программу.

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

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

Латентно uTP появился в µTorrent версии 1.8, но умел принимать только входящие uTP-соединения, инициировать их сам — не умел. Впервые это научилась альфа-версия 1.9, потом стало возможным включить это и в новых версиях 1.8 ключиком bt.transp_disposition. Его значение от версии к версии менялось, но сейчас устаканилось на следующих битовых флагах:

1 — разрешить инициировать исходящие TCP-соединения,
2 — разрешить инициировать исходящие uTP-соединения,
4 — разрешить принимать входящие TCP-соединения,
8 — разрешить принимать входящие uTP-соединения

Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 1.8, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15 (значение по умолчанию в 2.0) разрешает все виды как исходящих так и входящих соединений. Чтобы запретить uTP вообще (если он вызывает какие-либо проблемы) надо поставить 5 (1+4). Стоит ли ставить 15 в 1.8 — вопрос спорный, на официальном форуме пишут что поддержка uTP в версии 2.0 намного лучше, поэтому скорость в 1.8 может быть хуже, чем по TCP.

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

Ещё в 2.0 появится метод обхода некоторых NAT (STUN), что поможет соединяться большему числу NAT-страдальцев, хотя будет работать не во всех случаях.

Лично меня из всех новшеств 2.0 больше всего порадовал TCP Rate Control. Он позволяет подстраивать скорость и TCP-соединений так, чтобы они не мешали другим приложениям и минимизировать лишнюю перепосылку пакетов, о которой написано выше. Раньше это достигалось установкой cFos-драйвера, в котором можно было поставить низкий приоритет торренту, высокий — браузеру, а с версией 2.0 этого больше не требуется. Управляется это опцией bt.tcp_rate_control, если вам важнее чтобы торрент не мешает другим интернет-приложениям — его стоит включить, если важна максимальная скорость торрента — есть смысл отключить, на официальном форуме пишут что это иногда скорость увеличивает.

Замечу, что в uTP это делается всегда, даже в версии 1.8, а скорость TCP-трафика подстраивается под загрузку канала только в 2.0. В uTP постоянно меряется время отклика от пиров, с которыми происходит обмен данными. как только этот «пинг» начинает увеличиваться, задолго до начала потерь пакетов, µTorrent сбавляет скорость.

За счёт этого, пока канал свободен — он используется на полную. как только например другое приложение (броузер) начинает грузить канал — в µTorrent'е начинает возрастать время отклика, и он автоматически освобождает канал для броузера. Как только пинг вернулся обратно (канал снова освободился) — µTorrent увеличивает загрузку канала. При этом лишних перепосылок пакетов гораздо меньше, чем если бы это происходило на TCP-уровне

Впрочем, тут есть интересный момент, что с ней или по uTP исходящий канал может забиваться на 95%, а без неё только с TCP — на 100%, но эта разница в 5% может оказаться той самой излишней перепосылкой одних и тех же пакетов, что канал забивает, а реальной пользы не приносит, так что imho не всегда когда канал чуть недозабивается это значит что новая версия хуже.

Ещё в обсуждениях часто мелькает ключ net.calc_overhead. Если он включен, то при настройке скорости учитывается и служебный трафик — запросы блоков, подтверждения, уведомления какие блоки у кого есть и т.п. Если отключен — считаются только сами блоки данных. Поэтому раньше советовали ограничивать исходящий канал в торренте до 80-90% от реального, иначе он весь забивался отправляемыми блоками, и уведомления о получении блоков и запросы новых не успевали проходить, поэтому серьёзно страдала скорость скачивания. Опять же, на широких каналах некоторые пишут что при выключении этой опции скорость чуть выше, но может это глюк бета-версии и в релизе всё будет нормально.

Тут ещё есть такой момент, в котором я не уверен на 100%, но кажется что служебного трафика в uTP больше. Ибо в каждой маленькой датаграмме надо передавать что это за блок, от какого торрента, а по TCP можно посылать большие блоки, не подписывая каждый кусочек. Впрочем, тут будет служебный трафик самого TCP, так что не факт что он сильно «экономичнее».

Ещё нельзя не упомянуть такое явление, как «шейпинг» или «резание» P2P-трафика некоторыми провайдерами. Для России это (пока?) не актуально, а на открытых трекерах, где много пиров со всего мира, скорость по uTP значительно выше.

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

Другие «продвинутые» опции, на которые можно обратить внимание:
bt.connect_speed — сколько максимум новых соединений можно устанавливать в секунду (стоит увеличить, у меня стоит 80),
net.max_halfopen — про это много писалось, и менять стоит вместе с патчем tcpip.sys, хотя с протоколом uTP это уже не важно.
net.utp_target_delay — это некий целевой «пинг» при подстройке соединений, в некоторых случаях при его увеличении где-то до 400-500 скорость становится лучше.
peer.disconnect_inactive_interval — через сколько секунд закрывается соединение с пиром, с которым нет обмена данными, актуально больше для открытых трекеров где больше народу и «плохих» пиров, либо на случай сетевых глюков — чтобы быстрее определять разрыв соединения и переустанавливать его. в некоторых случаях имеет смысл понизить до 90-120.

Версия 2.0 хотя и бета — вполне стабильная, скачать можно тут: forum.utorrent.com/viewtopic.php?id=60602

По личным ощущениям, в старых альфах 1.9 при скачивании с открытых трекеров если до этого входящий канал загружался где-то на 1/3, с uTP стал грузиться где-то на 2/3. При скачивании с закрытых трекеров раньше канал загружался так, что броузер начинал подтормаживать, а в 2.0 всё летает.
alex14n @alex14n
карма
87,8
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

    Простите, не понял.
    • –1
      Не дает он гарантию, короче. :)
    • +1
      если смотреть со стороны пользователя — гарантия даётся. если смотреть что при этом происходит — то все эти «разные маршруты», «перепосылки», «подтверждения получения» — всё это есть, но лежит на совести операцинной системы и от пользователя скрыто
  • +2
    А провайдеры ставят UDP траффик в приоритет — игры, voip.
    Благодаря новой технологии надеюсь у нас останется возможность общаться и играть?
    • 0
      когда слухи о переходе торрента на UDP появились, появились опасения провайдеров как раз таких вот услуг.
  • 0
    внимание, вопрос. чем отличается µtp от udp? µtp — это какая-то специфическая реализация (если да, то неплохо бы описать отличия) или что?
    • +1
      µ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
  • 0
    2.0 Beta пока не разрешён на закрытых трекерах.
    • +2
      На многих уже разрешена.
  • 0
    «При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.»

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

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

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

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