Google Cloud Messaging (GCM) is a free service that enables developers to send downstream messages (from servers to GCM-enabled client apps), and upstream messages (from the GCM-enabled client apps to servers). This could be a lightweight message telling the client app that there is new data to be fetched from the server (for instance, a "new email" notification informing the app that it is out of sync with the back end), or it could be a message containing up to 4kb of payload data (so apps like instant messaging can consume the message directly). The GCM service handles all aspects of queueing of messages and delivery to and from the target client app.

구글클라우드 메시징(GCM)은 개발자가 다운스트림 메시지( 서버에서 GCM이 가능한 클라이언트 앱으로)와 업스트림메시지(GCM이가능한 앱에서 써버로)를 가능하게하는 공짜서비스다.

이 가벼운 메시지는 서버로부터 새로운 메시지(예를들면 백엔드와 동기화하지 않는 앱에서 '새 메일'정보를 알려주는 메시지)를 가지고 오거나 최대 4kb의 데이터를 가지고 온다(앱이 메시지를 바로 사용할 수 있다.)  GCM은 모든면의 메시지쿼리를 다룰 수있고, 타겟 클라이언트앱으로 메시지를 전달하거나, 가져올 수 있다.

Key Concepts 주요 컨셉

This table summarizes the key terms and concepts involved in GCM. It is divided into these categories:

이 표는 GCM의 주요 컨셉과 용어를 요학안다. 카테고리별로 나누어져 있다.

• Components — The entities that play a primary role in GCM.
• 컴포넌트 - GCM에서 개별적 역할을 가지고있는 독립체(entities)
• Credentials — The IDs and tokens that are used in GCM to ensure that all parties have been authenticated, and that the message is going to the correct place.
• 자격(credentials) - GCM에서 권한을 주고, 메시지를 정확한곳으로 인도하는 토큰과 아이디들

Table 1. GCM components and credentials. 표1. GCM컴포넌트와 자격들

Architectural Overview 구조적(Architectual) 개요

A GCM implementation includes a Google-provided connection server, a 3rd-party app server that interacts with the connection server, and a GCM-enabled client app. For example, this diagram shows GCM communicating with a client app on an Android device:

GCM은 구글이 제공한 컨넥션서버, 컨낵션서버와 소통하는 서드파티앱서버, GCM이 가능한 클라이언트 앱을 포함한다.

예를들어, 이 다이어그램은 안드로이드 디바이스에 있는 클라이언트앱이 GCM과 커뮤니케이션 하는 모습을 보여주는 다이어그램이다.

Figure 1. GCM Architecture.   그림1. GCM구조(Architecture)

This is how these components interact:

컴포넌트들이 소통하는 방법:

• Google-provided GCM Connection Servers take messages from a 3rd-party app server and send these messages to a GCM-enabled client app (the "client app"). Currently Google provides connection servers forHTTP and XMPP.
• 구글이 제공하는 GCM 컨넥션 서버는 서트파티 앱서버로 부터 메시지를 전달받는다, 그리고 클라이언트 앱으로 메시지를 전송한다. 현재 구글은 HTTP와 XMPP서버 컨넥션을 제공한다.
• The 3rd-Party App Server is a component that you implement to work with your chosen GCM connection server(s). App servers send messages to a GCM connection server; the connection server enqueues and stores the message, and then sends it to the client app. For more information, see Implementing GCM Server.
• 서드파티 앱 서버는 당신이 선택한 GCM연결 서버를 포함하는 요소(component)이다. 앱서버는 메시지를GCM으로 보낸다; 컨넥션 서버는 큐에 메시지를 넣고 저장한다. 그리고 클라이언트앱으로 전송한다. 더많은 정보는 Implementing GCM Server를 참고해라.
• The Client App is a GCM-enabled client app. To receive GCM messages, this app must register with GCM and get a registration ID. If you are using the XMPP (CCS) connection server, the client app can send "upstream" messages back to the 3rd-party app server. For more information on how to implement the client app, see the documentation for your platform.
• 클라이언트앱은 GCM이 가능한 앱이다. GCM메시지를 받기 위해서는 이 앱은 GCM에 등록하여 registrationID를 얻어야만한다. 만약 XMPP(CCS) 컨넥션서버를 사용한다면, 클라이언트앱은 서드파티앱서버로 업스트림메시지를 전송할 수 있다.  클라이언트앱에  포함시키기위한 더 많은 정보를 위해서 당신의 플랫폼 문서를 봐라

Lifecycle Flow 라이프사이클 흐름

• Register to enable GCM. A client app registers to receive messages. For more discussion, see Register to enable GCM.
• GCM이 가능하게 등록한다. 클라이언트앱을 메시지를 받기 위하여 등록한다. 더많은 설명을 보려면 REgister to Enable GCM을 봐라
• Send and receive downstream messages.
다운스트림 메시지 보내기

• Send a message. A 3rd-party app server sends messages to the client app:

메시지 보내개. 서드파티앱서버가 클라이언트앱으로 메시지를 보낸다:


1. The 3rd-party app server sends a message to GCM connection servers.  서드파티앱이 GCM컨넥션 서버에 메시지를 전송한다.
2. The GCM connection server enqueues and stores the message if the device is offline.  디바이스가 오프라인일 경우 컨넥션 서버는 메시지를 큐에 넣고 저장한다.
3. When the device is online, the GCM connection server sends the message to the device. 디바이스가 온라인이 되었을때 GCM 컨넥션 서버는 디바이스로 메시지를 보낸다.
4. On the device, the client app receives the message according to the platform-specific implementation. See your platform-specific documentation for details. 디바이스에서, 클라이언트앱을 platform-specific 확장을 통하여 메시지를 받는다. 세부사항을 위해서 당신의 디바이스의 platform0specific문서를 봐라
5. Receive a message. A client app receives a message from a GCM server. See your platform-specific documentation for details on how a client app in that environment processes the messages it receives. 메시지 수신, GCM서버로부터 메시지를 수신한 클라이언트앱. 당신의 platform-specific문서를 봐라 클라이언트앱이 수신된 메시지를 처리하는 환경 프로세스를 어떻게 처리하는지 알기 위하여
• Send and receive upstream messages. This feature is only available if you're using the XMPP Cloud Connection Server (CCS).

• 업스트림 메시지의 전송과 수신. 이 특징은 오직 당신이 XMPP Cloud Connection(CSS)를 사용할때만 적용된다.

  • Send a message. A client app sends messages to the 3rd-party app server: 메시지보내기. 클라이언트앱이 서드파티앱서버로 메시지를 보낸다.
    1. On the device, the client app sends messages to XMPP (CCS).See your platform-specific documentation for details on how a client app can send a message to XMPP (CCS).  디바이스에서, 클라이언트앱은 XMPP로 메시지를 보낸다. 클라이언트앱이 XMPP로 메시지를 보내는 방법에 대한 세부사항을 위해서 당신의 platform-specific 문서를 봐라.
    2. XMPP (CCS) enqueues and stores the message if the server is disconnected. XMPP(CCS)는 서버가 연결이 안돼있을경우 메시지를 큐에 넣고, 저장한다.
    3. When the 3rd-party app server is re-connected, XMPP (CCS) sends the message to the 3rd-party app server. 서드파티앱서버가 연결되었을때 XMPP(CCS)는 서드파티 앱서버로 메시지를 보낸다.
  • Receive a message. A 3rd-party app server receives a message from XMPP (CCS) and then does the following: 메시지 수신. 서드파티 앱서버는 아래사항에 따라서 XMPP(CCS)로부터 메시지를 받는다.
    1. Parses the message header to verify client app sender information. 클라이언트 앱 전송자의 절보를 확인하기위해 메시지 해더를 파싱한다.
    2. Sends "ack" to GCM XMPP connection server to acknowledge receiving the message.  메시지를 수신받았다는 것을 GCM XMPP연결서버에 알려주기 위해 "ack"를 보낸다.
    3. Optionally parses the message payload, as defined by the client app. 선택적으로 메시지 데이터(payload)를 파싱한다. 클라이언트앱을 정의하기 위해서

Register to enable GCM GCM을 가능하게 하기위한 등록

Regardless of the platform you're developing on, the first step a client app must do is register with GCM. This section covers some of the general best practices for registration and unregistration. See your platform-specific docs for details on writing a GCM-enabled client app on that platform.

당신이 개발해놓플랫폼의 종류와 상관없이. 클라이언트 앱의 첫번째 스탭은 GCM에 등록하는것이다. 이 섹션은 등록과 등록해지의 가장좋은 방법이다.

Keeping the Registration State in Sync 동기화에서 등록 상태 유지

Whenever the app registers as described in Implementing GCM Client, it should save the registration ID for future use, pass it to the 3rd-party server to complete the registration, and keep track of whether the server completed the registration. If the server fails to complete the registration, the client app should retry passing the registration ID to 3rd-party app server to complete the registration. If this continues to fail, the client app should unregister from GCM.

앱이 Implementing GCM Client 에서 말해놓은 등록을 할땐 언제라도, 미래의 사용하고, 서드파티 앱서버에 완벽하게 등록하고, 서버가 등록여부를 완전히 알고있게하기 위해서 registrationID를 저장해 놔야한다. 만약 서버가 등록에 실패하면, 클라이언트앱은 registrationID를 서트파티앱서버에 다시 전송해서 완전한 등록을 해야한다. 만일 계속해서 실패하면 클라이언트앱은 GCM에서 등록해지된다.

There are also two other scenarios that require special care:  특별한 관리를 위한 두가지 시나리오가 있다.

• Client app update   클라이언트 앱 업데이트
• Backup and restore   백업과 저장

Client app update: When a client app is updated, it should invalidate its existing registration ID, as it is not guaranteed to work with the new version. The recommended way to achieve this validation is by storing the current app version when a registration ID is stored. Then when the app starts, compare the stored value with the current app version. If they do not match, invalidate the stored data and start the registration process again.

클라이언트 앱 업데이트: 클라이언트 앱이 업데이트될따, 기존의 registrationid는 만료된다. 따라서 기존의 registration ID는 새로운 버전에서의 동작을 보장하지 않는다.  유혀성을 위해 추천되는 방법은 registration ID가 저장될때 현재의 앱 버전을 저장하는것이다. 그래서 앱이 실행될때 저장된 정보와 현재 앱버전을 비교한다. 만약 두 정보가 일지하지않는다면 저장된 데이터(registrationID)를 폐기하고, 등록 프로세스를 다시한번 실행한다.

Backup and restore: You should not save the registration ID when an app is backed up. This is because the registration ID could become invalid by the time the app is restored, which would put the app in an invalid state (that is, the app thinks it is registered, but the server and GCM do not store that registration ID anymore—thus the app will not get more messages). The best practice is to initiate the registration process as if the app has been installed for the first time.

백업과 저장: 앱이 백업될때 registrationID를 저장하면 안된다. 왜냐하면 registrationID는 앱이 다시 저장될때 만료되기 때문이다. 백업시 registrationID를 저장한다면 앱을 권한이 없는 상태로 만든다(왜냐면 앱은 지가 등록되어있다고 생각하지만 서버와 GCM은 해당 registrationID를 더이상 가지고있지 않기떄문이다. 그래서 앱은 더이상 메시지를 받을 수 없다.) 가장 좋은 방법은 앱이 처음 인트톨될때터럼 초기화 하는 방법이다.

Canonical IDs  예전 ID들

If a bug in the app triggers multiple registrations for the same device, it can be hard to reconcile state and you might end up with duplicate messages. 

만약 버그가 한 디바이스에서 여러 등록을 시켜버린다면,  다시 조정하기가 아주 어렵다 그래서 너는 메시지를 복제하게되는 상황에 처하게 될것이다.

GCM provides a facility called "canonical registration IDs" to easily recover from these situations. A canonical registration ID is defined to be the ID of the last registration requested by your app. This is the ID that the server should use when sending messages to the device.

GCM은  해당 상황에서 쉽게 벗어나게 해주기 위하여 "canonical registration IDs"라고 불리는 기능을 제공한다. conical registrationID는 앱에서 보낸 마지막 등록아이디로 정의되어있다. 이 아이디가 서버에서 디바이스로 보낼떄 써야하는 ID이다.

If later on you try to send a message using a different registration ID, GCM will process the request as usual, but it will include the canonical registration ID in the registration_id field of the response. Make sure to replace the registration ID stored in your server with this canonical ID, as eventually the ID you're using will stop working.

만일 나중에 당신이 다른 registrationID를 이용하여 메지시를 보내려고한다면, GCM 프로세스는 일반적 상황과 같게 요청할것이다. 그러나 그것은 응답(response)의 registration_id필드 안에있는 canonical registration ID를 포함할 것이다. 서버에 저장된 registrationID를 이 conanoical ID로 대체하기위해서 당신이 사용하던 ID는 동작을 멈출것이다.

Automatic Retry Using Exponential Back-Off  Exponential Back-Off를 이요한 자동 재요청

When registration or unregistration fails, the app should retry the failed operation.

등록 또는 등록해지가 실패했을때 앱은 실패한요청을 다시 시도해야한다.

In the simplest case, if your app attempts to register and GCM is not a fundamental part of the app, the app could simply ignore the error and try to register again the next time it starts. Otherwise, it should retry the previous operation using exponential back-off. In exponential back-off, each time there is a failure, it should wait twice the previous amount of time before trying again.

간단한 케이스에서, 너의 앱이 등록을 시도했는데 GCM이 앱의 구성요소가 아닐때, 앱을 앱은 간단하게 에러를 무시하고, 다음번에 앱이 실행될때 다시 시도한다.  그렇지않다면, exponential back-off를 이용하여 미리 재시도를 해야한다. exponential back-off에서 매번 실패가 있다면 다시 시도하기전에 두배로 기다려야한다.

Unregistration 등록해지

This section explains when you should unregister in GCM and what happens when you do.

이 섹션은 당신이 GCM에서 등록을 해지할 시기와 등록을 해지할때 일어나는 일에대해 설명한다.

Why you should rarely unregister   왜 당신은 드물게 등록해지를 해야하는가

You should only need to unregister in rare cases, such as if you want an app to stop receiving messages, or if you suspect that the registration ID has been compromised. In general, once an app has a registration ID, you shouldn't need to change it.

당신은 아주 드물게 등록해지를 해야만한다,  당신이 메시지를 더이상 받기를 원하지 않을때, 또는 registration ID가 제대로 작동하지 못했다고 생각될때 같은 경우 등록을 해지한다. 일반적으로 앱이 한번 regsistration ID를 생성하면 변경할 필요가 없다.

In particular, you should never unregister your app as a mechanism for logout or for switching between users, for the following reasons:

특히, 아래와 같은이유로 당신을 로그아웃시나, 유저를 변경할시 등록해지를 하는 행위를 절대로 하면 안된다.

• A registration ID isn't associated with a particular logged in user. If you unregister and then re-register, GCM may return the same ID or a different ID—there's no guarantee either way.  registrationID는 로그인한 유저와는 연관되지 않는다. 만약 등록해지 후 재등록을 하면 GCM은 같은 ID를 리턴하거나 다른 아이디를 리턴하는데 둘중 어떤것이 될지는 알 수 없다.
• Unregistration may take up to 5 minutes to propagate.      등록해지가 될때까지 최대 5분이 소요된다.
• After unregistration, re-registration may again take up to 5 minutes to propagate. During this time messages may be rejected due to the state of being unregistered, and after all this, messages may still go to the wrong user.  등록해지 이후에  재등록까지는 다시 최대 5분이 소요된다. 이 소요시간동안 메시지는 전달되지 않을것이다. 그리고 이 모든 메시지는 다른 유저에게 갈 수 있다.

To make sure that messages go to the intended user:     메시지가 원하는(intented)유저에게 전달되는것을 보장하기

• Your app server can maintain a mapping between the current user and the registration ID. 당신의 앱서버는 현재 유저와 registration ID 사이의 매핑을 유지(matain)할 수 있다.
• The app can then check to ensure that messages it receives match the logged in user. 앱은 로그인한 유저가 메시지를 받있는지 확인할 수 있다.

How unregistration works   등록해지는 어떻게 이루어지는가.

A client app can be automatically unregistered after it is uninstalled. However, this process does not happen right away. What happens in this scenario is as follows:

클라이언트 앱은 제거된(uninstalled)후 자동으로 등록을 해지한다. 이 프로세스는 바로 작동하지는 않는다. 아래의 시나리오에서 어떤일이 일루어지는지 보자

1. The end user uninstalls the client app. 유저가 앱을 지운다.
2. The 3rd-party app server sends a message to GCM server. 서드파티앱서버가 GCM에 메시지를 보낸다.
3. The GCM server sends the message to the GCM client on the device. GCM서버가 클라이언트의 디바이스에 메시지를 보낸다.
4. The GCM client on the device receives the message and detects that the client app has been uninstalled; the detection details depend on the platform on which the client app is running.  디바이스의 GCM클라이언트는 메시지를 받는다 그리고 클라이언트 앱이 지워진것을 발변한다;  발견에 관한 세부사항은 플랫폼에 어떤 클라이언트앱이 동작하고있는가에따라 다르다.
5. The GCM client on the device informs the GCM server that the client app was uninstalled.  GCM클라이언트는 GCM서버에 앱이 삭제되었단것을 알려준다.
6. The GCM server marks the registration ID for deletion. GCM서버는 registrationID에 삭제되었다는 마크를한다.
7. The 3rd-party app server sends a message to GCM. 서드파티 앱서버가 메시지를 GCM에 전송한다.
8. The GCM returns a NotRegistered error message to the 3rd-party app server. GCM은 'NotRegistered'에러메시지를 서드파티앱서버에 리턴한다.
9. The 3rd-party app server deletes the registration ID. 서드파티앱서버는 registrationID를 제거한다.

Note that it might take a while for the registration ID be completely removed from GCM. Thus it is possible that messages sent during step 7 above gets a valid message ID as response, even though the message will not be delivered to the client app. Eventually, the registration ID will be removed and the server will get a NotRegisterederror, without any further action being required from the 3rd-party server (this scenario happens frequently while an app is being developed and tested).     

registrationID가 GCM에서 완전하게 지워지기까지는 시간이 좀 걸린다. 이렇게해서 7단계보다 위로 메시지가 보내지는것이 가능한것은 응답으로 유효한 메시지 아이디를 받는것이 가능하다. 비록 클라이언트앱으로 메시지가 전달되지 않았다고 할지라도. 결국 registrationID는 지워질 것이다 그리고 서버는 notregistered에러를 받게 될 것이다. 서드파티앱서버에서 더나아간 행위가 요구되는것 없이(이 시나리오는 테스트에서 자주 발생한다.)