[nuclearcat]

Написал патчик. Бо задолбало, что юзеры могут "переюзать" за 2 Гига, и не устраивает идея обрывать им сессию через 2(integer) или 4(unsigned integer) Гб.

 

Работает конечно не идеально, т.к. сьем данных из системы все равно идет 32-bit, и если "упустить" момент переворота - то посчитает неправильно.

Переделывать больше - смысла на данный момент мало.

 

Чтоб "не упустить" - для скорости скажем 128 Mbit/s interim period должен быть не более 5 минут. 64Mbit - 10 минут

И т.д.

 

Ссылка на патчик http://www.nuclearcat.com/files/gigawords-v3.patch

На vanilla pppd не проверял, у меня патченый гентушный. Если патч нормально не накладывается (2.4.4 pppd) - сообщите.

 

[sirmax]

Я понимаю что вопрос не совсем в тему, но нужен ли вам VPN? Сам иду по пути отказа от оного ... Хотелось бы услыщать Ваши агрументы...

[disappointed]

Я это обработал в биллинге уже. Суть та же.

[AlKov]

Я это обработал в биллинге уже. Суть та же.

А каким образом? "Костылем", или код биллинга патчили?

[disappointed]

Биллинг свой, сразу принималось во внимание обнуление счетчиков софтового наса.

[nuclearcat]

У меня PPPoE, отказываться смысла нет. Сети доступа не мои, а во многих местах от "реселлеров". Железо у них предельно дешевое, и соответственно тупое.

Схема работы у меня не очень привычная для российских реселлеров, но эффективная для моей страны.

 

Костыль в биллинг поставить можно, но правильнее подправить NAS. Потому как пакеты от NAS с неактуальными данными - это зло. Неправильность надо убивать на самом возможно раннем этапе.

 

[sfstudio]

У меня PPPoE, отказываться смысла нет. Сети доступа не мои, а во многих местах от "реселлеров". Железо у них предельно дешевое, и соответственно тупое.

Схема работы у меня не очень привычная для российских реселлеров, но эффективная для моей страны.

 

Костыль в биллинг поставить можно, но правильнее подправить NAS. Потому как пакеты от NAS с неактуальными данными - это зло. Неправильность надо убивать на самом возможно раннем этапе.

А закоммитить авторам? Да и pppd 2.4.5 уже на дворе. Ы?

[nuclearcat]

Примут ли...

 

Кроме того можно сделать более clean. Вместо long счетчиков - просто считать сколько раз счетчик переполнился, и это будет значением гигавордсов.

Выигрыш конечно невелик, но может и есть толк. Более правильная реализация...

Кстати info_print в pppd кривой, %llu он не умеет например. А хотелось бы в syslog получить реальные значения траффика, а не unsigned integer.

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

Кроме того запрос счетчиков идет по ioctl, что есмь прошлый век, вроде давно можно netlink поюзать.

[nuclearcat]

А, ну и что вспомнил - long long не кроссплатформенно. Хотя очевидных багов не будет, но некрасиво.

Надо какой-нить uint64_t

[sfstudio]

Ну дык ноги в руки и подключаться к девелоперам pppd их сейчас мало, я им закидывал мелочёвку на предмет правки опций и мультилинка, но пока тишина, подождём.

[Ivantey]

А закоммитить авторам? Да и pppd 2.4.5 уже на дворе. Ы?

А где ppp 2.4.5 брали ? На офсайте тишина.

[nuclearcat]

Форкнуть pppd и сделать его GPL (вроде BSD это позволяет)

Вони будет на всю планету :-)

[sfstudio]

>А где ppp 2.4.5 брали ? На офсайте тишина.

http://git.ozlabs.org/?p=ppp.git;a=summary Кстати ссылка с официального сайта.

 

>Форкнуть pppd и сделать его GPL (вроде BSD это позволяет)

 

pppd под dual license насколько я помню.

[disappointed]

Заюзал, убрал костыль, спасибо.

[shaytan]

Написал патчик. ...

Этот патч смотрел, до того как создал новый?

 

 

Примут ли...

 

Кроме того можно сделать более clean. Вместо long счетчиков - просто считать сколько раз счетчик переполнился, и это будет значением гигавордсов.

Выигрыш конечно невелик, но может и есть толк. Более правильная реализация...

Кстати info_print в pppd кривой, %llu он не умеет например. А хотелось бы в syslog получить реальные значения траффика, а не unsigned integer.

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

Кроме того запрос счетчиков идет по ioctl, что есмь прошлый век, вроде давно можно netlink поюзать.

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

 

[nuclearcat]

Написал патчик. ...

Этот патч смотрел, до того как создал новый?

 

 

Примут ли...

 

Кроме того можно сделать более clean. Вместо long счетчиков - просто считать сколько раз счетчик переполнился, и это будет значением гигавордсов.

Выигрыш конечно невелик, но может и есть толк. Более правильная реализация...

Кстати info_print в pppd кривой, %llu он не умеет например. А хотелось бы в syslog получить реальные значения траффика, а не unsigned integer.

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

Кроме того запрос счетчиков идет по ioctl, что есмь прошлый век, вроде давно можно netlink поюзать.

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

Ну памяти там ненамного больше используется :-)

 

Тот патч во первых имеет бОльший overhead, во вторых затрагивает кучу вещей не относящихся к делу.

В pppd неспроста не используют sprintf напрямую (есть враппер slprintf, в котором нед поддерки %llu), думаю это связано с портабельностью. Поэтому я не затрагивал эту часть.

Кроме того автор делает поддержку vendor-specific атрибута - для примера Acct-Output-Packets-64, который посылает 64-бит значение как текстовую строку. Этот атрибут нафиг не нужен имхо.

[shaytan]

Это понятно что там есть лишнее, я имел ввиду ту часть кода которая отностится именно к вычислению GIGAWORDS.

Спрашиваю потому, что мне сейсас надо вставить в pppd 2.4.4 поддержку GIGAWORDS, и думаю какой код взять за основу вычисления счётчика переполнений, путём записи предыдущих значений и сравнением с текущим, если меньше то счётчик увеличивать на единицу и пихать значение этого счётчика в GIGAWORDS. Т.о. long long int уже не нужен. Ну вычисления делать только при ACCT-UPDATE и ACCT-STOP и не забываем про частоту обновлений.

 

ps. Надеялся счётчик переполнений есть в структуре pppstat, но увы :(

Изменено 11 марта, 2009 пользователем shaytan

[SokolovS]

Я как раз считаю сколько раз счетчик переполнился и храню это значение как атрибут сеанса связи. Т.е. в одном поле количество переполнений в другом актуальное значение от NAS. Итого трафик это 4 Гб * кол-во переполнений + текущее значение.

[shaytan]

Считаешь на стороне радиус сервера?

[nuclearcat]

Да, еще вот долго меня мучала мысль, т.к. не люблю очень цифры с потолка. Хотя сам когда тороплюсь - ставлю цифры от балды :-)

+ static char bigint[64];

достаточно 21

т.к. 2^64 = 18446744073709551616 , 20 цифр + NULL

 

Еще одна из вероятных ошибок(или скорее некрасивостей), и у меня и в том патче - скажется на 64-бит архитектурах, unsigned long long. На 32-бит архитектуры это 64 бита, а на 64-бит будет 128 бит. Т.е. нужно нечто u64. Плюс я еще не уверен в правильности работы на big-endian архитектуре.

 

 

[SokolovS]

Считаешь на стороне радиус сервера?

Ну вобщем-то да, freeradius + rlm_perl, при запросе на обновление.

[sfstudio]

Плюс я еще не уверен в правильности работы на big-endian архитектуре.

Работает корректно, тут я уже оттестил ;)

[nuclearcat]

Можно еще через триггеры в MySQL, без всяких perl

Это самый простенький. Не обрабатывается момент rollover, его надо дописать...

 

DROP TRIGGER IF EXISTS `pi`.`radacct_update`;
DELIMITER //
CREATE TRIGGER `pi`.`radacct_update` AFTER UPDATE ON `pi`.`radacct`
FOR EACH ROW BEGIN
DECLARE user_num INTEGER;
SELECT id INTO user_num FROM userinfo WHERE username = NEW.username;
IF NEW.AcctOutputOctets > OLD.AcctOutputOctets
THEN
INSERT INTO traffstat (userid,hour,date,rx,tx) VALUES (user_num,HOUR(NOW()),CURDATE(),NEW.AcctInputOctets-OLD.AcctInputOctets,NEW.AcctOutputOctets-OLD.AcctOutputOctets) ON DUPLICATE KEY UPDATE rx=rx+NEW.AcctInputOctets-OLD.AcctInputOctets,tx=tx+NEW.AcctOutputOctets-OLD.AcctOutputOctets,updates=updates+1;
END IF;
END

 

 

[SokolovS]

Можно и так :) У меня все равно за 1 запрос на обновление это делается.

[NiTr0]

Этот патч смотрел, до того как создал новый?

Спасибо за патч, работает.

С патчем в шапке - на CentOS с пересобранным патченным pppd наблюдалась проблемка - по алив-пакету падал туннель...