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

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

বার্তার ধরন

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

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

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

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

FCM একটি ঐচ্ছিক ডেটা পেলোড সহ একটি বিজ্ঞপ্তি বার্তা পাঠাতে পারে৷ এই ধরনের ক্ষেত্রে, 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 প্রোটোকল বিজ্ঞপ্তি অবজেক্ট রেফারেন্স ডকুমেন্টেশন দেখুন।

ডেটা বার্তা

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

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

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

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

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

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

ডেলিভারি অপশন

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

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

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

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

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

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

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

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

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

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

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

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

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

• স্বাভাবিক অগ্রাধিকার। অ্যাপটি অগ্রভাগে থাকলে সাধারণ অগ্রাধিকার বার্তাগুলি অবিলম্বে বিতরণ করা হয়। ব্যাকগ্রাউন্ডেড অ্যাপের জন্য, ডেলিভারি বিলম্বিত হতে পারে। কম সময়-সংবেদনশীল বার্তাগুলির জন্য, যেমন নতুন ইমেলের বিজ্ঞপ্তি, আপনার 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"
      }
    }
  }
}

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

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

জীবনের সমালোচনামূলক ব্যবহারের ক্ষেত্রে

FCM APIগুলি জরুরী সতর্কতা বা অন্যান্য উচ্চ-ঝুঁকিমূলক কার্যকলাপের জন্য ডিজাইন করা হয়নি যেখানে APIs ব্যবহার বা ব্যর্থতার ফলে মৃত্যু, ব্যক্তিগত আঘাত, বা পরিবেশগত ক্ষতি হতে পারে (যেমন পারমাণবিক সুবিধা, এয়ার ট্র্যাফিক কন্ট্রোল, বা লাইফ সাপোর্ট সিস্টেম)। ধারা 4 এর অধীনে এই জাতীয় যে কোনও ব্যবহার স্পষ্টভাবে নিষিদ্ধ। পরিষেবার শর্তাবলীর 7 . শর্তাবলীর সাথে আপনার অ্যাপের সম্মতি এবং আপনার অ-সম্মতির ফলে যেকোন ক্ষতির জন্য আপনি এককভাবে দায়ী। Google "যেমন আছে" API প্রদান করে এবং আপনার বা আপনার ব্যবহারকারীদের প্রতি কোনো দায়বদ্ধতা বা অন্য কোনো বাধ্যবাধকতা ছাড়াই যে কোনো কারণে এবং যেকোনো সময় APIs বা কোনো অংশ বা বৈশিষ্ট্য বা এতে আপনার অ্যাক্সেস বন্ধ করার অধিকার সংরক্ষণ করে।

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

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

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

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

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

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

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

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

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

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

থ্রটলিং এবং কোটা

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

ডাউনস্ট্রিম মেসেজ থ্রটলিং

HTTP v1 API প্রবর্তিত হয়েছে প্রতি-প্রকল্প, প্রতি মিনিটের কোটা ডাউনস্ট্রিম মেসেজিংয়ের জন্য। প্রতি মিনিটে 600k বার্তাগুলির ডিফল্ট কোটা 99% FCM বিকাশকারীদের কভার করে যখন সিস্টেমের স্থিতিশীলতা রক্ষা করে এবং স্পাইকি প্রকল্পগুলির প্রভাবকে কম করে।

স্পাইকি ট্রাফিক প্যাটার্নের ফলে কোটা অতিক্রম করা ত্রুটি হতে পারে। অতিরিক্ত কোটার পরিস্থিতিতে, পরবর্তী মিনিটে কোটা পুনরায় পূরণ না হওয়া পর্যন্ত সিস্টেমটি HTTP স্ট্যাটাস কোড 429 (QUOTA_EXCEEDED) পরিবেশন করে। ওভারলোড পরিস্থিতিতেও 429 প্রতিক্রিয়া ফেরত দেওয়া হতে পারে, তাই আপনাকে প্রকাশিত সুপারিশ অনুযায়ী 429গুলি পরিচালনা করার জন্য দৃঢ়ভাবে উত্সাহিত করা হচ্ছে৷

উল্লেখ্য যে:

• ডাউনস্ট্রিম কোটা বার্তা পরিমাপ করে, অনুরোধ নয়।
• ক্লায়েন্ট ত্রুটি (HTTP স্ট্যাটাস কোড 400-499) গণনা করা হয় (429 ব্যতীত)।
• কোটা প্রতি মিনিটে, কিন্তু এই মিনিটগুলি ঘড়ির সাথে সারিবদ্ধ নয়।

মনিটরিং কোটা

আপনি Google ক্লাউড কনসোলে কোটা, ব্যবহার এবং ত্রুটিগুলি দেখতে পারেন:

1. Google Cloud কনসোলে যান
2. APIs এবং পরিষেবাগুলি নির্বাচন করুন৷
3. টেবিল তালিকা থেকে, Firebase ক্লাউড মেসেজিং API নির্বাচন করুন
4. কোটা এবং সিস্টেম সীমা নির্বাচন করুন।

দ্রষ্টব্য: এই গ্রাফগুলি সঠিকভাবে কোটা মিনিটের সাথে সারিবদ্ধ নয়, যার অর্থ ট্রাফিক কোটার নিচে বলে মনে হলে 429গুলি পরিবেশন করা হতে পারে৷

কোটা বাড়ানোর অনুরোধ করছি

কোটা বৃদ্ধির অনুরোধ করার আগে, নিশ্চিত করুন যে:

• আপনার ব্যবহার নিয়মিতভাবে প্রতিদিন কমপক্ষে 5 টানা মিনিটের জন্য কোটার ≥ 80%।
• আপনার <5% ক্লায়েন্ট ত্রুটি অনুপাত আছে, বিশেষ করে সর্বোচ্চ ট্রাফিকের সময়।
• আপনি স্কেলে বার্তা পাঠানোর জন্য সর্বোত্তম অনুশীলনগুলি মেনে চলেন৷

আপনি যদি এই মানদণ্ডগুলি পূরণ করেন, আপনি +25% পর্যন্ত কোটা বৃদ্ধির অনুরোধ জমা দিতে পারেন এবং FCM অনুরোধটি পূরণ করার জন্য সর্বাত্মক চেষ্টা করবে (কোন বৃদ্ধির নিশ্চয়তা দেওয়া যাবে না)।

একটি আসন্ন লঞ্চ বা অস্থায়ী ইভেন্টের কারণে আপনার যদি আরও ডাউনস্ট্রিম মেসেজিং কোটার প্রয়োজন হয়, অনুরোধটি পরিচালনা করার জন্য পর্যাপ্ত সময় দেওয়ার জন্য কমপক্ষে 15 দিন আগে আপনার কোটার অনুরোধ করুন। বড় অনুরোধের জন্য (> প্রতি মিনিটে 18M বার্তা), কমপক্ষে 30 দিনের নোটিশ প্রয়োজন। লঞ্চ এবং বিশেষ ইভেন্টের অনুরোধগুলি এখনও ক্লায়েন্ট ত্রুটি অনুপাত এবং সর্বোত্তম অনুশীলনের প্রয়োজনীয়তার সাপেক্ষে।

এছাড়াও FCM কোটা সম্পর্কে প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী দেখুন।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

যদি আপনার সংস্থার কাছে ইন্টারনেটে বা থেকে ট্র্যাফিক সীমাবদ্ধ করার জন্য একটি ফায়ারওয়াল থাকে, তাহলে আপনার নেটওয়ার্কের ডিভাইসগুলি যাতে বার্তাগুলি পেতে পারে তার জন্য আপনাকে মোবাইল ডিভাইসগুলিকে 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 মিনিট বা তার বেশি সময়সীমা কার্যকর করুন। এটি আপনার ব্যবহারকারীদের মোবাইল ডিভাইসের ব্যাটারি খরচ কমানোর সাথে সাথে আমাদের নির্ভরযোগ্য সংযোগ প্রদান করতে সক্ষম করে।

ভিপিএন মিথস্ক্রিয়া এবং বাইপাসেবিলিটি

Firebase Cloud Messaging ফোন থেকে সার্ভারে পুশ মেসেজিং সংযোগটি যতবার সম্ভব নির্ভরযোগ্য এবং উপলব্ধ তা নিশ্চিত করতে বিভিন্ন পদক্ষেপ নেয়। একটি ভিপিএন ব্যবহার এই প্রচেষ্টাকে জটিল করে তোলে।

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

এটি বাইপাস করা যায় কিনা তা নিয়ন্ত্রণ করার জন্য বিভিন্ন ভিপিএন-এর বিভিন্ন পদ্ধতি থাকবে। নির্দেশাবলীর জন্য আপনার নির্দিষ্ট VPN এর জন্য ডকুমেন্টেশন দেখুন।

যদি VPN বাইপাসযোগ্য হওয়ার জন্য কনফিগার করা না থাকে তাহলে Firebase Cloud Messaging সার্ভারের সাথে সংযোগ করার জন্য VPN নেটওয়ার্ক ব্যবহার করবে। এর ফলে এমন সময় হতে পারে যেখানে বার্তাগুলি বিলম্বিত হয় এবং Cloud Messaging VPN সংযোগের মাধ্যমে সংযোগ বজায় রাখার জন্য কাজ করে বলে আরও ব্যাটারি ব্যবহার হতে পারে।

শংসাপত্র

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

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

বার্তার ধরন

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

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

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

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

FCM একটি ঐচ্ছিক ডেটা পেলোড সহ একটি বিজ্ঞপ্তি বার্তা পাঠাতে পারে৷ এই ধরনের ক্ষেত্রে, 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 প্রোটোকল বিজ্ঞপ্তি অবজেক্ট রেফারেন্স ডকুমেন্টেশন দেখুন।

ডেটা বার্তা

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

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

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

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

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

অ্যান্ড্রয়েড ট্রান্সপোর্ট লেয়ার ( FCM আর্কিটেকচার দেখুন) পয়েন্ট-টু-পয়েন্ট এনক্রিপশন ব্যবহার করে। আপনার প্রয়োজনের উপর নির্ভর করে, আপনি ডেটা বার্তাগুলিতে এন্ড-টু-এন্ড এনক্রিপশন যোগ করার সিদ্ধান্ত নিতে পারেন। 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 Admin SDK এবং FCM v1 HTTP প্রোটোকল উভয়ই আপনার বার্তা অনুরোধগুলিকে message অবজেক্টে উপলব্ধ সমস্ত ক্ষেত্র সেট করার অনুমতি দেয়৷ এর মধ্যে রয়েছে:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• এপিএনএস (অ্যাপল প্ল্যাটফর্মগুলি) কম সেটিংয়ে বার্তা অগ্রাধিকার নির্ধারণের সময় অ্যান্ড্রয়েড এবং ওয়েব প্ল্যাটফর্মগুলির জন্য দীর্ঘ সময় থেকে লাইভ সেট করে
• অ্যান্ড্রয়েড এবং অ্যাপল - 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"
       }
     }
   }
 }

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

বিতরণ বিকল্প

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

অ-সংঘটিত এবং সংযোগযোগ্য বার্তা

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

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

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

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

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

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

কোনও পে -লোডযুক্ত বিষয় বার্তাগুলি ডিফল্টরূপে সঙ্কুচিত হয়। বিজ্ঞপ্তি বার্তাগুলি সর্বদা সঙ্কুচিত হয় এবং collapse_key প্যারামিটারটিকে উপেক্ষা করবে।

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

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

একটি বার্তার অগ্রাধিকার নির্ধারণ

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

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

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

নতুন সামগ্রী ডাউনলোডের জন্য উপলব্ধ যে কোনও ম্যাগাজিনের গ্রাহককে অবহিত করার জন্য FCM এইচটিটিপি ভি 1 প্রোটোকলের মাধ্যমে প্রেরিত একটি সাধারণ অগ্রাধিকার বার্তার উদাহরণ এখানে রয়েছে:

{
  "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 এর অধীনে এ জাতীয় কোনও ব্যবহার স্পষ্টভাবে নিষিদ্ধ। ক। পরিষেবার শর্তাদি 7 । আপনি শর্তাবলীগুলির সাথে আপনার অ্যাপ্লিকেশনটির সম্মতি এবং আপনার অবহেলার ফলে প্রাপ্ত কোনও ক্ষয়ক্ষতি পরিচালনার জন্য আপনি একমাত্র দায়বদ্ধ। গুগল এপিআইগুলিকে "যেমন আছে তেমন" সরবরাহ করে এবং কোনও কারণে এবং যে কোনও সময় আপনার বা আপনার ব্যবহারকারীদের দায়বদ্ধতা বা অন্য কোনও বাধ্যবাধকতা ছাড়াই এপিআই বা কোনও অংশ বা বৈশিষ্ট্য বা আপনার অ্যাক্সেস বন্ধ করার অধিকার সংরক্ষণ করে।

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

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

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

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

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

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

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

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

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

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

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

সেরা কেস দৃশ্যে, যদি ডিভাইসটি FCM সাথে সংযুক্ত থাকে তবে স্ক্রিনটি চালু রয়েছে এবং কোনও থ্রোটলিং বিধিনিষেধ নেই, বার্তাটি এখনই সরবরাহ করা হবে।

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

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

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

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

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

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

থ্রটলিং এবং কোটা

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

ডাউনস্ট্রিম বার্তা থ্রোটলিং

এইচটিটিপি ভি 1 এপিআই ডাউন স্ট্রিম মেসেজিংয়ের জন্য প্রতি-প্রকল্প, প্রতি মিনিটের কোটা চালু করেছে। সিস্টেমের স্থায়িত্ব রক্ষা করার সময় এবং স্পিকি প্রকল্পগুলির প্রভাবকে হ্রাস করার সময় প্রতি মিনিটে 600k বার্তার ডিফল্ট কোটা FCM বিকাশকারীদের 99% এরও বেশি কভার করে।

স্পিকি ট্র্যাফিক নিদর্শনগুলির ফলে কোটা অতিক্রম করা ত্রুটি হতে পারে। ওভার কোটা দৃশ্যে, সিস্টেমটি নিম্নলিখিত মুহুর্তে কোটা পুনরায় পূরণ না করা পর্যন্ত HTTP স্ট্যাটাস কোড 429 (কোটা_এক্সইডেড) সরবরাহ করে। 429 টি প্রতিক্রিয়াগুলি ওভারলোড পরিস্থিতিতেও ফিরে আসতে পারে, সুতরাং প্রকাশিত সুপারিশ অনুসারে আপনাকে 429 গুলি পরিচালনা করতে দৃ strongly ়ভাবে উত্সাহিত করা হয়।

উল্লেখ্য যে:

• ডাউনস্ট্রিম কোটা বার্তাগুলি পরিমাপ করে, অনুরোধগুলি নয়।
• ক্লায়েন্ট ত্রুটিগুলি (এইচটিটিপি স্থিতি কোড 400-499) গণনা করা হয় (429s বাদে)।
• কোটা প্রতি মিনিটে হয় তবে এই মিনিটগুলি ঘড়ির সাথে একত্রিত হয় না।

নিরীক্ষণ কোটা

আপনি গুগল ক্লাউড কনসোলে কোটা, ব্যবহার এবং ত্রুটিগুলি দেখতে পারেন:

1. Google Cloud কনসোলে যান
2. এপিআই এবং পরিষেবাদি নির্বাচন করুন
3. টেবিল তালিকা থেকে, ফায়ারবেস ক্লাউড মেসেজিং এপিআই নির্বাচন করুন
4. কোটা এবং সিস্টেমের সীমা নির্বাচন করুন।

দ্রষ্টব্য: এই গ্রাফগুলি কোটা মিনিটের সাথে যথাযথভাবে একত্রিত হয় না, যার অর্থ ট্র্যাফিক কোটার নীচে উপস্থিত হলে 429 গুলি পরিবেশন করা যেতে পারে।

কোটা বাড়ানোর অনুরোধ করছি

কোটা বৃদ্ধির অনুরোধ করার আগে, তা নিশ্চিত করুন:

• আপনার ব্যবহার নিয়মিতভাবে প্রতিদিন কমপক্ষে 5 মিনিটের জন্য কোটা ≥ 80%।
• আপনার <5% ক্লায়েন্ট ত্রুটি অনুপাত রয়েছে, বিশেষত শিখর ট্র্যাফিকের সময়।
• আপনি স্কেলে বার্তা প্রেরণের জন্য সেরা অনুশীলনগুলি মেনে চলেন।

আপনি যদি এই মানদণ্ডগুলি পূরণ করেন তবে আপনি +25% পর্যন্ত কোটা বৃদ্ধির অনুরোধ জমা দিতে পারেন এবং FCM অনুরোধটি পূরণের জন্য প্রতিটি ব্যবহারিক প্রচেষ্টা করবে (কোনও বৃদ্ধির নিশ্চয়তা দেওয়া যায় না)।

আসন্ন লঞ্চ বা অস্থায়ী ইভেন্টের কারণে যদি আপনার আরও ডাউন স্ট্রিম মেসেজিং কোটা প্রয়োজন হয় তবে অনুরোধটি পরিচালনা করার জন্য পর্যাপ্ত সময় দেওয়ার জন্য আপনার কোটা কমপক্ষে 15 দিনের আগে অনুরোধ করুন। বড় অনুরোধগুলির জন্য (> প্রতি মিনিটে 18 মি বার্তা), কমপক্ষে 30 দিনের নোটিশ প্রয়োজন। লঞ্চ এবং বিশেষ ইভেন্টের অনুরোধগুলি এখনও ক্লায়েন্ট ত্রুটি অনুপাত এবং সেরা অনুশীলনের প্রয়োজনীয়তার সাপেক্ষে।

FCM কোটা সম্পর্কে FAQ এছাড়াও দেখুন।

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

বিষয় সাবস্ক্রিপশন অ্যাড/অপসারণের হারটি প্রতি প্রকল্পে 3,000 কিউপিএসের মধ্যে সীমাবদ্ধ।

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

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

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

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

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

সঙ্কুচিত বার্তা থ্রোটলিং

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

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

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

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

এক্সএমপিপি সার্ভার থ্রোটলিং

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

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

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

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

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

আইওএসের জন্য, হারটি এপিএনএস সীমা ছাড়িয়ে গেলে আমরা একটি ত্রুটি ফিরিয়ে দিই।

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

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

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

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

টিসিপি পোর্টগুলি খুলতে:

• 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
• ডিভাইস-সরবরাহকারী.গোগলিপিস.কম
• firebaseinstallations.googleapis.com

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

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

ভিপিএন ইন্টারঅ্যাকশন এবং বাইপাসিবিলিটি

Firebase Cloud Messaging ফোন থেকে সার্ভারে পুশ মেসেজিং সংযোগটি নির্ভরযোগ্য এবং যতবার সম্ভব সম্ভব উপলব্ধ তা নিশ্চিত করতে বিভিন্ন পদক্ষেপ নেয়। একটি ভিপিএন ব্যবহার এই প্রচেষ্টাটিকে জটিল করে তোলে।

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

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

যদি ভিপিএনটি বাইপাসেবল হিসাবে কনফিগার না করা হয় তবে Firebase Cloud Messaging সার্ভারের সাথে সংযোগ স্থাপনের জন্য ভিপিএন নেটওয়ার্ক ব্যবহার করবে। এর ফলে এমন সময় হতে পারে যেখানে বার্তাগুলি বিলম্বিত হয় এবং Cloud Messaging ভিপিএন সংযোগের সাথে সংযোগ বজায় রাখতে কাজ করে কারণ আরও ব্যাটারি ব্যবহার হতে পারে।

শংসাপত্র

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

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

বার্তার ধরন

FCM সহ, আপনি ক্লায়েন্টদের দুটি ধরণের বার্তা প্রেরণ করতে পারেন:

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

বিজ্ঞপ্তি বার্তাগুলিতে ব্যবহারকারী-দৃশ্যমান কীগুলির একটি পূর্বনির্ধারিত সেট রয়েছে। বিপরীতে ডেটা বার্তাগুলি কেবলমাত্র আপনার ব্যবহারকারী-সংজ্ঞায়িত কাস্টম কী-মান জোড়া ধারণ করে। বিজ্ঞপ্তি বার্তাগুলিতে একটি al চ্ছিক ডেটা পেডলোড থাকতে পারে। উভয় বার্তার প্রকারের জন্য সর্বাধিক পে -লোড 4096 বাইট, Firebase কনসোল থেকে বার্তা প্রেরণ করা ব্যতীত, যা 1000 চরিত্রের সীমা প্রয়োগ করে।

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

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

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

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

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

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

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

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

ডেটা বার্তা

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

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

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

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

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

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

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

প্রোগ্রামগতভাবে বা 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 এবং এফসিএম ভি 1 এইচটিটিপি প্রোটোকল উভয়ই আপনার বার্তার অনুরোধগুলিকে message অবজেক্টে উপলব্ধ সমস্ত ক্ষেত্র সেট করার অনুমতি দেয়। এর মধ্যে রয়েছে:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• এপিএনএস (অ্যাপল প্ল্যাটফর্মগুলি) কম সেটিংয়ে বার্তা অগ্রাধিকার নির্ধারণের সময় অ্যান্ড্রয়েড এবং ওয়েব প্ল্যাটফর্মগুলির জন্য দীর্ঘ সময় থেকে লাইভ সেট করে
• অ্যান্ড্রয়েড এবং অ্যাপল - 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"
       }
     }
   }
 }

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

বিতরণ বিকল্প

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

অ-সংঘটিত এবং সংযোগযোগ্য বার্তা

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

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

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

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

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

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

কোনও পে -লোডযুক্ত বিষয় বার্তাগুলি ডিফল্টরূপে সঙ্কুচিত হয়। বিজ্ঞপ্তি বার্তাগুলি সর্বদা সঙ্কুচিত হয় এবং collapse_key প্যারামিটারটিকে উপেক্ষা করবে।

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

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

একটি বার্তার অগ্রাধিকার নির্ধারণ

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

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

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

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

Life critical use cases

The FCM APIs are not designed for emergency alerts or other high-risk activities where the use or failure of the APIs could result in death, personal injury, or environmental damage (such as the operation of nuclear facilities, air traffic control, or life support systems). Any such use is expressly prohibited under Section 4. a. 7 of the Terms of Service. You are solely responsible for managing your app's compliance with the Terms, and any damages resulting from your noncompliance. Google provides the APIs "as is," and reserves the right to discontinue the APIs or any portion or feature or your access thereto, for any reason and at any time, without liability or other obligation to you or your users.

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
• ক্যালেন্ডার ইভেন্ট

Another advantage of specifying the lifespan of a message is that FCM doesn't apply collapsible message throttling to messages with a time-to-live value of 0 seconds. FCM provides best effort handling of 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.

থ্রটলিং এবং কোটা

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. The types of limits and quotas described in this section help us balance these important factors.

Downstream message throttling

The HTTP v1 API introduced per-project, per-minute quotas for downstream messaging. The default quota of 600k messages per minute covers over 99% of FCM developers while protecting the stability of the system and minimizing the impact of spiky projects.

Spiky traffic patterns can result in quota exceeded errors. In an over quota scenario, the system serves HTTP status code 429 (QUOTA_EXCEEDED) until the quota is refilled in the following minute. 429 responses may also be returned in overload situations, so you are strongly encouraged to handle 429s according to published recommendations .

উল্লেখ্য যে:

• The downstream quota measures messages, not requests.
• Client errors (HTTP status code 400-499) are counted (excluding 429s).
• Quotas are per-minute, but these minutes are not aligned to the clock.

Monitoring quota

You can view quota, usage, and errors on the Google Cloud Console:

1. Google Cloud কনসোলে যান
2. Select APIs & services
3. From the table list, select Firebase Cloud Messaging API
4. Select QUOTA & SYSTEM LIMITS .

NOTE: These graphs are not precisely time aligned with quota minutes, meaning 429s may be served when traffic appears to be below quota.

কোটা বাড়ানোর অনুরোধ করছি

Before requesting a quota increase, ensure that:

• Your usage is regularly ≥ 80% of quota for at least 5 consecutive minutes per day.
• You have < 5% client error ratio, especially during peak traffic.
• You adhere to the best practices for sending messages at scale .

If you meet these criteria, you can submit a quota increase request for up to +25% and FCM will make every practical effort to fulfill the request (no increase can be guaranteed).

If you need more downstream messaging quota due to an impending launch or temporary event, request your quota at least 15 days in advance to allow sufficient time to handle the request. For large requests (>18M messages per minute), at least 30 days of notice is required. Launches and special event requests are still subject to the client error ratio and best practices requirements.

See also the FAQ about FCM quotas .

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.

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 the system. For each project, FCM allows 2500 connections in parallel.

For upstream messaging with XMPP, FCM limits 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.

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

Android এর জন্য, আপনি একটি ডিভাইসে 240টি বার্তা/মিনিট এবং 5,000টি বার্তা/ঘন্টা পাঠাতে পারেন৷ 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.

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.

VPN interactions and bypassability

Firebase Cloud Messaging takes various steps to ensure that the push messaging connection from the phone to the server is reliable and available as often as possible. The use of a VPN complicates this effort.

VPNs mask the underlying information that FCM needs to tune its connection to maximize reliability & battery life. In some cases VPNs actively break long lived connections resulting in a bad user experience due to missed or delayed messages or a high battery cost. When the VPN is configured to allow us to do so, we bypass the VPN using an encrypted connection (over the base network wifi or LTE) so as to ensure a reliable, battery friendly experience. FCM 's usage of bypassable VPNs is specific to the FCM Push Notification channel. Other FCM traffic, such as registration traffic, uses the VPN if it is active. When the FCM connection bypasses the VPN it loses additional benefits the VPN may provide, such as IP masking.

Different VPNs will have different methods for controlling whether or not it can be bypassed. Consult the documentation for your specific VPN for instructions.

If the VPN is not configured to be bypassable then Firebase Cloud Messaging will use the VPN network in order to connect to the server. This may result in periods of time where messages are delayed and may result in more battery usage as Cloud Messaging works to maintain the connection over the VPN connection.

শংসাপত্র

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

Firebase Cloud Messaging ( FCM ) offers a broad range of messaging options and capabilities. The information in this page is intended to help you understand the different types of FCM messages and what you can do with them.

বার্তার ধরন

With FCM , you can send two types of messages to clients:

• Notification messages, sometimes thought of as "display messages." এগুলি স্বয়ংক্রিয়ভাবে FCM SDK দ্বারা পরিচালিত হয়৷
• Data messages, which are handled by the client app.

Notification messages contain a predefined set of user-visible keys. Data messages, by contrast, contain only your user-defined custom key-value pairs. Notification messages can contain an optional data payload. Maximum payload for both message types is 4096 bytes, except when sending messages from the Firebase console, which enforces a 1000 character limit.

Use notification messages when you want the FCM SDK to handle displaying a notification automatically when your app is running in the background. আপনি যখন আপনার নিজস্ব ক্লায়েন্ট অ্যাপ কোড দিয়ে বার্তাগুলি প্রক্রিয়া করতে চান তখন ডেটা বার্তাগুলি ব্যবহার করুন৷

FCM can send a notification message including an optional data payload. এই ধরনের ক্ষেত্রে, FCM বিজ্ঞপ্তি পেলোড প্রদর্শন করে এবং ক্লায়েন্ট অ্যাপ ডেটা পেলোড পরিচালনা করে।

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

For testing or for marketing and user re-engagement, you can send notification messages using the Firebase console . The Firebase console provides analytics-based A/B testing to help you refine and improve marketing messages.

অ্যাডমিন SDK বা FCM প্রোটোকল ব্যবহার করে প্রোগ্রাম্যাটিকভাবে বিজ্ঞপ্তি বার্তা পাঠাতে, বিজ্ঞপ্তি বার্তার ব্যবহারকারী-দৃশ্যমান অংশের জন্য কী-মানের বিকল্পগুলির প্রয়োজনীয় পূর্বনির্ধারিত সেট সহ notification কী সেট করুন। For example, here is a JSON-formatted notification message in an IM app. The user can expect to see a message with the title "Portugal vs. Denmark" and the text "great match!" ডিভাইসে:

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

অ্যাপ্লিকেশানটি ব্যাকগ্রাউন্ডে থাকলে বিজ্ঞপ্তি বার্তাগুলি বিজ্ঞপ্তি ট্রেতে বিতরণ করা হয়। For apps in the foreground, messages are handled by a callback function.

See the HTTP v1 Protocol notification object reference documentation for the full list of predefined keys available for building notification messages.

Data messages

Set the appropriate key with your custom key-value pairs to send a data payload to the client app.

For example, here is a JSON-formatted message in the same IM app as above, where the information is encapsulated in the common data key and the client app is expected to interpret the content:

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

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

Encryption for data messages

The Android Transport Layer (see FCM architecture ) uses point-to-point encryption. Depending on your needs, you may decide to add end-to-end encryption to data messages. FCM does not provide an end-to-end solution. However, there are external solutions available such as Capillary or DTLS .

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

প্রোগ্রামগতভাবে বা Firebase কনসোলের মাধ্যমে, আপনি কাস্টম কী-মানের জোড়ার ঐচ্ছিক পেলোড ধারণ করে এমন বিজ্ঞপ্তি বার্তা পাঠাতে পারেন। In the Notifications composer , use the Custom data fields in Advanced options .

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

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

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

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

Customizing a message across platforms

The Firebase Admin SDK and the FCM v1 HTTP protocol both allow your message requests to set all fields available in the message object. এর মধ্যে রয়েছে:

• a common set of fields to be interpreted by all app instances that receive the message.
• platform-specific sets of fields, such as AndroidConfig and WebpushConfig , interpreted only by app instances running on the specified platform.

Platform-specific blocks give you flexibility to customize messages for different platforms to ensure that they are handled correctly when received. The FCM backend will take all specified parameters into account and customize the message for each platform.

When to use common fields

Use common fields when you're:

• Targeting app instances on all platforms — Apple, Android, and web
• Sending messages to topics

All app instances, regardless of platform, can interpret the following common fields:

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

When to use platform-specific fields

Use platform-specific fields when you want to:

• Send fields only to particular platforms
• Send platform-specific fields in addition to the common fields

Whenever you want to send values only to particular platforms, don't use common fields; use platform-specific fields. For example, to send a notification only to Apple platforms and web but not to Android, you must use two separate sets of fields, one for Apple and one for web.

When you are sending messages with specific delivery options , use platform-specific fields to set them. You can specify different values per platform if you want. However, even when you want to set essentially the same value across platforms, you must use platform-specific fields. This is because each platform may interpret the value slightly differently—for example, time-to-live is set on Android as an expiration time in seconds, while on Apple it is set as an expiration date .

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.

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

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.

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.

• উচ্চ অগ্রাধিকার. 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

Life critical use cases

The FCM APIs are not designed for emergency alerts or other high-risk activities where the use or failure of the APIs could result in death, personal injury, or environmental damage (such as the operation of nuclear facilities, air traffic control, or life support systems). Any such use is expressly prohibited under Section 4. a. 7 of the Terms of Service. You are solely responsible for managing your app's compliance with the Terms, and any damages resulting from your noncompliance. Google provides the APIs "as is," and reserves the right to discontinue the APIs or any portion or feature or your access thereto, for any reason and at any time, without liability or other obligation to you or your users.

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
• ক্যালেন্ডার ইভেন্ট

Another advantage of specifying the lifespan of a message is that FCM doesn't apply collapsible message throttling to messages with a time-to-live value of 0 seconds. FCM provides best effort handling of 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.

থ্রটলিং এবং কোটা

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. The types of limits and quotas described in this section help us balance these important factors.

Downstream message throttling

The HTTP v1 API introduced per-project, per-minute quotas for downstream messaging. The default quota of 600k messages per minute covers over 99% of FCM developers while protecting the stability of the system and minimizing the impact of spiky projects.

Spiky traffic patterns can result in quota exceeded errors. In an over quota scenario, the system serves HTTP status code 429 (QUOTA_EXCEEDED) until the quota is refilled in the following minute. 429 responses may also be returned in overload situations, so you are strongly encouraged to handle 429s according to published recommendations .

উল্লেখ্য যে:

• The downstream quota measures messages, not requests.
• Client errors (HTTP status code 400-499) are counted (excluding 429s).
• Quotas are per-minute, but these minutes are not aligned to the clock.

Monitoring quota

You can view quota, usage, and errors on the Google Cloud Console:

1. Google Cloud কনসোলে যান
2. Select APIs & services
3. From the table list, select Firebase Cloud Messaging API
4. Select QUOTA & SYSTEM LIMITS .

NOTE: These graphs are not precisely time aligned with quota minutes, meaning 429s may be served when traffic appears to be below quota.

কোটা বাড়ানোর অনুরোধ করছি

Before requesting a quota increase, ensure that:

• Your usage is regularly ≥ 80% of quota for at least 5 consecutive minutes per day.
• You have < 5% client error ratio, especially during peak traffic.
• You adhere to the best practices for sending messages at scale .

If you meet these criteria, you can submit a quota increase request for up to +25% and FCM will make every practical effort to fulfill the request (no increase can be guaranteed).

If you need more downstream messaging quota due to an impending launch or temporary event, request your quota at least 15 days in advance to allow sufficient time to handle the request. For large requests (>18M messages per minute), at least 30 days of notice is required. Launches and special event requests are still subject to the client error ratio and best practices requirements.

See also the FAQ about FCM quotas .

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.

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 the system. For each project, FCM allows 2500 connections in parallel.

For upstream messaging with XMPP, FCM limits 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.

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

Android এর জন্য, আপনি একটি ডিভাইসে 240টি বার্তা/মিনিট এবং 5,000টি বার্তা/ঘন্টা পাঠাতে পারেন৷ 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.

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.

VPN interactions and bypassability

Firebase Cloud Messaging takes various steps to ensure that the push messaging connection from the phone to the server is reliable and available as often as possible. The use of a VPN complicates this effort.

VPNs mask the underlying information that FCM needs to tune its connection to maximize reliability & battery life. In some cases VPNs actively break long lived connections resulting in a bad user experience due to missed or delayed messages or a high battery cost. When the VPN is configured to allow us to do so, we bypass the VPN using an encrypted connection (over the base network wifi or LTE) so as to ensure a reliable, battery friendly experience. FCM 's usage of bypassable VPNs is specific to the FCM Push Notification channel. Other FCM traffic, such as registration traffic, uses the VPN if it is active. When the FCM connection bypasses the VPN it loses additional benefits the VPN may provide, such as IP masking.

Different VPNs will have different methods for controlling whether or not it can be bypassed. Consult the documentation for your specific VPN for instructions.

If the VPN is not configured to be bypassable then Firebase Cloud Messaging will use the VPN network in order to connect to the server. This may result in periods of time where messages are delayed and may result in more battery usage as Cloud Messaging works to maintain the connection over the VPN connection.

শংসাপত্র

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