Cloud to Device Messaging

Cloud to Device Messaging (C2DM) — это технология, позволяющая серверной части приложения отправлять короткие push-уведомления и данные на мобильные устройства под управлением операционной системы Android. Данный механизм был разработан компанией Google и являлся предшественником современного сервиса Firebase Cloud Messaging (FCM). C2DM обеспечивал постоянное соединение между устройством и серверами Google, что позволяло приложениям получать сообщения даже в фоновом режиме, без необходимости постоянно опрашивать сервер.

История

Разработка и запуск

Технология C2DM была анонсирована Google в 2010 году на конференции Google I/O. Она стала ответом на необходимость создания единого, стандартизированного механизма для отправки push-уведомлений на Android-устройства. До появления C2DM разработчики были вынуждены использовать собственные решения, такие как постоянное подключение по протоколу XMPP или периодический опрос сервера (polling), что приводило к повышенному расходу батареи и трафика.

Прекращение поддержки

В 2012 году Google представила новую, более совершенную платформу — Google Cloud Messaging (GCM), которая пришла на смену C2DM. Официально C2DM был объявлен устаревшим (deprecated) в 2013 году, а полное прекращение работы его серверов произошло в 2015 году. Все разработчики были переведены на использование GCM, который, в свою очередь, в 2018 году был заменён на Firebase Cloud Messaging (FCM). На сегодняшний день C2DM не поддерживается и не может быть использован для отправки уведомлений.

Принцип работы

Архитектура C2DM основывалась на трёх ключевых компонентах: сервер приложения (3rd-party application server), серверы Google (C2DM servers) и клиентское Android-устройство.

Регистрация устройства

Процесс начинался с регистрации устройства. При первом запуске приложения, которое поддерживало push-уведомления, оно отправляло запрос на серверы Google. В ответ устройство получало уникальный идентификатор — регистрационный токен (Registration ID). Этот токен представлял собой строку символов, однозначно идентифицирующую конкретное приложение на конкретном устройстве. Приложение затем передавало этот токен своему серверу.

Отправка сообщения

Когда сервер приложения хотел отправить уведомление, он формировал HTTP-запрос к серверам Google. Запрос содержал:

• Регистрационный токен устройства-получателя.
• Ключ авторизации (Sender ID), который выдавался Google при регистрации приложения в консоли разработчика.
• Данные сообщения — до 4 килобайт информации.

Серверы Google аутентифицировали запрос, находили устройство по токену и отправляли ему сообщение через постоянное соединение, которое поддерживалось между устройством и серверами Google.

Получение и обработка

На устройстве сообщение принималось системным сервисом Google Play Services (или его предшественником). Затем оно передавалось в конкретное приложение через широковещательный Intent (BroadcastReceiver). Приложение могло обработать сообщение: показать уведомление в строке состояния, обновить данные в фоне или запустить определённый код.

Схема взаимодействия

1. Приложение регистрируется на серверах Google, получает Registration ID.
2. Приложение отправляет Registration ID на свой сервер приложений.
3. Сервер приложений отправляет HTTP-запрос на серверы Google с данными сообщения и Registration ID.
4. Серверы Google отправляют сообщение на устройство.
5. Системное приложение на устройстве передаёт сообщение целевому приложению.

Классификация сообщений

C2DM поддерживал два основных типа сообщений, которые различались по способу обработки на устройстве:

• Сообщения с уведомлением (Notification messages) — сообщения, которые автоматически отображались в строке состояния устройства в виде иконки и текста. Приложение не требовалось для их обработки; система сама показывала уведомление. При нажатии на уведомление запускалось соответствующее приложение.
• Сообщения с данными (Data messages) — сообщения, которые содержали произвольные данные (например, JSON-объект) и передавались непосредственно приложению. Приложение должно было быть запущено (хотя бы в фоне) для обработки такого сообщения. Если приложение не было запущено, сообщение могло быть потеряно.

Характеристики и ограничения

C2DM имел ряд технических особенностей и ограничений, которые были преодолены в последующих версиях сервиса:

• Максимальный размер сообщения: 4 килобайта.
• Количество сообщений: не было строгого лимита, но при превышении определённого порога серверы Google могли временно блокировать отправку с конкретного сервера приложения.
• Срок жизни сообщения (TTL): сообщение могло храниться на серверах Google до 4 недель, если устройство было офлайн. По истечении этого срока сообщение удалялось.
• Отсутствие гарантии доставки: C2DM не гарантировал доставку каждого сообщения. При переполнении очереди на устройстве старые сообщения могли быть отброшены.
• Зависимость от Google Play Services: для работы C2DM требовалось наличие сервисов Google Play на устройстве.
• Однонаправленность: C2DM поддерживал только отправку сообщений от сервера к устройству. Обратная связь (от устройства к серверу) требовала отдельного механизма.

Применение

C2DM использовался для широкого круга задач, связанных с оперативным информированием пользователя и синхронизацией данных:

• Push-уведомления: оповещения о новых сообщениях, письмах, комментариях, лайках.
• Синхронизация данных: обновление контента в приложении (например, ленты новостей, прогноза погоды) без участия пользователя.
• Запуск фоновых задач: выполнение кода на устройстве по команде с сервера (например, очистка кэша, обновление базы данных).
• Управление устройством: отправка команд на удалённое устройство (например, блокировка, сброс настроек).

Критика и недостатки

Несмотря на свою инновационность, C2DM имел ряд недостатков, которые привели к его замене:

• Сложность настройки: разработчикам требовалось вручную регистрировать приложение в консоли Google и управлять ключами авторизации.
• Отсутствие аналитики: не было встроенных инструментов для отслеживания доставки и открытия уведомлений.
• Нестабильность: сообщения могли теряться или доставляться с задержкой, особенно при высокой нагрузке на серверы Google.
• Ограниченная функциональность: отсутствовала поддержка тем (topics), групповых сообщений и расширенных настроек доставки.
• Зависимость от Google: сервис был полностью привязан к инфраструктуре Google, что вызывало проблемы в регионах, где доступ к сервисам Google был ограничен или заблокирован.

Наследие

C2DM заложил основу для современных систем push-уведомлений на Android. Опыт, полученный при его разработке и эксплуатации, был использован при создании GCM и FCM. Основные принципы — регистрация устройства, отправка через серверы Google, обработка через BroadcastReceiver — остались неизменными. Сегодня C2DM представляет собой исторический интерес как первый шаг Google в области облачных push-уведомлений для мобильной платформы.

Источники

• Google I/O 2010: Announcement of Cloud to Device Messaging (C2DM)
• Официальная документация Google Cloud Messaging (GCM) (архивная версия)
• Android Developers Blog: "Cloud to Device Messaging" (2010)
• Документация Firebase Cloud Messaging (FCM) — раздел "History"
• Статья "Google Cloud Messaging for Android" на сайте Android Developers (архив)