GCM 구글문서 번역(2) - How is GCM Different from C2DM

가장 중요한 포인트인, How is GCM Different from C2DM

How is GCM Different from C2DM?

GCM builds on the core foundation of C2DM. Here is what's different:

Simple API Key

To use the GCM service, you need to obtain a Simple API Key from Google APIs console page. For more information, see Getting Started. Note that GCM only accepts Simple API Key—using ClientLogin or OAuth2 tokens will not work.

→ API 키를 쉽게 받을 수 있습니다.

Sender ID

In C2DM, the Sender ID is an email address. In GCM, the Sender ID is a project ID that you acquire from the API console, as described in Getting Started.

→ C2DM에서는 Sender ID가 이메일 주소였지만 GCM에서는 Sender ID를 프로젝트 ID로 사용합니다.

JSON format

GCM HTTP requests support JSON format in addition to plain text. For more information, see theArchitectural Overview.

→ GCM은 JSON포멧의 HTTP 요청을 지원합니다. 기존에 있던 평문도 사용가능 합니다. JSON으로 데이터를 보내면 Parsing해서 쓰기 좋게 변경되겠지요 :)

Multicast messages

In GCM you can send the same message to multiple devices simultaneously. For example, a sports app wanting to deliver a score update to fans can now send the message to up to 1000 registration IDs in the same request (requires JSON). For more information, see the Architectural Overview.

→GCM은 동일한 메시지를 다수의 디바이스에 동시에 보낼 수 있습니다.1000개의 Registration ID(이하 RID)들에게 동시에 보낼 수 있습니다.

Multiple senders

Multiple parties can send messages to the same app with one common registration ID. For more information, see Advanced Topics.

→ 한 App(1개의 common RID)에 다수의 서버/개발자가 메시지를 전송 할 수 있습니다.

Time-to-live messages

Apps like video chat and calendar apps can send expiring invitation events with a time-to-live value between 0 and 4 weeks. GCM will store the messages until they expire. A message with a time-to-live value of 0 will not be stored on the GCM server, nor will it be throttled. For more information, see Advanced Topics.

→ Time-to-live 는 메시지 포멧에 포함되는 항목을 선택하여 0~4주간의 시간 동안 GCM서버에 메시지를 저장하는 기능을 제공합니다.

Messages with payload

Apps can use "messages with payload" to deliver messages of up to 4 Kb. This would be useful in a chat application, for example. To use this feature, simply omit the collapse_key parameter and messages will not be collapsed. GCM will store up to 100 messages. If you exceed that number, all messages will be discarded but you will receive a special message. If an application receives this message, it needs to sync with the server. For more information, see Advanced Topics.

→ 실제 전달할 수 있는 메시지 데이터 양은 4 Kb로, 채팅어플리케이션에 유용합니다. collapsed Key를 활용하여 사용자 디바이스가 메시지를 전달 받지 못한경우 100개까지 서버에 메시지를 저장합니다. 100개가 넘을 경우에는 서버와 통신을 하여 데이터를 가져올 수 있도록 제공합니다. 100개가 넘는 경우에는 모든 메시지가 버려지고 특별한 메시지가 전달됩니다. 이 메시지를 받으면 서버와의 통신이 필요합니다.

Canonical registration ID

There may be situations where the server ends up with 2 registration IDs for the same device. If the GCM response contains a registration ID, simply replace the registration ID you have with the one provided. With this feature your application doesn't need to send the device ID to your server anymore. For more information, see Advanced Topics. GCM also provides helper libraries (client and server) to make writing your code easier.

→ 2개의 서버에서 동일한 디바이스에 각기 다른 RID로 메시지를 보낼 때, Canonical registration  ID를 활용하여 추후에는 이 디바이스에 IDs를 바꿀 수 있습니다.

---

내용을 알고 있는 부분은 포함해서 이해를 돕도록 넣었습니다.

---

확인해야 할 부분.

Exponential Back-off : GCM에서 개발사에서 보낸 메시지에 응답하지 않을때, 지수승으로 올라가면서~ GCM 서버에 재요청하는 기능입니다.