Save the date - Google I/O returns May 18-20. Register to get the most out of the digital experience: Build your schedule, reserve space, participate in Q&As, earn Google Developer profile badges, and more. Register now
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

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

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

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

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

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

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

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

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

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

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

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

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

एडमिन नोड्स एसडीके डिवाइस समूहों को संदेश भेजने के लिए तरीके प्रदान करता है।

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

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

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

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

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

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

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

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

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

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

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

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

0 बी 3 ए 40 सी 300

प्रतिक्रिया प्रारूप

एक FCM प्रतिक्रिया के तीन संभावित रूप हो सकते हैं। पहला एक नियमित 'एक' संदेश है। लेकिन जब प्रतिक्रिया में त्रुटि होती है, तो 2 अलग-अलग रूप होते हैं जो संदेश ले सकता है, नीचे वर्णित है।

एसीके संदेश

यहाँ एक एक्सएमपीपी श्लोक है जिसमें एफसीएम से ऐप सर्वर पर एसीके / एनएके संदेश शामिल है:

<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 यह इंगित करने के लिए एक 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 तक पहुंच जाती है, तो ऐप सर्वर को नए संदेश भेजना बंद कर देना चाहिए और एफसीएम के लिए प्रतीक्षा करनी चाहिए कि मौजूदा लंबित संदेशों में से कुछ को चित्र 1 में दर्शाया गया है:

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

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

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