Программирование мобильных устройств на платформе .NET Compact Framework

Салмре Иво

IР-адреса Internet-серверов изменяются редко. Кроме того, существуют механизмы поиска IP адресов по дружественным именам URL. Самой популярной службой поиска имен в Internet является DNS, название которой — это аббревиатура от Domain Naming System (система именования доменов); эта служба транслирует дружественные имена, например, www.microsoft.com или www.yahoo.com, в IР-адреса. DNS-серверы поддерживают реплицируемые базы данных, которые преобразуют имена в IР-адреса. Это работает хорошо, поскольку IP-адреса серверов изменяются редко.

Аналогичным образом все это работает и в пределах интрасетей. Имя сервера, настольного компьютера или лэптопа регистрируется и связывается с IP-адресом. Иногда эти адреса являются фиксированными, но обычно внутренние адреса назначаются компьютерам так называемыми DHCP-серверами. Аббревиатура DHCP происходит от Dynamic Host Configuration Protocol — протокол динамической конфигурации хоста, и, как нетрудно догадаться, роль DHCP-сервера заключаются в присвоении IР-адресов тем компьютерам-клиентам, которые это запрашивают. Опять-таки, предполагается. что эти IP-адреса

изменяются не очень часто. Сервер, часто изменяющий свой IP-адрес, будет дополнительно нагружать сеть, поскольку этот адрес будет требовать постоянного обновления и вынуждать клиентские компьютеры к проведению поиска. Частое появление и исчезновение в сети устройств, вызванное их непрерывным перемещением между различными участками сети или частым включением и отключением, также будет приводить к частой смене их IР-адресов.

Если сфера использования мобильного устройства ограничивается сетью определенной топологии (например, одной корпоративной сетью), то все проблемы, связанные с его адресацией, можно преодолеть сравнительно легко. В этом случае можно поступить двояким образом: 1) ограничиться назначением мобильному устройству фиксированного IP адреса, что было бы самым простым, но при этом наименее гибким решением, или 2) создать пользовательский сервер отображения адресов, вызываемый устройствами для регистрации своих IP-адресов всякий раз, когда они изменяются; остальные устройства могут запрашивать у этого сервера адрес любого конкретного устройства.

Для устройств, которые могут мигрировать между различными сетями, проблема значительно усложняется. Статические IP-адреса использовать нельзя, поскольку они должны быть разрешены действующей сетью, но любой заданный адрес, который хотело бы использовать устройство, уже мог быть до этого назначен или зарезервирован в данной сети. При наличии прокси-серверов, трансляторов сетевых адресов (Network Address Translators — NAT) или брандмауэров (firewalls) возникают дополнительные проблемы. Прокси-серверы, NAT и брандмауэры разрешают лишь определенные виды исходящих запросов и передают ответы на них тем вычислительным устройствам, которыми эти запросы были направлены; поступления же нежелательных запросов на устройства, находящиеся внутри сети, они, как правило, не допускают. Находящиеся внутри сети устройства, которые посылают запросы серверу, не обязаны знать ничего об этих тонкостях, но о них должно быть известно любой стороне, пытающейся получить доступ к устройству извне сети.

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

Не решаются ли все эти проблемы набором протоколов IPv6?

Ответ таков: "В перспективе — возможно", однако, как сказал известный экономист Мейнард Кинис (Maynard Keyneys): "В делах повседневных перспектива — плохой советчик. В перспективе нас всех ожидает смерть". Пройдет немало лет, пока IPv6 прочно утвердится в мире, но в любом случае такие компоненты сетевой безопасности, как брандмауэры, просуществуют еще очень долго. Как следствие, адресовать серверы по- прежнему будет проще, чем мобильные устройства. Для адресации мобильных устройств, непрерывно мигрирующих между различными сетевыми топологиями, будут требоваться специальные механизмы.

В некоторых случаях полезно иметь возможность принудительной перекачки информации на мобильное устройство. Как ранее уже отмечалось, в случае стационарных пользовательских сетевых топологий это не составляет особого труда; мобильное устройство может иметь фиксированный или специальным образом зарегистрированный IP-адрес, так что ему остается только открыть сокет и дожидаться поступления запросов. Для универсальных мобильных устройств, мигрирующих между различными сетями, это представляет определенные трудности. Имеется несколько путей преодоления этих проблем: 

■ Мобильные телефоны могут использовать механизм SMS-сообщений. Большинство современных мобильных телефонов поддерживают широко популярный механизм сообщений SMS (Short Message Service), который очень хорошо приспособлен для передачи коротких потоков данных на устройства. Служба SMS предлагает удобную универсальную схему адресации — телефонный номер устройства. Как правило, SMS-сообщения являются текстовыми и предназначаются для прочтения пользователем, но это не исчерпывает всего круга их возможных применений. Поскольку длина SMS-сообщений ограничена примерно 160 символами, неплохой моделью, позволяющей использовать SMS-сообщения для закачки информации на устройства, является так называемая "двухтактная" ("push to pull") модель; прибытие определенного SMS-сообщения запускает локальное приложение, осуществляющее доступ к серверу и загрузку большего объема информации. 

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

■ Опрос. Суть опроса (polling)

заключается в периодическом опрашивании устройством сервера для выяснения того, не находится ли на сервере информация, которая еще не была передана на устройство.

Из трех вышеописанных механизмов опрос является наименее сложным и во многом — простейшим для реализации. Привлекать другие механизмы следует лишь в тех случаях, когда решение, основанное на механизме опроса, по тем или иным причинам использовать не удается.

В настоящее время при разработке приложений в рамках .NET Compact Framework версии 1.1 встроенная библиотечная поддержка получения или просмотра поступающих сообщений электронной почты или SMS-сообщений не предоставляется; для этого приходится писать функции в собственных кодах и выполнять сложные операции. Доступ к поступающим сообщениям электронной почты и SMS-сообщениям не является чем-то неосуществимым, однако требует выполнения большого объема работы. Эта работа будет оправдана лишь в том случае, если для удовлетворения потребностей вашего мобильного приложения возможностей менее элегантных, но более простых решений оказывается недостаточно. Написание низкоуровневого кода для обработки сообщений — вещь интересная, но вряд ли когда-либо эту работу можно выполнить в сжатые сроки; всегда оценивайте альтернативные возможности и принимайте взвешенные решения.

Организация доступа к поступающим SMS-сообщениям на устройствах Microsoft Smartphone

Для работы с SMS-сообщениями в операционной системе Microsoft Smartphone существует два способа: 1) работа на низком уровне путем создания собственного фильтра для проверки поступающих сообщений, или 2) работа на высоком уровне с использованием интерфейса прикладного программирования CEMAPI (СЕ Messaging API) для просмотра сообщений после того, как они поступили. В настоящее время оба эти способа требуют использования собственных кодов С/С++ для доступа к необходимым функциональным средствам операционной системы. 

1. Создание собственного низкоуровневого фильтра для поступающих SMS-сообщений

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

В принципе, оба эти подхода аналогичны разработке ISAPI-фильтра для сервера Internet Information Server; могут выполняться одновременно несколько фильтров, и запрос дескриптора передается первому из фильтров, критерии которого согласуются с поступающими запросами. (Например, в случае ISAPI-фильтров запросы Web-страницы *.ASP маршрутизируются на один дескриптор, а запросы Web-страницы *.ASPX — на другой, исходя из расширения файла.) Создание ISAPI-фильтра для Internet Information Server — задача нелегкая, требующая тщательного проектирования и тестирования. Точно так же как почти никому из Web-разработчиков не требуется использование собственных ISAPI-фильтров, создание собственных SMS-поставщиков или компонентов IMailRuleClient может понадобиться разработчикам мобильных приложений лишь в редких случаях. Тем не менее, если на первый план выходит гибкость, ее необходимо обеспечивать именно таким способом.

• SMS-поставщики 

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

Более подробную информацию относительно создания SMS-поставщиков вы сможете найти в справочной документации по Smartphone SDK, проведя поиск по термину "SMS Provider" или просмотрев раздел "Short Message Service" комплекта справочной документации "Smartphone Adaptation Kit for Mobile Operators".

• IMailRuleClient

Для устройств Smartphone 2003 и более поздних моделей можно реализовать и зарегистрировать компонент, реализующий интерфейс IMailRuleClient. Этому высокоуровневому, по сравнению с созданием SMS-поставщика, подходу следует отдавать предпочтение, поскольку он ориентирован на разработчиков приложений, а не на операторов сетей мобильной связи, выпускающих телефоны.

Интерфейс IMailRuleClient позволяет компоненту проверять входящие SMS-сообщения и отвечать на них. Такой подход может оказаться более легким в реализации по сравнению с написанием кода собственного SMS-поставщика, но для этого необходимо еще, чтобы компонент был подписан разрешенным криптографическим ключом, если этого требует изготовитель телефона. Более подробную информацию относительно интерфейса IMailRuleClient вы сможете найти, проведя в оперативной справочной документации MSDN поиск по ключевым словам "IMailRuleClient" или "CEMAPI". 

2. Использование CEMAPI для высокоуровневого доступа к SMS-сообщениям

Интерфейс CEMAPI предлагает высокоуровневый механизм доступа к текстовым SMS- сообщениям, которые были маршрутизированы на почтовый ящик смартфона. CEMAPI предлагает набор интерфейсов для навигации по хранилищу сообщений устройства, а также создания и просмотра сообщений. Ваше мобильное приложение может периодически опрашивать папку входящих сообщений устройства с целью проверки того, не поступили ли новые сообщения, предназначенные для этого приложения. Для получения более подробной информации относительно порядка работы с папкой входящих сообщений Pocket PC или смартфона выполните в комплекте справочной документации Smartphone SDK поиск по ключевому слову "CEMAPI".