Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

आपका सर्वर वातावरण और FCM

फायरबेस क्लाउड मैसेजिंग के सर्वर साइड में दो घटक होते हैं:

  • FCM गूगल द्वारा प्रदान की बैकएंड।
  • आपका अनुप्रयोग सर्वर या अन्य विश्वसनीय सर्वर वातावरण, जहां इस तरह के रूप में अपने सर्वर तर्क रन Firebase के लिए बादल कार्य या अन्य बादल वातावरण Google द्वारा प्रबंधित किया।

आपका ऐप सर्वर या विश्वसनीय सर्वर वातावरण FCM बैकएंड को संदेश अनुरोध भेजता है, जो तब संदेशों को उपयोगकर्ताओं के उपकरणों पर चलने वाले क्लाइंट ऐप्स को रूट करता है।

विश्वसनीय सर्वर वातावरण के लिए आवश्यकताएँ

आपके ऐप सर्वर परिवेश को निम्नलिखित मानदंडों को पूरा करना चाहिए:

  • FCM बैकएंड को उचित रूप से स्वरूपित संदेश अनुरोध भेजने में सक्षम।
  • अनुरोधों को हैंडल और का उपयोग कर उन्हें पुन: भेजने के लिए सक्षम घातीय वापस बंद।
  • सर्वर प्राधिकरण क्रेडेंशियल और क्लाइंट पंजीकरण टोकन को सुरक्षित रूप से संग्रहीत करने में सक्षम।
  • एक्सएमपीपी प्रोटोकॉल (यदि उपयोग किया जाता है) के लिए, सर्वर को प्रत्येक संदेश को विशिष्ट रूप से पहचानने के लिए संदेश आईडी उत्पन्न करने में सक्षम होना चाहिए (एफसीएम HTTP बैकएंड संदेश आईडी उत्पन्न करता है और उन्हें प्रतिक्रिया में देता है)। XMPP संदेश आईडी प्रति प्रेषक आईडी अद्वितीय होनी चाहिए।

सर्वर विकल्प चुनना

आप FCM सर्वर के साथ बातचीत करने के लिए एक तरह से पर फैसला करना होगा: या तो का उपयोग कर Firebase नियंत्रक SDK या कच्चे प्रोटोकॉल। लोकप्रिय प्रोग्रामिंग भाषाओं में इसके समर्थन और प्रमाणीकरण और प्राधिकरण को संभालने के लिए इसकी सुविधाजनक विधियों के कारण, फायरबेस एडमिन एसडीके अनुशंसित विधि है।

FCM सर्वर के साथ इंटरैक्ट करने के विकल्पों में निम्नलिखित शामिल हैं:
  • Firebase नियंत्रक SDK है, जिसके लिए समर्थन हासिल है नोड , जावा , अजगर , सी # , और जाओ
  • FCM HTTP v1 एपीआई , अधिक सुरक्षित प्राधिकरण और लचीला के साथ जो प्रोटोकॉल विकल्पों में से आज तक की सबसे ऊपर है, पार मंच संदेश सुविधा (Firebase नियंत्रक SDK इस प्रोटोकॉल पर आधारित है और अपने निहित फायदे के सभी प्रदान करता है)।
  • विरासत HTTP प्रोटोकॉल।
  • XMPP सर्वर प्रोटोकॉल। ध्यान दें कि यदि आप अपने क्लाइंट एप्लिकेशन से अपस्ट्रीम मैसेजिंग का उपयोग करना चाहते हैं, तो आपको XMPP का उपयोग करना चाहिए।

FCM के लिए Firebase व्यवस्थापक SDK

व्यवस्थापक FCM API बैकएंड के साथ प्रमाणीकरण संभालता है और संदेश भेजने और विषय सदस्यता प्रबंधित करने की सुविधा प्रदान करता है। फायरबेस एडमिन एसडीके के साथ, आप यह कर सकते हैं:

  • अलग-अलग उपकरणों पर संदेश भेजें
  • एक या अधिक विषयों से मेल खाने वाले विषयों और शर्त विवरणों को संदेश भेजें।
  • विषयों के लिए और उनसे उपकरणों की सदस्यता लें और सदस्यता समाप्त करें
  • विभिन्न लक्ष्य प्लेटफार्मों के अनुरूप संदेश पेलोड का निर्माण

Admin Node.js SDK डिवाइस समूहों को संदेश भेजने के तरीके प्रदान करता है।

Firebase नियंत्रक SDK सेट करने के लिए, को देखने के अपने सर्वर पर Firebase नियंत्रक SDK जोड़े । आप पहले से ही एक Firebase परियोजना है, के साथ शुरू एसडीके जोड़े । फिर, एक बार में Firebase नियंत्रक SDK स्थापित किया गया है, तो आप करने के लिए तर्क लेखन शुरू कर सकते हैं का निर्माण भेजने अनुरोध

एफसीएम सर्वर प्रोटोकॉल

वर्तमान में FCM ये कच्चे सर्वर प्रोटोकॉल प्रदान करता है:

आपका ऐप सर्वर इन प्रोटोकॉल का अलग से या एक साथ उपयोग कर सकता है। चूंकि यह कई प्लेटफार्मों पर संदेश भेजने के लिए सबसे अद्यतित और सबसे लचीला है, जहां भी संभव हो, एफसीएम एचटीटीपी v1 एपीआई की सिफारिश की जाती है। अगर आपकी ज़रूरतों में डिवाइस से सर्वर तक अपस्ट्रीम मैसेजिंग शामिल है, तो आपको एक्सएमपीपी प्रोटोकॉल लागू करना होगा।

XMPP मैसेजिंग HTTP मैसेजिंग से निम्नलिखित तरीकों से अलग है:

  • अपस्ट्रीम/डाउनस्ट्रीम संदेश
    • HTTP: केवल डाउनस्ट्रीम, क्लाउड-टू-डिवाइस।
    • एक्सएमपीपी: अपस्ट्रीम और डाउनस्ट्रीम (डिवाइस-टू-क्लाउड, क्लाउड-टू-डिवाइस)।
  • मैसेजिंग (सिंक्रोनस या एसिंक्रोनस)
    • HTTP: सिंक्रोनस। ऐप सर्वर HTTP POST अनुरोधों के रूप में संदेश भेजते हैं और प्रतिक्रिया की प्रतीक्षा करते हैं। यह तंत्र समकालिक है और प्रतिक्रिया प्राप्त होने तक प्रेषक को दूसरा संदेश भेजने से रोकता है।
    • एक्सएमपीपी: अतुल्यकालिक। ऐप सर्वर लगातार एक्सएमपीपी कनेक्शन पर पूरी लाइन गति से अपने सभी उपकरणों को/से संदेश भेजते/प्राप्त करते हैं। एक्सएमपीपी कनेक्शन सर्वर एसिंक्रोनस रूप से पावती या विफलता सूचनाएं (विशेष एसीके और एनएके जेएसओएन-एन्कोडेड एक्सएमपीपी संदेशों के रूप में) भेजता है।
  • JSON
    • HTTP: JSON संदेश HTTP POST के रूप में भेजे गए।
    • एक्सएमपीपी: जेएसओएन संदेश एक्सएमपीपी संदेशों में समाहित हैं।
  • सादे पाठ
    • HTTP: सादा पाठ संदेश HTTP POST के रूप में भेजे गए।
    • एक्सएमपीपी: समर्थित नहीं है।
  • मल्टीकास्ट डाउनस्ट्रीम एकाधिक पंजीकरण टोकन को भेजता है।
    • HTTP: JSON संदेश प्रारूप में समर्थित।
    • एक्सएमपीपी: समर्थित नहीं है।

HTTP सर्वर प्रोटोकॉल को लागू करना

एक संदेश भेजने के लिए, ऐप सर्वर एक HTTP शीर्षलेख के साथ एक POST अनुरोध जारी करता है और एक HTTP निकाय जिसमें JSON कुंजी मान जोड़े शामिल होते हैं। शीर्षक और शरीर के लिए विकल्पों पर जानकारी के लिए, बिल्ड अनुप्रयोग सर्वर संदेश अनुरोध

XMPP सर्वर प्रोटोकॉल को लागू करना

FCM संदेशों के लिए JSON पेलोड इन अपवादों के साथ HTTP प्रोटोकॉल के समान है:

  • एकाधिक प्राप्तकर्ताओं के लिए कोई समर्थन नहीं है।
  • FCM क्षेत्र कहते हैं message_id है, जो आवश्यक है। यह आईडी विशिष्ट रूप से एक एक्सएमपीपी कनेक्शन में संदेश की पहचान करती है। एसीके या FCM से NACK का उपयोग करता message_id संदेश FCM एप्लिकेशन को सर्वर से भेजे गए। इसलिए, यह महत्वपूर्ण है कि इस message_id न केवल (प्रति अद्वितीय होना प्रेषक आईडी ), लेकिन हमेशा मौजूद।
  • XMPP FCM से लगातार कनेक्शन को अधिकृत करने के लिए सर्वर कुंजी का उपयोग करता है। देखें अनुरोध अधिकृत भेजें अधिक जानकारी के लिए।

नियमित रूप से FCM संदेशों के अलावा, नियंत्रण संदेश भेजे जाते हैं, ने संकेत दिया message_type JSON ऑब्जेक्ट में क्षेत्र। मान या तो 'ack' या 'nack', या 'control' हो सकता है (नीचे प्रारूप देखें)। एक अज्ञात के साथ कोई FCM संदेश message_type अपने सर्वर द्वारा नजरअंदाज कर दिया जा सकता है।

आपके ऐप सर्वर को FCM से प्राप्त होने वाले प्रत्येक डिवाइस संदेश के लिए, उसे एक ACK संदेश भेजने की आवश्यकता होती है। इसे कभी भी NACK संदेश भेजने की आवश्यकता नहीं है। यदि आप किसी संदेश के लिए ACK नहीं भेजते हैं, तो अगली बार नया XMPP कनेक्शन स्थापित होने पर FCM उसे फिर से भेजता है, जब तक कि संदेश पहले समाप्त न हो जाए।

FCM प्रत्येक सर्वर-टू-डिवाइस संदेश के लिए एक ACK या NACK भी भेजता है। यदि आपको या तो प्राप्त नहीं होता है, तो इसका मतलब है कि ऑपरेशन के बीच में टीसीपी कनेक्शन बंद कर दिया गया था और आपके सर्वर को संदेशों को फिर से भेजने की जरूरत है। देखें प्रवाह नियंत्रण जानकारी के लिए।

देखें प्रोटोकॉल संदर्भ सभी संदेश पैरामीटर की एक सूची के लिए।

अनुरोध प्रारूप

पेलोड के साथ संदेश — अधिसूचना संदेश

अधिसूचना संदेश के लिए यहां एक एक्सएमपीपी श्लोक है:

<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 श्लोक है जिसमें एक ऐप सर्वर से FCM तक JSON संदेश शामिल है:

<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 प्रतिक्रिया के तीन संभावित रूप हो सकते हैं। पहला एक नियमित 'ack' संदेश है। लेकिन जब प्रतिक्रिया में कोई त्रुटि होती है, तो संदेश के 2 अलग-अलग रूप हो सकते हैं, जिनका वर्णन नीचे किया गया है।

एसीके संदेश

यहाँ एक XMPP श्लोक है जिसमें FCM से ऐप सर्वर पर ACK/NACK संदेश है:

<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 त्रुटि कोड।
  • एक 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>

देखें सर्वर संदर्भ NACK त्रुटि कोड की एक पूरी सूची के लिए। जब तक अन्यथा संकेत न दिया गया हो, एक NACKed संदेश का पुन: प्रयास नहीं किया जाना चाहिए। अप्रत्याशित NACK त्रुटि कोड के रूप में ही व्यवहार किया जाना चाहिए 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 कनेक्शन को संदेश भेजने, एक नया कनेक्शन यदि आवश्यक हो तो खोलने शुरू करना चाहिए। हालांकि, आपको मूल कनेक्शन को खुला रखना चाहिए और कनेक्शन पर आने वाले संदेशों को प्राप्त करना जारी रखना चाहिए (और उन्हें एसीके करना) - एफसीएम कनेक्शन तैयार होने पर बंद होने की शुरुआत करता है।

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 संदेश / पावती प्रवाह।

इसके विपरीत, ऐप सर्वर को ओवरलोड करने से बचने के लिए, यदि बहुत अधिक अनजाने संदेश हैं, तो FCM भेजना बंद कर देता है। इसलिए, ऐप सर्वर को आने वाले संदेशों के निरंतर प्रवाह को बनाए रखने के लिए जितनी जल्दी हो सके एफसीएम के माध्यम से क्लाइंट एप्लिकेशन से प्राप्त अपस्ट्रीम संदेशों को "एसीके" करना चाहिए। उपरोक्त लंबित संदेश सीमा इन एसीके पर लागू नहीं होती है। भले ही लंबित संदेश संख्या 100 तक पहुंच जाए, ऐप सर्वर को नए अपस्ट्रीम संदेशों के वितरण को अवरुद्ध करने से बचने के लिए एफसीएम से प्राप्त संदेशों के लिए एसीके भेजना जारी रखना चाहिए।

एसीके केवल एक कनेक्शन के संदर्भ में मान्य हैं। यदि किसी संदेश को ACKed किए जाने से पहले कनेक्शन बंद कर दिया जाता है, तो ऐप सर्वर को FCM द्वारा अपस्ट्रीम संदेश को फिर से ACK करने से पहले उसे फिर से भेजने के लिए प्रतीक्षा करनी चाहिए। इसी तरह, सभी लंबित संदेश जिनके लिए कनेक्शन बंद होने से पहले FCM से ACK/NACK प्राप्त नहीं हुआ था, उन्हें फिर से भेजा जाना चाहिए।