[Forst]

Ну вобщем коллектор работает. Все данные без всякой агрегации ложит во временную таблицу.

srcIP dstIP srcPort dstPort Packets Octets DateTime

 

Как лучше сделать агрегацию всей временной таблицы? Вот три варианта:

 

1) Можно сразу всё обрабатывать:

Т.е. приходит пакет на коллектор, тот определяет тип трафика, пользователя, кому он принадлежит, тарифицирует его и пихает в базу. Но как мне кажется проделывать с каждым пришедшим NetFlow пакетом - это извращение...

 

2) Или можно так:

Все полученные NetFlow данные будут пихаться в массив.

Раз в несколько минут (допустим 5 мин) загружать в программу основные таблицы (Тарифы, Пользователи, ТипыТрафика).

Затем (после загрузки основных таблиц) произвести расчёт относительно всех данных и результат в БД.

 

3) Ну и естественно:

Раз в несколько минут будет запускаться вторая программа.

И обрабатывать временную таблицу.

 

Может у кого-нибудь есть ещё варианты?

Изменено 1 октября, 2006 пользователем Forst

[deep_admin]

Ну вобщем коллектор работает. Все данные без всякой агрегации ложит во временную таблицу.

srcIP dstIP srcPort dstPort Packets Octets DateTime

 

Как лучше сделать агрегацию всей временной таблицы? Вот три варианта:

 

1) Можно сразу всё обрабатывать:

Т.е. приходит пакет на коллектор, тот определяет тип трафика, пользователя, кому он принадлежит, тарифицирует его и пихает в базу. Но как мне кажется проделывать с каждым пришедшим NetFlow пакетом - это извращение...

 

2) Или можно так:

Все полученные NetFlow данные будут пихаться в массив.

Раз в несколько минут (допустим 5 мин) загружать в программу основные таблицы (Тарифы, Пользователи, ТипыТрафика).

Затем (после загрузки основных таблиц) произвести расчёт относительно всех данных и результат в БД.

 

3) Ну и естественно:

Раз в несколько минут будет запускаться вторая программа.

И обрабатывать временную таблицу.

 

Может у кого-нибудь есть ещё варианты?

Очень верной дорогой идете товарищ.

 

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

Плюсы: в один момент времени тарифицируем только подключенных юзеров, диапазон просмотра временных таблиц нетфлоу можем задавать разный для каждого юзера, тарификация происходит параллельно

Минусы: для тысячи он-лайн пользователей например нужно ооочень много оперативной памяти

[Forst]

Очень верной дорогой идете товарищ.

 

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

Плюсы: в один момент времени тарифицируем только подключенных юзеров, диапазон просмотра временных таблиц нетфлоу можем задавать разный для каждого юзера, тарификация происходит параллельно

Минусы: для тысячи он-лайн пользователей например нужно ооочень много оперативной памяти

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

Я вобщем сейчас пробую реализовать вот такой вариант: коллектор - всё инсертит в БД. больше он ничего не делает.

Наверное по крону, потом видно будет. Будет запускаться парсер БД. Он во время запуска загрузит в себя все тарифы, пользователей и виды трафика.

Затем начинает, обсчитывать временную таблицу.

По завершению, обработанные записи он удалит.

 

Но сразу всплывает идея, а что, если коллектор заставить раз в несколько минут загружать в себя данные из БД (тарифы, пользователи и виды трафика).

И на основе полученных данных пришедший Netflow обрабатывать и укладывать в БД, не простым инсертом, а апдейтом. Т.е. сразу же делать агрегацию трафика.

 

А вот ещё какой вопрос, нужна ли в БД информация о том, с какого шлюза пришли данные о трафике??

[Microsoft]

А вот ещё какой вопрос, нужна ли в БД информация о том, с какого шлюза пришли данные о трафике??

Если сейчас и не нужна, то неплохо было бы оставить возможность подключения такой фичи. Потом переделывать не придется.

[deep_admin]

>Смысла в этом нет. Если юзверь неприконектился, тогда и трафика от него не будет, соответственно и >нечего считать.

Еще как есть - видно четкое соответствие между сессией пользователя и его неаггрегированным трафиком. Просто в голове летает мысля о быстрой и индивидуальной тарификации пользователя.

 

>Я вобщем сейчас пробую реализовать вот такой вариант: коллектор - всё инсертит в БД. больше он >ничего не делает.

>Наверное по крону, потом видно будет. Будет запускаться парсер БД. Он во время запуска загрузит в >себя все тарифы, пользователей и виды трафика.

>Затем начинает, обсчитывать временную таблицу.

>По завершению, обработанные записи он удалит.

 

>Но сразу всплывает идея, а что, если коллектор заставить раз в несколько минут загружать в себя >данные из БД (тарифы, пользователи и виды трафика).

>И на основе полученных данных пришедший Netflow обрабатывать и укладывать в БД, не простым >инсертом, а апдейтом. Т.е. сразу же делать агрегацию трафика.

Лучше отделить мухи от котлет, во-первых если коллектор что-то типа циски, то сразу облом. Во-вторых, даже если это тачка с линуксом/фрей, то на ней (а это роутер) надо иметь либы коннектора к БД, хотя бы того же mysql'а, плюс расход памяти/ресурсов под загрузку всего этого. Уж лучше пусть роутер роутит и файрволит.

 

>А вот ещё какой вопрос, нужна ли в БД информация о том, с какого шлюза пришли данные о трафике??

 

Обязательно, ведь фактически привязка юзера это коллектор-интерфейс-ipадрес.

[vsteshak]

у меня реализовано так:

1 есть таблица в которой хранится информация про он-лайн пользователей

2 есть таблица в которую сваливается весь Netflow

3 есть таблица для хранения сортированого трафика с разделением по внутренний(входящий/исходящий), внешний(входящий/исходящий)

4 есть таблица в которой перечислены адреса всех задействованных в процессе узлов

5 есть таблица в которой хранятся критерии по которым следует распознавать трафик

6 есть таблица с тарифами

7 есть таблица с доп услугами

 

Использую коллектор nnfc (1 процесс), который принимает данные с трех сенсоров - два на других узлах, один та том же узле где и сам. Парсер (2 процесс) Netflow работает постоянно т.е. как только он завершил цикл обработки Netflow стартует сначала. По критериям из таблицы (адрес и/или порт источника и/или приемника) 4 производится сортировка трафика и сохранение его в таблице 3. (в моейм месности не требуется разделение на зоны типа зарубежный/не зарубежный, потому и не реализовывал).

Тарификация производится на основе данных из таблиц 3, 6, 7, примерно раз в 5 минут другим процессом и только для пользователей он-лайн.

База Postgresql 7.3.х.

[stacs]

Всем доброго дня.

Написали коллектор. Приняли пакеты. Сложили в текстовый файл.

Раз в сутки запустили джоб из скуля:

1) Загружаем логи

2) Агрегируем трафик

3) Считаем деньги

Для юридических лиц считать чаще не видим смысла/необходимости.

Для физических лиц есть пппое.

 

P.S. Дальше рецептура на любителя: отчеты, уровень детализации логов в ини-файлах, частота загрузки логов и прочее-прочее-прочее :)

 

P.S.S. Написано под винду на си-шарпе + MS_SQL

[Kuzmich]

Вот затянул вас netflow, сил нет... зачем писать очередной однобокий биллинг, который через пол-года обрастет подпорками, обходами и заглушками?

 

Во-первых - откажитесь от mysql, ибо немасштабируемо. Отсутсвие внятной системы хранимых процедур, триггеров и пакетов (впрочем, в пятой ветке вроде как что-то получшало...) заставляет выносить всю логику во внешние модули, а результат - необходимость постоянно думать о целостности данных и бить себя по рукам при каждой попытке что-то закэшировать в памяти процесса. Берите постгрес.

 

Во-вторых - надо строить систему не от способа загрузки трафика, а от расчетв с абонентами. Биллинг - это же "Автоматизированная Система Расчетов", а вовсе не "Считалка трафика".

 

Предлагаю следующую структуру:

 

клиент ( id, ЮЛ/ФЛ, реквизиты (ФИО, Юр.Адрес, номер паспорта))

 

договор (номер договора, баланс по договору) // баланс по договору двигается триггерами таблиц "начисления" и "платежи"

 

дейстие договора ( номер договора, id клиента, дата начала, дата окончания) // возможна передача прав и обязанностей по договору от одного человека другому

 

объект договора ( id объекта, тип объекта, номер договора, адрес установки, контактное лицо, идентифицирующие параметры (например, IP-адрес))

 

Виды услуг ( id, название, способы расчетов (абонентка, количественный, повременка), разрешение назначения на объекты договоров определенного типа (чтобы девочки-операционистки не напутали), единица измерения )

 

Назначение услуг ( id объекта договора, id услуги дата начала, дата окончания)

 

Факты оказания услуг ( id объекта, id услуги, дата оказания, количество)

 

Счетчики услуг ( id объекта договра, id услуги, отчетный период (месяц), сам счетчик ) (двигается триггером на таблице фактов оказания услуг)

 

Начисления ( id договора, id объекта, id услуги, сумма, расчетный период ) ( двигаются триггером на таблице "счетчики услуг")

 

Платежи ( id платежа, номер договора, сумма, дата плетежа, тип платежа и т.п.)

 

Тарифные планы (id, название)

 

Назначение тарифных планов ( id тарифного плана, id объекта договра, дата начала действия, дата окончания действия)

 

Правила начисления по тарфиным планам... это уже от фантазии.

Например:

id услуги, верхний порог счетчика услуги, цена за единицу

 

 

Это то, что относится к ядру биллинга, способного тарифицировать любые услуги, поддающиеся количественному измерению

 

Дальше к нему нужно прикручивать модули, отвечающие за отдельные услуги, например за трафик. Состоит из следующих таблиц:

 

Зоны трафика (id, название, флаг поиска объекта договора в этой зоне )

 

Адреса в зонах (id, первый адрес, последний адрес, дата начала принадлежности адресов зоне, дата окончания)

 

Типы трафика (если надо. Здесь можно учитывать приоритеты, протоколы и т.п.)

 

Правила определения услуг

( id зоны клиента, id зоны удаленного хоста, направление трафика, id услуги)

 

 

Нормальный интернет-пользователь заводится так:

 

Абонент (ФИО)

Договор

Объект договора - подключение к сети интернет

Тарифный план

Услуги по объекты договора:

абонентка

входящий трафик интернет

исходящий трафик интернет

входящий внутрисетевой

исходящий внутрисетевой

входящий пиринговый

исходящий пиринговый

входящий с медиа-площадки

исходящий с медиа-площадки

 

Тарифный план (кусоче правил начисления)

входящий интернет, до 200 мегабайт, по 2 рубля

входящий интернет, до 500 мегабайт, по 1.80

входящий интерне, до 1 Тб, по 1.20

 

Платеж - сегодня, 1000 рублей.

 

Пусть абонент наработал 100 мегабайт входящего...

 

Модуль обработки интернет-трафика получает данные:

 

1.2.3.4 > 192.168.5.1, 20 Mb

5.6.7.8 > 192.168.5.1, 80 Mb

 

Агрегатор, полазив по справочнику зон, и обнаружив, что 192.168.5.1 относится к зоне клиентов (есть "галочка" надо искать абонентов), превращает эту запись в

 

зона IКлиенты, Зона Интернет, Входящий, 100 мегабайт, сегодня в пол-первого.

 

Сравнивая с таблицей лпределения услуг, получаем вид услуги - входящий трафик интернет

 

Поиском по таблице идентифицирующия параметров объектов договоров находим Васю Пупкина, которому "принадлежит" адрес 192.168.1.5

 

Создаем запись о факте оказания услуг:

 

Объект договора с Васей Пупкиным, входящий трафик интернет, 100 мегабайт, сегодня в пол-первого.

 

Автоматически двигается счетчик услуги "входящий трафик" для этого объекта договора на 100 Mb ( триггером на вставку записи в таблицу фактов оказания услуги)

 

Автоматически производится начисление 100*2 рубля=200 рублей по объекту договора, и попадает в таблицу начислений ( триггер на таблице фактов оказания услуг)

 

Автоматически изменяется баланс по договору (триггер на таблице начислений).

 

 

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

[Forst]

Уважаемый Kuzmich, спасибо за развёрнутый ответ. Бум учить постгрес. И врубать в вылаженную вами информацию. Тут есть надчем поразмыслить.

Сейчас сделал рабочий вариант, спихнул всё в одну программу.

Таблицы:

1. Tariffs - инофрмация по тарифу

2. Users - информация по пользователю (краткая: ид, тариф, счёт, ип)

3. Traffic - сюда падают уже обработанные данные с коллектора. (ид-пользователя, Ип_куда_он_ходил, порт, входяший_трафик, исходящий_трафик, дата, час).

4. Trash - Если нельзя определить кому из пользователей принадлежит трафик, то он падает сюда. (src_ip, dst_ip, src_port, dst_port, octets)

 

Вобщем логика такая:

Колектор при запуске читает таблицы Tariffs и Users на базе этого заполняет массив struct users_arr (ID, struct Tariff, IP).

Потом раз в несколько минут обновляет их.

 

1>>NetFlow пакет (делается для себя, поэтому и прибился гвоздями к NetFlow) приходит на коллектор:

2>>Если не srcIP, не dstIP не найденны в users_arr то делается Insert в trash -> обрабатываем следующий пакет

3>>Если (например srcIP) принадлежит какому-нибудь пользователю, то трафик исходящий oBytes=Octets, iBytes=0; Адрес_куда_он_пошёл=dstIP; порт=dstPort.

Тутже считается стоимость трафика.

4>>Делаем update users, вычетаем деньги.

5>>Делаем update traffic прибавляем iBytes, oBytes, деньги.

В записи где равны UserID, InternetIP, Port, Date, Hour.

6>>Если результат обнавления 0, то делаем инсерт.

 

Вобщем работает, щас пишу программулинку, которая сгенерирует поток пакетов, чтобы проверить на стабильность.

При помощи постгрес можно часть процедур вынести в БД?

Т.е. сделать, чтобы СУБД делала шаг 2, 3,...?

[boykov]

варианты, варианты...

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

 

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

Если у кого есть опыт/данные по этим вопросам -- поделитесь, плиз.

[Forst]

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

Это всё сформулировано в требования к АСР. Где-то на сайте минсвязи валяется.

В каком-то законе написано, если у девайса/программы которые отлавливают трафик (сенсорами их вроде звать) есть сертификат. (Любая циска имеет ССС). То в принципе уже можно работать. А для получения сертификата на АСР надо не так уж и много крови/пота/нервов.

Вроде так, если ничего не путаю. Я не юрист, как мне объяснили, так и понял. И вообще штатный юрист очень полезно :-)

[balamutang]

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

Если у кого есть опыт/данные по этим вопросам -- поделитесь, плиз.

требования действительно есть на сайте минсвязи. единственное что в них не указано - это сумма которую придется потратить на сертификацию. :) дешевле УТМ5 или ЛанБиллинг купить будет, да еще и с пожизненной техподдержкой :) чем свою писанину сертифицировать :)

[jab]

:) дешевле УТМ5 или ЛанБиллинг купить будет, да еще и с пожизненной техподдержкой :) чем свою писанину сертифицировать :)

Угу, и потом пожизненно мучаться геморроем с техподдержкой. Без сорцов. И за каждый чих платить,

платить, платить... :-)

[balamutang]

Угу, и потом пожизненно мучаться геморроем с техподдержкой. Без сорцов. И за каждый чих платить,

платить, платить... :-)

а платить своему программеру зряплату значит дешевле? да и люди приходят-уходят... новый придет, пока асилит предыдущую писанину, клиенты разбегутся или наоборот скачают весь интернет... :)

 

а на биллинги по 70k$ стоимостью исходники дают?

[Kuzmich]

Уважаемый Kuzmich, спасибо за развёрнутый ответ. Бум учить постгрес. И врубать в вылаженную вами информацию. Тут есть надчем поразмыслить.

Сейчас сделал рабочий вариант, спихнул всё в одну программу.

Таблицы:

1. Tariffs - инофрмация по тарифу

2. Users - информация по пользователю (краткая: ид, тариф, счёт, ип)

3. Traffic - сюда падают уже обработанные данные с коллектора. (ид-пользователя, Ип_куда_он_ходил, порт, входяший_трафик, исходящий_трафик, дата, час).

4. Trash - Если нельзя определить кому из пользователей принадлежит трафик, то он падает сюда. (src_ip, dst_ip, src_port, dst_port, octets)

 

Вобщем логика такая:

Колектор при запуске читает таблицы Tariffs и Users на базе этого заполняет массив struct users_arr (ID, struct Tariff, IP).

Потом раз в несколько минут обновляет их.

 

1>>NetFlow пакет (делается для себя, поэтому и прибился гвоздями к NetFlow) приходит на коллектор:

2>>Если не srcIP, не dstIP не найденны в users_arr то делается Insert в trash -> обрабатываем следующий пакет

3>>Если (например srcIP) принадлежит какому-нибудь пользователю, то трафик исходящий oBytes=Octets, iBytes=0; Адрес_куда_он_пошёл=dstIP; порт=dstPort.

Тутже считается стоимость трафика.

4>>Делаем update users, вычетаем деньги.

5>>Делаем update traffic прибавляем iBytes, oBytes, деньги.

В записи где равны UserID, InternetIP, Port, Date, Hour.

6>>Если результат обнавления 0, то делаем инсерт.

 

Вобщем работает, щас пишу программулинку, которая сгенерирует поток пакетов, чтобы проверить на стабильность.

При помощи постгрес можно часть процедур вынести в БД?

Т.е. сделать, чтобы СУБД делала шаг 2, 3,...?

CREATE OR REPLACE FUNCTION charge_traf(p_src_ip int4, p_dst_ip int4, p_datestamp "timestamp", p_octets int8)
  RETURNS "char" AS
$BODY$DECLARE
    user_id int4;
BEGIN

    SELECT U.id INTO user_id FROM users_arr U WHERE U.ip = p_src_ip;

    IF user_id IS NOT NULL THEN
        INSERT INTO traffic_facts ( datestamp, "user", remote, direction, octets ) VALUES
        ( p_datestamp, user_id, p_dst_ip, 'O', p_octets );
        RETURN 'O';
    ELSE 
        SELECT U.id INTO user_id FROM users_arr U WHERE U.ip = p_dst_ip;

        IF user_id IS NOT NULL THEN
            INSERT INTO traffic_facts ( datestamp, "user", remote, direction, octets ) VALUES
            ( p_datestamp, user_id, p_src_ip, 'I', p_octets );
            RETURN 'I';
        ELSE
            INSERT INTO trash ( stamp, src_ip, dst_ip, octets ) VALUES
            ( p_datestamp, p_src_ip, p_dst_ip, p_octets );
            RETURN 'U';
        END IF;
    END IF;

END;$BODY$
  LANGUAGE 'plpgsql' VOLATILE;

 

Это в качестве затравки :)

[jab]

а платить своему программеру зряплату значит дешевле? да и люди приходят-уходят... новый придет, пока асилит предыдущую писанину, клиенты разбегутся или наоборот скачают весь интернет... :)

Платить зряплату своему программеру придется независимо от того, какой биллинг. :-) Потому как

ни один коробочный биллинг без собственного программера нормально не работает.

У меня вот от УТМ5 только пол-ядра используется и ССС для отмашки. Все остальное переписано.

 

а на биллинги по 70k$ стоимостью исходники дают?

Бывает и дают. Правда это смотря кому. Некоторым вон исходники винды дают. :-)

[gtbear]

Написал для дома биллинг..выглядит типа такого:

1.Юзер авторизуется по впн и радиусу.Вся логика авторизации запихана в MySQL процедуры.

2.Трафик снимает netflow сенсор(или radacc..собсна это настраиваемо),скидывает в коллектор из flow-tools и потом все это дело загружается напрямую в базу с помощью flow-export раз в 5 минут.При загрузке срабатывает триггер,так что он разносит инфу по 2м доп таблицам..в первой находится агрегированная по зонам инфа,во второй по адресам назначения.

3.При получении update запроса происходит обсчет трафика по данным из таблицы с агрегированным трафиком.

 

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

 

P.S.Вообще собираюсь дописать это дело,вылизать и выложить в общий доступ..мож кому и пригодится)))

[Forst]

Мой билинг, который обрабатывает, данные и пихает в ЭСКЬЮЭЛЬ на каждый пришедший NetFlow, тест не прошёл. сделал flow-gen -V5 -n1000 | flow-send 0/127.0.0.1/9996

Вобщем он поймал тока 250 пакетов из 1000 и это при том, что данные ложились простым инсертом. Конечно скорость генерации флоу-Пакетов зверская, но блин незнаю...

Вобщем пробую сделать по другому.

 

Плюс думаю такой вопрос.

Есть допустим общий тариф. Тарификация относительно текущего времени.

Но надо какому-нибудь пользователю или группе, сделать другую тарификацию на определённый диапазон адресов.

Как лучше такое реализовать?

Ну поятно: сделать таблицу с описанием тарифа.

сделать вторую таблицу в неё вписать диапазон, или один адрес и сслыку на ИД тарифа.

 

Чё-то фантазии нехватат.

[Microsoft]

Мой билинг, который обрабатывает, данные и пихает в ЭСКЬЮЭЛЬ на каждый пришедший NetFlow, тест не прошёл. сделал flow-gen -V5 -n1000 | flow-send 0/127.0.0.1/9996

Вобщем он поймал тока 250 пакетов из 1000 и это при том, что данные ложились простым инсертом. Конечно скорость генерации флоу-Пакетов зверская, но блин незнаю...

Ну не справляется не сервер БД, а скорее всего буфер приема пакетов мал. Попробуй установить на сокете буфер приема полтора-два мегабайта. Я же говорил уже ранее про эти грабли. Буфер приема переполняется быстрее, чем ты выгребаешь пакеты из него. Если пакеты выгребаются из сокета в цикле - иногда помогает задержка в 1 мс между чтением каждого пакета - не знаю почему, но были у меня и такие грабли. Вобщем особенности сокетов...

 

Сообщи о результате

[Forst]

Мой билинг, который обрабатывает, данные и пихает в ЭСКЬЮЭЛЬ на каждый пришедший NetFlow, тест не прошёл. сделал flow-gen -V5 -n1000 | flow-send 0/127.0.0.1/9996

Вобщем он поймал тока 250 пакетов из 1000 и это при том, что данные ложились простым инсертом. Конечно скорость генерации флоу-Пакетов зверская, но блин незнаю...

Ну не справляется не сервер БД, а скорее всего буфер приема пакетов мал. Попробуй установить на сокете буфер приема полтора-два мегабайта. Я же говорил уже ранее про эти грабли. Буфер приема переполняется быстрее, чем ты выгребаешь пакеты из него. Если пакеты выгребаются из сокета в цикле - иногда помогает задержка в 1 мс между чтением каждого пакета - не знаю почему, но были у меня и такие грабли. Вобщем особенности сокетов...

 

Сообщи о результате

буфер был 4096. сейчас сделал на всякий случай 8192.

хотя с новой логикой и 4096 хватает. потеряных пакетов нет.

 

Сейчас главный вопрос, это как реализовать тарификацию.

Тариф задаётся такой таблицей:

TarifName - Название

StartHour - Время с которого действует указанная ниже цена.

EndHour - Время по которое действует эта цена.

iTrafCost - Стоимость входящего трафика. (за мегабайт)

oTrafCost - Стоимость исходящего трафика.

 

Т.е. получается примерно вот что:

 

"pro", 0, 2, 1, 0 # c 0 до 2 1р за мб.

"pro", 2, 8, 0.5, 0 # с 2 до 8 50коп за мб.

"pro", 8, 24, 1, 0 # с 8 до 24 1р за мб.

 

"icq", 0, 24, 0.01, 0

 

Но задача вот какая.

 

по тарифу pro идёт тарификация диапазона 0.0.0.0/0

а по тарифу icq надо сделать тарификацию другого диапазона 64.12.161.153/32

 

вот как лучше это реализовать????

[Kuzmich]

тиблица zones: name, start_ip, stop_ip

например:

'localnet',ip_to_int('192.168.0.0'), ip_to_int('192.168.15.255');

'media',ip_to_int('192.168.16.0'),ip_to_int('192.168.16.10');

'media',ip_to_int('1.2.3.4'), ip_to_int('1.2.3.8');

'peering',ip_to_int('10.0.0.0'),ip_to_int('10.0.255.255');

 

таблица определения класса услуг service_kinds: тар.план, зона-источник, зона-приемник, услуга (можно дополнить "время начала - время окончания", "день недели" - по желанию)

например:

'basic','localnet','localnet','local_traf'

'basic','media','localnet','media_traf_in'

'basic','localnet','media','media_traf_out'

'basic','peering','localnet','peer_traf_in'

'basic','localnet','peering','peer_traf_out'

 

таблица правил тарификации услуг по тарифному плану:

tafif_schema: tarif, service, round, price

'basic','local',1,0 (бесплатно)

'basic','media', 1024*1024*1024,10 (10 руб/гигабайт)

'basic','peer_traf_in',1024*1024,1 (1 руб/мегабайт )

'basic','peer_traf_out',1,0 (бесплатно)

'basic','inet_traf_in',1024*1024,3.50 (3.50 руб/мегабайт )

'basic','inet_traf_out',1,0 (бесплатно)

 

Определение зоны по IP-адресу лучше делать хранимой процедурой, которая при невозможности найти запись в таблице зон для данного адреса будет возвращать предопределенное значение 'inet' (т.е. все явно не обозначенные зоны считаются интернетом). Аналогично при невозможности найти услугу для двух указанных зон трафика можно возвращать предопреленное значение "none", и не тарифицировать его, лобо тарифицировать по специально обученной строке с нулевым тарифом - для единообразия.

 

Такая схема позволит достаточно гибко рулить несколькими тарифными планами (например, в одном аська считатеся отдельно, а в другом - как обычный интернет), при этом имея одну таблицу зон....

[gtbear]

2Kuzmich,подскажи как преобразовать IP-адрес в число..чтобы потом можно было сравнивать хосты по маске.

[jab]

2Kuzmich,подскажи как преобразовать IP-адрес в число..чтобы потом можно было сравнивать хосты по маске.

INET_ATON(ip)&0xffffffff например

[gtbear]

2Kuzmich,подскажи как преобразовать IP-адрес в число..чтобы потом можно было сравнивать хосты по маске.

INET_ATON(ip)&0xffffffff например

а как это реализовать на PL/SQL?))

[Kuzmich]

2Kuzmich,подскажи как преобразовать IP-адрес в число..чтобы потом можно было сравнивать хосты по маске.

INET_ATON(ip)&0xffffffff например

а как это реализовать на PL/SQL?))

А зачем теббе это? Грузи в базу уже в двоичном виде. Мало того - в агрегированном. И не забудь, что целые числа бывают знаковые и беззнаковые - много времени сэкономишь на отладке :)

 

На всякий случай, самое тупое решение:

 

create or replace function IP_TO_NUMBER(address in varchar2) return number is
  Result number;
  pos number;
  addr varchar2(16);
begin
  
  addr :=address;
  Result := 0;
  pos:=0;
  
  loop
      pos:=instr(addr,'.');
      
      if pos >0 then
            Result := Result*254 + to_number( substr(addr,1,pos-1) );
            addr := substr(addr, pos+1 );
      else
            return Result*256+to_number(addr);
      end if;
  end loop;
  
  return(Result);
exception
         when others then 
              return NULL;
end IP_TO_NUMBER;

 

Впрочем, не понимаю - зачем тебе это. Ты же на mysql биллинг пишешь? Там PL/SQL'а-то нет....

Изменено 10 октября, 2006 пользователем Kuzmich