Подсчет траффика, откуда выборка из базы

[tuneil]

Доброго времени суток.
Волей судеб была необходимость сделать динамическую выдачу внешних адресов. Сделано.
Но с недавнего времени возникла необходимость считать этот самы трафик и подсовывать клиентам.
С помощью процедур заполняются x-таблицы, тоесть в разделе Траффик кабенета юзера трафик наличиствует.
Но, на главной пользовательской странице (модуль Smain.pl) трафик все-равно по нулям. В связи с этим хотелось бы узнать, откуда берутся выборки для формирования значений подведеных красным.
Биллинг официален и куплен за кровные.

[0xbad0c0d3]

Из таблицы users_trf
web/calls.pl

Код:

966 sub GetClientTraf
967 {
968  my($sth,$p);
969  $sth=$dbh->prepare("SELECT * FROM users_trf WHERE uid=$_[0] LIMIT 1");
970  $sth->execute;
971  return(0,0,0,0,0,0,0,0) unless $p=$sth->fetchrow_hashref;
972  return($p->{in1},$p->{out1},$p->{in2},$p->{out2},$p->{in3},$p->{out3},$p->{in4},$p->{out4});
973 }

[tuneil]

Премного благодарен за ответ.

[tuneil]

На ваше обсуждение выложу тут свои наработки в плане подсчета трафика.
Входящий и исходящий направления подсчитываются с помощью radius аккаунтинга, с помощью процедур radupdate и radstop.

accounting_update_query = "... ,'%{Acct-Input-Packets}','%{Acct-Output-Packets}')"

Выглядит примерно это так:

1. Создается временная таблица, содержащая поточные даные аккаунтинга по каждому клиенту

CREATE TABLE temp_trf (
login VARCHAR (64),
in_o BIGINT,
out_o BIGINT,
PRIMARY KEY (login)
);

2. Модифицируется процедура radupdate


DROP PROCEDURE IF EXISTS `radupdate`;
DELIMITER $$  
CREATE PROCEDURE `radupdate` (IN login VARCHAR(64), IN stime VARCHAR (12), IN iccts VARCHAR(12), IN occts VARCHAR (12), ip_h VARCHAR(12))
BEGIN
  INSERT into dblogin (mid,act,time) VALUES ((SELECT id FROM users WHERE name=login LIMIT 1),47,unix_timestamp());
  INSERT INTO temp_trf VALUES (login,iccts,occts) ON DUPLICATE KEY UPDATE in_o=iccts, out_o=occts;
END$$
DELIMITER ;

3. Внедряется тригер, который и обрабатывает расчеты

DROP TRIGGER IF EXISTS `update_trf`;
DELIMITER ;;
CREATE TRIGGER `update_trf` AFTER UPDATE ON `temp_trf`
FOR EACH ROW BEGIN
   UPDATE users_trf SET in1 = `in1` + (NEW.in_o - OLD.in_o), out1 = `out1` + (NEW.out_o - OLD.out_o) WHERE uid = (SELECT id FROM users WHERE name= OLD.login LIMIT 1);
END;;


Сделано топорно, готов выслушать ваши идеи
Единственное что меня смущает - производительность тригеров.

Косяки:
- если будет сбой в работе связки NAS(RADIUS+DB+MPD) сервера последняя сессия не будет учтена.
- нагрузка???

[0xbad0c0d3]

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

[tuneil]

Клиенту назначается адрес из фейковой сети  (таблица users поле ip)
Дальше проверка баланса в radreply:

DROP PROCEDURE IF EXISTS `radreply`;
DELIMITER $$
CREATE PROCEDURE `radreply` (IN login VARCHAR(64), IN mac VARCHAR(18),
IN nas_ip VARCHAR(16))
BEGIN
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(16);
DECLARE rate_limit INT;
DECLARE rate_limit_out INT;
DECLARE normal_burst INT;
DECLARE normal_burst_out INT;
DECLARE extended_burst INT;
DECLARE extended_burst_out INT;
DECLARE balance_ch INT;
DECLARE lmbalance INT;


SELECT id,balance,limit_balance INTO usr_id,balance_ch,lmbalance FROM
users WHERE name=login;
SELECT plans2.speed,plans2.speed_out INTO rate_limit,rate_limit_out
from users,plans2 where users.name=login and users.paket=plans2.id ;


IF balance_ch < lmbalance THEN
SELECT ip INTO usr_ip FROM users WHERE name=login;
END IF;

INSERT into dblogin (mid,act,time) VALUES (usr_id,47,unix_timestamp());
INSERT INTO usession (login,ip,mac,nas_ip,status) VALUES (login,ip,mac,nas_ip,'START');
SET rate_limit=rate_limit*1024*1024;
SET rate_limit_out=rate_limit_out*1024*1024;
SET normal_burst=ROUND(rate_limit*3/16);
SET normal_burst_out=ROUND(rate_limit_out*3/16);
SET extended_burst=2*normal_burst;
SET extended_burst_out=2*normal_burst_out;

SELECT NULL,login,'Framed-IP-Address',usr_ip,'=';
SELECT NULL,login,'Framed-IP-Netmask','255.255.255.255','=';
SELECT NULL,login,'Framed-Protocol','PPP','=';
SELECT NULL,login,'Simultaneous-Use','1',':=';
IF (rate_limit>0) THEN SELECT usr_id as id,login,"mpd-limit" as
Attribute,concat("out#1=all rate-limit ",rate_limit," ",normal_burst," ",extended_burst) as Value,"+=" as op;
END IF;
IF (rate_limit_out>0) THEN SELECT usr_id as id,login,"mpd-limit" as
Attribute,concat("in#1=all rate-limit ",rate_limit_out," ",normal_burst_out," ",extended_burst_out) as Value,"+=" as op;
END IF;
END$$
DELIMITER;

Соответственно РРРоЕ автризация доступна всегда, просто заблоченым юзерам выдается не маршрутизируемые айпи, с переадресацией на страницу, где сообщается об отсутствии денег или нарушении (спам,флуд,учасник ботнент)
Опять же, я понимаю, что корифеи програмерства меня сейчас заплюют.

Ах да, есть ещё внешний скрипт, чекает баланс каждые 5 минут по крону.

[tuneil]

Есть ещё таблица usession, где собирается статистика по коннектам.
Ну и понятное дело модифицирован под неё Sseance.pl

Прошу прощения ещё раз за свой "индийский код", конечно правильно было бы отдавать radius отлупом (reject), и все такое, но строгал на коленке, в продакшн не запускал.  

[tuneil]

Пока такая система работает в тестовом режиме около 3 месяцев (без аккаунтинга), обслуживает 150 юзеров.

Косяки, решение которых пока не внедрено:
- Двойной логин под одной учеткой. Решение есть, но пока не внедрено.

[0xbad0c0d3]

Так получается, что шлюз пропускает динамический диапазон всегда?

[tuneil]

На сервер доступа замаршрутизировано /26 внешних адресов. Адресация распределяется из пула mpd (в будущем sqlippool), маленькая проверка и клиенту выдается либо внешний либо фейковый адресс.