Курсовая: Проект учета пользовательских счетов для интернет-провайдеров на базе OS FreeBSD с применением программы "Billing ISP" - текст курсовой. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Курсовая

Проект учета пользовательских счетов для интернет-провайдеров на базе OS FreeBSD с применением программы "Billing ISP"

Банк рефератов / Компьютерные сети

Рубрики  Рубрики реферат банка

закрыть
Категория: Курсовая работа
Язык курсовой: Русский
Дата добавления:   
 
Скачать
Архив Zip, 37 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникальной курсовой работы

Узнайте стоимость написания уникальной работы

САНКТ-ПЕТЕРБУ РГСКИЙ ГОСУДАРСТВЕННЫЙ МОРСКОЙ ТЕХ НИЧЕСКИЙ УНИВЕРСИТЕТ КУРСОВАЯ РАБОТА КОМП ЬЮТЕРНОЕ УПРАВЛЕНИЕ ПРОИЗВОДСТВОМ Проект у чета пользовательских счетов для интернет-провайд еров на базе OS FreeBSD с применением программы « Billing ISP » ВЫПОЛНИЛ : СТУДЕНТ ГРУППЫ 6420 Иванов М.Н. ПРОВЕРИЛ : НАУМОВА . САНКТ-ПЕТЕРБУ РГ 1999г. Разделы курсового прое к та : 1. Предпроектное обследование объекта автоматизации. 1.1. Описание предметной области решаемой задачи. 1.2. Функции предметной облас ти , реализуемой задачи. 1.3. Организационно-экономическая сущность задачи. 2. Разработка информационного обеспечени я з адачи. 2.1. Описание входной информации. 2.2. Описание выходной информ ации. 3. Описание технологии и алгоритмов решения задачи и их машинная реализация. 3.1. Описание ввода в базу данных входной информации. 3.2. Обобщенный алгоритм реше ния задачи. 3.3. Алг оритм выполнения отдельных модулей. 4. Контрольный пример. 1. Предпроектное обследование объе кта автоматизации. 1.1. Описание предметной области решаемой задачи. В настоящие время многие ( ISP ) интернет серви с провайдеров решают проблему учета пользо вательских счетов , и проблему контроля трафика путем написания новых приложений , ч то зачастую приводит к частым сбоям данно го ПО , и соответственно не оправдывает вл оженные в него средства . Кроме того , такие продукты не способны обслуживать большое число п ользовательских счетов и п редставлять всю обработанную информацию в ком пактной , удобной для работы и анализа форм е . Большинство предлагаемых в настоящее время систем биллинга , т.е. систем учета отработ анного "он-лайнового " времени пользователями Интерн ет- провайдера (ISP) основано , как правило , на анализе стандартных лог-файлов таких опирационн ых систем , как SCO Unix , SunOS , HpOS , AIX, IRIX раз в сутки , в нед елю , в месяц и т.д . В то время как предлагаемая система биллинга основаная прин ципиально другой ид ее , заключающейся в контроле за каждой сессией пользователя в отдельности в реальном масштабе времени . Что позволяет значительно снизить время на обработку биллинг-инженером статистики работы к аждого пользователя или группы , снизить трудо емкость занесения платежей пользователей на лицевые счета (базу данных этой пр ограммы ) и соответственно позволяет провайдерам уменьшить количество обслуживающего персоонала , что непосредственно отражается на себестоимост и предоставляемых услуг . 1.2. Функции предметно й об ласти , реализуемой задачи. Основные функциональные преимущества такого подхода заключается в том , что отслеживаю тся и корректно отрабатываются , фиксируются и генерируются в отчеты такие данные как : · Регистрирование соединения любой пр одолжительности с точностью , равной одному кванту времени (например , 5 секунд ). Квант в ремени задается системным администратором ; · Исчерпывание ср едств на лицевом счете пользователя , если он находится в данный момент в режиме "он-лайн ", и принудительное его отключение (э та ситуация очень актуальна , когда ISP пр едоставляет новому клиенту "тестовый час "); · Возможность зад ания для каждого пользователя или для гру пп пользователей гибких прайс-листов с указан ием цены в у.е . за 1 час "он-лайнового " вр емени в зависимости от вр емени суток и дня недели . Например , имеется ISP, у ко торого стоимость "дневного " (с 9 утра до 6 веч ера ) Интернета - $1, а "вечернего " (с 6 вечера до 9 утра ) - $0,6. Пользователь звонит без четверти 6-ть вечера и работает 15 минут по тарифу $1 за час и 30 м инут по тарифу $0,6 за час (всего 45 минут ), а с его лиц евого счета , соответственно , снимается сумма $0,25+$0,3, т.е . $0,55; · Переход пользов ателя с одного прайс-листа в другой , при исчерпывании средств на лицевом счете в первой схеме и при авансовом пла те же по другому прайс-листу без отключения п ользователя . Реально это означает ситуацию , ко гда работал пользователь по одному прайс-лист у , и когда у него стали заканчиваться средства на лицевом счете , он сделал новый взнос , но уже по другому (например , "ль г отному ") прайс-листу . Затем он дора ботал свои часы по "старому " прайс-листу и спокойно начал работу по "новому " прайсу-л исту ; · Удаленным польз ователям предоставляется удобный www-интерфейс при помощи которого они могут полностью конт ролировать свою работ у в Интернете вп лоть до каждого модемного звонка на узел ISP, в том числе , разумеется , они могут в любое время посмотреть размер своего лиц евого счета на текущий момент (момент гене рирования web отчета из базы данных программы « Billing ISP ». · Cистемному администратору (биллинг-инженеру ) предоставляетс я достаточно простой в освоении стандартный для Unix систем режим командной строки , открытос ть , простота и возможность "затачивания " систем ы под свои конкретные особенности. Основные качества и особенности п редлагаемой системы б иллинга · Высокая точность подсчета "он-лайново го времени " отработанного пользователями ; · Простая интеграция предлагаемой системы в существующую систему а утентификации DialUp-пользователей провайдера (забегая вперед , хочется отметить , что в настоящи й момент наша система поддерживает только схемы TACACS+ и pppd); · Возможность развертыван ия предлагаемой системы параллельно с уже существующей системой биллинга провайдера для тестирования и отладки с целью окончател ьного запуска в экспл уатацию ; · Автоматическое получени е ежедневных (еженедельных , ежемесячных ) отчетов отработанных часов и их стоимости по р азличным группам клиентов (например , "основной тариф ", "льготный тариф ", "бартер ", "халява "); · Возможность подключения SQL-сервера д ля генерации более гибкой системы статистик при помощи SQL-запросов ; · Минимальные требования к аппаратным ресурсам сервера биллинга (п редлагаемая система может функционировать даже без SQL-сервера ). Однако , www-сервер (Apache) все-таки сле дует установит ь для того , чтобы удален ные пользователи имели доступ к своей ста тистики через привычный www-интерфейс ; · Своевременное оповещени е пользователя и системного администратора че рез e-mail о том , что размер лицевого счета пользователя приближается к концу ; · Гибкое ведение прай с-листов по группам пользователей , их быстрая и несложная модификация (например , установка "праздничного тарифа " когда "народное гулянье " выпадает на середину недели ); · Возмость удаленного администрирования пользователей P . S . В выше изложенном тексте применяются некоторые профессиональные термины относящиеся к различным клонам Unix систем , а такж е к общесистемному профессиональному ПО такие как :( демон , Apache , pppd, домашний каталог пользователя , ядро , с ервер биллинга , лог-файл , пол ьзователь , www -интерфейс , SQL и т.д .), которые нуждаются в дополнительных комментариях . Опи сания данных терминов можно сравнить с по лноценным книжным изданием , вследствие чего о но здесь не присутствует . Короткие пояснения можно получить у составителя данно й курсовой работы. 1.3. Организационно-экономическая сущность зада чи. Использование данного комплекса программного обеспечения позволит небольшому интерне-провайде ру значительно снизить себестоимость услуг по коммутационному подключению своих абонентов , а также предоставить им удобную систе му тарифных планов , тестовых подключений , сист ему анализа и мониторинга собственных счетов и статистики подключений , что естественно способствует росту клиентской базы и увели чению прибыли нашего ISP . Также стоит отмет ить , что основная экономия средств происходит за счет испо льзования абсолютно бесплатного программного обе спечения , а именно операционной системы FreeBSD и системы уч ета « Billing ISP » , которые ра спространяются с открытым исходном кодом по лицензии GNU и не имеют ограничений на число к опий и т.д . Наличие исходного кода данных продуктов дает возможность адаптации их под уже существующие бухгалтерские программы и системы учета . Также значительная экономия происходит за счет небольшого числа техн ического персо н ала обслуживающего дан ную систему . По персоналу можно отметить , что управлять данной системой могут специалис ты низкой квалификации , т.е . именно система « BillinISP » не требует углубленного знания Unix подобных опирационных сис тем , сетевых технологий и слож ного сет евого оборудования такого как CI S CO, из чего следует , что з /п такого работника будет относительно не велика . В тоже время средняя з /п сертифицированного специалиста колеблется от 500$-1500$. Естественно , что для поддержки системы в актуальном состо янии такие работники необходимы , но за счет применения данной схемы их число можно значительно уменьшить без потери качества обслуживания клиентов . Для справки некоторые коммерческие операц ионные системы могут достигать стоимости 5000$, пр и это с ограниче нным числом установок и с ограниченным числом пользователей пл юс к этому около 2000-3000$ может стоить какая ни будь посредственная биллинговая система. Из всего выше сказанного видно , что при применении данного программного обеспечени я интернет-провайдер ы получают существенную выгоду. 2. Разработка информ ационного обеспечения задачи. 2.1. Описание входной информации. Основным входным документом , с которым взаимодействует рассматриваемая биллинговая систем а это копия платежного поручения пользователя I SP . Пр и регистрации клиента провайдер предлагает ем у выбрать установленный тариф (прайс-лист ) на услуги коммутируемого подключения на определен ное (тарифом ) время , по которому клиент буд ет перечислять установленную денежную сумму . После регистрации и предо платы услуг нашего ISP на счет (в домашний каталог пользователя копир уются определенный набор файлов см . ниже ) пользователя поступает определенная прайс-листом сумма , которая в процессе работы пользователя в интернете уменьшается через определенный тарифом (прайс-листом ) квант на определе нную сумму . Соответственно все , что делает одна часть программы биллинга другая ее ч асть фиксирует все в базе данных и в том же личном каталоге пользователя в отдельный лог-файл на основании , которого и генерируются отчеты пользователю и администратору . Также к входной информации можно отнести : отчисления с пользовательского счета , проведенное время в интернете , время подключения (регистрации в системе ). На осно вании изложенной выше информации вспомогательный модуль програм м ы билинга может предоставлять подробную статистикуего счета по льзователя , как администратору так и самому клиенту ISP . Файл задания прайс-листа (тарифной схемы ) - account.conf # # # Пример файла account.conf (.account.conf). # Лидирующие пробелы, пустые строки, # строки, начинающиеся с символа "#" игнорируются. # Обрабатываются лишь строки, начинающиеся с ключевого # слова "price:". Количество строк "price" неограченно. # Формат прайс-листа (тарифной схемы) - # price: День_недели, час_начала-час_окончания $стоимость_в_у.е. # что соответствует промежутку времени # час_начала:00-час_окончания:59 # Если при указании временные диапазоны пересекаются, то стоимость # часа принимается последняя. # Основная тарифная схема. # Цена: в будние дни с 10:00-18:00 - $1 # в остальное время - $0,6 # # comment: Поле_comment_будет_автоматически_выводиться_при_запуске comment: демома_в_режиме_получения_сведений_о_размере_лицевого comment: счета_пользователя._Удобно_использовать_для_задания_комментарий comment: к _ прайс _ листу . commenth: 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 , .w eekly и .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 (см . выш е ), но только для авансового платежа. 2.2. Описание в ыходных документов. В результате работы биллинговой программы вся информация о работе пользова тель , как было сказано выше , фиксируется в лог-файлах и базе данных . Это является основным базисом для генерации отчетов и статистики . Извлекаемые данные могут быть п редс тавлены в качестве структурированных таблиц , либо в форме отчетов по запрашивае мым данным . Данная информация , также является подтверждением того , что пользователь работа л в сети на случай претензий последнего. Список информации - данных , которые предлаг ают ся пользователю и системному администр атору (биллинг-инженеру ): 1. Время регистрации пользователя в конкретный день 2. Оставшаяся сумма на счету у пользователя 3. Время , проведенное в сети 4. Статистика работы в сети по дням , неделям и месяцам 5. Почтовое уведомле ние пользователя и администратора об истечени и денежного взноса. 6. Общая структурированна я таблица статистики за определенный период времени При генерации выше указанной информации используются дополнительные модули программы « Billing ISP » и сист емные программы Unix такие как , CGI - модули (для обращения к базам д анных и генерации HTML кода и форм или писем ), Apache web server (для вывода на экран HTML кода сгенерирован ного CGI програ ммой ), MTA Sendmail (для отправки электронного письма пол ьзовател ю об окончании счета ). 3. Описа ние технологии и алгоритмов решения задачи и их машинная реализация. 3.1. Описание ввода в базу данных в ходной информации. Отличительная черта рассматриваемой программ ы от других вариантов данной курсовой раб оты , является полностью ароматическая генера ция и занесение в базу данных информации за исключением создания самих счетов пол ьзователей . Это определяется в основном специ фикой данного программного продукта и операци онной среды , в которой он работает. Алгоритм начисле ния условных единиц на лицевой счет пользователя 1. Если файл .pay в домашнем каталоге пользоват еля отсутствует , то занести размер платежа в файл .pay , а индекс прайс-листа в файл .account . Переход к пункту 3; 2. Вычислить текущий размер лицевого счета по льзователя . Если он отрицателен или равен нулю , то очередной платеж з аносится в файл .pay , а выбранный индекс прайс-лист в файл .account . Если текущий размер лицевого счета пользов ателя положителен , то очередной платеж заноси тся в файл .pay.next , а выбранн ый индекс прайс-листа в файл .account.next ; 3. Обновить файл .current с текущим размером лицевого счета ; 4. Занести платеж в таблицу "ПЛАТЕЖИ " базы данных (опционально ). Алгоритм фикса ции в базе статистической информации Введение. Рассматриваемый про граммный продукт н апрямую зависит от системных вызовов операцио нной среды , в которой он работает , а та кже и от некоторых приложений , например PPPD (название это го демона происходит от названия протокола соединения пользователя и провайдера Point to Point P rotocol ), syslog (системная программа , которая фиксирует пребывание пользователя в системе , а также фиксирует в лог-файлы сообщения ядра ОС ). В связ и с тем , что описания данных продуктов это тема отдельной курсовой работы , данный алгоритм будет описан пове рхностно. 1. При соединении пользователя к провайдеру запускается программа Mgetty , которая управляе т и инициализирует работу модема . Запуск д анной програмы фиксируется в системных лог-фа йлах системы . После ее запуска она активиз ирует , в нашем случаи демон PPPD , который в сво ю очередь принемает и регистрирует пользовате льские запросы и после проверки всего нео бходимого впускает или нет в систему . Все действия данных сервисов после соединения отслеживает программа syslog , которая и генерирует основную б азу д ействий пользователя в системе. 2. Billing ISP , как уже говорилось выше напряму ю взаимодействует с PPPD проверяя актуальность данного подкл ючения и в случаи удачного входа изменяет (уменьшает ) за определенный квант времени счет пользователя. 3. Также демон б иллинга с момента соединения пользователя нач инает вести подсчет времени пребывания пользо вателя с соответствующим изменением в SQL базе полей. 3.2. Обобщенный алгор итм решения задачи. Ядром предлага емой системы является специально написанный д емон " биллинга " (в дальнейшем просто демо н ), осуществляющий контроль за израсходованнным временем и /или условными единицами пользов ателя , находящегося в данный момент в режи ме "он-лайн ". Демон запускается в момент вхо да пользователя в систему , по истечении од но г о кванта времени (например , 5 сек унд ) снимает с лицевого счета пользователя стоимость одного кванта в соответствии с действующей в данный момент ценой , которая , кстати , может меняться в зависимости от времени суток , а после завершения сеанса связи демон п р екращает свою работу , протоколируя информацию о продолжительнос ти сеанса связи и отработанной стоимости в специальный лог-файл в домашнем каталоге пользователя и , при необходимости , в общую SQL-базу данных . Другими словами , отдельная копия демона постоянн о присутствует в памяти сервера биллинга и "следит " за пользователем на протяжении всего сеанса связи . Информация о начислениях на лицевой счет пользователя и снятия с лицевого счета за фактически отработанное "он-лайновое " время (так называемая "биллингов а я информация ") хранится в домашних каталогах пользователей в обычных текстовых файлах . Т. е . для каждого пользователя создается свой набор файлов с биллинговой информацией . Соо тветственно , вычисление размера лицевого счета пользователя происходит на основа н ии содержимого этих файлов . Такое распределен ное хранение биллинговой информации по каждом у пользователю обеспечивает простоту построения системы , а значит надежность , и предостав ляет возможность организации несложной системы доступа к лицевым счетам чере з www-интерфейс . В тоже время , такая же инфор мация , но немного в другом виде хранится в SQL-базе , однако она используется исключит ельно для генерации статистической информации предоставляемой системному администратору. 3.3. Алгоритм выполне ния отдельных мо дулей. Алгоритм вычислен ия лицевого счета при входе пользователя в систему Данный алгоритм должна реализовывать прог рамма , выполняющая аутентификацию пользователя (TACACS+ или pppd) на этапе подключения его к Интернет у . В этот случае основную роль должен играть файл .current , который содержит уже вычисленное значение размера лицевого счета , т.к . в данный момент размер лицевого счета должен быть получен практически мгновенно . 1. Если файл .refused присутствуе т в домашнем каталоге пользователя , то тек ущий размер лицевого счета принимается отрицательным . Переход к пункту 5; 2. Если файл .time присутствует в домашнем катал оге пользователя , то текущий размер лицевого счета принимается положительным . Переход к пункту 5; 3. Если файл .current присутствует в до машнем каталоге пользователя , то из него берется текущий размер лицевого сче та (файл .current обновляется каждый раз после завершени я работы демона ). Переход к пункту 5; 4. Текущий размер лиц евого счета вычисляется по формуле : "общая сумма начислений из файла .pay минус общая с умма отчислений из файла .work минус общая сумма отчислений из файла .weekly "; 5. Если текущий размер лицевого сче та положителен , доступ в систему пользователю разрешатеся , в противном случае - запрещается. Алгоритм выбора прайс-ли ста (тарифной схемы ) для пользователя при старте демона · Если в домашнем каталоге пользов ателя находится файл .account.conf , то прайс-лист для данного пользователя читается из этого файла ; · Если в домашнем каталоге пользователя присутсвует файл .account , то из него читается первая строчка , которая добавляется в слову account , к полученной строке добавляется расшир ение .conf , и , таким образом файл c прайс-листом с полученн ым именем читается из каталога /var/statserv/etc ; · Если файлы .account.conf и .acc ount отсутствуют в домашнем каталоге пользователя , то прайс-л ист для данного пользователя читается из файла /var/statserv/etc/account.conf (прайс-лист по умолчанию ) Действия , выполняе мые демоном при старте · Анализирует командную строку . В качестве перв ого параметра ему передается имя пользователя , в качестве второго - NAS-по рт (или устройство , например , /dev/cuaa2), в качестве третьего - адрес NAS-сервера (третий параметр н ужен только в том случае когда у пров айдера более одного NAS'a); · Выбирает прай с-л ист (тарифную схему ) для пользователя (см . "Алгоритм выб ора прайс-листа для пользователя при старте демона " ); · Проверяет присутствие в домашнем каталоге файла .time , если он там есть - взв одит соответствующий флажок в пе ременную us.unoff=1; · Проверяет присутствие в домашнем каталоге файла .refused , если он там есть - взводит соответствующий флажок в переменную us.refused=1; · Вычисляет значение лицевого счета пользователя (см . пункт 4 "Алгоритма вычисления лицевого счета при входе пользо вателя в систему " ). Даже если размер лицевого счета отрицателен , демон все равно продолжит св ою работу , поскольку по истечении первого же кванта времени он , при необходимости , подаст сигнал на отключение этого пользо вателя ; · Демонизируется ;-); · Записывает свой PID в файл с именем NAS-порта в каталог /var/run (если у про вайдера больше одного NAS'a - то необходимо модифиц ировать демон , ч тобы избежать конфликтов в каталоге /var/run между NAS'ами ); · Программирует собственн ый таймер на заданный квант времени и входит в бесконечный цикл , вывести из к оторого может только SIGHUP. Действия , выполняе мые демоном при истечении одного кванта в рем ени 1. Обновить счетчик (в секундах ) про должительности текущего соединения , в соответстви и с действующим тарифом вычислить стоимость одного кванта времени , обновить переменную в которой накапливается стоимость текущей сессии ; 2. Проверить , присутствует ли поль зователь все еще в системе - просмотреть ф айл /var/run/utmp . Ес ли пользователя в системе нет , то вызвать процедуру , выполняемую при завершении сессии ; 3. Если пользователь не исч ерпал свой лицевой счет , то ждать истечение следующего кванта времени . В противном случае описанные ниже действия возникают при исчерпывании средств на лице вом счете : 4. Проверить , является ли этот пользовать "привелегированным ". Для этого посмотреть на ф лажок us.unoff . Если us.unoff==1 , то ждать ист ечение следующего кванта времени ; 5. Проверить , была ли вызвана программа /var/statserv/bin/killuser , если да - то ждать истеч ение следующего кванта времени . Дело в том , что из-за особенностей построения некот орых систем аутентификации , при исчерпыва нии средств на лицевом счете , фактически п ользователь отключается не сразу после вызова программы /var/statserv/bin/killuser , а через некоторый интервал време ни ; 6. Если файл .pay.next отсутствует в домашнем катало ге пользователя , значит , пользователя необходимо принудительно отключить . Переход к пункту 9; 7. Прочитать сумму из файла .pay.next . Переписать ее в файл .pay . Удалить файл .pay.next . Вычислить текущий р азмер лицевого счета пользователя . Если он отрицател ен , то переход к пункту 9; 8. Перечитать новый п райс-лист из файла .account.next . Удалить файл .account.conf , если он присутствует . П ереименовать файл .account.next в файл .account и ждать истечение следующего кванта времени . 9. Вызвать программу /var/statserv/bin/killuser с параметрами имя _пользователя и NAS-порт , которая пошлет сигнал на отключение пользователя ; Действия , выполняе мые демоном при завершении сессии При завершении сессии сервер аутентификации TACACS (или pppd) читает PID демона из каталога /var/run/ и посылает ему SIGHUP (возможен , также другой вариант , когда демон постоянно сканирует файл utmp и выполняет ниже описанные действия , если пользователь "изчез " из файла utmp ). Демон удаляет файл со своим PID-ом из /var/run/ , записывает сведения о только что завершенной сессии в файл .weekly , обновляет файл .current с текущим размер ом лицевого счета пользователя и вызывает скрипт /var/statserv/bin/close_session . с параметрами имя _пользователя , NAS-port, продолжительност ь _сессии , стоимость _сессии. 4. Контрольный прим ер. Описание использо вания демона биллинга Описание использования демона бил линга Демон billing является ядром предлагаемой систе мы учета пользователей для ISP. Он может рабо тать в двух режимах - в "основном " режиме (т.е . р ежиме демона ) для контроля лиц евого счета пользователя в реальном масштабе времени и в "вспомогательном " режиме выда чи сведений о размере лицевого счета поль зователя или контроля правильности задания та рифной схемы . Ниже приведены все возможные ключи запу с ка и параметры кома ндной строки : /var/statserv/bin/billing Usage error: billing [-vdeashtpPrRwW] [username] [port] [nas] -v show version and exit -d daemonize billing -e increase debug level in daemonize mode -a show current price -c show current account for sysadmin -s show current account -h show current account in HTML format -t total user account -p show pay -P show pay history -n show pay.next -N show pay.next history -r show work -R show work history -w show weekly -W show weekly history Режим демона - запуск с ключом -d. Далее следуют обязательные параметры - имя пользователя , NAS-порт (порт модема ) и имя NAS- сервера (если NAS-сервер у ISP один , то этот параметр вы бирается произвольно , однако с овсем опускать его нельзя ). Пример : /var/statserv/bin/billing -d jackson Async2 access.provider.net Режим выдачи сведений о разме ре лицевого счета пользователя - запуск с ключом -s и единственным параметром - именем пол ьзоват еля . Пример : /var/statserv/bin/billing -s jackson В данном варианте на стандарт ный вывод ничего не выводится , а "знак " лицевого счета отражается в коде возврата . Если размер лицевого счета больше либо равен нулю , т.е . доступ пользователю в си стему разреше н , то billing возвращает число 0, если меньше нуля , т.е . доступ пользователю в систему ограничен , то billing возвращает число 1. /var/statserv/bin/billing -st jackson На стандартный вывод выводится общий размер лицевого счета пользователя в plain text. См. п .4 алгоритма вычисления размера лицевого счета пользователя /var/statserv/bin/billing -spt jackson На стандартный вывод выводится общий размер начислений на лицевой счет пользователя и его общий размер в plain text. А лгоритм вычисления лицевого счета то т же самый . Ключ -P задает вывод истории на числений . /var/statserv/bin/billing -c jackson Соответствует вызову /var/statserv/bin/billing -stpnrw jackson т.е . наиболее "употребительному " ис пользованию billing с точки зрения системного админ истратора . Вызо в billing с ключом -h, например /var/statserv/bin/billing -shtpnrw jackson выводит информацию о лицевом счете пользователя в HTML-формате для того , ч тобы ее можно было предоставлять пользователю через www-интерфейс ; Режим проверки алгоритма выбора прайс- листа для пользователя . Вызов : /var/statserv/bin/billing -a jackson Предназначен исключительно для с истемного администратора чтобы контролировать пр авильность задания тарифной схемы для данного пользователя .
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Уважаемые власти Грузии! Уточните, пожалуйста, размер премиальных за информацию о месте нахождения Саакашвили, я, кажется, знаю где он.
© KONDEXIII
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, курсовая по компьютерным сетям "Проект учета пользовательских счетов для интернет-провайдеров на базе OS FreeBSD с применением программы "Billing ISP"", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru