Приоритетное использование сигнала WI-FI

[Rezor666]

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

[AMDBulldozer]

Он уйдет и придет на шлюз провайдера.
От камеры до шлюза провайдера с нужным битрейтом, провайдер отправит на Ваш маршутизатор, маршутизатор половину пакетов отбросит до нужного трафика.
Таким способом Петя и Вася могут одновременно сидеть в интернете и с горе пополам смотреть потоковое видео.
Я это так представляю. »

Всё верно, кроме вывода. Петя не сможет залезать на сайты. Потому что при ширине канала 128 кбит он будет полностью забит пакетами RTP.
Давайте посмотрим как это будет происходить в динамике: первоначально Петя шлялся по web-сайтам и получал с них информацию со скоростью 128 кбит/сек. Потом Вася включил потоковое видео с битрейтом 500 кбит/сек. На шлюз провайдера начало поступать 500+128=628 кбит/сек.
Которые провайдер начал резать до 128 - тарифной скорости подключения. При этом он отбрасывал пакеты случайным образом, не разбираясь кому они предназначены - Пете или Васе. Но вся беда в том, что Петя получает информацию по протоколу прикладного уровня HTTP, который использует протокол транспортного уровня TCP. А последний требует отправки подтверждения получения пакетов. И у Пети, и у Васи первоначально терялось по 80% пакетов. Но Петя еще мог несколько секунд бродить по сайтам со скоростью хотя бы 25 кбит/сек. Увы, его счастье было недолгим - заметив, что компьютер Пети не посылает подтверждения, сервер начал снижать скорость передачи. Допустим он в какой-то момент снизил её до 64 кбит/сек.
Но сервер потокового видео своей скорости снижать не стал. Значит на шлюз провайдера стало поступать 500+64=564кбит/сек. Шлюз по-прежнему отбросил случайным образом пакеты. В результате Вася стал получать чуть больше, чем раньше: его доля была 500/628=79.6%, а стала 500/564=88.6%, а Петя, соответственно, меньше. Заметив, что компьютер Пети по прежнему не принимает все отправленные пакеты, HTTP-сервер еще раз внизит скорость передачи.
...и всё описанное в предыдущем абзаце повторится. Чем дело закончится? Тем, что вся полоса пропускания достанется Васе. И никакие манипуляции с маршрутизатором, кроме полного отключения Васи от сети, чтобы он не мог запрашивать передачу потоковых данных, не позволят ситуацию изменить.

[Rezor666]

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

[AMDBulldozer]

Вася посылает информацию с битрейтом, а если маршрутизатор при пакете с определенном битрейтом начнет изменять битрейт в меньшую сторону и отсылать ее уже дальше провайдеру? »

Если бы Вася что-то посылал, это был бы исходящий трафик, который элементарно поддается шейпингу. Вася посылает только запрос на начало передачи ему данных. После этого удаленный сервер начинает отправлять фиксированное число пакетов в секунду.
Результат будет такой же, как если бы Вася зашел по ssh на удаленный сервер и с него дал команду "ping -i 0.001 vasya.ru".
Канал от провайдера будет заполнен пакетами icmp echo request и маршрутизатор никак не сможет предотвратить поступление этих пакетов.
Только нагрузка которую создает ping не слишком велика (хотя командой ping -f несколько человек могут спокойно положить чей-то не слишком широкий канал), а потоковые данные с того сайта, который Вы указали, могут отправляться со скоростью до 5Мбит/сек.
При этом можно одновременно можно инициировать любое количество rtp-сессий.
Выполнять полисинг этого трафика можно только из желания насолить Васе и ни по какой иной причине - после того как он уже прошел по каналу провайдера и забил его, он становится безвреден (локальные сети обычно всегда имеют большую пропускную способность, чем канал провайдера).

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

[Rezor666]

AMDBulldozer, Вы меня не верно поняли.
В запросе Васи должен быть битрейт или скорость.
Маршутизатор ловит его запрос и изменяет, после этого отправляет дальше на сервер.
Таким образом уже не пользователь Вася будет выбирать битрейт а наш маршутизатор.
Например если у нас скорость в 23 мб и 2 клиента то маршутизатор при отправке запроса от Васи изменит битрейт до 15.5 мб/сек.

[AMDBulldozer]

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

Рассуждая чисто теоретически, Вы правы. Таким образом можно было бы управлять скоростью поступления данных.
...если бы такой способ существовал в природе. К сожалению, его нет.
При запросе на передачу потоковых данных, битрейт выбирается не одним из полей запроса, а просто указанием URL.
Щелкнете по одной ссылке на сайте - будет один битрейт. Щелкнете по другой - другой. Или тот же самый. Непредсказуемо.
Сайт может предлагать несколько источников потоковых мультимедийных данных с разным битрейтом. Или несколько разных с одинаковым. Или один источник с несколькими битрейтами. Всё зависит от автора сайта. Даже если какой-то телеканал и можно смотреть с разном качествым (что далеко не всегда так), то автоматизации процесс выбора правильной ссылки абсолютно не поддается.
Еще раз повторю: сам протокол установления RTP-сессии не содержит поля битрейта, который можно было бы изменить.
Правда есть еще один момент, о котором необходимо упомянуть.
Формально до 5% от объема потоковых данных занимают пакеты управляющего протокола RTCP, в котором, в частности, передается статистика по проценту успешно принятых пакетов. Предполагалось, что, обнаружив высокий процент потерь, сервер потоковых данных может уменьшить скорость передачи.
На практике этого никогда не происходит. Почему? Потому что это почти всегда мультикаст - одни и те же данные пересылаются одновременно множеству клиентов. Снижать скорость передачи (даже если эта возможность вообще реализована на сервере) изза одного клиента никто не станет.
Поэтому идея у Вас в теории хорошая, но, увы, не реализуемая.
И это логично. Допустим, у Вас есть DVD диск, который Вы транслируете в интернет. Со стандартным битрейтом - 1.32Мбайт/сек. Тут Вам кто-то сообщает, что не успевает принимать данные и просит снизить битрейт. Как Вы это сделаете? Будете перекодировать видео "на лету" по требованию клиента? А если их сотня и каждый хочет свой собственный битрейт?

Так что единственный способ попытаться дать Пете спокойно пользоваться интернетом - это реагировать на любой большой трафик как на сетевую угрозу (помните, Вы меня в самом начале спрашивали что общего между DDOS и потоковым видео?) и блокировать ip с которого эти данные поступают. Какой-нибудь IDS. Snort, к примеру.
Разумеется это не помешает отправленным с сервера пакетам забить канал. Однако когда соединение с сервером разорвется, сервер перестанет отправлять данные (аналогично: запущенный по ssh ping продолжит работу, но прервется сама ssh сессия).
Но ведь это не то, что мы хотели, правда? Такое решение сводится по сути к отключению Васи от сети. А не к выделению ему остатков от полосы пропусканию не использованных Петей.
К тому же, подобная блокировка легко обходится путем использования proxy-сервера.

[Rezor666]

AMDBulldozer, Согласен, вы правы, признаю что был не прав.
Чисто теоретически можно сделать сканирование на наличие url с битрейтом и выбором оптимального варианта, но реализация очень затруднительна и вряд ли многие web программисты пойдут на систематизацию URL.

Откровенно говоря в наше время я уже не вижу в этом проблемы.
Если дома канал 100 мб то можно спокойно смотреть видео и лазить в интернете.
На предприятиях можно разделить трафик на группы.
Например:
http, https - wan1
httpvideo, torrent - wan2
VPN, RDP - wan 3
и.т.д

Но ведь это не то, что мы хотели, правда? »
Да.

[2gan]

Так что в итоге?))))
Вот. к примеру, сейчас на втором устройстве скачивается торрент файл. вся скорость уходит на него. у меня никакое видео, ничего не грузится...

[Angry Demon]

2gan, TRENDnet не знает, что выпустил такую модель.

[2gan]

Angry Demon, TRENDnet TEW-651BR. Зато я знаю. Ну вот уточнили модель, дальше что? или Вы просто из занудства спрашивали? Сертификаты нужно скопировать может?

[Iska]

или Вы просто из занудства спрашивали? »
2gan, спрашивают для того, чтобы вести разговор на одном языке. Воздержитесь от ехидства.

[Angry Demon]

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

TRENDnet TEW-651BR
Роутер не обладает функцией шейпера. Вашу задачу с помощью него не решить.

[2gan]

Iska, ну так можно же нормально сказать, а не кидать умняки про форд и про то как мы должны догадаться о модели? Просто модель спросить нельзя?

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

[Rezor666]

а не кидать умняки про форд и про то как мы должны догадаться о модели? Просто модель спросить нельзя? »
А нельзя просто сразу говорить о модели? Поверьте эта ошибка многих и просто надоедает в день по 10 раз говорить "А какая у Вас модель?".
Согласитесь что мы не телепаты тут и попробуйте нас понять.

[2gan]

Rezor666, "А модель нам, видимо, угадать нужно..." "Если вы скажете, что у вас автомобиль Ford, и спросите, ездит ли он со скоростью свыше 200 км/ч, как вы думаете, что вам ответят?" "TRENDnet не знает, что выпустил такую модель."
Ну да, конечно, просто спросить модель куда сложнее, особенно если надоело говорить по 10 раз...

[Rezor666]

"TRENDnet не знает, что выпустил такую модель." »
Согласитесь что Вы сами не верно указали модель в начале.
Просто роутер может обладать функцией Shaper а может и не обладать и для того что бы это узнать нужна точная модель устройства.

Я понимаю что услышать
А модель нам, видимо, угадать нужно... »
не очень приятно. Но Вы сами пренебрегли пунктом 2.7 в правилах.
Пункт гласит
В заголовке темы обязательно обозначайте название предмета, которого касается вопрос, а в теле сообщения максимально подробно опишите проблему (приведите аппаратную/программную конфигурацию, а также изложите ситуацию, в которой возникает проблема). Темы с несодержательными или слишком общими заголовками будут закрываться или переноситься в раздел "Зона тестирования" в зависимости от политики конкретного форума. Подробнее о принципах создания тем читайте в этом документе и Правилах форумов.

Я уже не говорю о том что в поиске на сайте можно вбить
1- Shaper
2- Ограничения скорости
3- Распределение скорости

И все эти запросы Вас приведут к нужному ответу.

[2gan]

Rezor666, спасибо. Я Вас понял, надеюсь Вы меня тоже поняли