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

сеть небольшая до 10 человек
подскажите новичку эффективен ли данный метод?

ЗЫ шейпером не знаю как,потому что для мира и Украины и разная пропускная способность

• Динамическое распределение пропускной способности,DmitryChemerik, 09:14 , 13-Янв-06
• Динамическое распределение пропускной способности,Иван Федорович, 14:16 , 13-Янв-06
  • Динамическое распределение пропускной способности,napTu, 12:01 , 17-Янв-06
    • Динамическое распределение пропускной способности,gavro, 22:18 , 10-Май-06
      • Динамическое распределение пропускной способности,DeadLoco, 17:44 , 12-Май-06
        • Динамическое распределение пропускной способности,DeadLoco, 17:58 , 12-Май-06

>цель: установка пропускной способности пользователей в соответстви с их запросами,не дать пользователю,который
>скачивает много файлов захватить весь канал

Недумаю, что изменять пропускную способность канала путем изменения squid.conf и последующей реконфигурацией squid будет еффективно. У squid вроде был такой баг, что при перезапуске squid плюет на прописанные в конфиге delay poolы и докачивает файлы на полной скорости. Ну, и кроме того, перезапускать squid каждые, скажем, 1-2-3 минуты, имхо, может привести к нестабильной работе. А производить пересчет загрузки канала за более большой срок - неэффективно.
P.S. если бы меня дергали каждые 2-3 минуты, я бы убил кого-нить :)

>цель: установка пропускной способности пользователей в соответстви с их запросами,не дать пользователю,который
>скачивает много файлов захватить весь канал
>метод: вызывать программу через каждые Х времени,которая считывает лог Старгайзера,судит об активности
>юзера за это время и соответственно изменяет пропускную способность в конфиге
>сквида и перезапускает его.
>
>сеть небольшая до 10 человек
>подскажите новичку эффективен ли данный метод?
>
>ЗЫ шейпером не знаю как,потому что для мира и Украины и разная
>пропускная способность

Этот метод довольно удачный. И я бы поспорил насчет того, что он неэффективный, ведь процесс не перезапускается, а только проводится переконфигурация.

>>цель: установка пропускной способности пользователей в соответстви с их запросами,не дать пользователю,который
>>скачивает много файлов захватить весь канал
>>метод: вызывать программу через каждые Х времени,которая считывает лог Старгайзера,судит об активности
>>юзера за это время и соответственно изменяет пропускную способность в конфиге
>>сквида и перезапускает его.
>>
>>сеть небольшая до 10 человек
>>подскажите новичку эффективен ли данный метод?
>>
>>ЗЫ шейпером не знаю как,потому что для мира и Украины и разная
>>пропускная способность
>
>
>
>Этот метод довольно удачный. И я бы поспорил насчет того, что он
>неэффективный, ведь процесс не перезапускается, а только проводится переконфигурация.

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

это конечно все хорошо, а вот решения проблемы... получается нет? .. а очень бы хотелось бы.

>это конечно все хорошо, а вот решения проблемы... получается нет? .. а
>очень бы хотелось бы.
Решение есть, реализуется через внешний ACL. Но систему придется писать самому.

1. По cron раз в 5-10 минут подбиваем статистику по каждому юзеру на основании логов сквида.
2. На основании скачанных объемов проставляем каждому юзеру рейтинг в рейтинговом файле.
3. При обращении к сквиду тот делает запрос ко внешнему ACL-процессу, который читает рейтинговый файл и возвращает Ok/Err.

    external_acl_type RATE1 "%SRC" /usr/local/squid/rate1
    external_acl_type RATE2 "%SRC" /usr/local/squid/rate2
    external_acl_type RATE3 "%SRC" /usr/local/squid/rate3
    external_acl_type RATE4 "%SRC" /usr/local/squid/rate4

4. Делаем шкалу делей-пулов с ацлями вида:

    delay_access    1       allow           ALL RATE1
    delay_access    1       deny            all

    delay_access    2       allow           ALL RATE2
    delay_access    2       deny            all

    delay_access    3       allow           ALL RATE3
    delay_access    3       deny            all

    delay_access    4       allow           ALL RATE4
    delay_access    4       deny            all

Из подводных камней подобной реализации: в хелперах необходимо отключать буферизацию stdin/stdout, а также предусматривать возможность управления хелперами через прерывания - для перечитывания рейтингового файла по тому же крону.

Я решал родственную задачу на перле - вполне сносно работало.

Нужно иметь в виду, что запрос, поставленный в соответствующий делей-пул, уже не перемещаем и неуправляем до завершения. Т.е. если кто-то качает 500Мб одним файлом, то санкции удастся применить только к последующим его закачкам.