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

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

मैसेज के टाइप

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

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

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

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

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

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

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

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

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

{
  "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 असली समाधान उपलब्ध नहीं कराता. हालांकि, 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 एडमिन SDK टूल और FCM v1 एचटीटीपी प्रोटोकॉल, दोनों ही आपके मैसेज अनुरोधों को message ऑब्जेक्ट में उपलब्ध सभी फ़ील्ड सेट करने की अनुमति देते हैं. ऐसे कॉन्टेंट के कुछ उदाहरण यहां दिए गए हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• यह 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 पुराने मैसेज की जगह ले लेता है. उदाहरण के लिए: ऐसे मैसेज जिनका इस्तेमाल, सर्वर से डेटा सिंक करने के लिए किया गया हो या पुरानी सूचना वाले मैसेज.	अपने मैसेज अनुरोध में सही पैरामीटर सेट करें: Android पर collapseKey Apple पर apns-collapse-id वेब पर 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 मैसेज भेजे जाने के तुरंत बाद उन्हें डिलीवर कर देता है. हालांकि, ऐसा हमेशा नहीं हो पाता है. उदाहरण के लिए, अगर प्लैटफ़ॉर्म 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 द्वारा कम प्राथमिकता वाला एक संदेश तब तक सेव किया जाता है जब तक कि डिवाइस की बैटरी खत्म नहीं हो जाती. ऐसी स्थिति में 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 लाख मैसेज का डिफ़ॉल्ट कोटा, 99% से ज़्यादा FCM डेवलपर को कवर करता है. साथ ही, यह सिस्टम की स्थिरता को बनाए रखता है और स्पाइकी प्रोजेक्ट के असर को कम करता है.

ज़्यादा ट्रैफ़िक पैटर्न की वजह से, कोटा से ज़्यादा गड़बड़ियां हो सकती हैं. कोटा से ज़्यादा स्थिति में, यह सिस्टम एचटीटीपी स्टेटस कोड 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 हर प्रोजेक्ट के लिए अपस्ट्रीम मैसेज को 15,00,000/मिनट पर सीमित करता है, ताकि अपस्ट्रीम डेस्टिनेशन सर्वर को ओवरलोड होने से बचाया जा सके.

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

किसी एक डिवाइस पर मैसेज की ज़्यादा से ज़्यादा दर

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

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

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 क्लाउड से मैसेज, यह पक्का करने के लिए कई कदम उठाता है कि फ़ोन से सर्वर पर पुश मैसेज सेवा कनेक्शन भरोसेमंद हो और जितनी बार संभव हो, उतनी बार उपलब्ध हो. वीपीएन का इस्तेमाल करने की वजह से, यह काम और मुश्किल हो जाता है.

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

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

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

क्रेडेंशियल

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

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