>Загвоздка в том, что вы не сможете описать все такие ситуации
>в терминах просто шейпинга трафика - бывают ретрансмиты, количество ответного трафика
>от приложения клиента тоже непредсказуемо, и т.д. Этот вариант в теории
>рабочий, но на практике будет работать плохо. Шейпинг прямого трафика гораздо
>адекватнее. Я конечно не такой умный как ....
Но вот в связке iptables+iproute(tc), у меня больше шансов чем ...
>То есть, вы расписываетесь в том, что не сможете справиться с такой
>ситуацией лишь исходящими филтрами :) Что и требовалось показать.
Вот после этого я уж не сколько не удивлюсь, если вдруг вы окажетесь латентным виндузятником, который в добавок еще и сидит под рутом.
Торрент клиент на сервере - не нужно оно там.
>Ваша проблема в том, что вы мыслите не в тех терминах. Мы
>балансируем сегмент [сам сервер]--[eth1]--[внутренние машины], а не сегмент [сам сервер]--[eth1]-[внутренние машины],
>который только и можно зашейпить исходящими. А на сегмент [канал к
>провайдеру]-----[eth0] мы не влияем, повлиять не можем, но это и не
>надо - он эквивалентен участку [аплинк провайдера]--[провайдер], на который нам тоже
>наплевать.
Бред, слов нет.
>Ну и что? Головой-то думать кто будет? Шейпинг, в отличие от полисинга,
>оперирует не только текущим моментом, когда оно пришло, и ничего не
>сделаешь - но и будущим. На которое уже можно повлиять.
Чего чего, сами то поняли че сказали это вы в сетевом контексте эту охинею несете, ужас.
>Это просто у вас в голове каша, и как оно всё работает,
>в полную картину не укладывается. Проблема-то не у меня - у
>меня вон шейпинг входящих прекрасно работает :)
А позвольте узнать на выходе то же шейпите?
