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 प्रोटोकॉल के सूचना ऑब्जेक्ट का रेफ़रंस दस्तावेज़ देखें.

डेटा मैसेज

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

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

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

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

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

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

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

प्रोग्राम के ज़रिए या 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 और वेब प्लैटफ़ॉर्म के लिए, 'लाइव रहने का समय' लंबा सेट करता है. साथ ही, APNs (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"
       }
     }
   }
 }

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

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

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

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

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

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

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 होने का मतलब है कि ऐसे मैसेज जिन्हें तुरंत डिलीवर नहीं किया जा सकता उन्हें खारिज कर दिया जाता है. हालांकि, इस तरह के मैसेज कभी सेव नहीं किए जाते. इसलिए, सूचना वाले मैसेज भेजने के लिए, यह सबसे कम इंतज़ार का समय देता है.

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

{
  "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 में है, तो FCM के ज़रिए कम प्राथमिकता वाला मैसेज तब तक सेव किया जाता है, जब तक डिवाइस की बैटरी खत्म नहीं हो जाती. और यहीं पर collapse_key फ़्लैग की भूमिका अहम हो जाती है: अगर पहले से ही एक मैसेज, एक ही कॉलप करें बटन की सुविधा वाली कुंजी (और रजिस्टरेशन टोकन) के साथ सेव है और डिलीवरी के लिए इंतज़ार कर रहा है, तो पुराने मैसेज को हटा दिया जाता है और नए मैसेज को उसकी जगह ले लिया जाता है. इसका मतलब है कि पुराने मैसेज को नए मैसेज से छोटा कर दिया जाता है. हालांकि, अगर 'छोटा करें' बटन को सेट नहीं किया गया है, तो आने वाले समय में डिलीवरी के लिए नए और पुराने, दोनों मैसेज सेव किए जाते हैं.

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

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

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

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

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

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

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

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

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

ट्रैफ़िक के अचानक बढ़ने वाले पैटर्न की वजह से, कोटा से ज़्यादा अनुरोध होने पर दिखने वाली गड़बड़ियां हो सकती हैं. कोटा से ज़्यादा अनुरोध मिलने पर, सिस्टम एचटीटीपी स्टेटस कोड 429 (QUOTA_EXCEEDED) दिखाता है. ऐसा तब तक होता है, जब तक अगले मिनट में कोटा फिर से भर नहीं जाता. ज़्यादा अनुरोध मिलने पर भी 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 दिन पहले कोटा का अनुरोध करें, ताकि अनुरोध को पूरा करने के लिए ज़रूरत के मुताबिक समय मिल सके. ज़्यादा अनुरोधों (हर मिनट में 18 करोड़ से ज़्यादा मैसेज) के लिए, कम से कम 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 को अपने कनेक्शन को बेहतर बनाने और बैटरी लाइफ़ बढ़ाने के लिए होती है. कुछ मामलों में, वीपीएन लंबे समय तक चलने वाले कनेक्शन को सक्रिय रूप से बंद कर देते हैं. इस वजह से, उपयोगकर्ता को खराब अनुभव मिलता है. ऐसा, मैसेज न मिलने या देर से मिलने या बैटरी की खपत ज़्यादा होने की वजह से होता है. जब वीपीएन को इस तरह कॉन्फ़िगर किया जाता है कि हम ऐसा कर सकें, तो हम एन्क्रिप्ट किए गए कनेक्शन (बेस नेटवर्क वाई-फ़ाई या LTE पर) का इस्तेमाल करके वीपीएन को बायपास कर देते हैं. इससे, भरोसेमंद और बैटरी के हिसाब से बेहतर अनुभव मिलता है. FCM के लिए, FCM पुश नोटिफ़िकेशन चैनल पर ही, ऐसे वीपीएन का इस्तेमाल किया जा सकता है जिन्हें ब्लॉक नहीं किया जा सकता. रजिस्टर करने वाले उपयोगकर्ताओं का ट्रैफ़िक वगैरह, वीपीएन के चालू होने पर उसका इस्तेमाल करता है. जब FCM कनेक्शन, वीपीएन को बायपास करता है, तो उसे वीपीएन से मिलने वाले अतिरिक्त फ़ायदे नहीं मिलते. जैसे, आईपी मास्किंग.

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

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

क्रेडेंशियल

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