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

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

मैसेज के टाइप

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

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

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

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

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

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

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

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

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

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

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

डेटा मैसेज

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मैसेज कितने समय तक सेव रहता है

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हम हर डिवाइस पर, हर ऐप्लिकेशन के लिए 20 मैसेज तक सिमटने की सुविधा देते हैं. साथ ही, हर तीन मिनट में एक मैसेज फिर से भर जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

• 5228
• 5229
• 5230
• 443

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

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

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

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

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

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

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

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

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

क्रेडेंशियल

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