Check out what’s new from Firebase at Google I/O 2022. Learn more

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आपके ऐप सर्वर को 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 तक पहुंच जाए, ऐप सर्वर को नए अपस्ट्रीम संदेशों के वितरण को अवरुद्ध करने से बचने के लिए FCM से प्राप्त संदेशों के लिए ACK भेजना जारी रखना चाहिए।

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