твой проект?
минусы? на каких потоках тестил?

Да. На небольшом количестве тоненьких потоков.

Основано на epoll_wait (без EPOLLET), однопоточное.

Больше 509 подключений не потянет (fd закончатся)

>P.S. Да, я пока не осилил «tc qdisc»

лучше помучайсь пару суток, и осиль. Это того стоит. Я сам вот только недавно его осилил, было трудно, но зато теперь это проще простого)

tc short intro

Можешь привести пример как, например, сделать, чтобы от пользователя qqq трафик был не более 10 kbytes/s (в обе стороны, строгое ограничение), а от пользователя zzz трафик считался приоритетным (опять же в обе стороны).

iptables -t mangle -A OUTPUT -m owner --uid-owner qqq -j MARK --set-xmark 1
iptables -t mangle -A OUTPUT -m owner --uid-owner zzz -j MARK --set-xmark 2
ip ???
tc ???

А то это как emacs - уже N раз подступался, но пока не «взял».

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

tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb prio 1
tc class add dev eth0 parent 1: classid 1:2 htb rate 10kbytes ceil 10kbytes prio 2

#вроде отправляет все пакеты с меткой 2 в первый класс
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 2: fw flowid 1:1
#это с меткой 3
tc filter add dev eth0 parent 1: protocol ip prio 2 handle 3: fw flowid 1:2

а этим можно ограничить скорость aptitude, а то он весь канал забивает?

Да, можно.

Что-то типа

iptables -t nat -A OUTPUT -d ip_address_of_where_aptitude_downloads_from -p tcp -m owner ! --uid-owner tcplim -j REDIRECT --to 1236
su tcplim ./tcplim 0.0.0.0 1236 REDIRECT REDIRECT 500000 500000 0 0 100

Если только к одному серверу, то можно даже без iptables:

./tcplim 127.0.0.1 1236 141.76.2.4 80 500000 500000 0 0 100
http_proxy=http://127.0.0.1:1236/ apt-get update

Можно на ходу регулировать скорость командами в stdin.

Ты не можешь узнать, какому пользователю пришел пакет.

Можешь.

-j CONNMARK

Твои настройки tc qdisc, tc class и tc filter будут оганичивать входящую скорость и задавать входящий приоритет если все соответствующие пакеты будут иметь нужный fwmark?

P.S. мои настройки iptables: http://vi-server.org/vi/iptables.txt

не буду спорить, если захотеть то можно сделать через tc http://www.linux.org.ru/forum/admin/4615270

твой модуль против злостных пользователей плохо работает(или обычных торрентов), если

Да. На небольшом количестве тоненьких потоков.

Основано на epoll_wait (без EPOLLET), однопоточное. Больше 509 подключений не потянет (fd закончатся)

не буду спорить, если захотеть то можно сделать через tc iptables, маркировка пакетов, tc (ingress) = не выходит ничего

Как минимум это сложнее, чем при помощи userspace-овых штук.

твой модуль против злостных пользователей плохо работает(или обычных торрентов)

Что не так? Нужно чтобы могло больше подключений? Или нужно больше ограничений.

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

Лично для меня (один пользователь, тоненькое подключение, и то не всегда есть) это достаточно. А что нужно другим я не знаю.

ЕМНИП, то в настоящий момент скорость входящих подключений рулится через ifb, а так как он работает до iptables, то особой гибкости у него нет. Раньше был imq, он позволял делать различные выкрутасы.

ИМХО, ваш проект имеет право на существование, но особо наворачивать его (равномерно распределяло трафик между IP-шниками, а внутри них уже между подключениями) не стоит. Уж лучше сначала сделать его многопоточным, потом научить парсить его http-заголовки и сделать GUI с ползунками, чтобы хомячёк сам мог делить канал между загрузками, ИМХО.

многопоточным

Так ли нужна многопоточность? Что она даст (кроме увеличения максимального числа подключений)?

наворачивать его (равномерно распределяло трафик между IP-шниками, а внутри них уже между подключениями) не стоит

... то особой гибкости у него нет

Соответственно, почему бы тогда не поставить акцент на выкрутасах и гибкости?

Например, следующий шаг - слушать несколько портов, в зависимости от номера порта, на который подключились разная политика. Типа "--to 1236" - обычный траффик, "--to 1235" - высокоприоритетный, "--to 1237" - высокоприоритетный, но с ограничением 20 kbps и "--to 1238" - низкоприоритетный.

Распределение трафика между IP-шниками - не такая уж большая заслуга.

(BTW - вообще осознанное распределение проводится только при наличии total limit. Нужно ли пытаться делать, чтобы оно само определяло производительность канала (чтобы знать что распределять)?)

Ещё думаю про UDP - нужно/не нужно? Добавить не сложно.

парсить его http-заголовки

А зачем? Что с ними потом делать?

сделать GUI с ползунками, чтобы хомячок сам мог делить канал между загрузками

Можно. Будет присасываться к интерфейсу командной строки. Если для хомячков, то можно сделать чтобы оно само умело iptables настраивать. Так?

Многопоточность в том числе и многоядерности.

Чётко сформулировать, почему не нужны наворты не могу, по мне, лучше сначала обкатать архитектуру, а потом расширять функционал. То есть многопоточность, поддержка udp, возможно работа не через сокеты, а через "-j NFQUEUE" сначала, а потом уже думать, как сделать распределение трафика между ip в случае многопотчности.

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

Да, ГУИ и для tcplim и для iptables, но сейчас подумал, что не очень получиться. Если бы с помощью этой тулзы можно было бы ограничивать все коннекты определённой программы/пользователя/группы пользователей, то было бы хорошо. То же обновление дистрибутива --- это проверка нескольких репозитариев и поиск/выбор доступного зеркалирующего сервера. То есть уже куча серверов, а сверху ещё может добавиться DNS (одно имя резолвится в несколько ip-адресов).

лучше сначала обкатать архитектуру

«Обкатывать» архитектуру лучше когда знаешь что потом будешь прикручивать.

работа не через сокеты, а через "-j NFQUEUE"

А я хочу чтобы оно ещё работало и без iptables.

Многопоточность в том числе и многоядерности.

Ещё раз, зачем она здесь? «Многопоточность в каждый дом»?

Парсинг http-заголовков, это, наверное, лишнее

А, понял: чтобы показывать пользователю какой файл качается. Тогда понятно.

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

Пользователя/группы - да. "-m owner" же.

 iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner slowslow -j REDIRECT --to 1236

По имени программы - нет. (раньше это вроде как было в "-m owner", но теперь нет).

То же обновление дистрибутива --- это проверка нескольких репозитариев и поиск/выбор доступного зеркалирующего сервера...

Вот тут как раз, я думаю, тоже HTTP-awareness решит проблему.

Наверное, можно сделать чтобы просто по подстроке можно было помещать подключение в определённую группу. Строка может быть и типа «GET http://», и «Content-Type: application/x-».

Относительно многопоточности --- решать вам. ИМХО, сейчас много народа имеют широкий канал и «воюют» с торентами. Когда хочется, чтобы всё быстро закачивалось и страничнки быстро грузились. И там нужно будет думать о том, как обрабатывать много соединений.

NFQUEUE позволяет получать «чистые» пакеты. То есть у них будет нужный dst-ip и dst-port. И, вроде, можно будет сделать так, что нужные соединения маркируем, отправляем в NFQUEUE, и входящие пакеты соединений с этим же маркером бросаем в NFQUEUE. И можно будет завернуть туда диапазон портов или все udp или вобще весь трафик.

Просто, избранный вами путь сложен, допустим, как вы будете ограничивать ftp? Там ведь порты data соедиения могут быть заранее неизвестными.

Относительно имени программы, то можно смотреть какой pid какой сокет открыл (как выводит команда netstat -p). Для долгих закачек, которые длятся несколько секнуд это вполне подойдёт.

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

Наверное, я пока закончу фантазировать.

>P.S. Да, я пока не осилил «tc qdisc»

tc не осилил, зато написать свою приблуду осилил, инетесно, а какой смысл в ней, умеет что-то, что не умеет tc? или просто для прокачки знаний?

Скорее хочется, чтобы можно было держать свои подключения под контролем и регулировать их, а с tc это слишком сложно. И входящеее там сильно отличается от исходящего (почти всега нужно контролировать именно входящую скорость).

То есть у них будет нужный dst-ip и dst-port

И так есть. getsockopt SO_ORIGINAL_DST.

Оно и так знает куда пользователь намеревался подключаться.

Относительно многопоточности --- решать вам. ИМХО, сейчас много народа имеют широкий канал и «воюют» с торентами.

Просто нужно чётко знать что она даст.

Для per connection ограничений это просто. Но сделать total-ограничение многопоточным будет сложнее.

У меня, к сожалению, нету широкого канала, и странички у меня всегда открываются медленно (firefox (lots of addons) -> ziproxy -> local polipo -> (ssh forwarding) -> remote ziproxy -> server). Поэтому нужно или делать искусственные тесты, или что-бы кто-то другой оценивал.

Относительно имени программы, то можно смотреть какой pid какой сокет открыл (как выводит команда netstat -p).

Можно. Вообще я не хочу всё это внутри реализовывать, а сделать чтобы пользователи моги указывать policying script, которому моя прога говорит информацию о подключении, а скрипт возвращает policy для этого подключения.

А trickle не рулит?

Помогите расставить приоритеты

По вашему мнению, чего не хватает больше для полезности tcplim?

1. GUI с графиками и ползунками (qtcplim) и автоматической настройкой iptables.
2. Многопоточности (с пояснением что она даст)
3. Автоматического определения доступной ширины канала или задание минимальной скорости. В общем, чтобы приоритеты работали не только в присутствии total limit.
4. Обработка UDP
5. Анализ содержимого подключения (HTTP, по подстроке, ...)
6. Гибкая система определения политики каждого подключения на основании пользовательского скрипта.

trickle

trickle works by taking advantage of the unix loader preloading

Это другой подход со своими плюсами и минусами. Соответственно, обе программы нужны.

P.S. до этого не знал о trickle.