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

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

मैसेज के टाइप

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

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

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

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

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

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

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

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

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

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

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

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

डेटा मैसेज

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

पक्का करें कि आपने कस्टम की-वैल्यू पेयर में, बुक किए गए किसी भी शब्द का इस्तेमाल न किया हो. रिज़र्व किए गए शब्दों में "from", "notification," "message_type" या "google" या "gcm" से शुरू होने वाला कोई भी शब्द शामिल है.

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

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

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

डेटा मैसेज के लिए एन्क्रिप्शन

Android ट्रांसपोर्ट लेयर (FCM आर्किटेक्चर देखें) में पॉइंट-टू-पॉइंट एन्क्रिप्शन का इस्तेमाल किया जाता है. अपनी ज़रूरतों के हिसाब से, डेटा मैसेज में एंड-टू-एंड एन्क्रिप्शन जोड़ा जा सकता है. FCM, एंड-टू-एंड समाधान उपलब्ध नहीं कराता. हालांकि, Capillary या 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 पर इसे खत्म होने की तारीख के तौर पर सेट किया जाता है.

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

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

• यह 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"
       }
     }
   }
 }

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

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

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

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

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

FCM डिलीवरी के क्रम की गारंटी नहीं देता.

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

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

छोटा किया जा सकने वाला मैसेज ऐसा मैसेज होता है जिसे डिवाइस पर डिलीवर न किए जाने पर, नए मैसेज से बदला जा सकता है.

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

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

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

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

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

	सिनारियो का इस्तेमाल करना	भेजने का तरीका
छोटा नहीं किया जा सकता	हर मैसेज, क्लाइंट ऐप्लिकेशन के लिए ज़रूरी होता है और उसे डिलीवर करना होता है.	सूचना वाले मैसेज को छोड़कर, सभी मैसेज डिफ़ॉल्ट रूप से छोटे नहीं किए जा सकते.
छोटा किया जा सकता है	जब कोई नया मैसेज, क्लाइंट ऐप्लिकेशन के लिए पुराने और मिलते-जुलते मैसेज को अप्रासंगिक बना देता है, तो FCM पुराने मैसेज की जगह ले लेता है. उदाहरण के लिए: सर्वर से डेटा सिंक करने के लिए इस्तेमाल किए गए मैसेज या पुराने नोटिफ़िकेशन मैसेज.	मैसेज के अनुरोध में सही पैरामीटर सेट करें: collapseKey Android पर Apple पर apns-collapse-id Topic वेब पर collapse_key लेगसी प्रोटोकॉल में (सभी प्लैटफ़ॉर्म)

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

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

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

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

Apple डिवाइसों को डेटा मैसेज भेजते समय, प्राथमिकता को 5 या सामान्य प्राथमिकता पर सेट करना ज़रूरी है. ज़्यादा प्राथमिकता वाले मैसेज को FCM बैकएंड ने अस्वीकार कर दिया है. इसकी वजह यह गड़बड़ी है: INVALID_ARGUMENT.

यहां सामान्य प्राथमिकता वाला एक मैसेज दिया गया है. इसे 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, एपीआई को "जैसा है वैसा" के आधार पर उपलब्ध कराता है. साथ ही, Google के पास यह अधिकार है कि वह किसी भी समय और किसी भी वजह से, एपीआई या उसके किसी हिस्से, सुविधा या उसके ऐक्सेस को बंद कर सकता है. इसके लिए, Google पर आपको या आपके उपयोगकर्ताओं को जवाब देने की कोई ज़िम्मेदारी या अन्य जवाबदेही नहीं होगी.

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

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

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

Android और वेब/JavaScript पर, किसी मैसेज की ज़्यादा से ज़्यादा अवधि तय की जा सकती है. इसकी वैल्यू 0 से 24,19,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 से कनेक्ट है, स्क्रीन चालू है, और थ्रॉटलिंग से जुड़ी कोई पाबंदी नहीं है, तो मैसेज तुरंत डिलीवर हो जाता है.

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

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

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

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

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

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

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

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

ध्यान दें: इस सेक्शन में बताई गई सीमाएं बदल सकती हैं.

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

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

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

ध्यान दें कि:

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

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

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

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

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

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

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

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

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

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

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

विषय के हिसाब से मैसेज भेजने की सीमा

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

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

डुप्लीकेट डेटा की गड़बड़ी के लिए थ्रॉटलिंग

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

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

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

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

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

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

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

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

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

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 मिनट या उससे ज़्यादा का टाइम आउट लागू करें. इससे हम भरोसेमंद कनेक्टिविटी उपलब्ध करा पाते हैं. साथ ही, इससे आपके उपयोगकर्ताओं के मोबाइल डिवाइसों की बैटरी कम खर्च होती है.

ध्यान दें: अगर आपको APNs के ज़रिए सूचनाएं मिल रही हैं, तो पक्का करें कि आपने Apple की ओर से तय किए गए पोर्ट भी खोले हों.

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

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

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

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

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

क्रेडेंशियल

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

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