FCM मैसेज के बारे में जानकारी

Firebase Cloud Messaging (FCM) में मैसेज भेजने के कई विकल्प हैं और क्षमताओं को शामिल किया है. इस पेज पर दी गई जानकारी से, आपको अलग-अलग तरह के FCM मैसेज और उनके इस्तेमाल के बारे में जानने में मदद मिलेगी.

मैसेज के टाइप

FCM के साथ, आप क्लाइंट को दो तरह के मैसेज भेज सकते हैं:

• सूचना मैसेज, जिन्हें कभी-कभी "डिसप्ले मैसेज" भी कहा जाता है. इन्हें FCM SDK टूल अपने-आप मैनेज करता है.
• डेटा मैसेज, जिन्हें क्लाइंट ऐप्लिकेशन मैनेज करता है.

सूचना वाले मैसेज में, पहले से तय उपयोगकर्ताओं को दिखने वाली कुंजियों का सेट होता है. इसके उलट, डेटा मैसेज में सिर्फ़ उपयोगकर्ता की ओर से तय की गई कस्टम कुंजी-वैल्यू होती है पेयर. सूचना वाले मैसेज में एक वैकल्पिक मैसेज हो सकता है डेटा पेलोड. दोनों तरह के मैसेज के लिए पेलोड ज़्यादा से ज़्यादा 4096 बाइट होना चाहिए. हालांकि, ऐसा तब नहीं होगा, जब Firebase कंसोल से मैसेज भेजना, जिससे 1,000 वर्ण लागू होते हैं सीमा तय करें.

सूचना मैसेज का इस्तेमाल तब करें, जब आपको FCM SDK टूल से, ऐप्लिकेशन के बैकग्राउंड में चलने के दौरान, सूचना अपने-आप दिखने की सुविधा मैनेज करनी हो. डेटा मैसेज का इस्तेमाल तब करें, जब आप अपने फ़ोन की मदद से मैसेज प्रोसेस करना चाहते हों खुद का क्लाइंट ऐप्लिकेशन कोड डालें.

FCM, वैकल्पिक डेटा के साथ सूचना वाला मैसेज भेज सकता है पेलोड. ऐसे मामलों में, FCM सूचना पेलोड को दिखाने की प्रोसेस को मैनेज करता है और क्लाइंट ऐप्लिकेशन, डेटा पेलोड को मैनेज करता है.

सूचना के मैसेज

टेस्टिंग या मार्केटिंग और उपयोगकर्ता को फिर से जोड़ने के लिए, Firebase console का इस्तेमाल करके सूचना मैसेज भेजे जा सकते हैं. Firebase कंसोल, आंकड़ों के आधार पर सुविधाएं देता है A/B टेस्टिंग का इस्तेमाल करके, मार्केटिंग मैसेज में सुधार किया जा सकता है.

Admin SDK टूल का इस्तेमाल करके या FCM प्रोटोकॉल, notification कुंजी को उपयोगकर्ता को दिखने वाले की-वैल्यू विकल्पों का पहले से तय किया गया ज़रूरी सेट ईमेल का हिस्सा बना रहता है. उदाहरण के लिए, यहां मैसेजिंग ऐप्लिकेशन में, जेएसओएन फ़ॉर्मैट में भेजा गया सूचना मैसेज दिया गया है. उपयोगकर्ता को डिवाइस पर, "पुर्तगाल बनाम डेनमार्क" टाइटल और "शानदार मैच!" टेक्स्ट वाला मैसेज दिख सकता है:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

जब ऐप बैकग्राउंड में मौजूद है. फ़ोरग्राउंड में चल रहे ऐप्लिकेशन के लिए, मैसेज को कॉलबैक फ़ंक्शन से मैनेज किया जाता है.

सूचना मैसेज बनाने के लिए, पहले से उपलब्ध कुंजियों की पूरी सूची देखने के लिए, एचटीटीपी v1 प्रोटोकॉल के सूचना ऑब्जेक्ट का रेफ़रंस दस्तावेज़ देखें.

डेटा मैसेज

अपने कस्टम की-वैल्यू पेयर के साथ सही पासकोड सेट करें क्लाइंट ऐप्लिकेशन को डेटा पेलोड भेजें.

उदाहरण के लिए, यहां उसी IM ऐप्लिकेशन में JSON-फ़ॉर्मैट किया गया मैसेज जिसकी जानकारी ऊपर दी गई है, जहां जानकारी को सामान्य data कुंजी में रखा जाता है और क्लाइंट ऐप्लिकेशन से कॉन्टेंट को समझना चाहिए:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

ऊपर दिया गया उदाहरण टॉप-लेवल या सामान्य data फ़ील्ड के इस्तेमाल को दिखाता है, जिसे मैसेज पाने वाले सभी प्लैटफ़ॉर्म पर क्लाइंट समझते हैं. हर प्लैटफ़ॉर्म पर, क्लाइंट ऐप्लिकेशन को डेटा पेलोड मिलता है का इस्तेमाल करें.

डेटा मैसेज को एन्क्रिप्ट (सुरक्षित) करने की सुविधा

Android ट्रांसपोर्ट लेयर (FCM आर्किटेक्चर देखें), पॉइंट-टू-पॉइंट एन्क्रिप्शन का इस्तेमाल करता है. आपके अनुरोध पर निर्भर है, तो आपके पास अपने डेटा मैसेज में पूरी तरह सुरक्षित (E2EE) सुविधा जोड़ने का विकल्प होता है. FCM, एंड-टू-एंड समाधान नहीं देता. हालांकि, ऐसे कुछ बाहरी समाधान भी मौजूद हैं, जैसे कि कैपिलरी के तौर पर या डीटीएलएस.

वैकल्पिक डेटा पेलोड के साथ सूचना वाले मैसेज

प्रोग्राम बनाकर या Firebase कंसोल से सूचना भेजी जा सकती है वे मैसेज जिनमें कस्टम की-वैल्यू पेयर का वैकल्पिक पेलोड मौजूद हो. सूचना कंपोज़र में, बेहतर विकल्पों में कस्टम डेटा फ़ील्ड का इस्तेमाल करें.

सूचना और डेटा, दोनों वाले मैसेज पाने के दौरान ऐप्लिकेशन का व्यवहार पेलोड इस बात पर निर्भर करते हैं कि ऐप्लिकेशन बैकग्राउंड में है या फ़ोरग्राउंड से जुड़ा कॉन्टेंट मौजूद होता है. इससे फ़र्क़ नहीं पड़ता कि इवेंट के समय यह ऐक्टिव है या नहीं रसीद.

• बैकग्राउंड में होने पर, ऐप्लिकेशन को सूचना ट्रे में सूचना का पेलोड मिलता है. साथ ही, उपयोगकर्ता जब सूचना पर टैप करता है, तब ही डेटा पेलोड को मैनेज किया जाता है.
• फ़ोरग्राउंड में होने पर, आपके ऐप्लिकेशन को एक मैसेज ऑब्जेक्ट मिलता है. इसमें, दोनों पेलोड उपलब्ध होते हैं.

यहां JSON के फ़ॉर्मैट में एक मैसेज दिया गया है, जिसमें दोनों notification और data बटन:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

अलग-अलग प्लैटफ़ॉर्म पर मैसेज को पसंद के मुताबिक बनाना

Firebase Admin SDK और FCM v1 एचटीटीपी प्रोटोकॉल, दोनों आपको मैसेज भेजने की अनुमति देते हैं में उपलब्ध सभी फ़ील्ड सेट करने के अनुरोध message ऑब्जेक्ट है. इसमें इस तरह का कॉन्टेंट शामिल है:

• फ़ील्ड का एक सामान्य सेट, जिसे मैसेज पाने वाले सभी ऐप्लिकेशन इंस्टेंस के हिसाब से समझा जाना चाहिए.
• AndroidConfig और WebpushConfig जैसे प्लैटफ़ॉर्म के हिसाब से फ़ील्ड के सेट, जिन्हें सिर्फ़ तय किए गए प्लैटफ़ॉर्म पर चल रहे ऐप्लिकेशन इंस्टेंस ही समझते हैं.

प्लैटफ़ॉर्म के हिसाब से ब्लॉक करने की सुविधा की मदद से, अलग-अलग प्लैटफ़ॉर्म के लिए मैसेज को पसंद के मुताबिक बनाया जा सकता है. इससे यह पक्का किया जा सकता है कि मैसेज मिलने पर उन्हें सही तरीके से मैनेज किया जाए. कॉन्टेंट बनाने FCM बैकएंड सभी पैरामीटर को ध्यान में रखेगा और मैसेज देख सकते हैं.

सामान्य फ़ील्ड का इस्तेमाल कब करना चाहिए

सामान्य फ़ील्ड का इस्तेमाल तब करें, जब:

• सभी प्लैटफ़ॉर्म — Apple, Android, और वेब पर ऐप्लिकेशन इंस्टेंस को टारगेट करना
• विषयों के लिए मैसेज भेज रहे हैं

किसी भी प्लैटफ़ॉर्म पर ऐप्लिकेशन के सभी इंस्टेंस के लिए, यहां दी गई सामान्य शर्तें लागू हो सकती हैं फ़ील्ड:

• message.notification.title
• message.notification.body
• message.data

प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल कब करना चाहिए

प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल तब करें, जब आपको:

• सिर्फ़ खास प्लैटफ़ॉर्म पर फ़ील्ड भेजें
• सामान्य फ़ील्ड के अलावा, प्लैटफ़ॉर्म के हिसाब से फ़ील्ड भेजना

जब आपको सिर्फ़ चुनिंदा प्लैटफ़ॉर्म पर वैल्यू भेजनी हों, तो सामान्य फ़ील्ड का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल करें. उदाहरण के लिए, सूचना भेजने के लिए केवल Apple प्लेटफ़ॉर्म और वेब पर, लेकिन Android पर नहीं, तो आपको एक फ़ील्ड Apple के लिए और एक वेब के लिए.

जब किसी खास डिलीवरी विकल्प के साथ मैसेज भेजे जा रहे हों, तो उन्हें सेट करने के लिए, प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल करें. अगर आप चाहें, तो हर प्लैटफ़ॉर्म के लिए अलग-अलग वैल्यू तय की जा सकती हैं. हालांकि, अगर आपको सभी प्लैटफ़ॉर्म पर एक ही वैल्यू सेट करनी है, तब भी आपको प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल करना होगा. ऐसा इसलिए है, क्योंकि हर प्लैटफ़ॉर्म वैल्यू को थोड़ा अलग तरीके से समझा सकता है—उदाहरण के लिए, टाइम-टू-लाइव है Android पर, खत्म होने का समय सेकंड में सेट करता है, जबकि Apple पर यह समयसीमा खत्म होने की तारीख.

उदाहरण: प्लैटफ़ॉर्म के हिसाब से डिलीवरी के विकल्पों के साथ सूचना मैसेज

यहां दिया गया, सूचना भेजने का अनुरोध, सभी प्लैटफ़ॉर्म पर एक जैसा टाइटल और कॉन्टेंट भेजता है. साथ ही, प्लैटफ़ॉर्म के हिसाब से कुछ बदलाव भी करता है. खास तौर पर, अनुरोध:

• यह Android और वेब प्लैटफ़ॉर्म के लिए 'लॉन्ग टाइम-टू-लाइव' पर सेट होती है. वहीं, एपीएन (Apple प्लैटफ़ॉर्म) के मैसेज की प्राथमिकता को 'कम' पर सेट करती है
• उपयोगकर्ता की ओर से Android और Apple — click_action, और category पर सूचना पर किए गए टैप का नतीजा तय करने के लिए सही कुंजियां सेट करती हैं.

{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

HTTP v1 संदर्भ दस्तावेज़ देखें में उपलब्ध डिजिटल बटन के बारे में पूरी जानकारी मैसेज के मुख्य हिस्से में प्लैटफ़ॉर्म के हिसाब से बनाए गए ब्लॉक. इसके बारे में ज़्यादा जानकारी पाने के लिए, ईमेल भेजने के लिए अनुरोध तैयार करता है, जिनमें संदेश का मुख्य भाग होता है, देखें ईमेल भेजने के अनुरोध बनाएं.

डिलीवरी के विकल्प

FCM, Android डिवाइसों पर भेजे गए मैसेज के लिए डिलीवरी के विकल्पों का एक खास सेट उपलब्ध कराता है. साथ ही, Apple के प्लैटफ़ॉर्म और वेब पर भी इसी तरह के विकल्प उपलब्ध कराता है. उदाहरण के लिए, "छोटा किया जा सकने वाला" मैसेज की सेटिंग इस पर काम करती है FCM के collapse_key से Android पर, Apple पर इसके ज़रिए apns-collapse-id और JavaScript/वेब पर Topic के ज़रिए. ज़्यादा जानकारी के लिए, इस सेक्शन में दी गई जानकारी और इससे जुड़े रेफ़रंस दस्तावेज़ देखें.

छोटे नहीं किए जा सकने वाले और छोटे किए जा सकने वाले मैसेज

छोटा न किया जा सकने वाला मैसेज बताता है कि हर मैसेज डिवाइस पर डिलीवर किए गए. छोटा न हो सकने वाला मैसेज, कुछ काम की जानकारी देता है ऐसा कॉन्टेंट जिसमें छोटे हो जाने वाले बैनर विज्ञापन, जैसे कि बिना कॉन्टेंट वाला "पिंग" दिखाया जाता है से मोबाइल ऐप्लिकेशन का इस्तेमाल करें, ताकि डेटा फ़ेच करने के लिए सर्वर से संपर्क किया जा सके.

आम तौर पर, छोटे नहीं किए जा सकने वाले मैसेज के इस्तेमाल के उदाहरण, चैट मैसेज या शामिल हैं. उदाहरण के लिए, किसी IM ऐप्लिकेशन में, आप हर मैसेज को डिलीवर करना चाहेंगे, क्योंकि हर मैसेज का कॉन्टेंट अलग-अलग होता है.

Android डिवाइसों पर, 100 मैसेज को बिना छोटा किए सेव किया जा सकता है. अगर सीमा पूरी हो गई है, सभी संग्रहित संदेश छोड़ दिए जाते हैं. डिवाइस वापस चालू होने पर तो उसे एक विशेष संदेश मिलता है, जो यह बताता है कि सीमा पूरी हो चुकी है. इसके बाद, ऐप्लिकेशन आम तौर पर पूरे डेटा का अनुरोध करके स्थिति को ठीक कर सकता है को सिंक करने की सुविधा मिलती है.

छोटा हो जाने वाला मैसेज, ऐसा मैसेज होता है जिसे नया मैसेज मिल सकता है, अगर उसे डिवाइस पर अभी तक डिलीवर नहीं किया गया है.

छोटा किए जा सकने वाले मैसेज के सामान्य इस्तेमाल के उदाहरणों में, ऐसे मैसेज शामिल हैं जिनका इस्तेमाल किसी मोबाइल ऐप्लिकेशन को सर्वर से डेटा सिंक करने के लिए किया जाता है. अगर आप उदाहरण के लिए, खेल-कूद से जुड़ा कोई ऐप्लिकेशन हो, जिसमें उपयोगकर्ताओं को उनके हाल ही के स्कोर की जानकारी दी जाती है. सिर्फ़ सबसे नया मैसेज काम का होता है.

Android पर किसी मैसेज को 'छोटा किया जा सकता है' के तौर पर मार्क करने के लिए, collapse_key पैरामीटर में मैसेज पेलोड. डिफ़ॉल्ट रूप से, ऐप्लिकेशन के पैकेज का नाम 'छोटा करें' बटन होता है Firebase कंसोल में रजिस्टर किया जाता है. FCM का सर्वर ये काम कर सकता है इस ऐप्लिकेशन में, छोटे हो जाने वाले चार अलग-अलग मैसेज एक साथ सेव किए जाते हैं. जिसमें हर डिवाइस पर अलग-अलग छोटा बटन मौजूद होता है. इस संख्या से ज़्यादा होने पर, FCM सिर्फ़ चार कॉलपस बटन सेव करता है. हालांकि, यह तय नहीं होता कि कौनसे बटन सेव किए जाएंगे.

बिना पेलोड वाले विषय संदेश, डिफ़ॉल्ट रूप से छोटे हो सकते हैं. सूचना वाले मैसेज को हमेशा छोटा किया जा सकता है. साथ ही, ये collapse_key पैरामीटर को अनदेखा करेंगे.

मुझे किसका इस्तेमाल करना चाहिए?

परफ़ॉर्मेंस के लिहाज़ से, छोटे किए जा सकने वाले मैसेज का बेहतर विकल्प होता है. यह मुमकिन है कि आपके ऐप्लिकेशन को छोटे न किए जा सकने वाले मैसेज इस्तेमाल करने की ज़रूरत न हो. हालांकि, अगर आपने मैसेज को छोटा करने की सुविधा का इस्तेमाल किया है, तो ध्यान रखें कि FCM, किसी भी समय रजिस्टर करने के लिए इस्तेमाल किए गए टोकन के लिए, FCM की मदद से सिर्फ़ चार अलग-अलग छोटा करने की कुंजियों का इस्तेमाल करने की अनुमति देता है. आपको इस संख्या से ज़्यादा क्वेरी नहीं भेजनी चाहिए. ऐसा करने पर, आपको अनचाहे नतीजे मिल सकते हैं.

किसी मैसेज की प्राथमिकता सेट करना

डाउनस्ट्रीम मैसेज की डिलीवरी की प्राथमिकता तय करने के लिए, आपके पास दो विकल्प हैं: सामान्य और ज़्यादा प्राथमिकता. अलग-अलग प्लैटफ़ॉर्म पर, मैसेज डिलीवर होने का तरीका थोड़ा अलग होता है. हालांकि, सामान्य और ज़्यादा प्राथमिकता वाले मैसेज डिलीवर होने का तरीका इस तरह से होता है:

• सामान्य प्राथमिकता. सामान्य प्राथमिकता वाले मैसेज, ऐप्लिकेशन के फ़ोरग्राउंड में होने पर तुरंत डिलीवर किए जाते हैं. बैकग्राउंड में इस्तेमाल किए जाने वाले ऐप्लिकेशन के लिए, डिलीवरी देर से है. अगर आपको ऐसे मैसेज डिलीवर करने हैं जिनके लिए समय का ज़्यादा फ़र्क़ नहीं पड़ता, तो डिलीवरी की सामान्य प्राथमिकता चुनें. जैसे, नए ईमेल की सूचनाएं, यूज़र इंटरफ़ेस (यूआई) को सिंक रखना या बैकग्राउंड में ऐप्लिकेशन का डेटा सिंक करना.

• ज़्यादा प्राथमिकता. FCM, सबसे ज़्यादा प्राथमिकता वाले मैसेज तुरंत डिलीवर करने की कोशिश करता है. भले ही, डिवाइस 'डॉज़ मोड' में हो. ज़्यादा प्राथमिकता वाले मैसेज, समय के हिसाब से ज़रूरी और उपयोगकर्ता को दिखने वाले कॉन्टेंट के लिए होते हैं.

यहां FCM एचटीटीपी v1 प्रोटोकॉल के ज़रिए भेजे गए सामान्य प्राथमिकता वाले मैसेज का उदाहरण दिया गया है. इस मैसेज का मकसद, मैगज़ीन के किसी सदस्य को यह सूचना देना है कि नया कॉन्टेंट डाउनलोड करने के लिए उपलब्ध है:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

प्लैटफ़ॉर्म के हिसाब से, मैसेज की प्राथमिकता सेट करने के बारे में ज़्यादा जानकारी पाने के लिए:

• एपीएन दस्तावेज़
• मैसेज की प्राथमिकता सेट और मैनेज करना (Android)
• वेब पर भेजे जाने वाले पुश मैसेज का कितना ज़रूरी है

जान बचाने के लिए इस्तेमाल के उदाहरण

FCM एपीआई को आपातकालीन सूचनाओं या ज़्यादा जोखिम वाली अन्य गतिविधियों के लिए डिज़ाइन नहीं किया गया है. इन गतिविधियों में, एपीआई के इस्तेमाल या काम न कर पाने पर, मौत, व्यक्तिगत चोट या पर्यावरण को नुकसान पहुंच सकता है. जैसे, परमाणु सुविधाओं का संचालन, एयर ट्रैफ़िक कंट्रोल या लाइफ़ सपोर्ट सिस्टम. सेक्शन 4. a के तहत, इस तरह के इस्तेमाल पर साफ़ तौर पर पाबंदी है. 7 के तहत किया जाएगा. शर्तों का पालन करने के लिए, ऐप्लिकेशन को मैनेज करने की ज़िम्मेदारी आपकी ही है. साथ ही, शर्तों का पालन न करने की वजह से होने वाले किसी भी नुकसान की ज़िम्मेदारी भी आपकी ही होगी. Google, एपीआई को "जैसा है" के तौर पर उपलब्ध कराता है, और वह एपीआई को बंद करने का अधिकार सुरक्षित रखता है या किसी भी भाग या सुविधा या वहां आपकी पहुंच, किसी भी कारण से और किसी भी बिना किसी कानूनी जवाबदेही या अन्य जवाबदेही के, आपके या आपके उपयोगकर्ताओं के प्रति बिना किसी कानूनी जवाबदेही के.

किसी मैसेज की समयसीमा सेट करना

आम तौर पर, FCM मैसेज भेजने के तुरंत बाद उन्हें डिलीवर कर देता है. हालांकि, ऐसा हमेशा नहीं हो पाता. उदाहरण के लिए, अगर प्लैटफ़ॉर्म Android डिवाइस बंद है, ऑफ़लाइन हो सकता है या हो सकता है कि वह उपलब्ध न हो. इसके अलावा, FCM जान-बूझकर मैसेज भेजने में देरी भी कर सकता है किसी ऐप्लिकेशन को संसाधनों का ज़रूरत से ज़्यादा इस्तेमाल करने से रोकने और बैटरी लाइफ़ पर असर डाल रही हैं.

ऐसा होने पर, FCM मैसेज सेव कर लेता है और उसे तुरंत डिलीवर कर देता है जितना मुमकिन है. ज़्यादातर मामलों में ऐसा करना ठीक है. हालांकि, कुछ ऐप्लिकेशन के लिए ऐसा हो सकता है कि देर से भेजा गया मैसेज कभी डिलीवर न हो. उदाहरण के लिए, अगर मैसेज, इनकमिंग कॉल या वीडियो चैट की सूचना है. इसका सिर्फ़ मतलब है को कुछ समय के लिए बरकरार रख सकते हैं. अगर मैसेज किसी इवेंट का न्योता है, तो इवेंट खत्म होने के बाद मिलने पर वह बेकार हो जाता है.

Android और वेब/JavaScript पर, दिखाई देगा. वैल्यू 0 से 2,419,200 सेकंड (28 दिन) के बीच होनी चाहिए. यह वह ज़्यादा से ज़्यादा समय होता है जिसके लिए FCM मैसेज को सेव करता है और डिलीवर करने की कोशिश करता है. जिन अनुरोधों में यह फ़ील्ड नहीं होता है उनके लिए, डिफ़ॉल्ट रूप से चार हफ़्ते की समयसीमा तय होती है.

इस सुविधा का इस्तेमाल इन कामों में किया जा सकता है:

• वीडियो चैट इनकमिंग कॉल
• समयसीमा खत्म होने वाले न्योते वाले इवेंट
• कैलेंडर इवेंट

मैसेज के दिखने की अवधि तय करने का एक और फ़ायदा यह है कि FCM, मैसेज के दिखने की अवधि 0 सेकंड पर सेट होने पर, मैसेज को छोटा करने की सुविधा लागू नहीं करता. FCM उन मैसेज को सबसे बेहतर तरीके से मैनेज करता है जिन्हें "अभी या कभी नहीं" डिलीवर किया. ध्यान रखें कि time_to_live का मान 0 का मतलब है कि जिन मैसेज को तुरंत डिलीवर नहीं किया जा सकता उन्हें खारिज कर दिया जाएगा. हालांकि, इस तरह के मैसेज कभी सेव नहीं किए जाते. इसलिए, सूचना वाले मैसेज भेजने के लिए, यह सबसे कम इंतज़ार का समय देता है.

यहां एक अनुरोध का उदाहरण दिया गया है जिसमें TTL शामिल है:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

मैसेज कब तक मौजूद रहेगा

जब कोई ऐप्लिकेशन सर्वर FCM को कोई मैसेज पोस्ट करता है और उसे मैसेज मिलता है आईडी नहीं है, तो इसका यह मतलब नहीं है कि संदेश को पहले ही डिवाइस. इसका मतलब है कि इसे डिलीवरी के लिए स्वीकार कर लिया गया है. क्या होता है कोई मैसेज तब ही दिखेगा, जब उसे स्वीकार किया जाएगा. यह कई बातों पर निर्भर करता है.

सबसे सही स्थिति में, अगर डिवाइस FCM से कनेक्ट है, स्क्रीन चालू है, और डेटा ट्रैफ़िक को कम करने से जुड़ी कोई पाबंदी नहीं है, तो मैसेज तुरंत डिलीवर हो जाता है.

अगर डिवाइस कनेक्ट है, लेकिन Doze में है, तो कम प्राथमिकता वाला मैसेज सेव किया जाता है जब तक डिवाइस Doze से खत्म नहीं हो जाता, तब तक FCM तक. और यहां collapse_key फ़्लैग की भूमिका होती है: अगर पहले से ही एक संदेश है, जिसमें उसी संक्षिप्त कुंजी (और पंजीकरण टोकन) को सहेजा गया है और इसकी इंतज़ार कर रही हूँ डिलीवरी के दौरान, पुराना मैसेज खारिज कर दिया जाता है और नया मैसेज उसकी जगह ले लेता है (इसका मतलब है कि नए मैसेज ने पुराने मैसेज को छोटा कर दिया है). हालांकि, अगर संक्षिप्त कुंजी सेट नहीं है, नए और पुराने दोनों संदेश भावी वितरण के लिए संग्रहित किए जाते हैं.

अगर डिवाइस FCM से कनेक्ट नहीं किया गया है, तो मैसेज इस समय तक सेव रहता है कनेक्शन स्थापित हो जाता है (संक्षिप्त मुख्य नियमों का दोबारा पालन करते हुए). जब कनेक्शन बन गया है, FCM बाकी सभी मैसेज इस ईमेल पते पर डिलीवर कर देगा डिवाइस. अगर डिवाइस फिर कभी कनेक्ट नहीं होता है (उदाहरण के लिए, अगर उसे फ़ैक्ट्री रीसेट किया गया था), तो मैसेज का समय खत्म हो जाता है और को FCM स्टोरेज से निकाल दिया जाता है. डिफ़ॉल्ट टाइम आउट चार हफ़्ते का है, जब तक कि time_to_live फ़्लैग सेट न किया गया हो.

मैसेज की डिलीवरी के बारे में ज़्यादा अहम जानकारी पाने के लिए:

Android या Apple प्लैटफ़ॉर्म पर मैसेज डिलीवरी के बारे में ज़्यादा जानकारी पाने के लिए, FCM रिपोर्टिंग डैशबोर्ड देखें. इसमें, Apple और Android डिवाइसों पर भेजे गए और खोले गए मैसेज की संख्या के साथ-साथ, Android ऐप्लिकेशन के लिए "इंप्रेशन" (उपयोगकर्ताओं को मिली सूचनाएं) का डेटा भी रिकॉर्ड किया जाता है.

अगर किसी Android डिवाइस पर चैनल के साथ सीधे मैसेज करने की सुविधा चालू है और वह डिवाइस एक महीने से FCM से कनेक्ट नहीं है, तो भी FCM मैसेज स्वीकार कर लेता है. हालांकि, वह मैसेज को तुरंत खारिज कर देता है. अगर आपके द्वारा इस पर भेजे गए अंतिम डेटा संदेश के चार सप्ताह के भीतर डिवाइस कनेक्ट हो जाता है, आपके क्लाइंट को on deletedMessages() कॉलबैक मिलता है. इसके बाद, ऐप्लिकेशन इस स्थिति को ठीक से मैनेज कर सकता है. आम तौर पर, ऐप्लिकेशन सर्वर से पूरी तरह सिंक करने का अनुरोध करके ऐसा किया जाता है.

आखिर में, जब FCM डिवाइस पर कोई मैसेज डिलीवर करने की कोशिश करता है और ऐप्लिकेशन को अनइंस्टॉल कर दिया जाता है, तो FCM उस मैसेज को तुरंत खारिज कर देता है और रजिस्ट्रेशन टोकन को अमान्य कर देता है. उस डिवाइस पर मैसेज भेजने की कोशिश करने पर, NotRegistered गड़बड़ी का मैसेज दिखता है.

थ्रॉटलिंग और कोटा

हमारा लक्ष्य है कि FCM से भेजे गए हर मैसेज को हमेशा डिलीवर किया जाए. हालांकि, कभी-कभी हर मैसेज डिलीवर करने से, उपयोगकर्ता को खराब अनुभव मिल सकता है. अन्य मामलों में, हमें सीमाएं तय करनी होती हैं, ताकि यह पक्का किया जा सके कि FCM, मैसेज भेजने वाले सभी लोगों के लिए, स्केलेबल सेवा उपलब्ध करा सके. इसमें बताई गई सीमाएं और कोटा के टाइप इस सेक्शन से, हमें इन अहम फ़ैक्टर के बीच संतुलन बनाने में मदद मिलती है.

डाउनस्ट्रीम मैसेज थ्रॉटलिंग

हर प्रोजेक्ट के लिए, डाउनस्ट्रीम के लिए हर मिनट के कोटा की मदद से पेश किया गया एचटीटीपी v1 API को बढ़ावा देते हैं. हर मिनट 6 लाख मैसेज भेजने की डिफ़ॉल्ट सीमा, FCM के 99% से ज़्यादा डेवलपर के लिए है. इससे सिस्टम की स्थिरता बनी रहती है और अचानक ज़्यादा प्रोजेक्ट होने पर होने वाले असर को कम किया जा सकता है.

ज़्यादा ट्रैफ़िक का पैटर्न कोटा से ज़्यादा गड़बड़ियां हो सकती हैं. कोटा से ज़्यादा उदाहरण के लिए, सिस्टम कोटा अगले मिनट में फिर से भर दिया जाता है. ज़्यादा अनुरोध मिलने पर भी 429 कोड वाले रिस्पॉन्स मिल सकते हैं. इसलिए, हमारा सुझाव है कि आप पब्लिश किए गए सुझावों के मुताबिक, 429 कोड वाले रिस्पॉन्स मैनेज करें.

ध्यान दें कि:

• डाउनस्ट्रीम कोटा, मैसेज का आकलन करता है, अनुरोधों का नहीं.
• क्लाइंट से जुड़ी गड़बड़ियों (एचटीटीपी स्टेटस कोड 400-499) की गिनती की जाती है. हालांकि, 429 कोड वाली गड़बड़ियों की गिनती नहीं की जाती.
• कोटा हर मिनट के हिसाब से होता है, लेकिन ये मिनट घड़ी के हिसाब से अलाइन नहीं होते.

मॉनिटरिंग कोटा

Google Cloud Console पर कोटा, इस्तेमाल, और गड़बड़ियां देखी जा सकती हैं:

1. Google Cloud console पर जाएं
2. एपीआई और सेवाएं चुनें
3. टेबल की सूची से, Firebase Cloud Messaging API चुनें
4. कोटा और सिस्टम की सीमाएं चुनें.

ध्यान दें: ये ग्राफ़, कोटा के मिनट के हिसाब से सटीक तौर पर अलाइन नहीं होते. इसका मतलब है कि जब ट्रैफ़िक कोटा से कम दिखता है, तो 429 कोड दिखाया जा सकता है.

कोटा बढ़ाने का अनुरोध करना

कोटा बढ़ाने का अनुरोध करने से पहले, पक्का करें कि:

• आपका इस्तेमाल, हर दिन कम से कम पांच मिनट तक लगातार कोटे के 80% से ज़्यादा होता है.
• आपके पास क्लाइंट गड़बड़ी का अनुपात 5% से कम है, खास तौर पर ज़्यादा ट्रैफ़िक के दौरान.
• आप बड़े पैमाने पर मैसेज भेजने के सबसे सही तरीकों का पालन करते हैं.

इन शर्तों को पूरा करने पर, ज़्यादा से ज़्यादा 25% तक कोटा बढ़ाने का अनुरोध सबमिट किया जा सकता है. FCM, अनुरोध को पूरा करने के लिए हर संभव कोशिश करेगा. हालांकि, कोटा बढ़ाए जाने की कोई गारंटी नहीं दी जा सकती.

अगर आपको किसी लॉन्च या कुछ समय के लिए होने वाले इवेंट की वजह से, डाउनस्ट्रीम मैसेजिंग के लिए ज़्यादा कोटा चाहिए, तो कम से कम 15 दिन पहले कोटा का अनुरोध करें, ताकि अनुरोध को पूरा करने के लिए ज़रूरत के मुताबिक समय मिल सके. बड़े अनुरोधों के लिए (हर मिनट 1.8 करोड़ मैसेज), कम से कम इसके लिए, 30 दिनों का नोटिस देना ज़रूरी है. लॉन्च और खास इवेंट के अनुरोध अब भी हैं गड़बड़ी का अनुपात और सबसे सही तरीके की शर्तों के हिसाब से तय होता है.

FCM कोटा के बारे में अक्सर पूछे जाने वाले सवाल भी देखें.

किसी विषय के लिए मैसेज की सीमा

किसी विषय की सदस्यता जोड़ने या हटाने की दर, हर प्रोजेक्ट के लिए 3,000 क्यूपीएस तक सीमित है.

मैसेज भेजने की दरों के बारे में जानने के लिए, फ़ैनआउट थ्रॉटलिंग देखें.

फ़ैनआउट थ्रॉटलिंग

मैसेज के फ़ैनआउट की मदद से, एक से ज़्यादा डिवाइसों पर मैसेज भेजे जा सकते हैं. जैसे: जब आप विषयों और समूहों को लक्षित करते है या जब आप सूचनाएं बनाने वाला व्यक्ति ऑडियंस या उपयोगकर्ताओं के ग्रुप को टारगेट करने के लिए किया जा सकता है.

मैसेज फ़ैनआउट तुरंत नहीं होता. इसलिए, कभी-कभी एक साथ कई फ़ैनआउट होते हैं. हम एक साथ दिखाए जाने वाले मैसेज की संख्या सीमित रखते हैं प्रति प्रोजेक्ट की संख्या 1,000 तक हो गई. इसके बाद, हम फ़ैनआउट के अतिरिक्त अनुरोधों को अस्वीकार कर सकते हैं या अनुरोधों के फ़ैनआउट को तब तक के लिए रोक सकते हैं, जब तक कि पहले से चल रहे कुछ फ़ैनआउट पूरे नहीं हो जाते.

फ़ैनआउट की दर पर, एक ही समय में फ़ैनआउट का अनुरोध करने वाले प्रोजेक्ट की संख्या का असर पड़ता है. 10,000 क्यूपीएस की फ़ैनआउट दर, अलग-अलग प्रोजेक्ट असामान्य नहीं हैं, लेकिन यह संख्या कोई गारंटी नहीं है और लोड करते हैं. यह ध्यान रखना ज़रूरी है कि मौजूदा फ़ैनआउट क्षमता को प्रोजेक्ट के हिसाब से बांटा गया है, न कि पूरे फ़ैनआउट के हिसाब से अनुरोध. इसलिए, अगर आपके प्रोजेक्ट में दो फ़ैनआउट चल रहे हैं, तो हर फ़ैनआउट को फ़ैनआउट के लिए उपलब्ध दर का सिर्फ़ आधा हिस्सा दिखेगा. आपके विज्ञापन को व्यवस्थित करने के लिए, फ़ैनआउट स्पीड का मतलब है कि एक बार में सिर्फ़ एक ऐक्टिव फ़ैनआउट बनाया जा रहा है.

मैसेज को छोटा करने की सुविधा

जैसा कि ऊपर बताया गया है, छोटा किए जा सकने वाले मैसेज, बिना कॉन्टेंट वाली सूचनाएं होती हैं. इन्हें एक-दूसरे के ऊपर छोटा किया जा सकता है. अगर कोई डेवलपर किसी ऐप्लिकेशन में एक ही मैसेज को बार-बार दिखाता है, तो हम मैसेज दिखाने में देरी करते हैं (थ्रॉटल करते हैं), ताकि उपयोगकर्ता की बैटरी पर कम से कम असर पड़े.

उदाहरण के लिए, अगर किसी एक डिवाइस पर ईमेल सिंक करने के कई नए अनुरोध भेजे जाते हैं, तो हम ईमेल सिंक करने के अगले अनुरोध को कुछ मिनट के लिए रोक सकते हैं, ताकि डिवाइस कम औसत दर से सिंक हो सके. यह थ्रॉटलिंग सिर्फ़ इन कामों के लिए की जाती है बैटरी पर उपयोगकर्ता के अनुभव को कम किया जा सकता है.

अगर आपके इस्तेमाल के उदाहरण के लिए, मैसेज भेजने के ऐसे पैटर्न की ज़रूरत है जिन्हें एक साथ कई बार हटाया गया है, तो हो सकता है कि छोटे न होने वाले मैसेज सही विकल्प नहीं चुना जा सकता. ऐसे मैसेज के लिए, बैटरी खर्च को कम करने के लिए, मैसेज में कॉन्टेंट शामिल करना न भूलें.

हम हर डिवाइस के लिए, हर ऐप्लिकेशन के लिए, छोटे किए जा सकने वाले मैसेज की संख्या को 20 मैसेज तक सीमित रखते हैं. हर तीन मिनट में एक मैसेज फिर से भरें.

XMPP सर्वर थ्रॉटलिंग

हम FCM XMPP सर्वर से कनेक्ट करने की दर को 400 कनेक्शन तक सीमित करते हैं प्रति मिनट प्रति मिनट की बचत करनी होगी. इससे मैसेज डिलीवरी पर कोई असर नहीं पड़ता. हालांकि, सिस्टम के सही तरीके से काम करने के लिए, यह ज़रूरी है. हर प्रोजेक्ट के लिए, FCM, एक साथ 2,500 कनेक्शन की अनुमति देता है.

XMPP के साथ अपस्ट्रीम मैसेजिंग के लिए, FCM हर प्रोजेक्ट के लिए अपस्ट्रीम मैसेज की सीमा को 1,500,000/मिनट तक सीमित करता है, ताकि अपस्ट्रीम डेस्टिनेशन सर्वर पर लोड कम हो.

हम हर डिवाइस के लिए, अपस्ट्रीम मैसेज की संख्या को 1,000/मिनट तक सीमित रखते हैं. इससे, ऐप्लिकेशन के खराब व्यवहार की वजह से बैटरी खत्म होने से बचा जा सकता है.

किसी एक डिवाइस पर मैसेज भेजने की दर

Android के लिए, आप एक मिनट में 240 मैसेज/मिनट और 5,000 मैसेज/घंटा तक भेज सकते हैं डिवाइस. इस थ्रेशोल्ड का मकसद, ट्रैफ़िक में कुछ समय के लिए होने वाली बढ़ोतरी को कंट्रोल करना है. जैसे, जब उपयोगकर्ता चैट पर तेज़ी से इंटरैक्ट कर रहे हों. इस सीमा से, डिवाइस की बैटरी को गलती से खर्च होने से रोकने के लिए, लॉजिक भेजने में होने वाली गड़बड़ियों को रोका जा सकता है.

iOS के लिए, अगर दर APNs की सीमाओं से ज़्यादा है, तो हम गड़बड़ी का मैसेज दिखाते हैं.

FCM पोर्ट और आपका फ़ायरवॉल

अगर आपके संगठन में इंटरनेट पर या उससे आने वाले ट्रैफ़िक पर पाबंदी लगाने के लिए फ़ायरवॉल है, तो आपको इसे कॉन्फ़िगर करना होगा, ताकि मोबाइल डिवाइसों को FCM से कनेक्ट करने की अनुमति मिल सके. इससे आपके नेटवर्क पर मौजूद डिवाइसों को मैसेज मिल पाएंगे. आम तौर पर, FCM पोर्ट 5228 का इस्तेमाल करता है. हालांकि, कभी-कभी यह 443, 5229, और 5230 का इस्तेमाल करता है.

आपके नेटवर्क से कनेक्ट होने वाले डिवाइसों के लिए, FCM यह सुविधा नहीं देता है अलग-अलग कर सकते हैं, क्योंकि हमारी आईपी रेंज बहुत बार बदलती रहती है. साथ ही, आपके फ़ायरवॉल के नियम भी बदलते रहते हैं पुराना हो सकता है, जिससे आपके उपयोगकर्ताओं पर अनुभव. आम तौर पर, अनुमति वाली सूची में पोर्ट 5228-5230 और 443 हो सकता है. हालांकि, अगर आपके पास आईपी पाबंदी है, तो आपको goog.json में दिए गए सभी आईपी पतों की अनुमति वाली सूची बनानी होगी. इस बड़ी सूची को नियमित तौर पर अपडेट किया जाता है. हमारा सुझाव है कि आप अपने नियमों को हर महीने अपडेट करते रहें. इस वजह से समस्याएं हुईं फ़ायरवॉल आईपी पाबंदियां, अक्सर रुक-रुककर काम करती हैं. इनका पता लगाना मुश्किल होता है.

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

खुलने के लिए टीसीपी पोर्ट:

• 5228
• 5229
• 5230
• 443

खोलने के लिए होस्टनेम:

• mtalk.google.com
• mtalk4.google.com
• mtalk-staging.google.com
• mtalk-dev.google.com
• alt1-mtalk.google.com
• alt2-mtalk.google.com
• alt3-mtalk.google.com
• alt4-mtalk.google.com
• alt5-mtalk.google.com
• alt6-mtalk.google.com
• alt7-mtalk.google.com
• alt8-mtalk.google.com
• android.apis.google.com
• device-provisioning.googleapis.com
• firebaseinstallations.googleapis.com

नेटवर्क ऐड्रेस ट्रांसलेशन और/या स्टेटफ़ुल पैकेट इंस्पेक्शन फ़ायरवॉल:

अगर आपके नेटवर्क में नेटवर्क एड्रेस ट्रांसलेशन (एनएटी) या स्टेटफ़ुल पैकेट जांच (एसपीआई) लागू है, तो पोर्ट 5228-5230 पर हमारे कनेक्शन के लिए, 30 मिनट या उससे ज़्यादा का टाइम आउट लागू करें. इससे हम भरोसेमंद जानकारी दे पाते हैं इससे आपके उपयोगकर्ताओं की बैटरी की खपत कम होगी और मोबाइल डिवाइस.

वीपीएन इंटरैक्शन और बायपासेबिलिटी

Firebase Cloud Messaging यह पक्का करने के लिए कई कदम उठाता है कि फ़ोन से सर्वर तक पुश मैसेजिंग कनेक्शन भरोसेमंद हो और जितनी बार हो सके उतनी बार उपलब्ध हो. वीपीएन का इस्तेमाल करने की वजह से, यह काम और मुश्किल हो जाता है.

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

अलग-अलग वीपीएन के लिए, यह तय करने का तरीका अलग-अलग होगा कि वह ऐसा कर सकता है या नहीं बायपास किया जा सकता है. निर्देशों के लिए, अपने वीपीएन के दस्तावेज़ देखें.

अगर वीपीएन को बायपास करने के लिए कॉन्फ़िगर नहीं किया गया है, तो Firebase Cloud Messaging, सर्वर से कनेक्ट करने के लिए वीपीएन नेटवर्क का इस्तेमाल करेगा. इसका नतीजा यह हो सकता है कि वह समयावधि जिसमें मैसेज देर से दिखते हैं और बैटरी ज़्यादा चार्ज हो सकती है Cloud Messaging का इस्तेमाल, वीपीएन पर कनेक्शन बनाए रखने के लिए किया जाता है कनेक्शन.

क्रेडेंशियल

FCM की कौनसी सुविधाएं लागू की जाती हैं, इसके आधार पर आपको अपने Firebase प्रोजेक्ट के इन क्रेडेंशियल की ज़रूरत पड़ सकती है: