Google, Siyah topluluklar için ırksal eşitliği ilerletmeye kararlıdır. Nasıl olduğunu gör.
Bu sayfa, Cloud Translation API ile çevrilmiştir.
Switch to English

Sunucu ortamınız ve FCM

Firebase Bulut Mesajlaşma'nın sunucu tarafı iki bileşenden oluşur:

  • Google tarafından sağlanan FCM arka ucu .
  • Uygulama sunucunuz veya Firebase için Bulut İşlevleri veya Google tarafından yönetilen diğer bulut ortamları gibi sunucu mantığınızın çalıştığı diğer güvenilir sunucu ortamınız .

Uygulama sunucunuz veya güvenilir sunucu ortamınız, FCM arka ucuna ileti istekleri gönderir ve bu da iletileri kullanıcıların cihazlarında çalışan istemci uygulamalarına yönlendirir.

Güvenilir sunucu ortamı için gereksinimler

Uygulama sunucusu ortamınız aşağıdaki ölçütleri karşılamalıdır:

  • FCM arka ucuna düzgün biçimlendirilmiş mesaj istekleri gönderebilir.
  • Üstel geri çekmeyi kullanarak istekleri işleyebilir ve yeniden gönderebilir .
  • Sunucu yetkilendirme kimlik bilgilerini ve istemci kayıt belirteçlerini güvenli bir şekilde depolayabilir.
  • XMPP protokolü için (kullanılıyorsa), sunucunun gönderdiği her iletiyi benzersiz şekilde tanımlamak için ileti kimlikleri oluşturabilmesi gerekir (FCM HTTP arka ucu ileti kimlikleri oluşturur ve yanıt olarak döndürür). XMPP ileti kimlikleri, gönderen kimliği başına benzersiz olmalıdır.

Bir sunucu seçeneği seçme

FCM sunucularıyla etkileşim kurmanın bir yoluna karar vermeniz gerekir: Firebase Yönetici SDK'sını veya ham protokolleri kullanarak. Popüler programlama dillerindeki desteği ve kimlik doğrulama ve yetkilendirme ile ilgili kolaylık yöntemleri nedeniyle, Firebase Admin SDK'si önerilen yöntemdir.

FCM sunucularıyla etkileşim seçenekleri aşağıdakileri içerir:

FCM için Firebase Yönetici SDK'sı

Yönetici FCM API'sı arka uçla kimlik doğrulamayı gerçekleştirir ve mesaj göndermeyi ve konu aboneliklerini yönetmeyi kolaylaştırır. Firebase Admin SDK'sı ile şunları yapabilirsiniz:

  • Tek tek cihazlara mesaj gönderme
  • Bir veya daha fazla konuyla eşleşen konulara ve koşul ifadelerine mesaj gönderin.
  • Konulara ve konulardan cihazlara abone olun ve aboneliklerini kaldırın
  • Farklı hedef platformlara uyarlanmış mesaj yükleri oluşturma

Yönetici Node.js SDK'sı, aygıt gruplarına ileti gönderme yöntemleri sağlar.

Firebase Yönetici SDK'sını ayarlamak için bkz . Firebase Yönetici SDK'sını Sunucunuza Ekleme . Zaten bir Firebase projeniz varsa SDK Ekle ile başlayın. Ardından, Firebase Admin SDK'sı yüklendikten sonra, gönderme istekleri oluşturmak için mantık yazmaya başlayabilirsiniz.

FCM Sunucu Protokolleri

Şu anda FCM şu ham sunucu protokollerini sağlamaktadır:

Uygulama sunucunuz bu protokolleri ayrı ayrı veya birlikte kullanabilir. Birden fazla platforma mesaj göndermek için en güncel ve en esnek olduğu için, mümkün olan her yerde FCM HTTP v1 API'si önerilir. Gereksinimleriniz aygıtlardan sunucuya akış yukarı mesajlaşma içeriyorsa, XMPP protokolünü uygulamanız gerekir.

XMPP mesajları, HTTP mesajlarından aşağıdaki şekillerde farklılık gösterir:

  • Memba / Memba mesajları
    • HTTP: Yalnızca aşağı akış, cihaza bulut.
    • XMPP: Akış yukarı ve akış aşağı (cihazdan buluta, buluttan cihaza).
  • Mesajlaşma (senkron veya asenkron)
    • HTTP: Senkron. Uygulama sunucuları HTTP POST istekleri olarak mesaj gönderir ve yanıt bekler. Bu mekanizma senkronizedir ve yanıt alınana kadar gönderenin başka bir mesaj göndermesini engeller.
    • XMPP: Eşzamansız. Uygulama sunucuları, kalıcı XMPP bağlantıları üzerinden tüm cihazlarına tam hat hızında mesaj gönderir / alır. XMPP bağlantı sunucusu eşzamansız olarak alındı ​​bildirimi veya hata bildirimleri (özel ACK ve NACK JSON kodlu XMPP iletileri biçiminde) gönderir.
  • JSON
    • HTTP: HTTP POST olarak gönderilen JSON mesajları.
    • XMPP: XMPP mesajlarına kapsüllenmiş JSON mesajları.
  • Düz Metin
    • HTTP: Düz HTTP POST olarak gönderilen kısa mesajlar.
    • XMPP: Desteklenmez.
  • Çok noktaya yayın aşağı akış, birden çok kayıt belirtecine gönderilir.
    • HTTP: JSON mesaj biçiminde desteklenir.
    • XMPP: Desteklenmez.

HTTP sunucusu protokolünü uygulama

Bir mesaj göndermek için, uygulama sunucusu bir HTTP üstbilgisi ve JSON anahtar değeri çiftlerinden oluşan bir HTTP gövdesi ile bir POST isteği yayınlar. Üstbilgi ve gövde seçenekleriyle ilgili ayrıntılar için bkz. App Server Gönderme İstekleri Oluşturma

XMPP sunucu protokolünü uygulama

FCM iletileri için JSON yükü, şu istisnalar dışında HTTP protokolüne benzer:

  • Birden fazla alıcı için destek yok.
  • FCM, zorunlu olan message_id alanını ekler. Bu kimlik bir XMPP bağlantısındaki mesajı benzersiz şekilde tanımlar. FCM'den gelen ACK veya NACK, uygulama sunucularından FCM'ye gönderilen bir mesajı tanımlamak için message_id kullanır. Bu nedenle, bu message_id yalnızca benzersiz ( gönderen kimliği başına) değil, her zaman mevcut olması önemlidir.
  • XMPP, FCM'ye kalıcı bir bağlantı izni vermek için sunucu anahtarını kullanır. Daha fazla bilgi için Gönderme İsteklerini Yetkilendirme konusuna bakın.

Normal FCM mesajlarına ek olarak, JSON nesnesindeki message_type alanı ile belirtilen kontrol mesajları gönderilir. Değer 'ack' veya 'nack' veya 'kontrol' olabilir (aşağıdaki biçimlere bakın). message_type bilinmeyen tüm FCM mesajları sunucunuz tarafından yok sayılabilir.

Uygulama sunucunuzun FCM'den aldığı her cihaz mesajı için bir ACK mesajı göndermesi gerekir. Hiçbir zaman bir NACK mesajı göndermesi gerekmez. Bir ileti için ACK göndermezseniz, iletinin süresi dolmadıkça FCM bir sonraki yeni XMPP bağlantısı kurulduğunda yeniden gönderir.

FCM ayrıca her sunucudan cihaza mesaj için bir ACK veya NACK gönderir. İkisini de almazsanız, işlemin ortasında TCP bağlantısının kapalı olduğu ve sunucunuzun iletileri yeniden göndermesi gerektiği anlamına gelir. Ayrıntılar için Akış Kontrolü'ne bakın.

Tüm mesaj parametrelerinin listesi için Protokol Referansına bakın.

İstek biçimi

Yüklü mesaj - bildirim mesajı

İşte bir bildirim mesajı için bir XMPP stanza:

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

Yüklü mesaj - veri mesajı

Bir uygulama sunucusundan FCM'ye JSON mesajını içeren bir XMPP stanzası:

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

Yanıt biçimi

Bir FCM yanıtının üç olası formu olabilir. İlki düzenli bir 'ack' mesajı. Ancak yanıt bir hata içerdiğinde, aşağıda açıklanan mesajın alabileceği 2 farklı form vardır.

ACK mesajı

İşte FCM'den uygulama sunucusuna ACK / NACK mesajını içeren bir XMPP stanzası:

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

NACK mesajı

NACK hatası, message_type durum mesajının "nack" olduğu normal bir XMPP mesajıdır. Bir NACK mesajı şunları içerir:

  • NACK hata kodu.
  • NACK hata açıklaması.

Aşağıda bazı örnekler verilmiştir.

Hatalı kayıt:

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

Geçersiz 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>

Cihaz Mesaj Oranı Aşıldı:

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

NACK hata kodlarının tam listesi için Sunucu Referansına bakın. Aksi belirtilmedikçe NACKed mesajı tekrar denenmemelidir. Beklenmeyen NACK hata kodları, INTERNAL_SERVER_ERROR aynı şekilde ele alınmalıdır.

Stanza hatası

Ayrıca bazı durumlarda bir stanza hatası da alabilirsiniz. Bir stanza hatası şunları içerir:

  • Stanza hata kodu.
  • Stanza hata açıklaması (serbest metin).

Örneğin:

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

Kontrol mesajları

Periyodik olarak, FCM'nin yük dengelemesi yapmak için bir bağlantıyı kapatması gerekir. Bağlantıyı kapatmadan önce FCM, bağlantının boşaltıldığını ve yakında kapatılacağını belirtmek için bir CONNECTION_DRAINING mesajı gönderir. "Boşaltma", bir bağlantıya gelen mesajların akışının kapatılması, ancak boru hattında olan her şeyin devam etmesine izin verilmesi anlamına gelir. Bir CONNECTION_DRAINING mesajı aldığınızda, derhal başka bir FCM bağlantısına mesaj göndermeye başlamanız ve gerekirse yeni bir bağlantı açmanız gerekir. Bununla birlikte, orijinal bağlantıyı açık tutmalı ve bağlantı üzerinden gelebilecek mesajlar almaya devam etmelisiniz (ve ACKing) - FCM hazır olduğunda yakın bir bağlantı başlatmayı yönetir.

CONNECTION_DRAINING mesajı şöyle görünür:

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

CONNECTION_DRAINING şu anda desteklenen tek control_type .

Akış kontrolü

FCM'ye gönderilen her mesaj bir ACK veya NACK yanıtı alır. Bu yanıtlardan birini almayan iletiler beklemede kabul edilir. Bekleyen mesaj sayısı 100'e ulaşırsa, uygulama sunucusu yeni mesaj göndermeyi durdurmalı ve FCM'nin mevcut bekleyen mesajlardan bazılarını şekil 1'de gösterildiği gibi onaylamasını beklemelidir:

Şekil 1. Mesaj / teyp akışı.

Tersine, uygulama sunucusunu aşırı yüklemekten kaçınmak için, çok fazla onaylanmamış mesaj varsa FCM göndermeyi durdurur. Bu nedenle, uygulama sunucusu, gelen iletilerin sürekli akışını sağlamak için, istemci uygulamasından FCM aracılığıyla alınan en kısa sürede gelen iletileri "ACK" yapmalıdır. Yukarıda belirtilen bekleyen mesaj sınırı bu ACK'ler için geçerli değildir. Bekleyen mesaj sayısı 100'e ulaşsa bile, uygulama sunucusu yeni yukarı akış mesajlarının iletimini engellememek için FCM'den alınan mesajlar için ACK göndermeye devam etmelidir.

ACK'lar yalnızca bir bağlantı bağlamında geçerlidir. Bir mesaj AÇILABİLMEDEN önce bağlantı kapatılırsa, uygulama sunucusu FCM'nin yukarı akım mesajını tekrar AÇMADAN önce yeniden göndermesini beklemelidir. Benzer şekilde, bağlantı kapatılmadan önce FCM'den ACK / NACK alınmayan tüm bekleyen mesajlar tekrar gönderilmelidir.