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

Из солидных фирм нашёл у нас только вот такой ASUS RT-N10. Проблема в том, что мне его нужно к потолку прицепить, а у него щели сверху. Спрашивал на хоботе про тепловой режим, но ответы были расплывчатыми. Если не решусь купить, то подожду до следующей поездки.


Дополнительные материалы

• Описание одного из дефектов, проявляющихся в роутерах в виде зависаний и нестабильной работы.

admin
Я обычно объясняю принцип работы портов по простому: вы, наверное, знаете (понимаете) телефонную функцию ограничения входящих и исходящих звонков. Считайте, что интренет это многоканальная телефонная сеть, где у абонента есть один номер (ип адрес) и 64к разных каналов (портов). Так вот, вы можете ограничить "звонки", причем как входящие, так и исходящие настройками своего рутера, также как в своём телефоне, только в качестве каналов у вас в наличии 65536 (64к или 2 байта для номера) портов.
Конечно, вы можете легко закрыть порты на вход, поэтому для хакеров так архиважно запустить прогу-вирус на вашем РС, чтобы она сама "дозвонилась" хакеру, открыв тем самым для него канал связи, но закрыв исходящие "звонки" вы можете обезопасить себя и от этого.

Извините. Замечал уже не раз, что многим профессионалам такие "детские" вопросы не просто смешны, а даже обижают. Они (в том числе и я) почему-то считают, что если им это как пять пальцев, то должно быть и всем (а иначе тут, наверное, какой-то злой умысел "клиента" . Электронщики на форумах так обращаются с нами, программистами.. Последствия русского воспитания скромности или хамства?

Заняться просветительской деятельностью в вашем стиле не готов, терпения не хватит.

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

Надо же, прежде чем рассуждать, понимать хотя бы базовые принципы портов и работы протокола BitTorrent. Ладно, благословясь, приступим..

Начнем с простого примера. Допустим, программа на вашем компе (напр. клиент uTorrent) хочет установить соединение с другой программой на другом компе (qbitTorrent), что называется пиром (peer). Она посылает запрос рАутеру (а, кстати, не рОтеру и не рУтеру, или по-русски сказать, маршрутизатору). Тот перенаправляет пакет уже удаленному компу, запоминая при этом локальный адрес вашего компа и порт, с которого пришел запрос. Поэтому, когда приходит ответ, маршрутизатору легко сразу переслать его на адрес вашего компа на тот порт, с которого первоначально пришел запрос (в простейшем случае. Кстати, также предполагаем, что это раутер типа switch, а не типа hub, что только немного усложняет, но на суть дела не влияет).

Таким образом, допустим, что ваш клиент uTorrent уже видит, скажем, 8 пиров, или, точнее, не просто peers, а seeds, т. е. тех, у кого есть вожделенный вами файл (чуть более, чем) полностью, потому что те, у которых у самих ничего нет, вам особо неинтересны. В такой ситуации никакой марштуризатор на свете (если в нем специально не запрещено кое-что) не может помешать вам установить прямое соединение с seed, т. е. донорами. Потому что это вы посылаете запрос им на разрешение на скачку, а они или посылают вас обратно , или таки соглашаются и ставят вас в свою очередь на откачку и качают вам кусочки вашего вожделенного файла. Таким образом, в тамом случае на скорость вашего скачивания открытие или неоткрытие портов в маршрутизаторе никак повлиять не может.

Другое дело, если у вас другие клиенты (пиры) хотят что-то полезное скачать. В таком случае они присылают свои запросы на ваш маршрутизатор. Но он их (их IP-адреса) видит впервые в жизни и понятия не имеет, куда б их запросы переплавить. Hub с этим особо не заморачивается и просто транслирует по всем сразу своим локальным клиентам - НО! и он не знает, на какой порт нужно отсылать их запросы. Таким образом, они к вам (удаленные пиры) пробиться не могут. Это есть плохо для работы всего протокола BT и, конечно, снижает его общую эффективность.

Таким образом, на скорость скачки открытие портов в маршрутизаторе НЕ влияет, а влияет на откачку - при условии, конечно, что вы откуда-то уже набрали достаточно много вменяемых доноров (seeds). Но это другая проблема, с проблемой портов прямо не связанная. Замечу только, что открытый порт помогает и ей. Хватит пока, думаю

Т. е. суть вашей проблемы была не в маршрутизаторе, а в малом кол-ве доноров (seeds).

qza, Владимир Е. спасибо за науку!

В общих чертах, я примерно так и представлял, но это почему-то кардинально расходится с практикой. Я заметил, что после подключения роутера, скорость скачивания с местного трекера стала меньше, особенно торрентов, у которых не очень много сидов. Ну, а так как почти у всех оптика, то этого быть не должно. То есть, мой клиент не мог сразу найти достаточно сидов, чтобы выйти на 100мб/сек. (Если сидов 1000 и более, то это не принципиально). Кроме того, мне как-то позвонил товарищ из соседнего дома, который пользуется услугами моего провайдера. Так вот, он начал скачивать фильм которой качал я, и скачал его за обычные 1,5-2 минуты прямо во время нашего разговора. Хотя я качал этот фильм почти десять минут. После открытия порта, проблема исчезла.
Ещё, я читал советы по открытию порта для торрент клиента на довольно авторитетных ресурсах. В самом роутере есть опция, позволяющая клиенту открывать выбранный порт при запуске клиента и закрывать порт при закрытии клиента. Честно говоря, сначала порт открытый вручную, оказался закрытым. Потом нашёл эту опцию, которая помогает настроить роутер и порт открылся. Хотя, конечно, глубоко я процесс не понимаю и на произволльном роутере сделать бы это не мог.

Включите в клиенте uPnP и не парьтесь с портами (для того он и придуман). Прим. - на беспроволочном () интерфейсе uPnP обычно по умолчанию отключен в маршрутизаторе как "угроза секьюрити".

По вашей картинке видно, что вы "ручками" открыли IP-адрес:порт 192.168.1.163:50000 для both TCP und UDP. А адрес этот фиксированный, тоже ручками прописанный или динамический, получаемый по DHCP, как оно по умолчанию в Винде? В последнем случае он будет регулярно слетать, вместе с "открытым" портом.
Кстати, в µTorrent есть спец. функция проверки "открытости" его порта - пользуйтесь. А еще лучше - включите uPnP (см. выше).

Владимир Е.
В моём клиента BitComet технология uPnP включена по-умолчанию. Порт пингуется автоматически (или принудительно, если требуется) и результат всегда виден в Строке состояний. Так что, если бы эта технология могла сама открыть нужный порт, то я бы это заметил. Да и скорость загрузки бы это подтвердила.
Номер порта на скриншоте, естественно, изменён. Но, он одинаковый с тем портом, что я выбрал в клиенте.

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

В таком случае порт будет "приоткрыт". Чтобы "технология" uPnP работала, наверное надо периодически перезагружать "игроков", так как она работает, скорее всего, в момент перезагрузки, как и родственная ей DHCP (или с интервалом по умолчанию в сутки). Впрочем, в ее детали я не вникал.

DHCP включите, а адрес компа с BitTorrent пропишите ручками, иначе эта ваша "открывашка" как вилами по воде. Через этот порт также идет обмен пирами, и с трекерами, вот что и влияло на вашу скорость (точнее, скорость набора пиров).
Вы поняли мое примечание насчет беспроволочного интерфейса? Популярно - через Wi-Fi uPnP не работает.


Надеюсь, за пределами системных спец. портов, т. е. больше чем 1024? (а то и 2048 уже, расширяли вроде, точно не помню). Я их никогда меньше 3000 не ставлю.


Чего-то я уже точно не помню, но порт пинговаться не может! Пинг - это специальный пакет спец. протокола ICMP и, соответственно, на своем собственном порту (куда подвязана служба ответа на ICMP). Поэтому пинговаться может только сам IP-адрес. Видать, они как-то по-своему следят за открытием этого порта. В детали опять же не вникал.



BitComet никогда в жизни не использовал, но все уважающие себя клиенты ведут лог, доступный взору пользователя. Глядя на него, можно проанализировать работу uPnP. Именно так я лично "открыл", что он забанен в маршрутизаторе на WiFi. И еще Это конечно хорошо, что uPnP у вас в клиенте включен, а вот включен ли он вообще в маршрутизаторе? Ведь "согласие - продукт непротивления обеих сторон" (м. Безенчук).

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

Да, порядок номера порта соответствует рисунку, только цифры заменены нолями.

Клиента менять не стану, так как всё устраивает и всё работает. Одно время перешёл на uTorrent, но выяснилось, что он не поддерживает изменение состава загружаемых файлов во время загрузки. Кроме того, в одной из последних версий не работает де-факто управление скоростью то ли загрузки, то ли отдачи, то ли того и другого (точно не помню). Приятель попросил разобраться, почему серфинг тормозит, оказалось, что uTorrent третьей с хвостиком версии не умеет это делать. Проверил на другом компе, та же беда. Запустил BitComet, всё пучком.

Так что, пока проблемы с роутером исчерпаны. Начинаются проблемы с системным блоком. Наверное, завтра буду менять матернку на десктопе. Это будет третья попытка. В положительный исход уже верю мало, но очень хочется…

$#@@^!! Любое "изменение состава файлов" в торренте автоматически меняет его хэш-функцию. Т. е. это будет уже другой торрент


А первые две попытки... огласите весь список, пожалуйста