From 13d7ea464ec7947a0c55cd778c8b2bacc9d0745d Mon Sep 17 00:00:00 2001 From: kmccormick Date: Tue, 14 Oct 2014 15:34:21 -0700 Subject: DO NOT MERGE - Doc update: deliv receipt, rate exceeded, bug fixes. Cherry-pick from: Change-Id: I17d9604da9a894501c7701174e4f7c61dfa9e80e Fix for: b/17936796 Change-Id: I17d9604da9a894501c7701174e4f7c61dfa9e80e --- docs/html/google/gcm/ccs.jd | 58 +++++++++++++++++++-------------------------- 1 file changed, 25 insertions(+), 33 deletions(-) (limited to 'docs/html/google/gcm/ccs.jd') 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)
  • Upstream Messages
      -
    1. Receive return receipts
      2. +
    2. Receive delivery receipts
  • Flow Control
    • @@ -45,11 +45,15 @@ page.title=GCM Cloud Connection Server (XMPP) -

    The GCM Cloud Connection Server (CCS) is an XMPP endpoint that provides a +

    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.

    +

    Note: The content in this document +applies to +GCM with Chrome apps as well as Android. +

    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:

    @@ -259,22 +263,6 @@ message is "nack". A NACK message contains:

    </message> -

    Quota exceeded:

    - -
    <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>
-
    - -

    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}.

    @@ -312,11 +300,11 @@ message should be immediately retried over another connection. {@code INVALID_JSON} The JSON message payload is not valid. - -{@code QUOTA_EXCEEDED} -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. +{@code DEVICE_MESSAGE_RATE_EXCEEDED} +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. {@code SERVICE_UNAVAILABLE} @@ -429,15 +417,17 @@ response to the above message:

    </gcm> </message> -

    Receive return receipts

    +

    Receive delivery receipts

    -

    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.

    +

    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.

    To enable this feature, the message your 3rd-party app server sends to CCS must include a field called "delivery_receipt_requested". When this field is set to -true, CCS sends a return receipt. Here is an XMPP stanza containing a JSON +true, CCS sends a delivery receipt when a device confirms that it received a particular message.

    + +

    Here is an XMPP stanza containing a JSON message with "delivery_receipt_requested" set to true:

    <message id="">
@@ -457,8 +447,10 @@ message with "delivery_receipt_requested" set to tr
 </message>
    -

    Here is an example of a receipt notification message that CCS sends back to your 3rd-party -app server:

    + + +

    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:

    <message id="">
@@ -483,12 +475,12 @@ app server:
    
 
      
   
    • The {@code "message_type"} is set to {@code "receipt"}.
   
    • 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.
      • 
   
    • The receipt message ID consists of the original message ID, but with a
-dr: prefix. Your 3rd-party app server must send an ACK back with this ID,
+dr2: prefix. Your 3rd-party app server must send an ACK back with this ID,
 which in this example is {@code dr2:m-1366082849205}.
      • 
-  
    • The original message ID and status are inside the
+  
    • The original message ID, the device registration ID, and the status are inside the
 {@code "data"} field.
      • 
 
    
 
-- 
cgit v1.1