С.Кадаков
sgerr@clubpro.spb.ru
SMS-приложение. Часть 4. Но не последняя... И ни в чем себе не отказывать...

Наконец-то (с заметным перерывом), нам удалось выпустить следующую статью цикла. Собственно, как мы и обещали, она содержит код простого, но работающего SMS приложения (для нетерпеливых: брать тут (см. заголовок ;) ).

Собственно, задержка обусловлена еще и тем, что мы достаточно долго решали, а насколько простым должно быть это приложение. С одной стороны, это не продукт, а нечто, что можно написать и отладить за пару дней и за столько же "разобрать" и осознать. Но, с другой, хотелось показать основные "подводные камни", с которыми приходится сталкиваться в реальных проектах. Как кажется, разумный компромисс найти удалось.

Архив (в формате tar) содержит исходные файлы на C++ (содержащие, надеемся, достаточные комментарии); файлы окружения (.dsw) и проекта (.dsp) для MS VC 6 -- в каталоге MSVC6. Под *NIX (тестировался на Linux RH 6.2, если кто возьмет на себя труд собрать и потестировать на другой *NIX платформе -- будем благодарны за комментарии; фактически, должно работать на любой... но, как обычно -- as is) же проект собирается обычным образом: $./configure $make Инсталлировать не надо -- надо положить рядышком конфигурационный файл. Вот пример такого файла: # This is a dumb_esme configuration file # Host and port host=192.168.0.5 port=8200 # Bound parameters system_id=System ID password=the password system_type=Dumb ESME # Lifetime in seconds lifetime=60 # Time delay for select operation seconds... tv_sec=0 # ...and microseconds tv_usec=100000 # i. e. 0.1 sec

В форуме проскакивала ссылка на эмулятор, написанный на Java. Мы же тестировали на "внутреннем" эмуляторе и на реальном SMSC (поверьте на слово -- отправляет и принимает).

Само приложение совсем простое: будучи запущенным, оно "висит" указанное количество времени (параметр "lifetime" в конфигурационном файле), открывая два соединения к центру (transmitter и receiver). Receiver принимает все, что успевает за это время (не забывая отвечать ACK-ами) и "складывает" принятое в файл с именем "inbox", а transmitter отправляет все, что смог прочитать из файла "outbox". Вот пример формата файла "outbox": 1234 1 1 9672345 1 1 9872345 Message text Первая группа цифр -- идентификатор сообщения, присваиваемый пользователем, ни для кого, кроме него он значения не имеет (и никуда не передается), но служит для связи ответов SMSC с исходными сообщениями. Далее, через пробел, TON, NPI и адрес оригинатора (т. к. ESME, в принципе, может обслуживать как отдельный номер, так и диапазон, или набор), т. е. адрес ESME. То же для получателя. Все остальное до конца строки -- текст сообщения. Проверка на длину, кстати, для простоты, опущена (как и многие другие проверки, в т. ч. на длину адресов).

После обработки "outbox" переименовывается. Далее, по приходу ACK'а заносится запись в файл "sent" (в случае, если код ACK'а рапортует положительный статус) или, в обратном случае, в файл "err". В файл "sent" помешается строчка, содержащая упомянутый пользовательский идентификатор и идентификатор, присваиваемый центром. В файл "err" -- только пользовательский. По приходу же delivery receipt'а (status report'а) в файл "deliv" помещается строчка с идентификатором сообщения, выданный центром, если, опять же, в рапорте сообщается об успешном доведении, и, в обратном случае, такая же запись помещается в файл "undeliv".

Такой механизм работы позволяет связать исходное сообщение с ответами центра. Действительно, не сложно написать приложение (а, фактически, с этим может справиться несложный скрипт) для анализа полученных файлов. На практике же, обычно "входом" и "выходом" часто является некая база данных, но механизм связывания остается примерно тем же. Это то, что мы между собой называем "чехордой идентификаторов" :). Но подробнее об этом в следующей статье.

Подробный "разбор полетов" будет в следующей статье. А пока можно просто проанализировать код и, кому удастся, потестировать приложение. Мы, к слову, ввиду недостатка времени, тестировали не очень интенсивно, так что bug-report'ы направляйте в форум ;). Тем не менее, на стенде этот простенький (dumb!) SMS client показал устойчивую работу при нагрузках порядка 100 mess/sec в обоих каналах, что явилось некоторой неожиданностью.