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

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

मैसेज के टाइप

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

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

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

	उदाहरण का इस्तेमाल करें	भेजने का तरीका
सूचना मैसेज	जब बैकग्राउंड में चल रहा होता है, तब FCM SDK टूल, क्लाइंट ऐप्लिकेशन की ओर से असली उपयोगकर्ता के डिवाइसों को मैसेज दिखाता है. अगर सूचना मिलने के दौरान ऐप्लिकेशन फ़ोरग्राउंड में चल रहा है, तो ऐप्लिकेशन का कोड यह तय करता है कि सूचना कैसे दिखेगी. सूचना मैसेज में, उपयोगकर्ता को दिखने वाली की का पहले से तय किया गया सेट होता है. साथ ही, इसमें कस्टम की-वैल्यू पेयर का वैकल्पिक डेटा पेलोड भी होता है.	Cloud Functions या अपने ऐप्लिकेशन सर्वर जैसे भरोसेमंद प्लैटफ़ॉर्म में, एडमिन SDK टूल या एचटीटीपी v1 API का इस्तेमाल करें. notification बटन सेट करें. इसमें डेटा पेलोड वैकल्पिक हो सकता है. हमेशा छोटा किया जा सकता है. डिसप्ले सूचनाओं के कुछ उदाहरण देखें और अनुरोध पेलोड भेजें. सूचनाएं कंपोजर का इस्तेमाल करें: मैसेज का टेक्स्ट, टाइटल वगैरह डालें और भेजें. कस्टम डेटा देकर, वैकल्पिक डेटा पेलोड जोड़ें.
डेटा मैसेज	डेटा मैसेज प्रोसेस करने की ज़िम्मेदारी क्लाइंट ऐप्लिकेशन की होती है. डेटा मैसेज में सिर्फ़ कस्टम की-वैल्यू पेयर होते हैं जिनमें कोई रिज़र्व कुंजी नाम नहीं होता (नीचे देखें).	Cloud Functions या अपने ऐप्लिकेशन सर्वर जैसे भरोसेमंद प्लैटफ़ॉर्म में, एडमिन SDK टूल या FCM सर्वर प्रोटोकॉल का इस्तेमाल करें. डेटा भेजने के अनुरोध में, data बटन सेट करें.

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

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

सूचना वाले मैसेज

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

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

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

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

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

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

• ज़्यादा प्राथमिकता. 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 मोड में है, तो FCM कम प्राथमिकता वाले मैसेज को तब तक सेव करता है, जब तक डिवाइस Doze मोड से बाहर नहीं निकल जाता. ऐसी स्थिति में 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 (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 दिन पहले कोटा का अनुरोध करें, ताकि अनुरोध को पूरा करने के लिए ज़रूरत के मुताबिक समय मिल सके. बड़े अनुरोधों (हर मिनट 1.8 करोड़ से ज़्यादा मैसेज) के लिए, कम से कम 30 दिनों का नोटिस देना ज़रूरी है. लॉन्च और खास इवेंट के अनुरोधों पर अब भी क्लाइंट गड़बड़ी के अनुपात और सबसे सही तरीकों की ज़रूरी शर्तें लागू होती हैं.

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

विषय संदेश सीमा

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

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

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

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

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

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

छोटा किया जा सकने वाला मैसेज थ्रॉटलिंग

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

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

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

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

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

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

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 प्रोजेक्ट के इन क्रेडेंशियल की ज़रूरत पड़ सकती है:

प्रोजेक्ट आईडी	आपके Firebase प्रोजेक्ट के लिए एक यूनीक आइडेंटिफ़ायर, जिसका इस्तेमाल FCM v1 एचटीटीपी एंडपॉइंट के अनुरोधों में किया जाता है. यह वैल्यू Firebase कंसोल सेटिंग पैनल में उपलब्ध है.
रजिस्ट्रेशन टोकन	एक यूनीक टोकन स्ट्रिंग, जो हर क्लाइंट ऐप्लिकेशन इंस्टेंस की पहचान करती है. एक डिवाइस और डिवाइस पर ग्रुप मैसेज के लिए, रजिस्ट्रेशन टोकन ज़रूरी है. ध्यान दें कि रजिस्ट्रेशन टोकन को गुप्त रखना ज़रूरी है.
ईमेल भेजने वाले का आईडी	Firebase प्रोजेक्ट बनाते समय बनाई गई यूनीक संख्या वाली वैल्यू, जो Firebase कंसोल के सेटिंग पैनल के Cloud Messaging टैब में उपलब्ध होती है. भेजने वाले के आईडी का इस्तेमाल, ईमेल भेजने वाले हर उस व्यक्ति की पहचान करने के लिए किया जाता है जो क्लाइंट ऐप्लिकेशन पर मैसेज भेज सकता है.
ऐक्सेस टोकन	कुछ समय के लिए उपलब्ध OAuth 2.0 टोकन, जो एचटीटीपी v1 API को अनुरोध भेजने की अनुमति देता है. यह टोकन, आपके Firebase प्रोजेक्ट से जुड़े सेवा खाते से जुड़ा होता है. ऐक्सेस टोकन बनाने और रोटेट करने के लिए, अनुरोध भेजने की अनुमति दें में बताया गया तरीका अपनाएं.
सर्वर पासकोड (**बंद किए गए** लेगसी प्रोटोकॉल के लिए)	एक सर्वर कुंजी, जो आपके ऐप्लिकेशन सर्वर को Google की सेवाओं को ऐक्सेस करने की अनुमति देती है. इसमें, इस्तेमाल में न होने वाले Firebase Cloud Messaging लीगेसी प्रोटोकॉल के ज़रिए मैसेज भेजना भी शामिल है. अहम जानकारी: अपने क्लाइंट कोड में, सर्वर पासकोड को कहीं भी शामिल न करें. साथ ही, अपने ऐप्लिकेशन सर्वर को अनुमति देने के लिए, सिर्फ़ सर्वर कुंजियों का इस्तेमाल करें. Android, Apple प्लैटफ़ॉर्म, और ब्राउज़र कुंजियों को FCM ने अस्वीकार कर दिया है.