Extensible Messaging and Presence Protocol (XMPP) with GCM

1. Extensible Messaging and
Presence Protocol (XMPP)
with GCM

2. What is XMPP?
• Extensible Messaging and Presence Protocol (XMPP) is a
communications protocol based on XML (Extensible Markup
Language).
• Originally named Jabber, the protocol was developed by the Jabber
open-source community in 1999.

3. Strengths of XMPP
• Open standards: The Internet Engineering Task Force formalized
XMPP as an approved instant messaging and presence technology
under the name of XMPP (the latest specifications are RFC
6120 and RFC 6121). No royalties or granted permissions are required
to implement these specifications.
• History: XMPP technologies have been in use since 1999. Many
implementations of the XMPP standards exist for clients, servers,
components, and code libraries.

4. Weakness of XMPP
• Does not support Quality of Service (QoS): Assured delivery of
messages has to be built on-top of the XMPP layer.

5. Architecture of XMPP
In XMPP, a client with a unique name communicates with another
client with a unique name through an associated server. Each client
implements the client form of the protocol, where the server provides
routing capability.
In this case, each client is part of the same domain
(discovery.nasa.guv).

6. • Servers can also communicate for purposes of routing between
domains (for example, between discovery.nasa.guv and
europa.nasa.guv). Further, gateways can exist for purposes of
translating between foreign messaging domains and protocols.
• Gateways are most often used in this context to translate between
IM protocols (for example, XMPP to Internet Relay Chat [IRC]).
• As an extensible protocol, XMPP is an ideal backbone protocol to
provide universal connectivity among different endpoint protocols.
The XMPP gateway permits the termination of a given client-to-server
session and the initiation of a new session to the target endpoint
protocol (along with the necessary protocol translation).

7. This example shows an XMPP network with gateways to a
Short Message Service (SMS) domain and an SMTP
domain.

8. XMPP
• XMPP is a relatively simple protocol that occurs over TCP sockets
using XML messages. Asynchronous communication occurs within
XML streams and with XML stanzas.
• An XML stream is an envelope that encapsulates the exchange of
XML information between two entities. XML streams
communicate XML stanzas, which are discrete units of information.
• For example, XML stanzas are used within XMPP to
communicate messages(text between IM users) as well as presence
information. To illustrate these concepts, look at a simple example of
an IM communication using XMPP between two clients.

9. This Figure illustrates a simple
conversation between two entities. Note
that at least one server appears within
the conversation (in this case, because
both clients exist within the same
domain, there's exactly one server).
The left client is known as the initiating
entity (it initiates the XMPP
communication between the two
entities). This XML stream uses the to
attribute to identify the receiving
domain (as well as define the XML
namespace).
The receiving client on the right receives
this XML stream and responds with an
XML stream response (in this case, using
the from attribute).

10. The next step in the XML stream from
figure is communicating messages. This
communication occurs within the
message stanza and includes the source
and destination XMPP addresses (from
and to), the language used, and a
message contained within the body of
the stanza. The peer responds with its
own message, the key difference being
the source and destination XMPP
addresses. Finally, the XML stream is
closed by issuing the stream closure
message (which occurs on both sides of
the connection).

11. In case of Invalid XML stream or stanza
• Either side can return an error, such as defined below. In this case, the
peer sent an XML stream or stanza that was invalid.
<stream:error>
<xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-
streams'/>
<stream:error>

12. About GCM Connection Server
• The server side of Google Cloud Messaging (GCM) consists of two
components:
• GCM connection servers provided by Google. These servers take
messages from an app server and send them to a client app running
on a device. Google provides connection servers for HTTP and XMPP
(CCS) (XMPP).
• An application server that you must implement in your environment.
This application server sends data to a client app via the chosen GCM
connection server, using the appropriate XMPP or HTTP protocol.
A full GCM implementation requires both a client implementation and
a server implementation.

13. Role of the Application Server
Before you can write client apps that use GCM, you must have an application
server that meets the following criteria:
• Able to communicate with your client.
• Able to send properly formatted requests to the GCM connection server.
• Able to handle requests and resend them using exponential back-off.
• Able to store the API key and client registration tokens.
• Able to generate message IDs to uniquely identify each message it sends.
Message IDs should be unique per sender ID.
You'll need to decide which GCM connection server protocol(s) you want to
use to enable your app server to interact with GCM connection servers. Note
that if you want to use upstream messaging from your client applications,
you must use XMPP (CCS).

14. Choosing a GCM Connection Server Protocol
Currently GCM provides two connection server protocols: HTTP and XMPP (CCS).
Your app server can use them separately or in tandem. XMPP (CCS) messaging
differs from HTTP messaging in the following ways:
• 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.
• Messaging (synchronous or asynchronous)
HTTP: Synchronous. App servers send messages as HTTP POST requests and
wait for a response. This mechanism is synchronous and blocks the sender from
sending another message until the response is received.
XMPP (CCS): Asynchronous. App servers send/receive messages to/from all
their devices at full line speed over persistent XMPP connections. XMPP (CCS)
sends acknowledgment or failure notifications (in the form of special ACK and
NACK JSON-encoded XMPP messages) asynchronously.

15. • JSON
HTTP: JSON messages sent as HTTP POST.
XMPP (CCS): JSON messages encapsulated in XMPP messages.
• Plain Text
HTTP: Plain Text messages sent as HTTP POST.
XMPP (CCS): Not supported.
• Multicast downstream send to multiple registration tokens.
HTTP: Supported in JSON message format.
XMPP (CCS): Not supported.

16. Implementing an XMPP Connection Server
• The Google Cloud Messaging (GCM) Cloud Connection Server (CCS) is an XMPP endpoint
that provides a asynchronous, bidirectional connection to Google servers. The
connection can be used to send and receive messages between your server and your
users' GCM-connected devices.
• You can continue to use the HTTP request mechanism to send messages to GCM servers,
side-by-side with CCS which uses XMPP. Some of the benefits of CCS include:
•The asynchronous nature of XMPP allows you to send more messages with fewer
resources.
•Communication is bidirectional—not only can your server send messages to the
device, but the device can send messages back to your server.
•The device can send messages back using the same connection used for receiving,
thereby improving battery life.

17. Establishing a Connection
• CCS just uses XMPP as an authenticated transport layer, so you can use most
XMPP libraries to manage the connection.
• The CCS XMPP endpoint runs at gcm-xmpp.googleapis.com:5235. When testing
functionality (with non-production users), you should instead connect to gcm-
preprod.googleapis.com:5236 (note the different port). Regular testing on
preprod (a smaller environment where the latest CCS builds run) is beneficial
both for isolating real users from test code, as well as for early detection of
unexpected behavior changes.
• Note that a connection receives upstream messages destined for its GCM sender
ID, regardless of which environment (gcm or gcm-preprod) it is connected to.
Therefore, test code connecting to gcm-preprod.googleapis.com:5236 should use
a different GCM sender ID to avoid upstream messages from production traffic
being sent over test connections.

18. Downstream Messages
Once the XMPP connection is established, CCS and your server use normal XMPP
<message> stanzas to send JSON-encoded messages back and forth. The body of
the <message> must be:
<gcm xmlns:google:mobile:data>
JSON payload
</gcm>

19. The JSON payload for regular GCM messages is similar to what the GCM http endpoint
uses, with these exceptions:
• There is no support for multiple recipients.
• to is used instead of registration_ids.
• CCS adds the field message_id, which is required. This ID uniquely identifies the message
in an XMPP connection. The ACK or NACK from CCS uses the message_id to identify a
message sent from app servers to CCS. Therefore, it's important that this message_id not
only be unique (per sender ID), but always present.
In addition to regular GCM messages, control messages are sent, indicated by the
message_type field in the JSON object. The value can be either 'ack' or 'nack', or 'control'
(see formats below). Any GCM message with an unknown message_type can be ignored by
your server.
For each device message your app server receives from CCS, it needs to send an ACK
message. It never needs to send a NACK message. If you don't send an ACK for a message,
CCS resends it the next time a new XMPP connection is established, unless the message
expires first.
CCS also sends an ACK or NACK for each server-to-device message. If you do not receive
either, it means that the TCP connection was closed in the middle of the operation and
your server needs to resend the messages.

20. Message with payload — data message
Here is an XMPP stanza containing the JSON message from an app server to CCS:
<message id="">
<gcm xmlns="google:mobile:data">
{
"to":"REGISTRATION_ID", // "to" replaces "registration_ids"
"message_id":"m-1366082849205" // new required field
"data":
{
"hello":"world",
}
"time_to_live":"600",
}
</gcm>
</message>

21. ACK message
Here is an XMPP stanza containing the ACK/NACK message from CCS to the app server:
<message id="">
<gcm xmlns="google:mobile:data">
{
"from":"REGID",
"message_id":"m-1366082849205"
"message_type":"ack"
}
</gcm>
</message>

22. Flow Control • Every message sent to CCS receives either an ACK or a
NACK response. Messages that haven't received one
of these responses are considered pending. If the
pending message count reaches 100, the app server
should stop sending new messages and wait for CCS to
acknowledge some of the existing pending messages.
• Conversely, to avoid overloading the app server, CCS
stops sending if there are too many unacknowledged
messages. Therefore, the app server should "ACK"
upstream messages, received from the client
application via CCS, as soon as possible to maintain a
constant flow of incoming messages.
• ACKs are only valid within the context of one
connection. If the connection is closed before a
message can be ACKed, the app server should wait for
CCS to resend the upstream message before ACKing it
again. Similarly, all pending messages for which an
ACK/NACK was not received from CCS before the
connection was closed should be sent again.

23. Flow of events
• PART A (Registration): Android device sends request to the
Google CCS to register and obtain a RegId.
• PART A: Google CCS responds back with the RegId.
• PART B (Upstream): Device sends a message to CCS server.
• PART B: The message sent in the previous step is relayed
by the Google CCS server to the XMMP server application.
• PART C (Downstream): XMPP sends a downstream
message to the CCS.
• PART C: Google CCS relays the downstream message to
the registered Android device.

24. Sending downstream messages from the
server
• To address or "target" a downstream message, the app server sets to with the receiving client app's
registration token. You can send notification messages with predefined fields, or custom data messages.
• XMPP Message
<message id="">
<gcm xmlns="google:mobile:data">
{ "data": {
"score": "5x1",
"time": "15:10"
},
"to" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx..."
}
</gcm>
</message>

25. Receive and handle messages
• To receive simple downstream messages,
use a service that extends
GcmListenerService to handle messages
captured by GcmReceiver. GcmReceiver
extends WakefulBroadcastReceiver,
guaranteeing that the CPU is awake so
that your listener service can complete its
task.
• By overriding the method
GcmListenerService.onMessageReceived
, you can perform actions based on the
received message.
@Override
public void
onMessageReceived(String from,
Bundle data) {
String message =
data.getString("message");
Log.d(TAG, "From: " + from);
Log.d(TAG, "Message: " +
message);
// ...
}

26. Send Upstream Messages
• If your app server implements the XMPP Connection Server protocol, it can
receive upstream messages from a user's device to the cloud. To initiate an
upstream message, the client app sends a request containing the following:
• The address of the receiving app server, in the format
SENDER_ID@gcm.googleapis.com.
• A message ID that should be unique per sender ID.
• The message data comprising the key/value pairs of the message's payload.
• When it receives this data, GCM builds an XMPP stanza to send to the app
server, adding some additional information about the sending device and
app.

27. Send an upstream message from an Android
client app
• Your Android app can send an upstream message using the
GoogleCloudMessaging API to call gcm.send as shown:
private void sendMessage() throws IOException {
Bundle data = new Bundle();
data.putString("my_message", "Hello World");
data.putString("my_action","SAY_HELLO");
String id = Integer.toString(msgId.incrementAndGet());
gcm.send(SENDER_ID + "@gcm.googleapis.com", id, data);
}

28. Sending an ACK message
• In response to an upstream message like the above, the app server must send an
ACK message containing the unique message ID. If GCM does not recieve an ACK,
it may retry sending the message to the app server.
<message id="">
<gcm xmlns="google:mobile:data">
{
"to":"REGID",
"message_id":"m-123"
"message_type":"ack"
}
</gcm>
</message>

29. Chat between two devices