Ihre Serverumgebung und FCM

Die Serverseite von Firebase Cloud Messaging besteht aus zwei Komponenten:

  • Der FCM - Backend von Google bereitgestellt.
  • Ihr App - Server oder andere vertrauenswürdigen Server - Umgebung , wo Ihre Serverlogik läuft, wie Cloud - Funktionen für die Firebase oder andere Cloud - Umgebungen von Google verwaltet.

Ihre App-Server- oder vertrauenswürdige Serverumgebung sendet Nachrichtenanforderungen an das FCM-Back-End, das dann Nachrichten an Client-Apps weiterleitet, die auf den Geräten der Benutzer ausgeführt werden.

Anforderungen an die vertrauenswürdige Serverumgebung

Ihre App-Serverumgebung muss die folgenden Kriterien erfüllen:

  • Kann richtig formatierte Nachrichtenanforderungen an das FCM-Backend senden.
  • Able Anfragen zu bearbeiten und sende sie mit exponentieller Backoff-.
  • Kann Server-Autorisierungsanmeldeinformationen und Client-Registrierungstoken sicher speichern.
  • Für das XMPP-Protokoll (sofern verwendet) muss der Server in der Lage sein, Nachrichten-IDs zu generieren, um jede gesendete Nachricht eindeutig zu identifizieren (das FCM-HTTP-Backend generiert Nachrichten-IDs und gibt sie in der Antwort zurück). XMPP-Nachrichten-IDs sollten pro Absender-ID eindeutig sein.

Auswahl einer Serveroption

Sie müssen auf eine Art und Weise entscheiden , mit FCM - Servern zu interagieren: entweder die Verwendung von Firebase Admin SDK oder die rohen Protokolle. Aufgrund seiner Unterstützung für gängige Programmiersprachen und seiner praktischen Methoden zur Handhabung der Authentifizierung und Autorisierung ist das Firebase Admin SDK die empfohlene Methode.

Zu den Optionen für die Interaktion mit FCM-Servern gehören die folgenden:
  • Das Firebase Admin SDK, die Unterstützung für hat Knoten , Java , Python , C # und Go .
  • Der FCM HTTP - API v1 , das die bisher der Protokolloptionen nach oben ist, mit sicherer Autorisierung und flexible plattformübergreifende Messaging - Funktionen (die Firebase Admin SDK auf diesem Protokoll basiert und bietet alle seine inhärenten Vorteile).
  • Das Erbe HTTP - Protokoll.
  • Das XMPP - Server - Protokoll. Beachten Sie, dass Sie XMPP verwenden müssen, wenn Sie Upstream-Messaging von Ihren Clientanwendungen verwenden möchten.

Firebase Admin SDK für FCM

Die Admin FCM API übernimmt die Authentifizierung beim Backend und erleichtert das Senden von Nachrichten und die Verwaltung von Themenabonnements. Mit dem Firebase Admin SDK können Sie:

  • Nachrichten an einzelne Geräte senden
  • Senden Sie Nachrichten an Themen und Bedingungsanweisungen, die einem oder mehreren Themen entsprechen.
  • Geräte für Themen abonnieren und abbestellen
  • Erstellen Sie Nachrichtennutzlasten, die auf verschiedene Zielplattformen zugeschnitten sind

Das Admin Node.js SDK bietet Methoden zum Senden von Nachrichten an Gerätegruppen.

So richten Sie die Firebase Admin SDK finden Sie die Firebase Admin SDK zu Ihrem Server hinzufügen . Wenn Sie bereits ein Projekt Firebase, beginnen Sie mit dem SDK hinzufügen . Dann, wenn die Firebase Admin SDK installiert ist, können Sie mit dem Schreiben Logik starten Build Sendeaufträge .

FCM-Serverprotokolle

Derzeit bietet FCM diese Rohserverprotokolle:

Ihr App-Server kann diese Protokolle separat oder zusammen verwenden. Da es sich um die aktuellste und flexibelste Methode zum Senden von Nachrichten an mehrere Plattformen handelt, wird die FCM HTTP v1-API empfohlen, wo immer dies möglich ist. Wenn Ihre Anforderungen Upstream-Messaging von Geräten zum Server umfassen, müssen Sie das XMPP-Protokoll implementieren.

XMPP-Messaging unterscheidet sich von HTTP-Messaging in folgenden Punkten:

  • Upstream-/Downstream-Nachrichten
    • HTTP: Nur Downstream, Cloud-to-Device.
    • XMPP: Upstream und Downstream (Gerät-zu-Cloud, Cloud-zu-Gerät).
  • Messaging (synchron oder asynchron)
    • HTTP: Synchron. App-Server senden Nachrichten als HTTP-POST-Anforderungen und warten auf eine Antwort. Dieser Mechanismus ist synchron und verhindert, dass der Absender eine weitere Nachricht sendet, bis die Antwort eingegangen ist.
    • XMPP: Asynchron. App-Server senden/empfangen Nachrichten an/von all ihren Geräten mit voller Leitungsgeschwindigkeit über persistente XMPP-Verbindungen. Der XMPP-Verbindungsserver sendet asynchron Bestätigungs- oder Fehlerbenachrichtigungen (in Form spezieller ACK- und NACK-JSON-codierter XMPP-Nachrichten).
  • JSON
    • HTTP: JSON-Nachrichten, die als HTTP POST gesendet werden.
    • XMPP: In XMPP-Nachrichten gekapselte JSON-Nachrichten.
  • Klartext
    • HTTP: Als HTTP POST gesendete Nur-Text-Nachrichten.
    • XMPP: Nicht unterstützt.
  • Multicast-Downstream-Senden an mehrere Registrierungstoken.
    • HTTP: Wird im JSON-Nachrichtenformat unterstützt.
    • XMPP: Nicht unterstützt.

Implementieren des HTTP-Serverprotokolls

Um eine Nachricht zu senden, gibt der App-Server eine POST-Anfrage mit einem HTTP-Header und einem HTTP-Body aus, der aus JSON-Schlüsselwertpaaren besteht. Ausführliche Informationen zu den Header und Body - Optionen finden Sie Build - App - Server senden Anfragen

Implementieren des XMPP-Serverprotokolls

Die JSON-Nutzlast für FCM-Nachrichten ähnelt dem HTTP-Protokoll, mit folgenden Ausnahmen:

  • Es gibt keine Unterstützung für mehrere Empfänger.
  • FCM fügt das Feld message_id , die erforderlich ist. Diese ID identifiziert die Nachricht in einer XMPP-Verbindung eindeutig. Die ACK oder NACK von FCM verwendet die message_id eine Nachricht von App - Servern FCM geschickt zu identifizieren. Daher ist es wichtig , dass diese message_id nicht nur eindeutig sein (pro Sender - ID ), aber immer vorhanden.
  • XMPP verwendet den Serverschlüssel, um eine dauerhafte Verbindung zu FCM zu autorisieren. Siehe Autorisieren senden Anfragen für weitere Informationen.

Zusätzlich zu dem regulären FCM Meldungen, Steuernachrichten, die von dem angegebenen gesendet message_type Feld in dem Objekt JSON. Der Wert kann entweder 'ack' oder 'nack' oder 'control' sein (siehe Formate unten). All FCM - Nachricht mit einem unbekannten message_type kann von Ihrem Server ignoriert.

Für jede Gerätenachricht, die Ihr App-Server von FCM empfängt, muss er eine ACK-Nachricht senden. Es muss nie eine NACK-Nachricht senden. Wenn Sie für eine Nachricht keine ACK senden, sendet FCM sie beim nächsten Aufbau einer neuen XMPP-Verbindung erneut, es sei denn, die Nachricht läuft zuerst ab.

FCM sendet auch eine ACK oder NACK für jede Server-zu-Gerät-Nachricht. Wenn Sie beides nicht erhalten, bedeutet dies, dass die TCP-Verbindung mitten im Vorgang geschlossen wurde und Ihr Server die Nachrichten erneut senden muss. Siehe Flow Control für weitere Einzelheiten.

Siehe die Protokoll - Referenz für eine Liste aller Nachrichtenparameter.

Anfrageformat

Nachricht mit Nutzlast — Benachrichtigungsnachricht

Hier ist eine XMPP-Strophe für eine Benachrichtigungsnachricht:

<message id="">
  <gcm xmlns="google:mobile:data">
  {
     "to":"REGISTRATION_ID",  // "to" replaces "registration_ids"
     "notification": {
        "title": "Portugal vs. Denmark”,
        "body”: "5 to 1”
      },
      "time_to_live":"600"
  }
  </gcm>
</message>

Nachricht mit Nutzlast — Datennachricht

Hier ist eine XMPP-Zeilengruppe, die die JSON-Nachricht von einem App-Server an FCM enthält:

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

Antwortformat

Eine FCM-Antwort kann drei mögliche Formen haben. Die erste ist eine normale 'ack'-Nachricht. Wenn die Antwort jedoch einen Fehler enthält, kann die Nachricht zwei verschiedene Formen annehmen, die unten beschrieben werden.

ACK-Nachricht

Hier ist eine XMPP-Zeilengruppe, die die ACK/NACK-Nachricht von FCM an den App-Server enthält:

<message id="">
  <gcm xmlns="google:mobile:data">
  {
      "from":"REGID",
      "message_id":"m-1366082849205"
      "message_type":"ack"
  }
  </gcm>
</message>

NACK-Nachricht

Ein NACK Fehler ist eine regelmäßige XMPP - Nachricht , in der die message_type Statusmeldung „nack“. Eine NACK-Nachricht enthält:

  • Ein NACK-Fehlercode.
  • Eine NACK-Fehlerbeschreibung.

Nachfolgend finden Sie einige Beispiele.

Schlechte Registrierung:

<message>
  <gcm xmlns="google:mobile:data">
  {
    "message_type":"nack",
    "message_id":"msgId1",
    "from":"SomeInvalidRegistrationToken",
    "error":"BAD_REGISTRATION",
    "error_description":"Invalid token on 'to' field: SomeInvalidRegistrationId"
  }
  </gcm>
</message>

Ungültige JSON:

<message>
 <gcm xmlns="google:mobile:data">
 {
   "message_type":"nack",
   "message_id":"msgId1",
   "from":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
   "error":"INVALID_JSON",
   "error_description":"InvalidJson: JSON_TYPE_ERROR : Field \"time_to_live\" must be a JSON java.lang.Number: abc"
 }
 </gcm>
</message>

Gerätenachrichtenrate überschritten:

<message id="...">
  <gcm xmlns="google:mobile:data">
  {
    "message_type":"nack",
    "message_id":"msgId1",
    "from":"REGID",
    "error":"DEVICE_MESSAGE_RATE_EXCEEDED",
    "error_description":"Downstream message rate exceeded for this registration id"
  }
  </gcm>
</message>

Finden Sie in das Server - Handbuch für eine vollständige Liste des NACK - Fehlercodes. Sofern nicht anders angegeben, sollte eine NACK-Nachricht nicht wiederholt werden. Unerwartete NACK - Fehlercodes sollte die gleiche wie behandelt wird INTERNAL_SERVER_ERROR .

Strophenfehler

In bestimmten Fällen können Sie auch einen Zeilengruppenfehler erhalten. Ein Zeilengruppenfehler enthält:

  • Fehlercode der Zeilengruppe.
  • Zeilengruppenfehlerbeschreibung (Freitext).

Beispielsweise:

<message id="3" type="error" to="123456789@fcm.googleapis.com/ABC">
  <gcm xmlns="google:mobile:data">
     {"random": "text"}
  </gcm>
  <error code="400" type="modify">
    <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
      InvalidJson: JSON_PARSING_ERROR : Missing Required Field: message_id\n
    </text>
  </error>
</message>

Kontrollnachrichten

FCM muss in regelmäßigen Abständen eine Verbindung trennen, um einen Lastausgleich durchzuführen. Bevor die Verbindung geschlossen wird , sendet FCM eine CONNECTION_DRAINING Nachricht , um anzuzeigen , dass die Verbindung abgelassen wird, und wird in Kürze geschlossen werden. "Draining" bezieht sich auf das Unterbrechen des Nachrichtenflusses, der in eine Verbindung eingeht, aber das Fortsetzen von allem, was sich bereits in der Pipeline befindet, zuzulassen. Wenn Sie eine erhalten CONNECTION_DRAINING Nachricht, sollten Sie sofort beginnen , Nachrichten an eine andere FCM - Verbindung senden, eine neue Verbindung bei Bedarf öffnen. Sie sollten jedoch die ursprüngliche Verbindung geöffnet lassen und weiterhin Nachrichten empfangen, die möglicherweise über die Verbindung eingehen (und diese bestätigen). FCM übernimmt das Einleiten einer Verbindung, wenn sie bereit ist.

Die CONNECTION_DRAINING Nachricht sieht wie folgt aus :

<message>
  <data:gcm xmlns:data="google:mobile:data">
  {
    "message_type":"control"
    "control_type":"CONNECTION_DRAINING"
  }
  </data:gcm>
</message>

CONNECTION_DRAINING ist derzeit der einzige control_type unterstützt.

Ablaufsteuerung

Jede an FCM gesendete Nachricht erhält entweder eine ACK- oder eine NACK-Antwort. Nachrichten, die keine dieser Antworten erhalten haben, gelten als ausstehend. Wenn die Anzahl der ausstehenden Nachrichten 100 erreicht, sollte der App-Server das Senden neuer Nachrichten einstellen und warten, bis der FCM einige der vorhandenen ausstehenden Nachrichten bestätigt, wie in Abbildung 1 dargestellt:

Abbildung 1. Nachricht / ack fließen.

Um eine Überlastung des App-Servers zu vermeiden, stoppt FCM das Senden, wenn zu viele unbestätigte Nachrichten vorhanden sind. Daher sollte der App-Server Upstream-Nachrichten, die von der Client-Anwendung über FCM empfangen werden, so schnell wie möglich "ACK" um einen konstanten Fluss eingehender Nachrichten aufrechtzuerhalten. Das oben erwähnte Limit für ausstehende Nachrichten gilt nicht für diese ACKs. Auch wenn die Anzahl ausstehender Nachrichten 100 erreicht, sollte der App-Server weiterhin ACKs für Nachrichten senden, die von FCM empfangen wurden, um die Zustellung neuer Upstream-Nachrichten nicht zu blockieren.

ACKs sind nur im Kontext einer Verbindung gültig. Wenn die Verbindung geschlossen wird, bevor eine Nachricht bestätigt werden kann, sollte der App-Server warten, bis der FCM die Upstream-Nachricht erneut sendet, bevor er sie erneut bestätigt. Ebenso sollten alle anstehenden Nachrichten, für die vor dem Schließen der Verbindung kein ACK/NACK vom FCM empfangen wurde, erneut gesendet werden.