FCM বার্তা সম্পর্কে

ফায়ারবেস ক্লাউড মেসেজিং (FCM) মেসেজিং বিকল্প এবং ক্ষমতার বিস্তৃত পরিসর অফার করে। এই পৃষ্ঠার তথ্যগুলি আপনাকে বিভিন্ন ধরণের FCM বার্তাগুলি এবং আপনি সেগুলির সাথে কী করতে পারেন তা বুঝতে সাহায্য করার উদ্দেশ্যে।

বার্তার ধরন

FCM এর মাধ্যমে, আপনি ক্লায়েন্টদের কাছে দুই ধরনের বার্তা পাঠাতে পারেন:

• বিজ্ঞপ্তি বার্তা, কখনও কখনও "প্রদর্শন বার্তা" হিসাবে চিন্তা করা হয়। এগুলি স্বয়ংক্রিয়ভাবে FCM SDK দ্বারা পরিচালিত হয়৷
• ডেটা বার্তা, যা ক্লায়েন্ট অ্যাপ দ্বারা পরিচালিত হয়।

বিজ্ঞপ্তি বার্তাগুলিতে ব্যবহারকারী-দৃশ্যমান কীগুলির একটি পূর্বনির্ধারিত সেট থাকে। বিপরীতে, ডেটা বার্তাগুলিতে শুধুমাত্র আপনার ব্যবহারকারী-সংজ্ঞায়িত কাস্টম কী-মান জোড়া থাকে। বিজ্ঞপ্তি বার্তাগুলিতে একটি ঐচ্ছিক ডেটা পেলোড থাকতে পারে। উভয় বার্তা প্রকারের জন্য সর্বাধিক পেলোড হল 4000 বাইট, Firebase কনসোল থেকে বার্তা পাঠানো ছাড়া, যা একটি 1024 অক্ষর সীমা প্রয়োগ করে৷

	দৃশ্যকল্প ব্যবহার করুন	কীভাবে পাঠাবো
বিজ্ঞপ্তি বার্তা	FCM SDK ক্লায়েন্ট অ্যাপের পক্ষ থেকে শেষ-ব্যবহারকারীর ডিভাইসে বার্তাটি প্রদর্শন করে যখন এটি ব্যাকগ্রাউন্ডে চলছে। অন্যথায়, বিজ্ঞপ্তি পাওয়ার সময় অ্যাপটি ফোরগ্রাউন্ডে চলমান থাকলে, অ্যাপের কোড আচরণ নির্ধারণ করে। বিজ্ঞপ্তি বার্তাগুলিতে ব্যবহারকারী-দৃশ্যমান কীগুলির একটি পূর্বনির্ধারিত সেট এবং কাস্টম কী-মানের জোড়াগুলির একটি ঐচ্ছিক ডেটা পেলোড থাকে৷	ক্লাউড ফাংশন বা আপনার অ্যাপ সার্ভারের মতো বিশ্বস্ত পরিবেশে, অ্যাডমিন SDK বা FCM সার্ভার প্রোটোকল ব্যবহার করুন : notification কী সেট করুন৷ ঐচ্ছিক ডেটা পেলোড থাকতে পারে। সর্বদা সংকোচনশীল। প্রদর্শন বিজ্ঞপ্তির কিছু উদাহরণ দেখুন এবং অনুরোধ পেলোড পাঠান। নোটিফিকেশন কম্পোজার ব্যবহার করুন : মেসেজ টেক্সট, টাইটেল ইত্যাদি লিখুন এবং পাঠান। কাস্টম ডেটা প্রদান করে ঐচ্ছিক ডেটা পেলোড যোগ করুন।
ডেটা বার্তা	ক্লায়েন্ট অ্যাপ ডেটা বার্তা প্রক্রিয়াকরণের জন্য দায়ী। ডেটা বার্তাগুলিতে কোনও সংরক্ষিত কী নাম ছাড়াই কেবল কাস্টম কী-মানের জোড়া থাকে (নীচে দেখুন)।	ক্লাউড ফাংশন বা আপনার অ্যাপ সার্ভারের মতো বিশ্বস্ত পরিবেশে, অ্যাডমিন SDK বা FCM সার্ভার প্রোটোকল ব্যবহার করুন : শুধুমাত্র data কী সেট করুন।

যখন আপনার অ্যাপ ব্যাকগ্রাউন্ডে চলছে তখন আপনি যখন FCM SDK স্বয়ংক্রিয়ভাবে একটি বিজ্ঞপ্তি প্রদর্শন পরিচালনা করতে চান তখন বিজ্ঞপ্তি বার্তাগুলি ব্যবহার করুন৷ আপনি যখন আপনার নিজস্ব ক্লায়েন্ট অ্যাপ কোড দিয়ে বার্তাগুলি প্রক্রিয়া করতে চান তখন ডেটা বার্তাগুলি ব্যবহার করুন৷

FCM একটি ঐচ্ছিক ডেটা পেলোড সহ একটি বিজ্ঞপ্তি বার্তা পাঠাতে পারে৷ এই ধরনের ক্ষেত্রে, এফসিএম বিজ্ঞপ্তি পেলোড প্রদর্শন করে এবং ক্লায়েন্ট অ্যাপ ডেটা পেলোড পরিচালনা করে।

বিজ্ঞপ্তি বার্তা

পরীক্ষার জন্য বা বিপণন এবং ব্যবহারকারীর পুনঃনিযুক্তির জন্য, আপনি Firebase কনসোল ব্যবহার করে বিজ্ঞপ্তি বার্তা পাঠাতে পারেন। Firebase কনসোল আপনাকে বিপণন বার্তাগুলিকে পরিমার্জিত এবং উন্নত করতে সহায়তা করার জন্য বিশ্লেষণ-ভিত্তিক A/B পরীক্ষা প্রদান করে।

অ্যাডমিন SDK বা FCM প্রোটোকল ব্যবহার করে প্রোগ্রাম্যাটিকভাবে বিজ্ঞপ্তি বার্তা পাঠাতে, বিজ্ঞপ্তি বার্তার ব্যবহারকারী-দৃশ্যমান অংশের জন্য কী-মানের বিকল্পগুলির প্রয়োজনীয় পূর্বনির্ধারিত সেট সহ notification কী সেট করুন। উদাহরণস্বরূপ, এখানে একটি IM অ্যাপে একটি JSON- ফরম্যাট করা বিজ্ঞপ্তি বার্তা রয়েছে৷ ব্যবহারকারী "পর্তুগাল বনাম ডেনমার্ক" শিরোনাম সহ একটি বার্তা দেখার আশা করতে পারেন এবং "অসাধারন ম্যাচ!" ডিভাইসে:

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

অ্যাপ্লিকেশানটি ব্যাকগ্রাউন্ডে থাকলে বিজ্ঞপ্তি বার্তাগুলি বিজ্ঞপ্তি ট্রেতে বিতরণ করা হয়। অগ্রভাগে থাকা অ্যাপগুলির জন্য, বার্তাগুলি একটি কলব্যাক ফাংশন দ্বারা পরিচালিত হয়৷

বিজ্ঞপ্তি বার্তা তৈরির জন্য উপলব্ধ পূর্বনির্ধারিত কীগুলির সম্পূর্ণ তালিকার জন্য রেফারেন্স ডকুমেন্টেশন দেখুন:

• HTTP v1 প্রোটোকল বিজ্ঞপ্তি অবজেক্ট
• লিগ্যাসি HTTP প্রোটোকল বিজ্ঞপ্তি পেলোড
• XMPP প্রোটোকল বিজ্ঞপ্তি পেলোড

ডেটা বার্তা

ক্লায়েন্ট অ্যাপে ডেটা পেলোড পাঠাতে আপনার কাস্টম কী-মানের জোড়ার সাথে উপযুক্ত কী সেট করুন।

উদাহরণস্বরূপ, এখানে উপরের মতো একই IM অ্যাপে একটি JSON-ফরম্যাট করা বার্তা রয়েছে, যেখানে তথ্যটি সাধারণ data কীতে এনক্যাপসুলেট করা হয়েছে এবং ক্লায়েন্ট অ্যাপটি বিষয়বস্তু ব্যাখ্যা করবে বলে আশা করা হচ্ছে:

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

উপরের উদাহরণটি টপ-লেভেল বা সাধারণ data ফিল্ডের ব্যবহার দেখায়, যা বার্তা গ্রহণকারী সমস্ত প্ল্যাটফর্মের ক্লায়েন্টদের দ্বারা ব্যাখ্যা করা হয়। প্রতিটি প্ল্যাটফর্মে, ক্লায়েন্ট অ্যাপ কলব্যাক ফাংশনে ডেটা পেলোড গ্রহণ করে।

ডেটা বার্তাগুলির জন্য এনক্রিপশন

অ্যান্ড্রয়েড ট্রান্সপোর্ট লেয়ার ( এফসিএম আর্কিটেকচার দেখুন) পয়েন্ট-টু-পয়েন্ট এনক্রিপশন ব্যবহার করে। আপনার প্রয়োজনের উপর নির্ভর করে, আপনি ডেটা বার্তাগুলিতে এন্ড-টু-এন্ড এনক্রিপশন যোগ করার সিদ্ধান্ত নিতে পারেন। FCM একটি এন্ড-টু-এন্ড সমাধান প্রদান করে না। যাইহোক, ক্যাপিলারি বা DTLS এর মতো বাহ্যিক সমাধান রয়েছে।

ঐচ্ছিক ডেটা পেলোড সহ বিজ্ঞপ্তি বার্তা

প্রোগ্রামগতভাবে বা Firebase কনসোলের মাধ্যমে, আপনি কাস্টম কী-মানের জোড়ার ঐচ্ছিক পেলোড ধারণ করে এমন বিজ্ঞপ্তি বার্তা পাঠাতে পারেন। বিজ্ঞপ্তি কম্পোজারে , উন্নত বিকল্পগুলিতে কাস্টম ডেটা ক্ষেত্রগুলি ব্যবহার করুন৷

বিজ্ঞপ্তি এবং ডেটা পেলোড উভয়ই অন্তর্ভুক্ত করে এমন বার্তাগুলি পাওয়ার সময় অ্যাপের আচরণ নির্ভর করে অ্যাপটি ব্যাকগ্রাউন্ডে আছে নাকি ফোরগ্রাউন্ডে- মূলত, প্রাপ্তির সময় এটি সক্রিয় কিনা।

• ব্যাকগ্রাউন্ডে থাকাকালীন , অ্যাপগুলি বিজ্ঞপ্তি ট্রেতে নোটিফিকেশন পেলোড গ্রহণ করে এবং ব্যবহারকারী যখন বিজ্ঞপ্তিতে ট্যাপ করে তখনই শুধুমাত্র ডেটা পেলোড পরিচালনা করে।
• ফোরগ্রাউন্ডে থাকাকালীন , আপনার অ্যাপ দুটি পেলোড উপলব্ধ সহ একটি বার্তা অবজেক্ট গ্রহণ করে।

এখানে একটি JSON- ফর্ম্যাট করা বার্তা রয়েছে যাতে notification কী এবং data কী উভয়ই রয়েছে:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

প্ল্যাটফর্ম জুড়ে একটি বার্তা কাস্টমাইজ করা

Firebase অ্যাডমিন SDK এবং FCM v1 HTTP প্রোটোকল উভয়ই আপনার বার্তা অনুরোধগুলিকে message অবজেক্টে উপলব্ধ সমস্ত ক্ষেত্র সেট করার অনুমতি দেয়৷ এটা অন্তর্ভুক্ত:

• বার্তা প্রাপ্ত সমস্ত অ্যাপ্লিকেশন দৃষ্টান্ত দ্বারা ব্যাখ্যা করা ক্ষেত্রগুলির একটি সাধারণ সেট৷
• প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্রগুলির সেট, যেমন AndroidConfig এবং WebpushConfig , শুধুমাত্র নির্দিষ্ট প্ল্যাটফর্মে চলমান অ্যাপের উদাহরণ দ্বারা ব্যাখ্যা করা হয়।

প্ল্যাটফর্ম-নির্দিষ্ট ব্লকগুলি আপনাকে বিভিন্ন প্ল্যাটফর্মের জন্য বার্তাগুলি কাস্টমাইজ করার নমনীয়তা দেয় যাতে প্রাপ্তির সময় সেগুলি সঠিকভাবে পরিচালনা করা হয়। FCM ব্যাকএন্ড সমস্ত নির্দিষ্ট পরামিতি বিবেচনা করবে এবং প্রতিটি প্ল্যাটফর্মের জন্য বার্তাটি কাস্টমাইজ করবে।

কখন সাধারণ ক্ষেত্র ব্যবহার করবেন

সাধারণ ক্ষেত্রগুলি ব্যবহার করুন যখন আপনি:

• অ্যাপল, অ্যান্ড্রয়েড, এবং ওয়েব - সমস্ত প্ল্যাটফর্মে লক্ষ্য করা অ্যাপের উদাহরণ
• বিষয় বার্তা পাঠানো

সমস্ত অ্যাপ্লিকেশন উদাহরণ, প্ল্যাটফর্ম নির্বিশেষে, নিম্নলিখিত সাধারণ ক্ষেত্রগুলিকে ব্যাখ্যা করতে পারে:

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

কখন প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র ব্যবহার করবেন

আপনি যখন চান তখন প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র ব্যবহার করুন:

• শুধুমাত্র নির্দিষ্ট প্ল্যাটফর্মে ক্ষেত্র পাঠান
• সাধারণ ক্ষেত্র ছাড়াও প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র পাঠান

যখনই আপনি শুধুমাত্র নির্দিষ্ট প্ল্যাটফর্মে মান পাঠাতে চান, সাধারণ ক্ষেত্র ব্যবহার করবেন না ; প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র ব্যবহার করুন। উদাহরণস্বরূপ, শুধুমাত্র Apple প্ল্যাটফর্ম এবং ওয়েবে একটি বিজ্ঞপ্তি পাঠাতে কিন্তু Android এ নয়, আপনাকে অবশ্যই দুটি পৃথক ক্ষেত্র ব্যবহার করতে হবে, একটি Apple এর জন্য এবং একটি ওয়েবের জন্য৷

আপনি যখন নির্দিষ্ট ডেলিভারি অপশন সহ বার্তা পাঠাচ্ছেন, তখন সেগুলি সেট করতে প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্রগুলি ব্যবহার করুন৷ আপনি চাইলে প্ল্যাটফর্ম প্রতি বিভিন্ন মান নির্দিষ্ট করতে পারেন। যাইহোক, এমনকি যখন আপনি প্ল্যাটফর্ম জুড়ে অপরিহার্যভাবে একই মান সেট করতে চান, আপনাকে অবশ্যই প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র ব্যবহার করতে হবে। এর কারণ হল প্রতিটি প্ল্যাটফর্ম মানটিকে কিছুটা আলাদাভাবে ব্যাখ্যা করতে পারে—উদাহরণস্বরূপ, Android-এ টাইম-টু-লাইভ সেকেন্ডে মেয়াদ শেষ হওয়ার সময় হিসাবে সেট করা হয়, যখন Apple-এ এটি মেয়াদ শেষ হওয়ার তারিখ হিসাবে সেট করা হয়।

উদাহরণ: প্ল্যাটফর্ম-নির্দিষ্ট ডেলিভারি বিকল্প সহ বিজ্ঞপ্তি বার্তা

নিম্নলিখিত v1 প্রেরণের অনুরোধটি সমস্ত প্ল্যাটফর্মে একটি সাধারণ বিজ্ঞপ্তি শিরোনাম এবং সামগ্রী পাঠায়, তবে কিছু প্ল্যাটফর্ম-নির্দিষ্ট ওভাররাইডও পাঠায়। বিশেষ করে, অনুরোধ:

• অ্যান্ড্রয়েড এবং ওয়েব প্ল্যাটফর্মের জন্য দীর্ঘ সময়-টু-লাইভ সেট করে, যখন APNs (অ্যাপল প্ল্যাটফর্ম) বার্তা অগ্রাধিকার কম সেটিংয়ে সেট করে
• অ্যান্ড্রয়েড এবং অ্যাপলের বিজ্ঞপ্তিতে ব্যবহারকারীর ট্যাপের ফলাফল নির্ধারণ করতে যথাযথ কী সেট করে — যথাক্রমে 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 রেফারেন্স ডকুমেন্টেশন দেখুন। বার্তার মূল অংশ ধারণ করে পাঠানোর অনুরোধ তৈরি করার বিষয়ে আরও তথ্যের জন্য, বিল্ড সেন্ড রিকোয়েস্ট দেখুন।

সরবরাহের সুযোগ

এফসিএম অ্যান্ড্রয়েড ডিভাইসে প্রেরিত বার্তাগুলির জন্য ডেলিভারি বিকল্পগুলির একটি নির্দিষ্ট সেট সরবরাহ করে এবং অ্যাপল প্ল্যাটফর্ম এবং ওয়েবে অনুরূপ বিকল্পগুলির জন্য অনুমতি দেয়। উদাহরণস্বরূপ, "কলাপসিবল" মেসেজ আচরণ Android-এ FCM-এর collapse_key এর মাধ্যমে, Apple-এ apns-collapse-id এর মাধ্যমে এবং JavaScript/ওয়েব-এ Topic মাধ্যমে সমর্থিত। বিশদ বিবরণের জন্য, এই বিভাগে বিবরণ এবং সম্পর্কিত রেফারেন্স ডকুমেন্টেশন দেখুন।

অ-সংকোচনযোগ্য এবং সংকোচনযোগ্য বার্তা

একটি অ-সংকোচনযোগ্য বার্তা বোঝায় যে প্রতিটি পৃথক বার্তা ডিভাইসে বিতরণ করা হয়েছে। একটি অ-সংকোচনযোগ্য বার্তা কিছু দরকারী সামগ্রী সরবরাহ করে, যেমন একটি সংকোচনযোগ্য বার্তার বিপরীতে একটি সামগ্রী-মুক্ত "পিং" মোবাইল অ্যাপে ডেটা আনার জন্য সার্ভারের সাথে যোগাযোগ করতে।

অ-সংকোচনযোগ্য বার্তাগুলির কিছু সাধারণ ব্যবহারের ক্ষেত্রে চ্যাট বার্তা বা সমালোচনামূলক বার্তা। উদাহরণস্বরূপ, একটি IM অ্যাপে, আপনি প্রতিটি বার্তা প্রদান করতে চান, কারণ প্রতিটি বার্তার বিভিন্ন বিষয়বস্তু থাকে।

অ্যান্ড্রয়েডের জন্য 100টি বার্তার একটি সীমা রয়েছে যা ভেঙে না পড়ে সংরক্ষণ করা যেতে পারে৷ সীমা পৌঁছে গেলে, সমস্ত সঞ্চিত বার্তা বাতিল করা হয়। ডিভাইসটি আবার অনলাইন হলে, এটি একটি বিশেষ বার্তা পায় যা নির্দেশ করে যে সীমা পৌঁছে গেছে। অ্যাপটি তখন পরিস্থিতিটি সঠিকভাবে পরিচালনা করতে পারে, সাধারণত অ্যাপ সার্ভার থেকে সম্পূর্ণ সিঙ্কের অনুরোধ করে।

একটি সংকোচনযোগ্য বার্তা হল একটি বার্তা যা একটি নতুন বার্তা দ্বারা প্রতিস্থাপিত হতে পারে যদি এটি এখনও ডিভাইসে বিতরণ করা না থাকে।

সংকোচনযোগ্য বার্তাগুলির একটি সাধারণ ব্যবহারের ক্ষেত্রে একটি মোবাইল অ্যাপকে সার্ভার থেকে ডেটা সিঙ্ক করতে বলার জন্য ব্যবহৃত বার্তাগুলি। একটি উদাহরণ একটি স্পোর্টস অ্যাপ যা ব্যবহারকারীদের সর্বশেষ স্কোর দিয়ে আপডেট করে। শুধুমাত্র সাম্প্রতিক বার্তাটি প্রাসঙ্গিক।

Android এ একটি বার্তাকে সংকোচনযোগ্য হিসাবে চিহ্নিত করতে, বার্তা পেলোডে collapse_key প্যারামিটারটি অন্তর্ভুক্ত করুন। ডিফল্টরূপে, ফায়ারবেস কনসোলে নিবন্ধিত অ্যাপ প্যাকেজের নাম হল পতন কী। এফসিএম সার্ভার একই সাথে প্রতি ডিভাইসে চারটি ভিন্ন কলাপসিবল মেসেজ সঞ্চয় করতে পারে, প্রতিটিতে একটি আলাদা কম্পন কী সহ। আপনি যদি এই সংখ্যাটি অতিক্রম করেন, FCM শুধুমাত্র চারটি সংকোচন কী রাখে, কোনটি রাখা হবে তার কোনো নিশ্চয়তা নেই।

কোন পেলোড ছাড়া বিষয় বার্তা ডিফল্টরূপে সংকোচনযোগ্য. বিজ্ঞপ্তি বার্তাগুলি সর্বদা সংকোচনযোগ্য এবং collapse_key প্যারামিটার উপেক্ষা করবে৷

আমি কোনটি ব্যবহার করা উচিত?

সংকোচনযোগ্য বার্তাগুলি পারফরম্যান্সের দৃষ্টিকোণ থেকে একটি ভাল পছন্দ, যদি আপনার অ্যাপটিকে অ-সংকোচনযোগ্য বার্তাগুলি ব্যবহার করার প্রয়োজন না হয়৷ যাইহোক, যদি আপনি কলাপসিবল মেসেজ ব্যবহার করেন, তাহলে মনে রাখবেন যে FCM শুধুমাত্র যে কোনো নির্দিষ্ট সময়ে FCM প্রতি রেজিস্ট্রেশন টোকেন দ্বারা সর্বাধিক চারটি ভিন্ন কলপ কী ব্যবহার করার অনুমতি দেয়। আপনি অবশ্যই এই সংখ্যা অতিক্রম করবেন না, বা এটি অপ্রত্যাশিত পরিণতি ঘটাতে পারে।

	দৃশ্যকল্প ব্যবহার করুন	কীভাবে পাঠাবো
অ-সংকোচনযোগ্য	প্রতিটি বার্তা ক্লায়েন্ট অ্যাপের জন্য গুরুত্বপূর্ণ এবং বিতরণ করা প্রয়োজন।	বিজ্ঞপ্তি বার্তা ছাড়া, সমস্ত বার্তা ডিফল্টরূপে অ-সংকোচনযোগ্য।
কলাপসিবল	যখন একটি নতুন বার্তা থাকে যা একটি পুরানো, সম্পর্কিত বার্তাটিকে ক্লায়েন্ট অ্যাপের সাথে অপ্রাসঙ্গিক করে, তখন FCM পুরানো বার্তাটিকে প্রতিস্থাপন করে৷ উদাহরণস্বরূপ: সার্ভার থেকে ডেটা সিঙ্ক শুরু করতে ব্যবহৃত বার্তাগুলি, বা পুরানো বিজ্ঞপ্তি বার্তা৷	আপনার বার্তা অনুরোধে উপযুক্ত প্যারামিটার সেট করুন: অ্যান্ড্রয়েড-এ collapseKey অ্যাপল-এ apns-collapse-id ওয়েবে Topic উত্তরাধিকার প্রোটোকলের মধ্যে collapse_key (সমস্ত প্ল্যাটফর্ম)

একটি বার্তা অগ্রাধিকার সেট করা

ডাউনস্ট্রিম বার্তাগুলিতে ডেলিভারি অগ্রাধিকার নির্ধারণের জন্য আপনার কাছে দুটি বিকল্প রয়েছে: স্বাভাবিক এবং উচ্চ অগ্রাধিকার। যদিও প্ল্যাটফর্ম জুড়ে আচরণ কিছুটা আলাদা, স্বাভাবিক এবং উচ্চ অগ্রাধিকার বার্তাগুলির বিতরণ এই মত কাজ করে:

• স্বাভাবিক অগ্রাধিকার। অ্যাপটি অগ্রভাগে থাকলে সাধারণ অগ্রাধিকার বার্তাগুলি অবিলম্বে বিতরণ করা হয়। ব্যাকগ্রাউন্ডেড অ্যাপের জন্য, ডেলিভারি বিলম্বিত হতে পারে। কম সময়-সংবেদনশীল বার্তাগুলির জন্য, যেমন নতুন ইমেলের বিজ্ঞপ্তি, আপনার UI সিঙ্কে রাখা, বা পটভূমিতে অ্যাপ ডেটা সিঙ্ক করা, স্বাভাবিক বিতরণ অগ্রাধিকার বেছে নিন।

• বেশি অগ্রাধিকার. ডিভাইসটি ডোজ মোডে থাকলেও FCM অবিলম্বে উচ্চ অগ্রাধিকার বার্তা প্রদান করার চেষ্টা করে। উচ্চ অগ্রাধিকার বার্তাগুলি সময়-সংবেদনশীল, ব্যবহারকারীর দৃশ্যমান সামগ্রীর জন্য।

এখানে একটি সাধারণ অগ্রাধিকার বার্তার একটি উদাহরণ রয়েছে যা FCM HTTP 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"
      }
    }
  }
}

বার্তা অগ্রাধিকার সেট করার বিষয়ে আরও প্ল্যাটফর্ম-নির্দিষ্ট বিশদ বিবরণের জন্য:

• APNs ডকুমেন্টেশন
• বার্তা অগ্রাধিকার সেট করুন এবং পরিচালনা করুন (Android)
• ওয়েব পুশ বার্তা জরুরী

একটি বার্তার জীবনকাল সেট করা হচ্ছে

FCM সাধারণত বার্তাগুলি পাঠানোর সাথে সাথেই বিতরণ করে। যাইহোক, এটি সবসময় সম্ভব নাও হতে পারে। উদাহরণস্বরূপ, যদি প্ল্যাটফর্মটি Android হয়, তাহলে ডিভাইসটি বন্ধ, অফলাইন বা অন্যথায় অনুপলব্ধ হতে পারে। অথবা এফসিএম ইচ্ছাকৃতভাবে বার্তাগুলিকে বিলম্বিত করতে পারে যাতে একটি অ্যাপকে অত্যধিক সংস্থান গ্রহণ করা থেকে এবং ব্যাটারির জীবনকে নেতিবাচকভাবে প্রভাবিত করা থেকে বিরত রাখতে পারে।

যখন এটি ঘটে, FCM বার্তাটি সঞ্চয় করে এবং যত তাড়াতাড়ি এটি সম্ভব হয় তত তাড়াতাড়ি বিতরণ করে৷ যদিও বেশিরভাগ ক্ষেত্রে এটি ঠিক আছে, তবে কিছু অ্যাপ রয়েছে যার জন্য দেরী বার্তা কখনই বিতরণ করা যাবে না। উদাহরণস্বরূপ, যদি বার্তাটি একটি ইনকামিং কল বা ভিডিও চ্যাট বিজ্ঞপ্তি হয়, তবে কলটি বন্ধ হওয়ার আগে এটি শুধুমাত্র অল্প সময়ের জন্য অর্থবহ৷ অথবা যদি বার্তাটি একটি ইভেন্টের আমন্ত্রণ হয়, ইভেন্ট শেষ হওয়ার পরে প্রাপ্ত হলে তা অকেজো।

অ্যান্ড্রয়েড এবং ওয়েব/জাভাস্ক্রিপ্টে, আপনি একটি বার্তার সর্বোচ্চ জীবনকাল নির্দিষ্ট করতে পারেন৷ মানটি অবশ্যই 0 থেকে 2,419,200 সেকেন্ড (28 দিন) সময়কালের হতে হবে এবং এটি FCM সঞ্চয় করে এবং বার্তা প্রদানের প্রচেষ্টার সর্বোচ্চ সময়ের সাথে সামঞ্জস্যপূর্ণ। অনুরোধ যে এই ক্ষেত্রটি ডিফল্ট চার সপ্তাহের সর্বোচ্চ সময়ের জন্য ধারণ করে না।

এই বৈশিষ্ট্যটির জন্য এখানে কিছু সম্ভাব্য ব্যবহার রয়েছে:

• ভিডিও চ্যাট ইনকামিং কল
• আমন্ত্রণ ইভেন্টের মেয়াদ শেষ হচ্ছে
• ক্যালেন্ডার ইভেন্ট

একটি বার্তার জীবনকাল নির্দিষ্ট করার আরেকটি সুবিধা হল যে FCM কখনই 0 সেকেন্ডের টাইম-টু-লাইভ মান সহ বার্তাগুলিকে থ্রোটল করে না। অন্য কথায়, FCM বার্তাগুলির জন্য সর্বোত্তম প্রচেষ্টার গ্যারান্টি দেয় যেগুলি অবশ্যই "এখন বা কখনই" বিতরণ করা উচিত। মনে রাখবেন যে time_to_live মান 0 মানে যে বার্তাগুলি অবিলম্বে বিতরণ করা যায় না তা বাতিল করা হয়। যাইহোক, যেহেতু এই ধরনের বার্তাগুলি কখনই সংরক্ষণ করা হয় না, এটি বিজ্ঞপ্তি বার্তাগুলি পাঠানোর জন্য সর্বোত্তম লেটেন্সি প্রদান করে৷

এখানে একটি অনুরোধের একটি উদাহরণ রয়েছে যাতে TTL অন্তর্ভুক্ত রয়েছে:

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

একটি বার্তা আজীবন

যখন একটি অ্যাপ সার্ভার এফসিএম-এ একটি বার্তা পোস্ট করে এবং একটি বার্তা আইডি ফিরে পায়, তার মানে এই নয় যে বার্তাটি ইতিমধ্যেই ডিভাইসে পৌঁছে দেওয়া হয়েছে৷ বরং, এর অর্থ হল এটি প্রসবের জন্য গ্রহণ করা হয়েছিল। বার্তাটি গ্রহণ করার পরে কী হবে তা অনেক কারণের উপর নির্ভর করে।

সর্বোত্তম ক্ষেত্রে, যদি ডিভাইসটি FCM-এর সাথে সংযুক্ত থাকে, স্ক্রীন চালু থাকে এবং কোনো থ্রটলিং বিধিনিষেধ না থাকে, তাহলে বার্তাটি অবিলম্বে বিতরণ করা হয়।

যদি ডিভাইসটি সংযুক্ত থাকে কিন্তু Doze-এ, ডিভাইসটি Doze এর বাইরে না হওয়া পর্যন্ত FCM দ্বারা একটি কম অগ্রাধিকার বার্তা সংরক্ষণ করা হয়। এবং এখানেই collapse_key পতাকা একটি ভূমিকা পালন করে: যদি ইতিমধ্যেই একই পতন কী (এবং রেজিস্ট্রেশন টোকেন) সহ একটি বার্তা সংরক্ষিত থাকে এবং বিতরণের জন্য অপেক্ষা করা হয়, তবে পুরানো বার্তাটি বাতিল হয়ে যায় এবং নতুন বার্তাটি তার জায়গা নেয় (অর্থাৎ, পুরানো বার্তাটি নতুনটির দ্বারা ভেঙে পড়েছে)। যাইহোক, যদি পতন কী সেট করা না থাকে, তাহলে নতুন এবং পুরানো উভয় বার্তাই ভবিষ্যতে ডেলিভারির জন্য সংরক্ষণ করা হয়।

যদি ডিভাইসটি FCM-এর সাথে সংযুক্ত না থাকে, একটি সংযোগ স্থাপন না হওয়া পর্যন্ত বার্তাটি সংরক্ষণ করা হয় (পুনরায় পতনের মূল নিয়মগুলিকে সম্মান করে)। যখন একটি সংযোগ স্থাপন করা হয়, তখন FCM সমস্ত মুলতুবি বার্তাগুলি ডিভাইসে সরবরাহ করে৷ যদি ডিভাইসটি আর কখনও সংযুক্ত না হয় (উদাহরণস্বরূপ, যদি এটি ফ্যাক্টরি রিসেট করা হয়), বার্তাটি শেষ পর্যন্ত শেষ হয়ে যায় এবং FCM স্টোরেজ থেকে বাতিল করা হয়। ডিফল্ট টাইমআউট চার সপ্তাহ, যদি না time_to_live পতাকা সেট করা হয়।

একটি বার্তা বিতরণ সম্পর্কে আরও অন্তর্দৃষ্টি পেতে:

অ্যান্ড্রয়েড বা অ্যাপল প্ল্যাটফর্মগুলিতে বার্তাগুলির বিতরণ সম্পর্কে আরও অন্তর্দৃষ্টি পেতে, এফসিএম রিপোর্টিং ড্যাশবোর্ড দেখুন, যা অ্যাপল এবং অ্যান্ড্রয়েড ডিভাইসগুলিতে পাঠানো এবং খোলা বার্তাগুলির সংখ্যা রেকর্ড করে, এর জন্য "ইম্প্রেশন" (ব্যবহারকারীদের দ্বারা দেখা বিজ্ঞপ্তিগুলি) ডেটা সহ অ্যান্ড্রয়েড অ্যাপস।

সরাসরি চ্যানেল মেসেজিং সক্ষম থাকা Android ডিভাইসগুলির জন্য, যদি ডিভাইসটি এক মাসের বেশি সময় ধরে FCM-এর সাথে সংযুক্ত না থাকে, FCM এখনও বার্তাটি গ্রহণ করে কিন্তু অবিলম্বে এটিকে বাতিল করে দেয়। যদি ডিভাইসটি আপনার পাঠানো শেষ ডেটা বার্তার চার সপ্তাহের মধ্যে সংযোগ করে, তাহলে আপনার ক্লায়েন্ট onDeletedMessages() কলব্যাক পাবে। অ্যাপটি তখন পরিস্থিতিটি সঠিকভাবে পরিচালনা করতে পারে, সাধারণত অ্যাপ সার্ভার থেকে সম্পূর্ণ সিঙ্কের অনুরোধ করে।

অবশেষে, যখন FCM ডিভাইসে একটি বার্তা দেওয়ার চেষ্টা করে এবং অ্যাপটি আনইনস্টল করা হয়, তখন FCM সেই বার্তাটি অবিলম্বে বাতিল করে দেয় এবং নিবন্ধন টোকেনটিকে বাতিল করে দেয়। সেই ডিভাইসে একটি বার্তা পাঠানোর ভবিষ্যত প্রচেষ্টার ফলে একটি NotRegistered ত্রুটি দেখা দেয়।

থ্রটলিং এবং স্কেলিং

আমাদের লক্ষ্য হল FCM এর মাধ্যমে প্রেরিত প্রতিটি বার্তা সর্বদা বিলি করা। যাইহোক, প্রতিটি বার্তা প্রদান করার ফলে কখনও কখনও একটি খারাপ সামগ্রিক ব্যবহারকারীর অভিজ্ঞতা হয়। অন্যান্য ক্ষেত্রে, FCM সকল প্রেরকের জন্য একটি পরিমাপযোগ্য পরিষেবা প্রদান করে তা নিশ্চিত করার জন্য আমাদের সীমানা প্রদান করতে হবে।

সংকোচনযোগ্য বার্তা থ্রোটলিং

উপরে বর্ণিত হিসাবে, সংকোচনযোগ্য বার্তাগুলি হল বিষয়বস্তু-মুক্ত বিজ্ঞপ্তিগুলি একে অপরের উপরে ভেঙে পড়ার জন্য ডিজাইন করা হয়েছে৷ কোনো ডেভেলপার কোনো অ্যাপে একই বার্তা বারবার পুনরাবৃত্তি করলে, ব্যবহারকারীর ব্যাটারির ওপর প্রভাব কমাতে আমরা বার্তাগুলিকে বিলম্বিত করি (থ্রটল)।

উদাহরণস্বরূপ, যদি আপনি একটি একক ডিভাইসে বিপুল সংখ্যক নতুন ইমেল সিঙ্ক অনুরোধ পাঠান, তাহলে আমরা পরবর্তী ইমেল সিঙ্ক অনুরোধটি কয়েক মিনিট বিলম্বিত করতে পারি যাতে ডিভাইসটি কম গড় হারে সিঙ্ক করতে পারে। ব্যবহারকারীর দ্বারা অভিজ্ঞ ব্যাটারি প্রভাব সীমিত করার জন্য এই থ্রটলিং কঠোরভাবে করা হয়।

যদি আপনার ব্যবহারের ক্ষেত্রে উচ্চ বিস্ফোরণ প্রেরণের প্যাটার্নের প্রয়োজন হয়, তাহলে অ-সংকোচনযোগ্য বার্তাগুলি সঠিক পছন্দ হতে পারে। এই ধরনের বার্তাগুলির জন্য, ব্যাটারির খরচ কমানোর জন্য এই ধরনের বার্তাগুলিতে বিষয়বস্তু অন্তর্ভুক্ত করা নিশ্চিত করুন৷

আমরা প্রতি 3 মিনিটে 1টি বার্তা রিফিল সহ প্রতি ডিভাইস প্রতি অ্যাপ প্রতি 20টি বার্তার বিস্ফোরণে সংকোচনযোগ্য বার্তাগুলিকে সীমাবদ্ধ করি।

XMPP সার্ভার থ্রোটলিং

আপনি যে হার FCM XMPP সার্ভারের সাথে সংযোগ করতে পারেন তা আমরা প্রতি মিনিটে 400 সংযোগ প্রতি প্রকল্পে সীমাবদ্ধ করি। এটি বার্তা বিতরণের জন্য একটি সমস্যা হওয়া উচিত নয়, তবে এটি আমাদের সিস্টেমের স্থিতিশীলতা নিশ্চিত করার জন্য গুরুত্বপূর্ণ৷

প্রতিটি প্রকল্পের জন্য, FCM সমান্তরালভাবে 2500 সংযোগের অনুমতি দেয়।

একটি ডিভাইসে সর্বাধিক বার্তা হার

Android এর জন্য, আপনি একটি ডিভাইসে 240টি বার্তা/মিনিট এবং 5,000টি বার্তা/ঘন্টা পাঠাতে পারেন৷ এই উচ্চ থ্রেশহোল্ডটি স্বল্পমেয়াদী ট্র্যাফিকের বিস্ফোরণের অনুমতি দেওয়ার জন্য বোঝানো হয়েছে, যেমন ব্যবহারকারীরা যখন চ্যাটে দ্রুত যোগাযোগ করে। এই সীমাটি একটি ডিভাইসে অসাবধানতাবশত ব্যাটারি নিষ্কাশন থেকে যুক্তি প্রেরণে ত্রুটি প্রতিরোধ করে৷

iOS-এর জন্য, যখন হার APN-এর সীমা অতিক্রম করে তখন আমরা একটি ত্রুটি ফেরত দিই।

আপস্ট্রিম বার্তা সীমা

আমরা আপস্ট্রিম গন্তব্য সার্ভার ওভারলোড এড়াতে প্রকল্প প্রতি 1,500,000/মিনিট আপস্ট্রিম বার্তা সীমাবদ্ধ করি।

খারাপ অ্যাপ আচরণ থেকে ব্যাটারি ড্রেন থেকে রক্ষা করতে আমরা প্রতি ডিভাইসে আপস্ট্রিম বার্তা 1,000/মিনিট সীমাবদ্ধ করি।

বিষয় বার্তা সীমা

বিষয় সাবস্ক্রিপশন যোগ/মুছে ফেলার হার প্রকল্প প্রতি 3,000 QPS-এ সীমাবদ্ধ।

বার্তা পাঠানোর হারের জন্য, ফ্যানআউট থ্রটলিং দেখুন।

ফ্যানআউট থ্রটলিং

মেসেজ ফ্যানআউট হল একাধিক ডিভাইসে একটি বার্তা পাঠানোর প্রক্রিয়া, যেমন আপনি যখন বিষয় এবং গোষ্ঠীগুলিকে টার্গেট করেন বা যখন আপনি শ্রোতা বা ব্যবহারকারীর অংশগুলিকে লক্ষ্য করতে বিজ্ঞপ্তি কম্পোজার ব্যবহার করেন৷

বার্তা ফ্যানআউট তাত্ক্ষণিক নয় এবং তাই মাঝে মাঝে আপনার একাধিক ফ্যানআউট একই সাথে চলছে। আমরা প্রতি প্রজেক্টের সমবর্তী বার্তা ফ্যানআউটের সংখ্যা 1,000-এ সীমাবদ্ধ করি। এর পরে, আমরা অতিরিক্ত ফ্যানআউট অনুরোধগুলি প্রত্যাখ্যান করতে পারি বা অনুরোধগুলির ফ্যানআউটকে পিছিয়ে দিতে পারি যতক্ষণ না ইতিমধ্যে কিছু প্রগতিশীল ফ্যানআউট সম্পূর্ণ হয়৷

প্রকৃত অর্জনযোগ্য ফ্যানআউট হার একই সময়ে ফ্যানআউটের অনুরোধকারী প্রকল্পের সংখ্যা দ্বারা প্রভাবিত হয়। একটি স্বতন্ত্র প্রকল্পের জন্য 10,000 QPS এর একটি ফ্যানআউট হার অস্বাভাবিক নয়, তবে সেই সংখ্যাটি কোনও গ্যারান্টি নয় এবং এটি সিস্টেমে মোট লোডের ফলাফল। এটি লক্ষ্য করা গুরুত্বপূর্ণ যে উপলব্ধ ফ্যানআউট ক্ষমতা প্রকল্পগুলির মধ্যে বিভক্ত এবং ফ্যানআউট অনুরোধগুলির মধ্যে নয়৷ সুতরাং, যদি আপনার প্রকল্পের দুটি ফ্যানআউট প্রগতিতে থাকে, তাহলে প্রতিটি ফ্যানআউট উপলব্ধ ফ্যানআউট হারের অর্ধেক দেখতে পাবে। আপনার ফ্যানআউট গতি সর্বাধিক করার প্রস্তাবিত উপায় হল একটি সময়ে শুধুমাত্র একটি সক্রিয় ফ্যানআউট প্রগতিশীল।

FCM পোর্ট এবং আপনার ফায়ারওয়াল

যদি আপনার সংস্থার কাছে ইন্টারনেটে বা থেকে ট্র্যাফিক সীমাবদ্ধ করার জন্য একটি ফায়ারওয়াল থাকে, তাহলে আপনার নেটওয়ার্কের ডিভাইসগুলি যাতে বার্তাগুলি পেতে পারে তার জন্য আপনাকে মোবাইল ডিভাইসগুলিকে FCM-এর সাথে সংযোগ করার অনুমতি দেওয়ার জন্য এটি কনফিগার করতে হবে৷ এফসিএম সাধারণত পোর্ট 5228 ব্যবহার করে, তবে এটি কখনও কখনও 443, 5229 এবং 5230 ব্যবহার করে।

আপনার নেটওয়ার্কে সংযোগকারী ডিভাইসগুলির জন্য, FCM নির্দিষ্ট IP প্রদান করে না কারণ আমাদের IP পরিসর খুব ঘন ঘন পরিবর্তিত হয় এবং আপনার ফায়ারওয়াল নিয়মগুলি পুরানো হয়ে যেতে পারে, যা আপনার ব্যবহারকারীদের অভিজ্ঞতাকে প্রভাবিত করে৷ আদর্শভাবে, 5228-5230 এবং 443 আইপি বিধিনিষেধ ছাড়াই অনুমোদিত পোর্ট। যাইহোক, যদি আপনার অবশ্যই একটি আইপি সীমাবদ্ধতা থাকে, তাহলে আপনাকে goog.json- এ তালিকাভুক্ত সমস্ত আইপি ঠিকানার অনুমতি দেওয়া উচিত। এই বৃহৎ তালিকাটি নিয়মিত আপডেট করা হয় এবং আপনাকে মাসিক ভিত্তিতে আপনার নিয়ম আপডেট করার পরামর্শ দেওয়া হয়। ফায়ারওয়াল আইপি বিধিনিষেধ দ্বারা সৃষ্ট সমস্যাগুলি প্রায়ই মাঝে মাঝে এবং নির্ণয় করা কঠিন।

আমরা ডোমেন নামের একটি সেট অফার করি যা IP ঠিকানার পরিবর্তে অনুমোদিত তালিকাভুক্ত হতে পারে। সেই হোস্টনামগুলি নীচে তালিকাভুক্ত করা হয়েছে। আমরা যদি অতিরিক্ত হোস্টনাম ব্যবহার করা শুরু করি, আমরা এখানে তালিকা আপডেট করব। আপনার ফায়ারওয়াল নিয়মের জন্য ডোমেন নাম ব্যবহার করা আপনার ফায়ারওয়াল ডিভাইসে কার্যকরী হতে পারে বা নাও হতে পারে।

খোলার জন্য TCP পোর্ট:

• 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

নেটওয়ার্ক ঠিকানা অনুবাদ এবং/অথবা স্টেটফুল প্যাকেট পরিদর্শন ফায়ারওয়াল:

যদি আপনার নেটওয়ার্ক নেটওয়ার্ক অ্যাড্রেস ট্রান্সলেশন (NAT) বা স্টেটফুল প্যাকেট পরিদর্শন (SPI) প্রয়োগ করে, তাহলে 5228-5230 পোর্টে আমাদের সংযোগের জন্য 30 মিনিট বা তার বেশি সময়সীমা কার্যকর করুন। এটি আপনার ব্যবহারকারীদের মোবাইল ডিভাইসের ব্যাটারি খরচ কমানোর সাথে সাথে আমাদের নির্ভরযোগ্য সংযোগ প্রদান করতে সক্ষম করে।

শংসাপত্র

আপনি কোন FCM বৈশিষ্ট্যগুলি প্রয়োগ করেন তার উপর নির্ভর করে, আপনার Firebase প্রকল্প থেকে নিম্নলিখিত শংসাপত্রগুলির প্রয়োজন হতে পারে:

প্রকল্প আইডি	আপনার Firebase প্রোজেক্টের জন্য একটি অনন্য শনাক্তকারী, FCM v1 HTTP এন্ডপয়েন্টের অনুরোধে ব্যবহৃত হয়। এই মানটি Firebase কনসোল সেটিংস প্যানে উপলব্ধ।
রেজিস্ট্রেশন টোকেন	একটি অনন্য টোকেন স্ট্রিং যা প্রতিটি ক্লায়েন্ট অ্যাপ উদাহরণকে চিহ্নিত করে। একক ডিভাইস এবং ডিভাইস গ্রুপ মেসেজিংয়ের জন্য নিবন্ধন টোকেন প্রয়োজন। উল্লেখ্য যে নিবন্ধন টোকেন গোপন রাখা আবশ্যক.
প্রেরকের আইডি	আপনি যখন আপনার Firebase প্রকল্প তৈরি করেন তখন একটি অনন্য সংখ্যাসূচক মান তৈরি হয়, যা Firebase কনসোল সেটিংস ফলকের ক্লাউড মেসেজিং ট্যাবে উপলব্ধ। ক্লায়েন্ট অ্যাপে বার্তা পাঠাতে পারে এমন প্রতিটি প্রেরককে সনাক্ত করতে প্রেরকের আইডি ব্যবহার করা হয়।
অ্যাক্সেস টোকেন	একটি স্বল্পস্থায়ী OAuth 2.0 টোকেন যা HTTP v1 API-তে অনুরোধ অনুমোদন করে। এই টোকেনটি আপনার Firebase প্রকল্পের অন্তর্গত একটি পরিষেবা অ্যাকাউন্টের সাথে যুক্ত৷ অ্যাক্সেস টোকেন তৈরি করতে এবং ঘোরাতে, অনুমোদন পাঠাতে অনুরোধে বর্ণিত ধাপগুলি অনুসরণ করুন।
সার্ভার কী (লেগেসি প্রোটোকলের জন্য)	ফায়ারবেস ক্লাউড মেসেজিং লিগ্যাসি প্রোটোকলের মাধ্যমে বার্তা পাঠানো সহ Google পরিষেবাগুলিতে অ্যাক্সেসের জন্য আপনার অ্যাপ সার্ভারকে অনুমোদন করে এমন একটি সার্ভার কী৷ আপনি যখন আপনার ফায়ারবেস প্রকল্প তৈরি করেন তখন আপনি সার্ভার কী পান। আপনি এটি Firebase কনসোল সেটিংস ফলকের ক্লাউড মেসেজিং ট্যাবে দেখতে পারেন। গুরুত্বপূর্ণ: আপনার ক্লায়েন্ট কোডের কোথাও সার্ভার কী অন্তর্ভুক্ত করবেন না। এছাড়াও, আপনার অ্যাপ সার্ভার অনুমোদন করার জন্য শুধুমাত্র সার্ভার কী ব্যবহার করা নিশ্চিত করুন। Android, Apple প্ল্যাটফর্ম, এবং ব্রাউজার কী FCM দ্বারা প্রত্যাখ্যান করা হয়েছে।

,

ফায়ারবেস ক্লাউড মেসেজিং (FCM) মেসেজিং বিকল্প এবং ক্ষমতার বিস্তৃত পরিসর অফার করে। এই পৃষ্ঠার তথ্যগুলি আপনাকে বিভিন্ন ধরণের FCM বার্তাগুলি এবং আপনি সেগুলির সাথে কী করতে পারেন তা বুঝতে সাহায্য করার উদ্দেশ্যে।

বার্তার ধরন

FCM এর মাধ্যমে, আপনি ক্লায়েন্টদের কাছে দুই ধরনের বার্তা পাঠাতে পারেন:

• বিজ্ঞপ্তি বার্তা, কখনও কখনও "প্রদর্শন বার্তা" হিসাবে চিন্তা করা হয়। এগুলি স্বয়ংক্রিয়ভাবে FCM SDK দ্বারা পরিচালিত হয়৷
• ডেটা বার্তা, যা ক্লায়েন্ট অ্যাপ দ্বারা পরিচালিত হয়।

বিজ্ঞপ্তি বার্তাগুলিতে ব্যবহারকারী-দৃশ্যমান কীগুলির একটি পূর্বনির্ধারিত সেট থাকে। বিপরীতে, ডেটা বার্তাগুলিতে শুধুমাত্র আপনার ব্যবহারকারী-সংজ্ঞায়িত কাস্টম কী-মান জোড়া থাকে। বিজ্ঞপ্তি বার্তাগুলিতে একটি ঐচ্ছিক ডেটা পেলোড থাকতে পারে। উভয় বার্তা প্রকারের জন্য সর্বাধিক পেলোড হল 4000 বাইট, Firebase কনসোল থেকে বার্তা পাঠানো ছাড়া, যা একটি 1024 অক্ষর সীমা প্রয়োগ করে৷

	দৃশ্যকল্প ব্যবহার করুন	কীভাবে পাঠাবো
বিজ্ঞপ্তি বার্তা	FCM SDK ক্লায়েন্ট অ্যাপের পক্ষ থেকে শেষ-ব্যবহারকারীর ডিভাইসে বার্তাটি প্রদর্শন করে যখন এটি ব্যাকগ্রাউন্ডে চলছে। অন্যথায়, বিজ্ঞপ্তি পাওয়ার সময় অ্যাপটি ফোরগ্রাউন্ডে চলমান থাকলে, অ্যাপের কোড আচরণ নির্ধারণ করে। বিজ্ঞপ্তি বার্তাগুলিতে ব্যবহারকারী-দৃশ্যমান কীগুলির একটি পূর্বনির্ধারিত সেট এবং কাস্টম কী-মানের জোড়াগুলির একটি ঐচ্ছিক ডেটা পেলোড থাকে৷	ক্লাউড ফাংশন বা আপনার অ্যাপ সার্ভারের মতো বিশ্বস্ত পরিবেশে, অ্যাডমিন SDK বা FCM সার্ভার প্রোটোকল ব্যবহার করুন : notification কী সেট করুন৷ ঐচ্ছিক ডেটা পেলোড থাকতে পারে। সর্বদা সংকোচনশীল। প্রদর্শন বিজ্ঞপ্তির কিছু উদাহরণ দেখুন এবং অনুরোধ পেলোড পাঠান। নোটিফিকেশন কম্পোজার ব্যবহার করুন : মেসেজ টেক্সট, টাইটেল ইত্যাদি লিখুন এবং পাঠান। কাস্টম ডেটা প্রদান করে ঐচ্ছিক ডেটা পেলোড যোগ করুন।
ডেটা বার্তা	ক্লায়েন্ট অ্যাপ ডেটা বার্তা প্রক্রিয়াকরণের জন্য দায়ী। ডেটা বার্তাগুলিতে কোনও সংরক্ষিত কী নাম ছাড়াই কেবল কাস্টম কী-মানের জোড়া থাকে (নীচে দেখুন)।	ক্লাউড ফাংশন বা আপনার অ্যাপ সার্ভারের মতো বিশ্বস্ত পরিবেশে, অ্যাডমিন SDK বা FCM সার্ভার প্রোটোকল ব্যবহার করুন : শুধুমাত্র data কী সেট করুন।

যখন আপনার অ্যাপ ব্যাকগ্রাউন্ডে চলছে তখন আপনি যখন FCM SDK স্বয়ংক্রিয়ভাবে একটি বিজ্ঞপ্তি প্রদর্শন পরিচালনা করতে চান তখন বিজ্ঞপ্তি বার্তাগুলি ব্যবহার করুন৷ আপনি যখন আপনার নিজস্ব ক্লায়েন্ট অ্যাপ কোড দিয়ে বার্তাগুলি প্রক্রিয়া করতে চান তখন ডেটা বার্তাগুলি ব্যবহার করুন৷

FCM একটি ঐচ্ছিক ডেটা পেলোড সহ একটি বিজ্ঞপ্তি বার্তা পাঠাতে পারে৷ এই ধরনের ক্ষেত্রে, এফসিএম বিজ্ঞপ্তি পেলোড প্রদর্শন করে এবং ক্লায়েন্ট অ্যাপ ডেটা পেলোড পরিচালনা করে।

বিজ্ঞপ্তি বার্তা

পরীক্ষার জন্য বা বিপণন এবং ব্যবহারকারীর পুনঃনিযুক্তির জন্য, আপনি Firebase কনসোল ব্যবহার করে বিজ্ঞপ্তি বার্তা পাঠাতে পারেন। Firebase কনসোল আপনাকে বিপণন বার্তাগুলিকে পরিমার্জিত এবং উন্নত করতে সহায়তা করার জন্য বিশ্লেষণ-ভিত্তিক A/B পরীক্ষা প্রদান করে।

অ্যাডমিন SDK বা FCM প্রোটোকল ব্যবহার করে প্রোগ্রাম্যাটিকভাবে বিজ্ঞপ্তি বার্তা পাঠাতে, বিজ্ঞপ্তি বার্তার ব্যবহারকারী-দৃশ্যমান অংশের জন্য কী-মানের বিকল্পগুলির প্রয়োজনীয় পূর্বনির্ধারিত সেট সহ notification কী সেট করুন। উদাহরণস্বরূপ, এখানে একটি IM অ্যাপে একটি JSON- ফরম্যাট করা বিজ্ঞপ্তি বার্তা রয়েছে৷ ব্যবহারকারী "পর্তুগাল বনাম ডেনমার্ক" শিরোনাম সহ একটি বার্তা দেখার আশা করতে পারেন এবং "অসাধারন ম্যাচ!" ডিভাইসে:

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

অ্যাপ্লিকেশানটি ব্যাকগ্রাউন্ডে থাকলে বিজ্ঞপ্তি বার্তাগুলি বিজ্ঞপ্তি ট্রেতে বিতরণ করা হয়। অগ্রভাগে থাকা অ্যাপগুলির জন্য, বার্তাগুলি একটি কলব্যাক ফাংশন দ্বারা পরিচালিত হয়৷

বিজ্ঞপ্তি বার্তা তৈরির জন্য উপলব্ধ পূর্বনির্ধারিত কীগুলির সম্পূর্ণ তালিকার জন্য রেফারেন্স ডকুমেন্টেশন দেখুন:

• HTTP v1 প্রোটোকল বিজ্ঞপ্তি অবজেক্ট
• লিগ্যাসি HTTP প্রোটোকল বিজ্ঞপ্তি পেলোড
• XMPP প্রোটোকল বিজ্ঞপ্তি পেলোড

ডেটা বার্তা

ক্লায়েন্ট অ্যাপে ডেটা পেলোড পাঠাতে আপনার কাস্টম কী-মানের জোড়ার সাথে উপযুক্ত কী সেট করুন।

উদাহরণস্বরূপ, এখানে উপরের মতো একই IM অ্যাপে একটি JSON-ফরম্যাট করা বার্তা রয়েছে, যেখানে তথ্যটি সাধারণ data কীতে এনক্যাপসুলেট করা হয়েছে এবং ক্লায়েন্ট অ্যাপটি বিষয়বস্তু ব্যাখ্যা করবে বলে আশা করা হচ্ছে:

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

উপরের উদাহরণটি টপ-লেভেল বা সাধারণ data ফিল্ডের ব্যবহার দেখায়, যা বার্তা গ্রহণকারী সমস্ত প্ল্যাটফর্মের ক্লায়েন্টদের দ্বারা ব্যাখ্যা করা হয়। প্রতিটি প্ল্যাটফর্মে, ক্লায়েন্ট অ্যাপ কলব্যাক ফাংশনে ডেটা পেলোড গ্রহণ করে।

ডেটা বার্তাগুলির জন্য এনক্রিপশন

অ্যান্ড্রয়েড ট্রান্সপোর্ট লেয়ার ( এফসিএম আর্কিটেকচার দেখুন) পয়েন্ট-টু-পয়েন্ট এনক্রিপশন ব্যবহার করে। আপনার প্রয়োজনের উপর নির্ভর করে, আপনি ডেটা বার্তাগুলিতে এন্ড-টু-এন্ড এনক্রিপশন যোগ করার সিদ্ধান্ত নিতে পারেন। FCM একটি এন্ড-টু-এন্ড সমাধান প্রদান করে না। যাইহোক, ক্যাপিলারি বা DTLS এর মতো বাহ্যিক সমাধান রয়েছে।

ঐচ্ছিক ডেটা পেলোড সহ বিজ্ঞপ্তি বার্তা

প্রোগ্রামগতভাবে বা Firebase কনসোলের মাধ্যমে, আপনি কাস্টম কী-মানের জোড়ার ঐচ্ছিক পেলোড ধারণ করে এমন বিজ্ঞপ্তি বার্তা পাঠাতে পারেন। বিজ্ঞপ্তি কম্পোজারে , উন্নত বিকল্পগুলিতে কাস্টম ডেটা ক্ষেত্রগুলি ব্যবহার করুন৷

বিজ্ঞপ্তি এবং ডেটা পেলোড উভয়ই অন্তর্ভুক্ত করে এমন বার্তাগুলি পাওয়ার সময় অ্যাপের আচরণ নির্ভর করে অ্যাপটি ব্যাকগ্রাউন্ডে আছে নাকি ফোরগ্রাউন্ডে- মূলত, প্রাপ্তির সময় এটি সক্রিয় কিনা।

• ব্যাকগ্রাউন্ডে থাকাকালীন , অ্যাপগুলি বিজ্ঞপ্তি ট্রেতে নোটিফিকেশন পেলোড গ্রহণ করে এবং ব্যবহারকারী যখন বিজ্ঞপ্তিতে ট্যাপ করে তখনই শুধুমাত্র ডেটা পেলোড পরিচালনা করে।
• ফোরগ্রাউন্ডে থাকাকালীন , আপনার অ্যাপ দুটি পেলোড উপলব্ধ সহ একটি বার্তা অবজেক্ট গ্রহণ করে।

এখানে একটি JSON- ফর্ম্যাট করা বার্তা রয়েছে যাতে notification কী এবং data কী উভয়ই রয়েছে:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

প্ল্যাটফর্ম জুড়ে একটি বার্তা কাস্টমাইজ করা

Firebase অ্যাডমিন SDK এবং FCM v1 HTTP প্রোটোকল উভয়ই আপনার বার্তা অনুরোধগুলিকে message অবজেক্টে উপলব্ধ সমস্ত ক্ষেত্র সেট করার অনুমতি দেয়৷ এটা অন্তর্ভুক্ত:

• বার্তা প্রাপ্ত সমস্ত অ্যাপ্লিকেশন দৃষ্টান্ত দ্বারা ব্যাখ্যা করা ক্ষেত্রগুলির একটি সাধারণ সেট৷
• প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্রগুলির সেট, যেমন AndroidConfig এবং WebpushConfig , শুধুমাত্র নির্দিষ্ট প্ল্যাটফর্মে চলমান অ্যাপের উদাহরণ দ্বারা ব্যাখ্যা করা হয়।

প্ল্যাটফর্ম-নির্দিষ্ট ব্লকগুলি আপনাকে বিভিন্ন প্ল্যাটফর্মের জন্য বার্তাগুলি কাস্টমাইজ করার নমনীয়তা দেয় যাতে প্রাপ্তির সময় সেগুলি সঠিকভাবে পরিচালনা করা হয়। FCM ব্যাকএন্ড সমস্ত নির্দিষ্ট পরামিতি বিবেচনা করবে এবং প্রতিটি প্ল্যাটফর্মের জন্য বার্তাটি কাস্টমাইজ করবে।

কখন সাধারণ ক্ষেত্র ব্যবহার করবেন

সাধারণ ক্ষেত্রগুলি ব্যবহার করুন যখন আপনি:

• অ্যাপল, অ্যান্ড্রয়েড, এবং ওয়েব - সমস্ত প্ল্যাটফর্মে লক্ষ্য করা অ্যাপের উদাহরণ
• বিষয় বার্তা পাঠানো

সমস্ত অ্যাপ্লিকেশন উদাহরণ, প্ল্যাটফর্ম নির্বিশেষে, নিম্নলিখিত সাধারণ ক্ষেত্রগুলিকে ব্যাখ্যা করতে পারে:

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

কখন প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র ব্যবহার করবেন

আপনি যখন চান তখন প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র ব্যবহার করুন:

• শুধুমাত্র নির্দিষ্ট প্ল্যাটফর্মে ক্ষেত্র পাঠান
• সাধারণ ক্ষেত্র ছাড়াও প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র পাঠান

যখনই আপনি শুধুমাত্র নির্দিষ্ট প্ল্যাটফর্মে মান পাঠাতে চান, সাধারণ ক্ষেত্র ব্যবহার করবেন না ; প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র ব্যবহার করুন। উদাহরণস্বরূপ, শুধুমাত্র Apple প্ল্যাটফর্ম এবং ওয়েবে একটি বিজ্ঞপ্তি পাঠাতে কিন্তু Android এ নয়, আপনাকে অবশ্যই দুটি পৃথক ক্ষেত্র ব্যবহার করতে হবে, একটি Apple এর জন্য এবং একটি ওয়েবের জন্য৷

আপনি যখন নির্দিষ্ট ডেলিভারি অপশন সহ বার্তা পাঠাচ্ছেন, তখন সেগুলি সেট করতে প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্রগুলি ব্যবহার করুন৷ আপনি চাইলে প্ল্যাটফর্ম প্রতি বিভিন্ন মান নির্দিষ্ট করতে পারেন। যাইহোক, এমনকি যখন আপনি প্ল্যাটফর্ম জুড়ে অপরিহার্যভাবে একই মান সেট করতে চান, আপনাকে অবশ্যই প্ল্যাটফর্ম-নির্দিষ্ট ক্ষেত্র ব্যবহার করতে হবে। এর কারণ হল প্রতিটি প্ল্যাটফর্ম মানটিকে কিছুটা আলাদাভাবে ব্যাখ্যা করতে পারে—উদাহরণস্বরূপ, Android-এ টাইম-টু-লাইভ সেকেন্ডে মেয়াদ শেষ হওয়ার সময় হিসাবে সেট করা হয়, যখন Apple-এ এটি মেয়াদ শেষ হওয়ার তারিখ হিসাবে সেট করা হয়।

Example: notification message with platform-specific delivery options

The following v1 send request sends a common notification title and content to all platforms, but also sends some platform-specific overrides. Specifically, the request:

• sets a long time-to-live for Android and Web platforms, while setting the APNs (Apple platforms) message priority to a low setting
• sets the appropriate keys to define the result of a user tap on the notification on Android and Apple — click_action , and category , respectively.

{
  "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"
       }
     }
   }
 }

See the HTTP v1 reference documentation for complete detail on the keys available in platform-specific blocks in the message body. For more information about building send requests that contain the message body, see Build Send Requests .

Delivery options

FCM provides a specific set of delivery options for messages sent to Android devices, and allows for similar options on Apple platforms and web. For example, "collapsible" message behavior is supported on Android via FCM's collapse_key , on Apple via apns-collapse-id , and on JavaScript/Web via Topic . For details, see descriptions in this section and related reference documentation.

Non-collapsible and collapsible messages

A non-collapsible message denotes that each individual message is delivered to the device. A non-collapsible message delivers some useful content, as opposed to a collapsible message like a content-free "ping" to the mobile app to contact the server to fetch data.

Some typical use cases of non-collapsible messages are chat messages or critical messages. For example, in an IM app, you would want to deliver every message, because every message has different content.

For Android there is a limit of 100 messages that can be stored without collapsing. If the limit is reached, all stored messages are discarded. When the device is back online, it receives a special message indicating that the limit was reached. The app can then handle the situation properly, typically by requesting a full sync from the app server.

A collapsible message is a message that may be replaced by a new message if it has yet to be delivered to the device.

A common use cases of collapsible messages are messages used to tell a mobile app to sync data from the server. An example would be a sports app that updates users with the latest score. Only the most recent message is relevant.

To mark a message as collapsible on Android, include the collapse_key parameter in the message payload. By default, the collapse key is the app package name registered in the Firebase console. The FCM server can simultaneously store four different collapsible messages per device, each with a different collapse key. If you exceed this number, FCM only keeps four collapse keys, with no guarantees about which ones are kept.

Topic messages with no payload are collapsible by default. Notification messages are always collapsible and will ignore the collapse_key parameter.

Which should I use?

Collapsible messages are a better choice from a performance standpoint, provided your app doesn't need to use non-collapsible messages. However, if you use collapsible messages, remember that FCM only allows a maximum of four different collapse keys to be used by FCM per registration token at any given time. You must not exceed this number, or it could cause unpredictable consequences.

	Use scenario	How to send
Non-collapsible	Every message is important to the client app and needs to be delivered.	Except for notification messages, all messages are non-collapsible by default.
Collapsible	When there is a newer message that renders an older, related message irrelevant to the client app, FCM replaces the older message. For example: messages used to initiate a data sync from the server, or outdated notification messages.	Set the appropriate parameter in your message request: collapseKey on Android apns-collapse-id on Apple Topic on Web collapse_key in legacy protocols (all platforms)

Setting the priority of a message

You have two options for assigning delivery priority to downstream messages: normal and high priority. Though the behavior differs slightly across platforms, delivery of normal and high priority messages works like this:

• Normal priority. Normal priority messages are delivered immediately when the app is in the foreground. For backgrounded apps, delivery may be delayed. For less time-sensitive messages, such as notifications of new email, keeping your UI in sync, or syncing app data in the background, choose normal delivery priority.

• High priority. FCM attempts to deliver high priority messages immediately even if the device is in Doze mode. High priority messages are for time-sensitive, user visible content.

Here is an example of a normal priority message sent via the FCM HTTP v1 protocol to notify a magazine subscriber that new content is available to download:

{
  "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"
      }
    }
  }
}

For more platform-specific detail on setting message priority:

• APNs documentation
• Set and manage message priority (Android)
• Web push message urgency

Setting the lifespan of a message

FCM usually delivers messages immediately after they are sent. However, this might not always be possible. For example, if the platform is Android, the device could be turned off, offline, or otherwise unavailable. Or FCM might intentionally delay messages to prevent an app from consuming excessive resources and negatively affecting battery life.

When this happens, FCM stores the message and delivers it as soon as it's feasible. While this is fine in most cases, there are some apps for which a late message might as well never be delivered. For example, if the message is an incoming call or video chat notification, it is meaningful only for a short period of time before the call is terminated. Or if the message is an invitation to an event, it is useless if received after the event has ended.

On Android and Web/JavaScript, you can specify the maximum lifespan of a message. The value must be a duration from 0 to 2,419,200 seconds (28 days), and it corresponds to the maximum period of time for which FCM stores and attempts to deliver the message. Requests that don't contain this field default to the maximum period of four weeks.

Here are some possible uses for this feature:

• Video chat incoming calls
• Expiring invitation events
• Calendar events

Another advantage of specifying the lifespan of a message is that FCM never throttles messages with a time-to-live value of 0 seconds. In other words, FCM guarantees best effort for messages that must be delivered "now or never." Keep in mind that a time_to_live value of 0 means messages that can't be delivered immediately are discarded. However, because such messages are never stored, this provides the best latency for sending notification messages.

Here is an example of a request that includes TTL:

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

Lifetime of a message

When an app server posts a message to FCM and receives a message ID back, it does not mean that the message was already delivered to the device. Rather, it means that it was accepted for delivery. What happens to the message after it is accepted depends on many factors.

In the best-case scenario, if the device is connected to FCM, the screen is on and there are no throttling restrictions, the message is delivered right away.

If the device is connected but in Doze, a low priority message is stored by FCM until the device is out of Doze. And that's where the collapse_key flag plays a role: if there is already a message with the same collapse key (and registration token) stored and waiting for delivery, the old message is discarded and the new message takes its place (that is, the old message is collapsed by the new one). However, if the collapse key is not set, both the new and old messages are stored for future delivery.

If the device is not connected to FCM, the message is stored until a connection is established (again respecting the collapse key rules). When a connection is established, FCM delivers all pending messages to the device. If the device never gets connected again (for instance, if it was factory reset), the message eventually times out and is discarded from FCM storage. The default timeout is four weeks, unless the time_to_live flag is set.

To get more insight into the delivery of a message:

To get more insight into the delivery of messages on Android or Apple platforms, see the FCM reporting dashboard , which records the number of messages sent and opened on Apple and Android devices, along with data for "impressions" (notifications seen by users) for Android apps.

For Android devices with direct channel messaging enabled, if the device has not connected to FCM for more than one month, FCM still accepts the message but immediately discards it. If the device connects within four weeks of the last data message you sent to it, your client receives the onDeletedMessages() callback. The app can then handle the situation properly, typically by requesting a full sync from the app server.

Finally, when FCM attempts to deliver a message to the device and the app was uninstalled, FCM discards that message right away and invalidates the registration token. Future attempts to send a message to that device results in a NotRegistered error.

Throttling and scaling

Our goal is to always deliver every message sent via FCM. However, delivering every message sometimes results in a poor overall user experience. In other cases, we need to provide boundaries to ensure that FCM provides a scalable service for all senders.

Collapsible message throttling

As described above, collapsible messages are content-free notifications designed to collapse on top of each other. In the event that a developer is repeating the same message to an app too frequently, we delay (throttle) messages to reduce the impact on a user's battery.

For example, if you send large numbers of new email sync requests to a single device, we might delay the next email sync request a few minutes so that the device can sync at a lower average rate. This throttling is done strictly to limit the battery impact experienced by the user.

If your use case requires high burst send patterns, then non-collapsible messages may be the right choice. For such messages, make sure to include the content in such messages in order to reduce the battery cost.

We limit collapsible messages to a burst of 20 messages per app per device, with a refill of 1 message every 3 minutes.

XMPP server throttling

We limit the rate that you can connect to FCM XMPP servers to 400 connections per minute per project. This shouldn't be an issue for message delivery, but it is important for ensuring the stability of our system.

For each project, FCM allows 2500 connections in parallel.

Maximum message rate to a single device

For Android, you can send up to 240 messages/minute and 5,000 messages/hour to a single device. This high threshold is meant to allow for short term bursts of traffic, such as when users are interacting rapidly over chat. This limit prevents errors in sending logic from inadvertently draining the battery on a device.

For iOS, we return an error when the rate exceeds APNs limits.

Upstream message limit

We limit upstream messages at 1,500,000/minute per project to avoid overloading upstream destination servers.

We limit upstream messages per device at 1,000/minute to protect against battery drain from bad app behavior.

Topic message limit

The topic subscription add/remove rate is limited to 3,000 QPS per project.

For message sending rates, see Fanout Throttling .

Fanout throttling

Message fanout is the process of sending a message to multiple devices, such as when you target topics and groups, or when you use the Notifications composer to target audiences or user segments.

Message fanout is not instantaneous and so occasionally you have multiple fanouts in progress concurrently. We limit the number of concurrent message fanouts per project to 1,000. After that, we may reject additional fanout requests or defer the fanout of the requests until some of the already in progress fanouts complete.

The actual achievable fanout rate is influenced by the number of projects requesting fanouts at the same time. A fanout rate of 10,000 QPS for an individual project is not uncommon, but that number is not a guarantee and is a result of the total load on the system. It is important to note that the available fanout capacity is divided among projects and not across fanout requests. So, if your project has two fanouts in progress, then each fanout will only see half of the available fanout rate. The recommended way to maximize your fanout speed is to only have one active fanout in progress at a time.

FCM ports and your firewall

If your organization has a firewall to restrict traffic to or from the Internet, you need to configure it to allow mobile devices to connect with FCM in order for devices on your network to receive messages. FCM typically uses port 5228, but it sometimes uses 443, 5229, and 5230.

For devices connecting on your network, FCM doesn't provide specific IPs because our IP range changes too frequently and your firewall rules could get out of date, impacting your users' experience. Ideally, allowlist ports 5228-5230 & 443 with no IP restrictions. However, if you must have an IP restriction, you should allowlist all of the IP addresses listed in goog.json . This large list is updated regularly, and you are recommended to update your rules on a monthly basis. Problems caused by firewall IP restrictions are often intermittent and difficult to diagnose.

We do offer a set of domain names that can be allowlisted instead of IP addresses. Those hostnames are listed below. If we start using additional hostnames, we will update the list here. Using domain names for your firewall rule may or may not be functional in your firewall device.

TCP ports to open:

• 5228
• 5229
• 5230
• 443

Hostnames to open:

• 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

Network Address Translation and/or Stateful Packet Inspection firewalls:

If your network implements Network Address Translation (NAT) or Stateful Packet Inspection (SPI), implement a 30 minute or larger timeout for our connections over ports 5228-5230. This enables us to provide reliable connectivity while reducing the battery consumption of your users' mobile devices.

Credentials

Depending on which FCM features you implement, you may need the following credentials from your Firebase project:

Project ID	A unique identifier for your Firebase project, used in requests to the FCM v1 HTTP endpoint. This value is available in the Firebase console Settings pane.
Registration token	A unique token string that identifies each client app instance. The registration token is required for single device and device group messaging. Note that registration tokens must be kept secret.
Sender ID	A unique numerical value created when you create your Firebase project, available in the Cloud Messaging tab of the Firebase console Settings pane. The sender ID is used to identify each sender that can send messages to the client app.
Access token	A short-lived OAuth 2.0 token that authorizes requests to the HTTP v1 API. This token is associated with a service account that belongs to your Firebase project. To create and rotate access tokens, follow the steps described in Authorize Send Requests .
Server key (for legacy protocols)	A server key that authorizes your app server for access to Google services, including sending messages via the Firebase Cloud Messaging legacy protocols. You obtain the server key when you create your Firebase project. You can view it in the Cloud Messaging tab of the Firebase console Settings pane. Important: Do not include the server key anywhere in your client code. Also, make sure to use only server keys to authorize your app server. Android, Apple platform, and browser keys are rejected by FCM.