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

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

• Google द्वारा प्रदान किया गया FCM बैकएंड ।
• आपका ऐप सर्वर या अन्य विश्वसनीय सर्वर वातावरण जहां आपका सर्वर लॉजिक चलता है, जैसे फायरबेस के लिए क्लाउड फ़ंक्शंस या Google द्वारा प्रबंधित अन्य क्लाउड वातावरण।

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

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

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

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

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

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

FCM सर्वर के साथ इंटरैक्ट करने के विकल्पों में निम्नलिखित शामिल हैं:

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

FCM के लिए Firebase एडमिन SDK

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

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

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

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

Firebase Admin SDK, FCM विषयों से उपकरणों की सदस्यता लेने और सदस्यता समाप्त करने के लिए एक API प्रदान करता है। ये ऑपरेशन एक समय में 1000 डिवाइस पंजीकरण टोकन को सब्सक्राइब या अनसब्सक्राइब कर सकते हैं। अधिक जानकारी के लिए, सर्वर से विषय प्रबंधित करें देखें।

FCM सर्वर प्रोटोकॉल

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

• एफसीएम एचटीटीपी v1 एपीआई
• लीगेसी HTTP प्रोटोकॉल
• लीगेसी XMPP प्रोटोकॉल

आपका ऐप सर्वर इन प्रोटोकॉल का अलग-अलग या मिलकर उपयोग कर सकता है। क्योंकि यह एक से अधिक प्लेटफॉर्म पर संदेश भेजने के लिए सबसे अद्यतित और सबसे लचीला है, जहां भी संभव हो FCM HTTP v1 API की सिफारिश की जाती है। यदि आपकी आवश्यकताओं में उपकरणों से सर्वर तक अपस्ट्रीम संदेश शामिल हैं, तो आपको XMPP प्रोटोकॉल लागू करने की आवश्यकता होगी।

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

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

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

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

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

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

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

नियमित FCM संदेशों के अलावा, नियंत्रण संदेश भेजे जाते हैं, जो JSON ऑब्जेक्ट में message_type फ़ील्ड द्वारा इंगित किए जाते हैं। मान या तो 'एक' या 'नैक' या 'कंट्रोल' हो सकता है (नीचे प्रारूप देखें)। किसी अज्ञात message_type वाले किसी भी FCM संदेश को आपके सर्वर द्वारा अनदेखा किया जा सकता है।

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

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

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

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

पेलोड के साथ संदेश - सूचना संदेश

यहाँ एक अधिसूचना संदेश के लिए एक 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 छंद है जिसमें एक ऐप सर्वर से 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 संदेश

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>

NACK त्रुटि कोड की पूरी सूची के लिए सर्वर संदर्भ देखें। जब तक अन्यथा संकेत न दिया जाए, एक NACKed संदेश का पुनः प्रयास नहीं किया जाना चाहिए। अनपेक्षित NACK त्रुटि कोड को INTERNAL_SERVER_ERROR के समान माना जाना चाहिए।

छंद त्रुटि

आप कुछ मामलों में छंद त्रुटि भी प्राप्त कर सकते हैं। एक छंद त्रुटि में शामिल हैं:

• छंद त्रुटि कोड।
• छंद त्रुटि विवरण (मुफ्त पाठ)।

उदाहरण के लिए:

<message id="3" type="error" to="[e-mail]/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 में दिखाया गया है:

चित्र 1. संदेश/पावती प्रवाह।

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

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