Google is committed to advancing racial equity for Black communities. See how.
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

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

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

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

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

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

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

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

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

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

एफसीएम के लिए फायरबेस व्यवस्थापक एसडीके

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 श्लोक है, जिसमें 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>

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

एक एफसीएम प्रतिक्रिया के तीन संभावित रूप हो सकते हैं। पहला एक नियमित 'एक' संदेश है। लेकिन जब प्रतिक्रिया में एक त्रुटि होती है, तो 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":"SomeInvalidRegistrationId",
    "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>

संदेशों को नियंत्रित करें

समय-समय पर, एफसीएम को लोड संतुलन प्रदर्शन करने के लिए एक कनेक्शन को बंद करने की आवश्यकता होती है। इससे पहले कि यह कनेक्शन बंद हो जाए, एफसीएम एक CONNECTION_DRAINING संदेश भेजता है ताकि यह पता CONNECTION_DRAINING कि कनेक्शन सूखा जा रहा है और जल्द ही बंद हो जाएगा। "ड्रेनिंग" एक कनेक्शन में आने वाले संदेशों के प्रवाह को बंद करने को संदर्भित करता है, लेकिन जो कुछ भी पहले से ही जारी रखने के लिए पाइपलाइन में अनुमति देता है। जब आपको एक CONNECTION_DRAINING संदेश प्राप्त होता है, तो आपको तुरंत एक और FCM कनेक्शन के लिए संदेश भेजना शुरू करना चाहिए, जो एक नया कनेक्शन खोलना आवश्यक है। हालाँकि, आपको मूल कनेक्शन को खुला रखना चाहिए और ऐसे संदेश प्राप्त करना जारी रखना चाहिए जो कनेक्शन के ऊपर आ सकते हैं (और उन्हें ACKing) - जब यह तैयार हो जाता है, तो कनेक्शन बंद करना शुरू कर देता है।

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

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

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