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

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

• APNs ডকুমেন্টেশন
• বার্তা অগ্রাধিকার সেট করুন এবং পরিচালনা করুন (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টি বার্তার বিস্ফোরণে সংকোচনযোগ্য বার্তাগুলিকে সীমাবদ্ধ করি।

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

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 প্রকল্প থেকে নিম্নলিখিত শংসাপত্রগুলির প্রয়োজন হতে পারে: