The Russian Electronic Developer Magazine
	Русский электронный журнал разработчика

Применение OS/2 в пейджинговой связи.

Однако технические решения это далеко еще не все. Подготовка сообщения к отправке осуществляется програмным комплексом. Здесь важно не ошибиться при выборе программных продуктов, поскольку от их требовательности к ресурсам зависит стоимость необходимого аппаратного обеспечения. А способность безболезненно вынести возросшую нагрузку убережет от неприятных сбоев, возникающих при увеличении числа абонентов в несколько раз от первоначального.

Какая же операционная система наиболее оптимальна для развертывания узла пейджинговой связи? Для начала определимся, какие основные блоки необходимы для решения задачи отправки пейджингового сообщения в эфир. Это:

1. Пейджинговый кодер. Кодирует сообщение согласно используемому протоколу передачи (Flex, Pocsag и др.). Чаще всего представляет из себя аппаратный комплекс, но встречаются и программные реализации, требующие работы операционной системы в реальном времени и чаще всего отдельного компьютера. Дело в том, что стандарт передачи пейджинговых сообщений накладывает жесткие ограничения на стабильность фронтов сигнала. Отход от стандарта снижает дальность уверенного приема сообщений, повышает вероятность ошибки, снижает надежность приема в условиях помех. Кодер должен обладать высокой надежностью. Требования к интерфейсу - минимальны. К стабильности работы - максимальны.

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

3. Рабочие места операторов. Позволяют операторам ввести принятое сообщение в систему и поддерживать дополнительные сервисы, как то отправка сообщений из архива, пароль на отправку и некоторые другие. Здесь на первое место выходит понятный графический интерфейс. Также важна скорость работы. А вот надежность этого блока в крупной компании не столь важна , поскольку в реальности рабочих мест оператора обычно больше, нежели самих операторов. К тому же ожидать сверхвысокой надежности от программы, ориентированной на диалоговую работу с таким ненадежным элементом как человек довольно сложно. В небольшой же компании, где 2-3 рабочих места, выход из строя хотя бы одного их них серьезно влияет на пропускную способность.

4. Роботы. Служат для реализации дополнительных сервисов, как то роуминг, прием сообщений по e-mail, с веб-страницы, тоновый набор, голосовая почта и др. Основные требования этой категории - надежность и малая ресурсоемкость. В реальной работе любой пейджинговый оператор стремится к тому, чтобы один раз настроить всех роботов и больше к ним не возвращаться.

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

В небольших системах (до 150 абонентов) для решения задач 2,3 и 4, а иногда и 1-ой группы применяется один компьютер. Это значительно удешевляет систему, но практически не дает возможности для развития. Поэтому такие решения очень редко встречаются на практике. Обычно пейджинговый узел состоит из:

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

2. Выделенного пейджингового сервера. Максимальная производительность, минимальное время отклика системы. Можно принять меры для повышения надежности серверного компьютера. Самая, на мой взгляд, серьезная ошибка здесь может произойти в случае попытки объединить на одном процессоре кодер и сервер. В этом случае либо при увеличении нагрузки не хватит ресурсов серверу, либо будет крайне нестабильный сигнал. Но скорее всего проявятся обе проблемы.

3. От 2-х до 50 рабочих мест оператора. Большее число мест, позволяет принять в единицу времени больше сообщений, но скорость передачи в эфир ограничена протоколом, структурой построения системы и эффективностью работы кодера.

4. Нескольких роботов. Которые могут быть установлены на одном компьютере.

Какую же операционную систему лучше использовать для эффективной и безотказной работы? Мне встречались реализации пейджинговых центров под операционными системами DOS, OS/2, Windows 3.11, Windows 95, Windows NT 4.0, Nowell Netware 3.12, QNX.

OS/2 подходит по многим параметрам:

1. Это сетевая операционная система и, следовательно, не придется ничего придумывать дополнительного, чтобы увязать между собой компоненты пейджингового узла. Этот пункт самый проигрышный у систем под DOS, которые, как правило, требуют для работы организации любой одноранговой сети сторонними средствами, например Personal Netware или той же OS/2.

2. Это система которая поддерживает, кроме родных приложений, выполнение программ, написанных под DOS и Windows 3.11. Здесь самая больная точка для систем построенных исключительно на средствах Nowell Netware. Мне не известны эмуляторы других сред для Nowell.

3. И при этом обладает гораздо большей надежностью в автопилотном режиме. А это камень в огород продуктов Microsoft. Ни одна из многочисленных операционных систем, представленных этой фирмой (исключая DOS) не выдерживают испытание непрерывным рабочим циклом, который необходим пейджинговому узлу.

4. Легкая интеграция в Internet.
   Здесь в последнее время у всех современных операционных систем произошел качественный скачок. Исключая разве что DOS, как принципиально не сетевую.

5. И при этом высокая степень защищенности от взлома.
   Если очень постараться можно сломать все. Ломать - не строить, но чтобы остановить некоторые системы даже и стараться не надо. Microsoft и здесь отличился не в лучшую сторону. Вспомните знаменитые ошибки, позволяющие остановить систему дистанционно через Internet! А кто даст гарантию, что латая старые дыры не протираются новые?

6. Это доступная и понятная система с мощным графическим интерфейсом, необходимым для операторских мест. Слабое место DOS, многократно затрудняющее разработку качественного графического программного обеспечения по эту систему. Впрочем, то же самое можно сказать и о ранних версиях Nowell Netware.

7. Который можно отключить на сервере и роботах, где его наличие только расходует ресурсы компьютера. Попробуйте отключить графический интерфейс у Windows 95! И как вам это?

8. Интегрированная поддержка национальных языков.
   Да, русификаторы есть у многих систем, но встроенная поддержка - далеко не у всех.

9. Наконец найти и обучить специалистов для пользования и администрирования OS/2 системы не составит труда. Здесь самое слабое место у QNX и других Unix клонов. Разобраться в системе с нуля способен далеко не каждый, особенно на периферии, где информации очень мало, тем более на русском языке. Опыт показывает, что неподготовленному человеку гораздо легче установить и приемлемо настроить OS/2, нежели Unix.

Конечно не все так безоблачно, есть и один недостаток: OS/2 не является системой реального времени и реализовать кодер только программно на ней скорее всего не удастся. Однако этот недостаток в той или иной мере присущ всем операционным системам, исключая разве что QNX и MSDOS 5.0. Во всяком случае, про эти системы мне известно о прохождении ими тестов. Windows NT, вопреки заверениям разработчиков, также не является системой реального времени. И как показывают результаты опытов и цифры приведенные независимыми разработчиками программного обеспечения, кодер с допустимой стабильностью фронтов реализовать под Windows NT невозможно. Справедливости ради нужно отметить, что современные процессоры нивелируют этот недостаток снижая _среднюю_ погрешность, однако пиковые отклонения могут привести к срыву приема сигнала. Таким образом увеличивается процент отказов всей системы. Да и использование процессора Pentium III в качестве тактового генератора... Так ли это необходимо? Может стоит поискать другое решение?

Тем не менее OS/2 постоянно развивается и совершенствуется, да и программисты времени зря не теряют. Возможно, в скором времени, появится решение и для этой задачи. Скорее всего это будет программно-аппаратный комплекс с независимым высокостабильным (кварцевым) задающим генератором.

Чтобы подвести итог написанному, я хочу предложить некоторые свои наработки программного обеспечения для операционной системы OS/2 для пейджинговых станций и их клиентов.

Известно, что в данный момент стремительно развивается интеграция пейджинга и глобальной сети Internet. Протоколом отправки пейджинговых сообщений стал Simple Network Paging Protocol(SNPP), предложенный Алланом Гвином для стандартизации управления пейджинговым оборудованием.

Иначе говоря, пользуясь SNPP, вы можете передавать сообщения на пейджеры. Один из вариантов использования - организация роуминга между пейджинг-центрами городов, вещающими на одной частоте. Другой вариант - канал альтернативного доступа к системе отправки сообщений, например, для автоматического оповещения или от выносных терминалов и даже отдельных пользователей.

SNPP представляет собой диалоговый протокол типа клиент-сервер, построенный на командах, состоящих из четырех значащих символов, и трехзначных цифровых ответах. Идея заимствована из более широко распространенного протокола отправки электронной почты - SMTP. Вместе с тем, учитывая специфику пейджинга, команды переработаны для большей эффективности. Этому протоколу отведен стандартный порт - 444. Таким образом, имея возможность зайти Telnet-ом на 444 порт компьютера, вы должны получить стандартное приглашение SNPP.

Протокол предусматривает возможность расширения как системы команд, так и развитие системы ответов. В последнее время появились дополнительные команды работы с национальными кодовыми страницами и расширились возможности управления системой.

Вот примеры реализации клиентской и серверной частей SNPP для OS/2:

snppd.zip

SNPP-daemon. Этот сервер позволяет организовать прием сообщений по протоколу SNPP версии 2 (RFC1645). И может быть использован любым оператором или субоператором пейджинговой связи для построения приемного SNPP узла и/или организации роуминга(приемная часть).

Возможности:

• Поддержка SNPP версий 1 и 2;

• Cкорость обработки (версия 1.07):
  до 1660 сообщений в минуту без запуска cmd-файла,
  до 510 сообщений в минуту с запуском cmd-файла
  (тестировалось на PII-233 по loopback);

• Идентификация отправителя по Login/Password/IP-address в любых сочетаниях, в том числе и без логина и пароля, только по IP-адресу;

• Собственная высокопроизводительная база данных (отключаемая);

• Возможность обращения за информацией о пейджере в базу данных вашей пейджинговой системы;

• Индивидуальный пароль (PIN) на отправку сообщения через SNPP;

• Индивидуальная активация сервиса SNPP для каждого номера;

• Псевдонимы (Алиасы), на один номер их может быть неограниченное количество;

• Алфавитно-цифровые номера пейджеров и псевдонимы;

• Поддержка национальных кодовых страниц;

• Возможность запуска при приеме сообщения cmd-файла или OS/2 приложения в отдельной сесии;

• Возможность дистанционного администрирования системы (отключаемая);

• Ведение файла протокола с трехуровневой детализацией;

• Автоматическая перезагрузка программы при возникновении в ней критических ошибок;

• Легкая интеграция в существующую пейджинговую систему;

snppsend.zip

DLL с примером использования (Pascal), позволяющая отправлять сообщения на SNPP сервер версий 1 и 2. Возможен вызов из программ автоматического слежения за параметрами при возникновении критических ситуаций для отправки оповещения на пейджер. Также на основе этой библиотеки можно построить отправляющую часть роуминговой системы.

snpprexx.zip

REXX-скрипт, позволяющий отправлять сообщения на SNPP сервер версии 1. Простой и понятный пример клиентской части. Может быть использован для передачи небольших (до 75 символов) сообщений.

Несмотря на появление SNPP, многие пейджинговые компании продолжают использовать для своих нужд протоколы почтовой связи такие как SMTP и РОР3. В данный момент я заканчиваю написание и отладку программного продукта, который позволит реализовать большинство сервисов, доступных пейджинговому оператору, через электронную почту. Прежде всего это роуминг на несколько направлений в стандартах RadioPage и VessoLink. А также отправка e-mail сообщений на пейджер с поддержкой base64 и html почтовых стандартов и многочисленных кодировок русского языка; отправка сообщений через web-страницу и, наконец, просто обслуживание почтового ящика компании. Некоммерческая OS/2 версия этой программы будет также свободно доступна для всех желающих.

Игорь Васьков 30.08.1999

Интересные ссылки: Подробности услуги юриста адвокат у нас на сайте.

Комментариев к странице: 0 | Добавить комментарий

Редактор: Дмитрий Бан
Оформление: Евгений Кулешов