С.Кадаков

И ни в чем себе не отказывать...

Наконец-то (с заметным перерывом), нам удалось выпустить следующую статью цикла. Собственно, как мы и обещали, она содержит код простого, но работающего 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

Где брать эмулятор SMSC.

В форуме проскакивала ссылка на эмулятор, написанный на 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 в обоих каналах, что явилось некоторой неожиданностью.