סביבת השרת שלך ו- FCM

צד השרת של Firebase Cloud Messaging מורכב משני רכיבים:

  • על החלק העורפי FCM שמספקת גוגל.
  • שרת האפליקציה שלך או סביבת שרת מהימן אחרת שבם פועלים היגיון השרת שלך, כגון פונקציות ענן עבור Firebase או סביבות ענן אחרות המנוהלת על ידי גוגל.

שרת האפליקציות שלך או סביבת השרת המהימנה שלך שולחים בקשות הודעות אל ה- backm של FCM, ואז מנותבים הודעות לאפליקציות לקוח הפועלות במכשירי המשתמשים.

דרישות עבור סביבת השרת המהימנה

סביבת שרת האפליקציות שלך חייבת לעמוד בקריטריונים הבאים:

  • מסוגל לשלוח בקשות הודעות מעוצבות כהלכה אל ה- back של FCM.
  • מסוגל להתמודד עם בקשות ולשלוח אותם שוב באמצעות גב-off מעריכים.
  • מסוגל לשמור באופן מאובטח אישורי הרשאת שרת ואסימונים לרישום לקוחות.
  • עבור פרוטוקול XMPP (אם משתמשים בו), השרת צריך להיות מסוגל ליצור מזהי הודעות כדי לזהות באופן ייחודי כל הודעה שהוא שולח (ה- FCM HTTP backend מייצר מזהי הודעה ומחזיר אותם בתגובה). מזהי הודעות XMPP צריכים להיות ייחודיים לכל מזהה שולח.

בחירת אופציית שרת

תצטרך להחליט על דרך אינטראקציה עם שרתי FCM: או באמצעות SDK של ניהול Firebase או פרוטוקולי גלם. בגלל התמיכה שלה בשפות תכנות פופולריות ושיטות הנוחות שלה לטיפול באימות ואישור, ה- SDK Admin SDK הוא השיטה המומלצת.

האפשרויות לאינטראקציה עם שרתי FCM כוללות את האפשרויות הבאות:
  • ה- SDK Admin Firebase, אשר יש תמיכה צומת , Java , Python , C # , ו Go .
  • FCM HTTP v1 API , המהווה את רוב מעודכן של אפשרויות פרוטוקול, באישור יותר בטוחה וגמישה יכולות העברת הודעות חוצה פלטפורמות (SDK של מנהל המערכת Firebase מבוססת על פרוטוקול זה מספק את כל היתרונות הגלומים).
  • המורשת HTTP פרוטוקול.
  • XMPP פרוטוקול בשרת. שים לב שאם אתה רוצה להשתמש בהודעות upstream מיישומי הלקוח שלך, עליך להשתמש ב- XMPP.

Firkase Admin SDK עבור FCM

ה- Admin FCM API מטפל באימות עם ה backend ומאפשר שליחת הודעות וניהול מנויים לנושאים. באמצעות Firebase Admin SDK, אתה יכול:

  • שלח הודעות למכשירים בודדים
  • שלח הודעות לנושאים והצהרות מצב התואמות נושא אחד או יותר.
  • הרשמה והתנתק ממכשירים לנושאים וממנה
  • בנה מטענים בהודעות המותאמות לפלטפורמות יעד שונות

ה- SDK Admin Node.js מספק שיטות לשליחת הודעות לקבוצות מכשירים.

כדי להגדיר את ה- SDK Admin Firebase, לראות מוסיפים את SDK של ניהול Firebase לשרת שלך . אם כבר יש לך פרויקט Firebase, להתחיל עם הוספת ה- SDK . ואז, ברגע SDK של ניהול Firebase מותקן, אתה יכול להתחיל היגיון בכתב בקשות שליחה לבנות .

פרוטוקולי שרת FCM

נכון לעכשיו, FCM מספקת את פרוטוקולי השרת הגולמיים הבאים:

שרת האפליקציות שלך יכול להשתמש בפרוטוקולים אלה בנפרד או במקביל. מכיוון שהוא המעודכן והגמיש ביותר לשליחת הודעות למספר פלטפורמות, מומלץ FCM HTTP v1 API בכל מקום אפשרי. אם הדרישות שלך כוללות הודעות במעלה הזרם ממכשירים לשרת, יהיה עליך ליישם את פרוטוקול XMPP.

הודעות XMPP שונות מהודעות HTTP בדרכים הבאות:

  • הודעות במעלה/במורד הזרם
    • HTTP: במורד הזרם בלבד, ענן למכשיר.
    • XMPP: במעלה ובזרם (מכשיר לענן, ענן למכשיר).
  • הודעות (סינכרוני או אסינכרוני)
    • HTTP: סינכרוני. שרתי האפליקציה שולחים הודעות כבקשות HTTP POST ומחכים לתגובה. מנגנון זה סינכרוני וחוסם את השולח מלשלוח הודעה נוספת עד לקבלת התגובה.
    • XMPP: אסינכרוני. שרתי האפליקציות שולחים/מקבלים הודעות אל/מכל המכשירים שלהם במהירות קו מלאה באמצעות חיבורי XMPP מתמשכים. שרת חיבור XMPP שולח הודעות אישור או כישלון (בצורה של הודעות XMPP מקודדות ל- ACK ו- NACK JSON) באופן אסינכרוני.
  • JSON
    • HTTP: הודעות JSON שנשלחו כ- HTTP POST.
    • XMPP: הודעות JSON המקופלות בהודעות XMPP.
  • טקסט רגיל
    • HTTP: הודעות טקסט רגיל שנשלחו כ- HTTP POST.
    • XMPP: לא נתמך.
  • שידור מולטי-שידור במורד הזרם למספר אסימוני רישום.
    • HTTP: נתמך בפורמט הודעות JSON.
    • XMPP: לא נתמך.

יישום פרוטוקול שרת HTTP

כדי לשלוח הודעה, שרת האפליקציות מוציא בקשת POST עם כותרת HTTP וגוף HTTP המורכב מזוגות ערך מפתח JSON. לפרטים על אפשרויות בכותרת ובגוף, לראות בקשות לשלוח לשרת App Build

יישום פרוטוקול שרת ה- XMPP

המטען של JSON עבור הודעות FCM דומה לפרוטוקול HTTP, למעט חריגים אלה:

  • אין תמיכה במספר נמענים.
  • FCM מוסיף בתחום message_id , אשר נדרש. מזהה זה מזהה באופן ייחודי את ההודעה בחיבור XMPP. ACK או נאק מ FCM משתמש message_id לזהות הודעה שנשלחה משרתי אפליקציה כדי FCM. לכן, חשוב כי זה message_id לא רק להיות ייחודי (מחיר זיהוי שולח ), אבל תמיד נוכח.
  • XMPP משתמש במפתח השרת כדי לאשר חיבור מתמשך ל- FCM. ראה על הרשה לשלוח בקשות לקבלת מידע נוסף.

בנוסף להודעות FCM רגילות, הודעות בקרה נשלחות, שמציינים את message_type שדה אובייקט JSON. הערך יכול להיות 'ack' או 'nack', או 'control' (ראה פורמטים למטה). כל הודעה FCM עם ידוע message_type ניתן להתעלם ידי השרת שלך.

עבור כל הודעת מכשיר ששרת האפליקציה שלך מקבל מ- FCM, עליו לשלוח הודעת ACK. זה אף פעם לא צריך לשלוח הודעת NACK. אם אינך שולח ACK עבור הודעה, FCM שולח אותה שוב בפעם הבאה שנוצר חיבור XMPP חדש, אלא אם תוקף ההודעה יפוג תחילה.

FCM גם שולח ACK או NACK עבור כל הודעת שרת למכשיר. אם גם לא תקבל, המשמעות היא שחיבור TCP נסגר באמצע הפעולה והשרת שלך צריך לשלוח שוב את ההודעות. ראה בקרת זרימה לפרטים.

עיין במסמך על פרוטוקול עבור רשימה של כל הפרמטרים הודעה.

פורמט בקשה

הודעה עם מטען - הודעת הודעה

להלן נוסח XMPP להודעת התראה:

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

הודעה עם מטען - הודעת נתונים

להלן בית XMPP המכיל את הודעת JSON משרת אפליקציות ל- FCM:

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

פורמט תגובה

לתגובת FCM יכולות להיות שלוש צורות אפשריות. הראשון הוא הודעה 'אק' רגילה. אך כאשר התגובה מכילה שגיאה, ישנן 2 צורות שונות שההודעה יכולה ללבוש, המתוארות להלן.

הודעת ACK

להלן בית XMPP המכיל את הודעת ACK / NACK מ- FCM לשרת האפליקציה:

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

הודעת NACK

שגיאה ב- נאק הוא מסר XMPP קבוע שבו message_type הודעת המצב הוא "נאק". הודעת NACK מכילה:

  • קוד שגיאה של NACK.
  • תיאור שגיאה של NACK.

להלן מספר דוגמאות.

רישום לא טוב:

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

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>

שיעור הודעות המכשיר חרג:

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

ראה הפניה לשרת לקבלת רשימה מלאה של קודי השגיאה נאק. אלא אם כן צוין אחרת, אין לנסות שוב להודעה NACKed. קודי שגיאה נאק צפוי להתייחס אליהם זהה INTERNAL_SERVER_ERROR .

טעות בבית

אתה יכול גם לקבל שגיאת ביתול במקרים מסוימים. שגיאת בית מכילה:

  • קוד שגיאה בבית.
  • תיאור שגיאת בית (טקסט חופשי).

לדוגמה:

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

הודעות בקרה

מעת לעת, FCM צריכה לסגור חיבור לביצוע איזון עומס. לפני שהוא סוגר את החיבור, FCM שולח CONNECTION_DRAINING מסר לציין שחיבור נמצא סחוט ייסגר בקרוב. "ניקוז" מתייחס לכיבוי זרימת ההודעות הנכנסות לחיבור, אך לאפשר להמשיך את מה שכבר נמצא בצינור. כשאתה מקבל CONNECTION_DRAINING הודעה, אתה צריך מיד להתחיל לשלוח הודעות למשנהו חיבור FCM, פתיחת חיבור חדש במידת הצורך. עם זאת, עליך להשאיר את החיבור המקורי פתוח ולהמשיך לקבל הודעות שעלולות להגיע דרך החיבור (ולגשת אותן) - FCM מטפל בפתיחת חיבור סגור כאשר הוא מוכן.

CONNECTION_DRAINING ההודעה נראית כך:

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

CONNECTION_DRAINING היא כיום רק control_type נתמך.

בקרת זרימה

כל הודעה שנשלחת ל- FCM זוכה לתגובת ACK או NACK. הודעות שלא קיבלו אחת מהתגובות הללו נחשבות בהמתנה. אם ספירת ההודעות הממתינה מגיעה ל 100, על שרת האפליקציה להפסיק לשלוח הודעות חדשות ולחכות ל- FCM שיאשר חלק מההודעות הקיימות בהמתנה, כפי שמודגם באיור 1:

תרשים מפורט של זרימת הבקרה בין FCM לבין שרת האפליקציות

איור 1. מסר / ack לזרום.

לעומת זאת, כדי למנוע עומס יתר על שרת האפליקציה, FCM מפסיק לשלוח אם יש יותר מדי הודעות שלא אושרו. לכן, על שרת האפליקציות "ACK" הודעות במעלה, המתקבלות מיישום הלקוח באמצעות FCM, בהקדם האפשרי כדי לשמור על זרימה קבועה של הודעות נכנסות. מגבלת ההודעות הממתינה כאמור אינה חלה על ACKs אלה. גם אם מספר ההודעות הממתינות יגיע ל -100, שרת האפליקציות צריך להמשיך לשלוח הודעות ACK עבור הודעות שהתקבלו מ- FCM כדי למנוע חסימת מסירה של הודעות חדשות במעלה הזרם.

ACK תקפים רק בהקשר של חיבור אחד. אם החיבור נסגר לפני שניתן יהיה להזין הודעה ב- ACK, שרת האפליקציות צריך לחכות עד ש- FCM ישלח שוב את ההודעה במעלה הזרם לפני שיחזור אליה. באופן דומה, יש לשלוח שוב את כל ההודעות הממתינות שעבורן לא התקבל ACK / NACK מ- FCM לפני סגירת החיבור.