RDM/2 The Russian Electronic Developer Magazine  
RDM/2 Русский электронный журнал разработчика  
ДомойОт редактораПишите намОбратная связьRU/2

Опыт использования OS/2 в реальной жизни.

Шраго Иосиф

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

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

Второе. Надо было реализовать транспорт сообщений из компьютера в пейджинговую аппаратуру. Для этого в комплект оборудования пейджинговых систем входят пейджинговые терминалы PET использующие протокол TAP(Telocator Alpha-numeric Protocol), который иногда еще называется IXO. Все стандартные программы позволяющие передавать сообщения на пейджеры по телефону с помощью модема пользуются именно этим протоколом. Демон TAP я написал на Си (я почти все пишу на нем) с использованием возможностей multithread'а в OS/2. Одна нитка обслуживает именованный многоканальный pipe приема сообщений и ставит их в очередь, другая - разбирает очередь и поддерживает протокольную передачу данных. Команды управления также могут передаваться через pipe для сообщений. Обмен с COM-портом реализован на уровне IOCTL и DosRead/Write. При постановке в очередь сообщение кодируется согласно типу пейджера (они имеют разные таблицы кодирования кирилицы) и в этом вопросе принятая схема хранения данных в виде файлов, начинает скрипеть, т.к. одно дело проверить наличие файла, а другое - считать из него описание пейджера. Актуальность проблемы была занижена тем, что по схеме нумерации пейджеров принятой в компании можно было таблицу кодировки вычислить, чем я и воспользовался на первых порах.

Третье (еще не десерт, но уже шлюз), что сразу приходит в голову при реализации шлюза - это организация стыковки электронной почты с пейджингом, т.е. возможность отправлять письма по адресу nomer_pagera@operator.domain. Документации у меня тогда не было, поэтому я не особо задумываясь направил поток подобных писем на осевой копьютер под Warp 3, запустил на нем родной sendmail как сервер и скриптом на REXX стал разгребать образовавшуюся очередь. Все получилось весьма просто, правда потом, я обратил внимание на растущий файл сообщений об ошибках при попытке запуска mail'ера (umail я стер сразу-же как убедился в ее неспособности поддерживать кирилицу). Да оно оказалось и к лучшему, т.к. вводить в ULTIMAIL тысячи пользователей этого шлюза мне бы точно не захотелось. Наличие этого файла меня не очень озаботило, т.к. его рост не сопровождался письмами о несуществующем пользователе и я все оставил как есть. Про опции -bd -odq я теперь знаю, но их не знает варповская sendmail :(.

Скрипт на rexx разгребает файлы в каталоге /MPTN/ETC/MAIL выделял заголовки To:, вырезал из них номер пейджера а из тела письма формировал текст послания перекодируя его из кои8 в CP866 и удаляя все форматообразующие знаки, т.к. пейджер их не поддерживает. Кроме того, текст послания обрезался до 960 символов, так-как этого требует протокол. К сожалению констатирую, что есть, есть среди нас любители отправлять по почте на пейджеры всякие Advertising и прочий СПАМ в формате MS Word размером в мегабайты. А ведь пейджинг, он не Интернет - редкое сообщение в нем летит со скоростью превышающей 1200 бит/сек :(. Сформированное послание пишется в вышеупомянутый pipe демону TAP и далее идет в эфир. При успешной передаче в pipe сообщение регистрируется в файле соответствующего пейджера. Этот же скрипт проверяет факт начала нового месяца и производит архивационные работы: создает архивный каталог и копирует в него все накопленное за месяц, очищает файлы пользователей и запускает простой скрипт билинга, подсчитывающего сколько сообщений и какого объема на каждый пейджер было послано. Все. Некоторые операторы предоставляют возможность управлять датой и временем отправки сообщения командами в поле subject: или теле письма, но, т.к. эта услуга чревата ошибками в вычислении разницы во времени, а также злоумышленных действий, я ее не реализовал и не буду, зато компенсировал интерпретацию поля subject: аналогично полю Cc: в почтовом протоколе.

Второй канал по которому из Интернет могут приходить сообщения на пейджер - это странички веб-серверов. Опираясь на ранее сделанное, реализовать такой шлюз было не сложно. Простая HTML-страничка для ввода номера пейджера, текста послания и явно указанный признак кодировки отправляемого сообщения (для самых криво сконфигурированных броузеров) была положена на главный веб-сервер компании, котрый работает под FreeBSD и Apache. На компьютере пейджингового шлюза был запущен IBM ICS 4.12 и написан CGI-скрипт на rexx, который проверяет наличие пейджера, перекодирует текст передаваемого сообщения в CP866 и далее все аналогично почтовому шлюзу. Следует заметить, что при создании REXX-CGI скриптов я активно использую библиотечку rgiserv, которая мне показалась пошустрее интерфейса от IBM и удобнее.

Третий канал передачи сообщений - SNPP (Simple Network Paging Protocol - RFC1861), о котором я узнал случайно, но, который активно уже использовался пейджинговыми компаниями, в Томске, Новосибирске, Красноярске и, что интересно, не в Москве и не в Санкт-Петербурге. Для организации поддержки SNPP пришлось написать сервер (это был мой первый опус в TCP/IP). Сервер с точки зрения взаимодействия с пейджингом опирается на все выше описанное. С внешней стороны, он занят тем, что крутит нитку прослушивания сокета и устанавки соединения с клиентом. Для каждого соединения запускается своя нитка обмена про протоколу и отправки сообщений. Дополнительно крутится нитка опроса флагов управления для выполнения общих для всех нитей команд, типа остановки сервера. Протокол SNPP расширен несколькими командами управления и вывода статистики. При использовании этого сервера стали проявляться недостатки. Самым крупным из которых была блокировка файла при попытке регистрации сразу несколькими нитями. Для борьбы с этой коллизией я применил метод отката, но из-за крупности time slice в OS/2 (32msec) он не очень-то помог. В результате, пришлось написать независимую систему регистрации событий типа syslog, которая реализует следующие возможности:

Здесь вы найдете пример SNPP клиента на REXX (snpp.cmd). В особых комментариях он не нуждается, но может послужить неплохим примером работы с TCP/IP на REXX.

Тестировал я эту систему (ну и сервер тоже) посредством одновременной отправки на него из сети около 1000 сообщений подряд вызовом в цикле FreeBSD shell клиента SNPP на perl. Сервер SNPP работал с производительностью - 500 с хвостиком соединений в минуту, а подсистема регистрации событий за то-же время открыла записала и закрыла 4000 файлов. Для пейджинга это более чем достаточно - эквивалентно работе 500 операторов по обслуживанию 200 000 абонентов.

Вот такая система работает в нашей компании с 1996 года. Это ее костяк. Uptime на момент написания этой статьи - 110 суток. Средняя нагрузка не превышает 6%, только раз в месяц при архивации и билинге она поднимается до 50% на пару минут для чистки, копирования и анализа свыше 1500 файлов.

На базе этого костяка удалось запустить дополнительные сервисы:

Какие OS-зависимые неприятности у меня были в процессе эксплуатации. Однажды грохнулся ICS и ни при каких обстоятельствах не захотел работать дальше, а работать шлюз должен всегда :(. Был свободный компьютер, но уже под Мерлином. Думал - перекину все и запущу. Как бы не так! Сначала пришлось расхлебывать отсутствие в Мерлине букв "p" и "H" в их извращенном варповском виде. Ну это мелочи. Главное началось с того, что sendmail вместо честного сваливания всей почты в очередь, всю ее посылал обратно по причине отсутствия пользователя с именем - номер пейджера. Все мои попытки это сломать не увенчались успехом. Позже мне объяснили, что дело не в юзере а в цифровом его имени, которое эта (а также ее берклиевский прототип) версия sendmail на дух не переносит (в sendmail от TCPIP 4.1 это исправлено). Пришлось запустить варповский Sendmail. Он заработал, но приобрел дурацкую манеру - при формировании реального адреса получателя квитка о приходе -Return-Receipt к нему зачем-то многажды прибавлялся мой домен, что приводило почтовый сервер под FreeBSD в состояние ступора - sendmail падал в core dump и очередь не разбиралась. Вылечилось только заменой куска правил разбора sendmail.cf на аналогичный из фревого.

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

Развитие этой системы идет в следующем направлении:

Хорошо бы еще и Голосовой Почтовый ящик перетащить, но вроде под Vocaltech'овские платы нет осевых драйверов.

Если вдруг будут какие вопросы, то пишите joseph@fcn.ru
Если кого-то заинтересуют тексты программ связанных с пейджингом, клиенты snpp и прочее, то заходите на ftp://beit.fcn.ru/pub/paging.

24/12/1998, Шраго Иосиф

---
Интересные ссылки:

---

---
Комментариев к странице: 0 | Добавить комментарий
---
Редактор: Дмитрий Бан
Оформление: Евгений Кулешов


(C) Russian Underground/2