Firebase Cloud Messaging (FCM) में मैसेज भेजने के कई विकल्प और सुविधाएं मिलती हैं. इस पेज पर दी गई जानकारी से, आपको अलग-अलग तरह के FCM मैसेज और उनके इस्तेमाल के बारे में जानने में मदद मिलेगी.
मैसेज के टाइप
FCM की मदद से, क्लाइंट को दो तरह के मैसेज भेजे जा सकते हैं:
- सूचना वाले मैसेज, जिन्हें कभी-कभी "डिसप्ले मैसेज" भी कहा जाता है. इन्हें FCM SDK टूल अपने-आप मैनेज करता है.
- डेटा मैसेज, जिन्हें क्लाइंट ऐप्लिकेशन मैनेज करता है.
सूचना मैसेज में, उपयोगकर्ता को दिखने वाली कुंजियों का पहले से तय सेट होता है. इसके उलट, डेटा मैसेज में सिर्फ़ उपयोगकर्ता के तय किए गए कस्टम की-वैल्यू जोड़े होते हैं. सूचना वाले मैसेज में वैकल्पिक डेटा पेलोड शामिल किया जा सकता है. दोनों तरह के मैसेज के लिए, ज़्यादा से ज़्यादा पेलोड 4,096 बाइट का हो सकता है. हालांकि, Firebase कंसोल से मैसेज भेजने पर, 1,000 वर्ण की सीमा लागू होती है.
| स्थिति का इस्तेमाल करना | भेजने का तरीका | |
|---|---|---|
| सूचना मैसेज | FCM SDK टूल, बैकग्राउंड में चलने पर क्लाइंट ऐप्लिकेशन की ओर से, असली उपयोगकर्ता के डिवाइसों पर मैसेज दिखाता है. अगर सूचना मिलने के दौरान ऐप्लिकेशन फ़ोरग्राउंड में चल रहा है, तो ऐप्लिकेशन का कोड यह तय करता है कि सूचना कैसे दिखेगी. सूचना मैसेज में, उपयोगकर्ता को दिखने वाली की का पहले से तय किया गया सेट होता है. साथ ही, इसमें कस्टम की-वैल्यू पेयर का वैकल्पिक डेटा पेलोड भी होता है. |
|
| डेटा मैसेज | डेटा मैसेज को प्रोसेस करने की ज़िम्मेदारी क्लाइंट ऐप्लिकेशन की होती है. डेटा मैसेज में सिर्फ़ कस्टम की-वैल्यू पेयर होते हैं. इनमें, आरक्षित कीवर्ड के नाम नहीं होते (नीचे देखें). |
Cloud Functions
या अपने ऐप्लिकेशन सर्वर जैसे भरोसेमंद प्लैटफ़ॉर्म पर, एडमिन SDK टूल या
FCM सर्वर प्रोटोकॉल का इस्तेमाल करें. अनुरोध भेजने के लिए, data
बटन को सेट करें.
|
सूचना मैसेज का इस्तेमाल तब करें, जब आपको 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, और वेब जैसे सभी प्लैटफ़ॉर्म पर ऐप्लिकेशन इंस्टेंस को टारगेट करना
- विषयों पर मैसेज भेजना
सभी ऐप्लिकेशन इंस्टेंस, प्लैटफ़ॉर्म के बावजूद, इन सामान्य फ़ील्ड का इस्तेमाल कर सकते हैं:
प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल कब करना चाहिए
प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल तब करें, जब आपको:
- सिर्फ़ कुछ प्लैटफ़ॉर्म पर फ़ील्ड भेजना
- सामान्य फ़ील्ड के अलावा, प्लैटफ़ॉर्म के हिसाब से फ़ील्ड भेजना
जब आपको सिर्फ़ चुनिंदा प्लैटफ़ॉर्म पर वैल्यू भेजनी हों, तो सामान्य फ़ील्ड का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल करें. उदाहरण के लिए, सिर्फ़ 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, सबसे ज़्यादा प्राथमिकता वाले मैसेज तुरंत डिलीवर करने की कोशिश करता है. भले ही, डिवाइस 'डॉज़ मोड' में हो. ज़्यादा प्राथमिकता वाले मैसेज, समय के हिसाब से ज़रूरी और उपयोगकर्ता को दिखने वाले कॉन्टेंट के लिए होते हैं.
यहां 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"
}
}
}
}
मैसेज की प्राथमिकता सेट करने के बारे में, प्लैटफ़ॉर्म के हिसाब से ज़्यादा जानकारी के लिए:
जान बचाने के लिए इस्तेमाल के उदाहरण
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 पर कोटा, इस्तेमाल, और गड़बड़ियां देखी जा सकती हैं:
- Google Cloud console पर जाएं
- एपीआई और सेवाएं चुनें
- टेबल की सूची से, Firebase Cloud Messaging API चुनें
- कोटा और सिस्टम की सीमाएं चुनें.
ध्यान दें: ये ग्राफ़, कोटा के मिनट के साथ सटीक समय के हिसाब से अलाइन नहीं होते. इसका मतलब है कि जब ट्रैफ़िक कोटा से कम दिखता है, तो 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 प्रोजेक्ट के इन क्रेडेंशियल की ज़रूरत पड़ सकती है:
| प्रोजेक्ट आईडी | आपके Firebase प्रोजेक्ट के लिए यूनीक आइडेंटिफ़ायर, जिसका इस्तेमाल FCM v1 एचटीटीपी एंडपॉइंट के अनुरोधों में किया जाता है. यह वैल्यू, Firebase कंसोल के सेटिंग पैनल में उपलब्ध होती है. |
| रजिस्ट्रेशन टोकन | एक यूनीक टोकन स्ट्रिंग, जो हर क्लाइंट ऐप्लिकेशन इंस्टेंस की पहचान करती है. एक डिवाइस और डिवाइस के ग्रुप मैसेजिंग के लिए, रजिस्ट्रेशन टोकन की ज़रूरत होती है. ध्यान दें कि रजिस्ट्रेशन टोकन को गुप्त रखना ज़रूरी है. |
| भेजने वाले का आईडी | Firebase प्रोजेक्ट बनाते समय बनाई गई यूनीक संख्या वाली वैल्यू, जो Firebase कंसोल के सेटिंग पैनल के Cloud Messaging टैब में उपलब्ध होती है. भेजने वाले आईडी का इस्तेमाल, क्लाइंट ऐप्लिकेशन को मैसेज भेजने वाले हर व्यक्ति की पहचान करने के लिए किया जाता है. |
| ऐक्सेस टोकन | यह एक ऐसा OAuth 2.0 टोकन है जिसकी समयसीमा कम होती है. यह एचटीटीपी v1 एपीआई के अनुरोधों को अनुमति देता है. यह टोकन, आपके Firebase प्रोजेक्ट से जुड़े सेवा खाते से जुड़ा होता है. ऐक्सेस टोकन बनाने और उन्हें रोटेट करने के लिए, अनुरोध भेजने की अनुमति दें में बताया गया तरीका अपनाएं. |
| सर्वर पासकोड (**बंद किए गए** लेगसी प्रोटोकॉल के लिए) | एक सर्वर कुंजी, जो आपके ऐप्लिकेशन सर्वर को Google की सेवाओं को ऐक्सेस करने की अनुमति देती है. इसमें, इस्तेमाल में न होने वाले Firebase Cloud Messaging लीगेसी प्रोटोकॉल के ज़रिए मैसेज भेजना भी शामिल है. अहम जानकारी: अपने क्लाइंट कोड में, सर्वर पासकोड को कहीं भी शामिल न करें. साथ ही, अपने ऐप्लिकेशन सर्वर को अनुमति देने के लिए, सिर्फ़ सर्वर पासकोड का इस्तेमाल करें. Android, Apple प्लैटफ़ॉर्म, और ब्राउज़र की कुंजियों को FCM अस्वीकार कर देता है. |