commenth: Поле_commenth_выводится, _если_размер_лицевого_счета commenth: выдается_в_html_формате. _Пробелы_должны
commenth: заменяться_на_подчеркивания. _Количество_строк_comment_и commenth: commenth_не_ограничено, _однако_суммарная_длина_каждой_не commenth: не_должна_превышать_1000_символов. price: Monday, 0-9 $0. 6 price: Monday, 10-17 $1 price: Monday, 18-23 $0, 6 price: Tuesday, 0-9 $0. 6 price: Tuesday, 10-17 $1 price: Tuesday, 18-23 $0, 6 price: Wednesday, 0-9 $0. 6 price: Wednesday, 10-17 $1 price: Wednesday, 18-23 $0, 6 price: Thursday, 0-9 $0. 6 price: Thursday, 10-17 $1 price: Thursday, 18-23 $0, 6 price: Friday, 0-9 $0. 6 price: Friday, 10-17 $1 price: Friday, 18-23 $0, 6 price: Saturday, 0-23 $0. 6 price: Sunday, 0-23 $0. 6
Описание файлов в домашнем каталоге пользователя с "биллинговой информацией"
. pay - информация о начислениях (история начислений) на лицевой счет пользователя условных единиц или $. Файл имеет формат вида: # # # Платежи клиента ivan # # 1999/02/27 13: 00: 01 Add pay | 10. 5 1999/03/15 15: 12: 00 Add pay | 23 1999/05/05 12: 30: 40 Add pay | 6. 5
Как видно, данный файл имеет два поля произвольной длины разделенные символом "|". Первое (левое) поле содержит комментарий или, другими словами, обоснование для второго (правого) поля, в котором содержится число с плавающей точкой, определяющее стоимость транзакции, т. е. стоимость биллинговой информации. Основная и единственная единица измерения биллинговой информации - условная единица или $. Если приведенный выше файл содержится в домашнем каталоге пользователя ivan, то, просуммировав второе (правое) поле, можно выяснить, что общий размер начислений на лицевой счет (или платежей) клиента ivan равняется 40 условным единицам. Открыв этот файл, системный администратор или пользователь ivan может не только узнать сколько вообще было начислено на данный лицевой счет, но и то, когда (кем) это было сделано (забегая вперед, хочется отметить, что подобный способ хранения биллинговой информации в обычных текстовых файлах, т. е. "дата, обоснование операции | размер", является основным для предлагаемой системы). Добавлять или изменять информацию в файлах . pay должен только системный администратор. Делать это можно как из командной строки, так и через веб-интерфейс; . weekly - информация об отчислениях (история отчислений) с лицевого счета пользователя в условных единицах за фактическую работу за текущую неделю по каждому соединению (по каждой предоставленной услуге). Формат файла аналогичен формату файла . pay # # # Работа клиента ivan за текущую неделю # # 1999/05/18 13: 00: 01 Time elapsed=40 sec. , cost | 0. 052
1999/05/19 15: 12: 00 Time elapsed=1200 sec. , cost | 0. 156 1999/05/19 16: 30: 40 Time elapsed=75 sec. , cost | 0. 101
Запись в файл . weekly делает демон после окончания соединения. В приведенном выше фрагменте файла . weekly в первом поле содержится следующая информация: дата окончания соединения (YYYY/MM/DD), вреня окончания соединения (HH: MM: SS), продолжительность соединения в секундах (Time elapsed). Во втором поле файла . weekly, отделенного символом "|" содержится стоимость транзакции (стоимость соединения, стоимость фактически предоставленной услуги в условных единицах); . work - информация об отчислениях (история отчислений) с лицевого счета пользователя по за целые недели в сумме. В конце каждой недели второе поле файла . weekly суммируется и итоговая сумма заносится в файл . work. 1999/05/18 1999/05/25 cost | 5. 011 1999/05/26 1999/06/01 cost | 2. 133
Файлы . weekly в домашних каталогах пользователей "разбухают" вследствие того, что там протоколируется каждое соединение. С другой стороны, как показывает практика, большинству пользователей интересен лишь подробный отчет использования машинного времени за текущую и прошедшую неделю, поэтому информация, накопленная в файлах . weekly должна "компрессироваться". Если же пользователю нужно предоставить подробный отчет за работу двух- (трех-, четырех- и т. д. ) недельной давности (что случается не так часто), то эту информацию системный администратор может "вытащить" из SQL-базы. Обновлением файлов . work, . weekly и . weekly. last должна заниматься специальная программа w_update. pl, запускаемая по крону еженедельно; . weekly. last - копия файла . weekly за прошлую неделю;
. current - текущий размер лицевого счета пользователя в условных единицах, файл обновляется после завершения каждой сессии данного пользователя, служит для "быстрого" вычисления размера лицевого счета пользователя, например, при старте нового соединения;
. time - наличие такого файла (под наличием файла подразумевается файл с данным именем любой длины, в том числе и нулевой, доступный для чтения в данный момент) сигнализирует о том, что баланс лицевого счета пользователя всегда положителен. В русском языке обычно под этим подразумевают сладкое слово "халява". Разумеется, этот файл прежде всего должны иметь, например, сотрудники ISP и их ближайшие родственники ; -)
. refused - наличие такого файла сигнализирует о том, что баланс лицевого счета пользователя всегда отрицателен, т. е. доступ ему в систему временно приостановлен;
. type - тип пользователя (например, "свой", "халява", "бартер", "деньги"). Служит для деления пользователей на группы, по которым в дальнейшем генерируется статистическая информация;
. account - тип (или индекс) прайс-листа для данного пользователя. Этот файл очень удобно использовать для задания прайс-листа отдельным группам пользователей. Вы создаете желаемый прайс-лист и помещаете его в каталог /var/statserv/etc, а пользователям в домашних каталогах указываете лишь ссылку на него. Если Вы хотите поменять прайс-лист для некоторой группы пользователей, то, Вы редактируете прайс-лист всего в одном месте (см. ниже "Алгоритм выбора тарифной схемы для пользователя при старте демона");
. account. conf - собственный прайс-лист для данного пользователя. См. структуру файла . account. conf. Этот файл следует применять в том случае, когда Вы хотите задать для пользователя индивидуальный прайс-лист;
. pay. next - авансовый платеж, или следующее начисление на лицевой счет пользователя после обнуления текущего лицевого счета. Может быть использовано в том случае, когда пользователь не исчерпал текущий лицевой счет, однако оплатил следующую услугу по прежнему или новому прайс-листу;
. account. next - то же, что и . account (см. выше), но только для авансового платежа. Описание выходных документов.
В результате работы биллинговой программы вся информация о работе пользователь, как было сказано выше, фиксируется в лог-файлах и базе данных. Это является основным базисом для генерации отчетов и статистики. Извлекаемые данные могут быть представлены в качестве структурированных таблиц, либо в форме отчетов по запрашиваемым данным. Данная информация, также является подтверждением того, что пользователь работал в сети на случай претензий последнего. Список информации - данных, которые предлагаются пользователю и системному администратору (биллинг-инженеру): Время регистрации пользователя в конкретный день Оставшаяся сумма на счету у пользователя Время, проведенное в сети Статистика работы в сети по дням, неделям и месяцам
Почтовое уведомление пользователя и администратора об истечении денежного взноса. Общая структурированная таблица статистики за определенный период времени
При генерации выше указанной информации используются дополнительные модули программы “Billing ISP” и системные программы Unix такие как, CGI- модули (для обращения к базам данных и генерации HTML кода и форм или писем), Apache web server (для вывода на экран HTML кода сгенерированного CGI программой), MTA Sendmail (для отправки электронного письма пользователю об окончании счета).
Описание технологии и алгоритмов решения задачи и их машинная реализация. Описание ввода в базу данных входной информации.
Отличительная черта рассматриваемой программы от других вариантов данной курсовой работы, является полностью ароматическая генерация и занесение в базу данных информации за исключением создания самих счетов пользователей. Это определяется в основном спецификой данного программного продукта и операционной среды, в которой он работает.
Алгоритм начисления условных единиц на лицевой счет пользователя Если файл . pay в домашнем каталоге пользователя отсутствует, то занести размер платежа в файл . pay, а индекс прайс-листа в файл . account. Переход к пункту 3; Вычислить текущий размер лицевого счета пользователя. Если он отрицателен или равен нулю, то очередной платеж заносится в файл . pay, а выбранный индекс прайс-лист в файл . account. Если текущий размер лицевого счета пользователя положителен, то очередной платеж заносится в файл . pay. next, а выбранный индекс прайс-листа в файл . account. next; Обновить файл . current с текущим размером лицевого счета;
Занести платеж в таблицу "ПЛАТЕЖИ" базы данных (опционально). Алгоритм фиксации в базе статистической информации Введение.
Рассматриваемый программный продукт напрямую зависит от системных вызовов операционной среды, в которой он работает, а также и от некоторых приложений, например PPPD (название этого демона происходит от названия протокола соединения пользователя и провайдера Point to Point Protocol), syslog (системная программа, которая фиксирует пребывание пользователя в системе, а также фиксирует в лог-файлы сообщения ядра ОС). В связи с тем, что описания данных продуктов это тема отдельной курсовой работы, данный алгоритм будет описан поверхностно. При соединении пользователя к провайдеру запускается программа Mgetty, которая управляет и инициализирует работу модема. Запуск данной програмы фиксируется в системных лог-файлах системы. После ее запуска она активизирует, в нашем случаи демон PPPD, который в свою очередь принемает и регистрирует пользовательские запросы и после проверки всего необходимого впускает или нет в систему. Все действия данных сервисов после соединения отслеживает программа syslog, которая и генерирует основную базу действий пользователя в системе. Billing ISP, как уже говорилось выше напрямую взаимодействует с PPPD проверяя актуальность данного подключения и в случаи удачного входа изменяет (уменьшает) за определенный квант времени счет пользователя. Также демон биллинга с момента соединения пользователя начинает вести подсчет времени пребывания пользователя с соответствующим изменением в SQL базе полей. Обобщенный алгоритм решения задачи.
Страницы: 1, 2, 3
