Skip to content

Instantly share code, notes, and snippets.

@fnicastri
Created March 14, 2017 17:32
Show Gist options
  • Save fnicastri/0f08bc9fb0a6877683a8f4193279f9ec to your computer and use it in GitHub Desktop.
Save fnicastri/0f08bc9fb0a6877683a8f4193279f9ec to your computer and use it in GitHub Desktop.
Google Cloud Messaging Limitations
  • max 1000 registration IDs per multicast message

Topic Messaging (cloud-to-device):

  • max 1 million subscribers per app
  • max 2KB payload

Device Group Messaging (cloud-to-device) or (device-to-cloud):

  • max 20 members per device group
  • group name should be unique per user

Upstream/Downstream messages

  • HTTP: Downstream only, cloud-to-device up to 4KB of data.
  • XMPP (CCS): Upstream and downstream (device-to-cloud, cloud-to-device), up to 4 KB of data.
  • Max connections allowed per XMPP sender is 1000
  • Max outstanding messages per XMPP connection is 100

Upstream messages

  • Max pending upstream messages is 100
  • Max 1 day disconnect time
  • ACKing is required
  • Max 20 unacke'd upstream messages (w/ TTL != 0)
  • Max payload size is 4KB

Receiving Messages from Multi-senders

  • Limit of 100 multiple senders

Message storage when device offline for longer period

If the device is not connected to GCM, the message will be stored until a connection is established (again respecting the collapse key rules). When a connection is established, GCM will deliver all pending messages to the device, regardless of the delay_while_idle flag. If the device never gets connected again (for instance, if it was factory reset), the message will eventually time out and be discarded from GCM storage. The default timeout is 4 weeks, unless the time_to_live flag is set.

Note: There is a limit of 100 messages that can be stored without collapsing. If the limit is reached, all stored messages are discarded. When the device is back online, it receives a special message indicating that the limit was reached. The application can then handle the situation properly, typically by requesting a full sync from the app server.

To prevent abuse (such as sending a flood of messages to a device) and to optimize for the overall network efficiency and battery life of devices, GCM may throttle messages based on the messages-sent rate for a particular application per device. Because of this, an application may encounter additional message delivery latency when it sends a large number of messages to the same device within a short period of time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment