Андроид не столько тормозит, сколько имеет существенно менее отзывчивый интерфейс, чем айфон. Новые прошивки(с cgroups и прочими бэкпортами из Donut) работают чуть шустрее чем текущая прошивка Cupcake.
mutorrent — самый популярный клиент умеет UDP(правда он единственный). но даже в работе в режиме tcp при большом кол-ве коннектов, личеры будут вам слать больше, чем разрешает вам провайдер. Поэтому лучше ограничивать скоростью не двумя мегабитами(для приведенного примера), а меньше.
можно, но это верно только для TCP, где есть congestion control. У битторента через удп(и скайпа), есть похожий механизм, но он более «жадный»(агресивный, как зметил shandor). При большом количестве коннектов у торрент клиента входящий поток пакетов может существенно превышать выделенный вам лимит.
я думаю вы имеете ввиду ipset. Да, это известный и удобный патч, но в данном случае использовать его не получится, тк нам нужно уникальное правило ip->ipmark.
существует две популярные схемы создания соответствия ip->htb class: «ipmark» и «ipclassify».
Первая реализуется маркировкой в iptables, вторая использование tc filter u32(с хэшами).
У первой схемы недостаток в разрастании таблиц iptables. При существовании 10к пользователей мы имеем 10к правил iptables(через все проходит каждый пакет) и 10k фильтров tc. При большом потоке пакетов ksoftirqd уходит в вечный луп, загружая одно ядро сервера.
У второй схемы недостаток в абсолютной адском синтаксисе настройки и жуткой глючности при изменении(удалении) фильтров. При существовании статических классов и фильтров не плохое решение, если использовать хэш таблицы.
Не так давно в ядро добавили новую схему tc filter flow(разработанная изначально для sfq кудиска). Она лишена всех описанных недостатков, только совершенно не документирована и может быть использована только адептами, читающими исходный код. =)
зы марков 2^32, а вот классов увы может быть только 0xffff
зыы на днях соберусь — распишу подробно все три схемы с примерами.
Главная проблема — это как будет фильтроваться трафик и попадать в тот или иной класс. для 30-40 человек и 10МБит — это не критично, а вот если у вас 10к пользователей, то могут возникнуть проблемы. Если кому-то интересно — могу расписать чуть подробнее.
пчелайн иногда имеет огромные задержки до нескольких часов(если отправляется несколько смсок), поэтому от такого решения я отказался и подключил к серверу сотовый телефон.
Дело в том, что этот модуль считается dirty hack'ом. Все его возможности, кроме --tee(копирование пакетов) реализуются при помощи iproute2. Считается, что iptables маршрутизацией не должен заниматься, для этого есть iproute2 со своими таблицами.
зы у меня htc g1 dream
www.mail-archive.com/netdev@vger.kernel.org/msg60638.html
Первая реализуется маркировкой в iptables, вторая использование tc filter u32(с хэшами).
У первой схемы недостаток в разрастании таблиц iptables. При существовании 10к пользователей мы имеем 10к правил iptables(через все проходит каждый пакет) и 10k фильтров tc. При большом потоке пакетов ksoftirqd уходит в вечный луп, загружая одно ядро сервера.
У второй схемы недостаток в абсолютной адском синтаксисе настройки и жуткой глючности при изменении(удалении) фильтров. При существовании статических классов и фильтров не плохое решение, если использовать хэш таблицы.
Не так давно в ядро добавили новую схему tc filter flow(разработанная изначально для sfq кудиска). Она лишена всех описанных недостатков, только совершенно не документирована и может быть использована только адептами, читающими исходный код. =)
зы марков 2^32, а вот классов увы может быть только 0xffff
зыы на днях соберусь — распишу подробно все три схемы с примерами.