|
Возможно ли теоретически создать в рамках процесса, работающего со шлюзами ipn любого типа ( коммутатор, микротик, isg, manad ) работу со шлюзом типа "Abstract" ?
Дело в том что разработчики в процессе написания разного типа шлюзов, постоянно находятся в положении догоняющих поезд.
Им невозможно учесть весь спектр оборудования на доступе у провайдеров.
Да и провайдеры зажаты при выборе такого оборудования возможностями биллинга.
Но ведь созданием гипотетического, абстрактного шлюза, не зависимого от конкретного типа оборудования можно упростить этот процесс и провайдерам и разработчикам.
До БЖБ мы пользовались одной из ACP, которая могла в специальный файл в runtime сыпать строки в виде:
<Время события>
<блокировка/разблокировка интернета>
<идентификатор шлюза>
<идентификатор полосы пропускания>
<идентификатор клиента>
Дальше специальный процесс постоянно разбирал этот файл и управлял состоянием клиентов на десятке самых разнообразных устройств, от коммутатора и KN250 до RWR2002 и NSG502.
Переход на БЖБ конечно многое упростил , но приведение всех типов устройств на доступе к типам поддерживаемых шлюзов БЖБ далось не легко.
Я конечно понимаю, что идеология "конструктора в конструкторе" стимулирует админов становиться ещё и программистами на java. Но не всегда это оправдано.
Понимая ,что процесс в нашей старой ACP был без обратной связи, т.е. не учитывал текущее состояние клиента на шлюзе, мы научили её коннектиться по телнету на 127.0.0.1:8888 и при открытия tcp-соединения выпуливать всю эту информацию в виде потока символов аналогичных методу http get.
Задача проверки шлюзов коннектилась на 127.0.0.1:9999 и всасывала в себя поток состояния клиентов на шлюзе в том же ввиде.К нему правда прибавлялясь строка с содержимым
"NOOP", говорящая о том , что состояние клиента не известо,по какой-либо причине, но этот случай ACP обыгрывала сама по своей внутренней логике.
Что происходило после завершения обмена данными по телнету в недрах этого гипотетического шлюза - ACP совершенно не интересовало. И это было правильно.
Ответственность за бизнес логикой самого гипотетического шлюза ложилась на плечи сисадминов и состояла из кусков кода на bash-perl-fortran-expect...
c привлечением snmp,telnet,ssh, которые управляли десятками всяких железок. ACP вообще ни знала - каким оборудованием она управляла даже не всегда идентификаторы клиента были ип адресами.
Для неё шлюз был всегда один и единственный в системе -"Abstract"
Короче - если эта идея здравая с точки зрения разработчиков - прошу отнестить к ней с пониманием.Ведь можно задачу управления шлюзами ipn разбить на зоны ответственности. Задача БЖБ - "прителнетиться" и произвести обмен инфой в заранее оговорённом формате. Задача админов на стороне провайдера этот поток в первом случае переварить, во втором - сфомировать.
_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)
|
Вход
Регистрация
FAQ
Поиск
