bomberman
-
Публикации
226 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем bomberman
-
-
aabc планируете добавление ф-ционала, расширение возможностей?
-
Я очень сильно подозреваю что самому автору модуль не нужен, а задачи заказчика - полностью закрыты. Потому и правок нет :)
К сожалению так и есть
Я инсайдер и в курсе всех скрытых подробностей появления ratelimit/netflow модулей.
Этот модуль вообще появился только потому, что автору были предоплачены часы работы (20 часов afair), причем даже без гарантий что что-то получится на выходе. Изначально нужно было выяснить как это реализовать под большую нагрузку и при этом сделать удобным для isp. То что код публичный, так это позиция автора. На данный момент все оплаченное время закончилось.
А очень жаль.
-
До сих пор не могу понять как в мире опенсоурс могло появится такое продуманное и качественное решение.
извиняюсь за оффтоп, но звучит как нашли золото среди говна. Или в мире OpenSoource по вашему не может быть хороших (продуманных и качественных) продуктов?
-
Чего. Иногда может и сгодиться. В любом случае спасибо за разработку.
-
OpenSource версия не планируется? :)
-
По лицензированию - одна Lifetime лицензия на один брас.
Что подразумевается под Lifetime лицензия?
Верно ли я понял, что заплатив ~ 400EUR. Я получаю софт, который не имеет ограничений работы во времени, и ф-ционале.
При этом поддержка ограничена временем/сроком. И если мне захочется обновить софт, то необходимо будет продлевать лиценщию на суппорт. Если не продлил - покупать софт снова?
Если мне нужно будет перенести софт на другое железо, к примеру на более производительное. Могу ли я это сделать сам без обращения в суппорт или действий с лицензией? Иными словами лицензия завязывается на железо?
-
Сколько стоит Ваше решение?
Как происходит лицензирование? (количество абонентов, инсталляций, время)
Как то зависит ф-ционал от лицензий?
-
Ну коль Вы хотите регулировать доступ на уровне доменного имени, Вам необходимо подниматься выше уровня ip.
-
присоеденяюсь к вопросу pppoetest
-
Абонентов 500 штук
31Мб на 500 абоненетов?
-
bomberman
Больной вопрос ( спецов нет, все на удаленке и на коленках. Для тазиков нужен спец по линуксу. Думаю взять микротик, но опять же вдруг получится так же как и с 7200, что нифига подобное не реализовать...
Ну если на нём будет только NAT, то вполне. Главное чтоб железо выдержало.
-
Кроме того, вопрос стоит в том, ЧЕМ НАТить?
Ну как вариант тазиками.
-
NAT-те сегментам.
-
Архитектурно не развивается, идёт по сути фикс багов. Ну вообщем кроме как порисовать графики на какому-нибудь тестовом стенде, Cacti уже особо больше ни на что и не годится
Ну с тестовым стендом Вы уж слишьком. Она ещё поработает. А что архитектурного развитя нет - это согласен. Но будем надеяться что скоро всё поменяется.
-
Ну почему же труп. Вяло они просто ею занимаются.
-
там же зелёным написано всё понятно... ;)
-
Встречал как то однажды утилиту к счётчику, вроде как горячей воды, который на дом ставили. Счётчик по rs-232 подключается, и утилитой от вендора можно было мониторить параметры, а так же вести учёт. Финансовый тоже.
-
желаю автору модулей побольше предоплаченных часов.... :-)
-
На сколько я помню, рабочие часы на эту часть девелопмента не были оплачены
Что то я не припомню о коммерческой составляющей этого проэкта, или автор обещял плюшки за доп плату где то тут?
-
Как по мне - это вообще первый полисер в линукс
Ну тут я не соглашусь. Полисинг там был давно. tc в помощь.
А как подвигается, позволю напомнить, работа над воплощением полисинга над подсетями? Мы по /29 private клиентам выдаём, например.
IPv6 в планах есть?
Присоеденяюсь к вопросу.
-
Если машина тестовая, поставте 777 :) И поглядите будет ли работать. В правах ли дело. Коль в правах дальше по обстоятельству. Смотря от кого работает web сервер. Скорее он туда и писать доложен.
-
Сделал так. Параметр default_policy теперь может принимать три значения: block-all (блокировать строго все, чего нет в базе), block (блокировать все, кроме самого шейпера), pass (пропускать все).
Отлично. Считаю будет необходимым.
-
Плохо в этой схеме то, что мне не известно, чтоб кто-то такое практически использовал
Тоже не встречал. Но попробовать думаю стоит. Хотя бы из интереса.
самое главное, не понятно какие значения ставить, чтоб получить то, что обычно хотят получить QOS.
Ну раз QOS, то наверное будет логично, для начала попробовать задать общую полосу, и потом вес для какждого типа. Но сумма всех весов в пределах общего канала выделенного для IP или (если несколько IP)подписчика.
Т.е. я пока это вижу как параметры напрмер:
IP,<speed - общая скорость для подписчика> <num_q - количество классов> <clss_id=1:speed(или вес в процентах от общей скорости)>...<clss_id=N:speed(или вес в процентах от общей скорости)>
Это первое что пришло на ум. А там быть может что ещё интереснее посоветуется.
Ну и + идентификация трафика/клиента не по IP или сегменту, а ещё и по внутренней метке, или по значению в поле QOS. Но в последнем случае общей скоростью как вариант - скорость самого интерфейса.
-
Опубликовано · Изменено пользователем bomberman · Жалоба на ответ
Я уже писал выше про подобный вариант. Сейчас рулю у себя по метке skb->priority, но можно и fwmark как доп.вариант.
Тоже считаю необходимым разбор по метками или приоритету, как дополнительную полезную плюшку, не портящую основной идеи модуля - "простой полисинг".
Единственное, в голову приходит идея с различными значениями burst для разных классов трафика. Где для более приоритетного трафика burst выше. Тогда в случае забивания канала он будет проходит в первую очередь.
Некий метод вытеснения выходит. У кого больше, то выше прыгнет, и быстрее пройдет. Так выходит?
ipt-ratelimit
в Программное обеспечение, биллинг и *unix системы
Опубликовано · Изменено пользователем bomberman · Жалоба на ответ
Читайте внимательно эту ветку. Там не раз были предложения о расширении ф-ционала.
К примеру добавление ipv6.