diff options
Diffstat (limited to 'docs/html/google/gcm/ccs.jd')
| -rw-r--r-- | docs/html/google/gcm/ccs.jd | 58 |
1 files changed, 25 insertions, 33 deletions
diff --git a/docs/html/google/gcm/ccs.jd b/docs/html/google/gcm/ccs.jd index 2faf97f..7db7a74 100644 --- a/docs/html/google/gcm/ccs.jd +++ b/docs/html/google/gcm/ccs.jd @@ -21,7 +21,7 @@ page.title=GCM Cloud Connection Server (XMPP) </li> <li><a href="#upstream">Upstream Messages</a> <ol> - <li><a href="#receipts">Receive return receipts</a></li> + <li><a href="#receipts">Receive delivery receipts</a></li> </ol> </li> <li><a href="#flow">Flow Control</a> </li> @@ -45,11 +45,15 @@ page.title=GCM Cloud Connection Server (XMPP) </div> </div> -<p>The GCM Cloud Connection Server (CCS) is an XMPP endpoint that provides a +<p>The Google Cloud Messaging (GCM) Cloud Connection Server (CCS) is an XMPP endpoint that provides a persistent, 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.</p> +<p class="note"><strong>Note:</strong> The content in this document +applies to <a href="http://developer.chrome.com/apps/cloudMessaging"> +GCM with Chrome apps</a> as well as Android. + <p>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:</p> @@ -259,22 +263,6 @@ message is "nack". A NACK message contains:</p> </message> </pre> -<p>Quota exceeded:</p> - -<pre><message> - <gcm xmlns="google:mobile:data"> - { - "message_type":"nack", - "message_id":"msgId1", - "from":"APA91bHFOtaQGSwupt5l1og", - "error":"QUOTA_EXCEEDED", - "error_description":"Short-term downstream quota exceeded for this registration id" - } - </gcm> -</message> -</pre> - - <p>The following table lists NACK error codes. Unless otherwise indicated, a NACKed message should not be retried. Unexpected NACK error codes should be treated the same as {@code INTERNAL_SERVER_ERROR}.</p> @@ -312,11 +300,11 @@ message should be immediately retried over another connection.</td> <td>{@code INVALID_JSON}</td> <td>The JSON message payload is not valid.</td> </tr> -<tr> -<td>{@code QUOTA_EXCEEDED}</td> -<td>The rate of messages to a particular registration ID (in other words, to a -sender/device pair) is too high. If you want to retry the message, try using a slower -rate.</td> +<td>{@code DEVICE_MESSAGE_RATE_EXCEEDED}</td> +<td>The rate of messages to a particular device is too high. You should reduce +the number of messages sent to this device and should not immediately retry +sending to this device. This error code replaces {@code QUOTA_EXCEEDED}, +which has been deprecated.</td> </tr> <tr> <td>{@code SERVICE_UNAVAILABLE}</td> @@ -429,15 +417,17 @@ response to the above message:</p> </gcm> </message></pre> -<h3 id="receipts">Receive return receipts</h3> +<h3 id="receipts">Receive delivery receipts</h3> -<p>You can use upstream messaging to get receipt notifications, confirming -that a given message was sent to a device. Your 3rd-party app server receives the receipt -notification from CCS once the message has been sent to the device.</p> +<p>You can use upstream messaging to get delivery receipts (sent from CCS to +your 3rd party app server) when +a device confirms that it received a message sent by CCS.</p> <p>To enable this feature, the message your 3rd-party app server sends to CCS must include a field called <code>"delivery_receipt_requested"</code>. When this field is set to -<code>true</code>, CCS sends a return receipt. Here is an XMPP stanza containing a JSON +<code>true</code>, CCS sends a delivery receipt when a device confirms that it received a particular message.</p> + +<p>Here is an XMPP stanza containing a JSON message with <code>"delivery_receipt_requested"</code> set to <code>true</code>:</p> <pre><message id=""> @@ -457,8 +447,10 @@ message with <code>"delivery_receipt_requested"</code> set to <code>tr </message> </pre> -<p>Here is an example of a receipt notification message that CCS sends back to your 3rd-party -app server:</p> + + +<p>Here is an example of the delivery receipt that CCS sends to tell your 3rd-party +app server that a device received a message that CCS sent it:</p> </p> <pre><message id=""> @@ -483,12 +475,12 @@ app server:</p> <ul> <li>The {@code "message_type"} is set to {@code "receipt"}. <li>The {@code "message_status"} is set to {@code "MESSAGE_SENT_TO_DEVICE"}, - indicating that the message was delivered. Notice that in this case, + indicating that the device received the message. Notice that in this case, {@code "message_status"} is not a field but rather part of the data payload.</li> <li>The receipt message ID consists of the original message ID, but with a -<code>dr:</code> prefix. Your 3rd-party app server must send an ACK back with this ID, +<code>dr2:</code> prefix. Your 3rd-party app server must send an ACK back with this ID, which in this example is {@code dr2:m-1366082849205}.</li> - <li>The original message ID and status are inside the + <li>The original message ID, the device registration ID, and the status are inside the {@code "data"} field.</li> </ul> |