了解 2023 年 Google I/O 大会上介绍的 Firebase 亮点。了解详情

আপনার সার্ভার পরিবেশ এবং FCM

Firebase ক্লাউড মেসেজিংয়ের সার্ভার সাইড দুটি উপাদান নিয়ে গঠিত:

  • Google দ্বারা প্রদত্ত FCM ব্যাকএন্ড ৷
  • আপনার অ্যাপ সার্ভার বা অন্যান্য বিশ্বস্ত সার্ভার পরিবেশ যেখানে আপনার সার্ভার লজিক চলে, যেমন ফায়ারবেসের জন্য ক্লাউড ফাংশন বা Google দ্বারা পরিচালিত অন্যান্য ক্লাউড পরিবেশ।

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

বিশ্বস্ত সার্ভার পরিবেশের জন্য প্রয়োজনীয়তা

আপনার অ্যাপ সার্ভার পরিবেশ অবশ্যই নিম্নলিখিত মানদণ্ড পূরণ করবে:

  • FCM ব্যাকএন্ডে সঠিকভাবে ফরম্যাট করা বার্তার অনুরোধ পাঠাতে সক্ষম।
  • অনুরোধগুলি পরিচালনা করতে এবং সূচকীয় ব্যাক-অফ ব্যবহার করে পুনরায় পাঠাতে সক্ষম।
  • সার্ভার অনুমোদনের শংসাপত্র এবং ক্লায়েন্ট রেজিস্ট্রেশন টোকেন নিরাপদে সঞ্চয় করতে সক্ষম।
  • XMPP প্রোটোকলের জন্য (যদি ব্যবহার করা হয়), সার্ভারটি অবশ্যই বার্তা আইডি তৈরি করতে সক্ষম হবে যাতে এটি প্রেরিত প্রতিটি বার্তাকে স্বতন্ত্রভাবে সনাক্ত করতে পারে (FCM HTTP ব্যাকএন্ড বার্তা আইডি তৈরি করে এবং প্রতিক্রিয়াতে সেগুলি ফেরত দেয়)। XMPP মেসেজ আইডি প্রেরকের আইডি প্রতি অনন্য হওয়া উচিত।

একটি সার্ভার বিকল্প নির্বাচন করা হচ্ছে

আপনাকে FCM সার্ভারগুলির সাথে ইন্টারঅ্যাক্ট করার একটি উপায় নির্ধারণ করতে হবে: হয় Firebase অ্যাডমিন SDK বা কাঁচা প্রোটোকল ব্যবহার করে৷ জনপ্রিয় প্রোগ্রামিং ভাষা জুড়ে এর সমর্থন এবং প্রমাণীকরণ এবং অনুমোদন পরিচালনার জন্য এর সুবিধার পদ্ধতির কারণে, Firebase অ্যাডমিন SDK হল প্রস্তাবিত পদ্ধতি।

FCM সার্ভারগুলির সাথে ইন্টারঅ্যাক্ট করার বিকল্পগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে:

  • ফায়ারবেস অ্যাডমিন SDK, যা Node , Java , Python , C# এবং Go- এর জন্য সমর্থন করে।
  • FCM HTTP v1 API , যা প্রোটোকল বিকল্পগুলির মধ্যে সবচেয়ে আপ টু ডেট, আরও নিরাপদ অনুমোদন এবং নমনীয় ক্রস-প্ল্যাটফর্ম মেসেজিং ক্ষমতা সহ (Firebase Admin SDK এই প্রোটোকলের উপর ভিত্তি করে এবং এর সমস্ত অন্তর্নিহিত সুবিধা প্রদান করে)। যেহেতু নতুন বৈশিষ্ট্যগুলি সাধারণত শুধুমাত্র HTTP v1 API-তে যোগ করা হয়, তাই আমরা বেশিরভাগ ব্যবহারের ক্ষেত্রে এই API ব্যবহার করার পরামর্শ দিই।
  • উত্তরাধিকার HTTP প্রোটোকল। নতুন প্রজেক্টগুলিকে লিগ্যাসি প্রোটোকলের পরিবর্তে FCM v1 HTTP API গ্রহণ করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।
  • লিগ্যাসি XMPP সার্ভার প্রোটোকল। নতুন প্রজেক্টগুলিকে লিগ্যাসি প্রোটোকলের পরিবর্তে FCM v1 HTTP API গ্রহণ করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।

FCM এর জন্য Firebase অ্যাডমিন SDK

অ্যাডমিন এফসিএম এপিআই ব্যাকএন্ডের সাথে প্রমাণীকরণ পরিচালনা করে এবং বার্তা পাঠানো এবং বিষয় সাবস্ক্রিপশন পরিচালনার সুবিধা দেয়। Firebase অ্যাডমিন SDK-এর মাধ্যমে, আপনি করতে পারেন:

  • পৃথক ডিভাইসে বার্তা পাঠান
  • এক বা একাধিক বিষয়ের সাথে মেলে এমন বিষয় এবং শর্ত বিবৃতিতে বার্তা পাঠান।
  • বিষয়গুলিতে এবং থেকে ডিভাইসগুলি সদস্যতা এবং সদস্যতা ত্যাগ করুন৷
  • বিভিন্ন লক্ষ্য প্ল্যাটফর্মের জন্য উপযোগী বার্তা পেলোড তৈরি করুন

Admin Node.js SDK ডিভাইস গ্রুপে বার্তা পাঠানোর পদ্ধতি প্রদান করে।

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

FCM সার্ভার প্রোটোকল

বর্তমানে FCM এই কাঁচা সার্ভার প্রোটোকল প্রদান করে:

আপনার অ্যাপ সার্ভার এই প্রোটোকলগুলিকে আলাদাভাবে বা একসাথে ব্যবহার করতে পারে৷ যেহেতু এটি একাধিক প্ল্যাটফর্মে বার্তা পাঠানোর জন্য সবচেয়ে আপ-টু-ডেট এবং সবচেয়ে নমনীয়, তাই যেখানেই সম্ভব সেখানে FCM HTTP v1 API সুপারিশ করা হয়। যদি আপনার প্রয়োজনীয়তার মধ্যে ডিভাইস থেকে সার্ভারে আপস্ট্রিম মেসেজিং অন্তর্ভুক্ত থাকে, তাহলে আপনাকে XMPP প্রোটোকল বাস্তবায়ন করতে হবে।

XMPP মেসেজিং HTTP মেসেজিং থেকে নিম্নলিখিত উপায়ে আলাদা:

  • আপস্ট্রিম/ডাউনস্ট্রিম বার্তা
    • HTTP: শুধুমাত্র ডাউনস্ট্রিম, ক্লাউড-টু-ডিভাইস।
    • XMPP: আপস্ট্রিম এবং ডাউনস্ট্রিম (ডিভাইস-টু-ক্লাউড, ক্লাউড-টু-ডিভাইস)।
  • মেসেজিং (সিঙ্ক্রোনাস বা অ্যাসিঙ্ক্রোনাস)
    • HTTP: সিঙ্ক্রোনাস। অ্যাপ সার্ভারগুলি HTTP POST অনুরোধ হিসাবে বার্তা পাঠায় এবং একটি প্রতিক্রিয়ার জন্য অপেক্ষা করে৷ এই প্রক্রিয়াটি সিঙ্ক্রোনাস এবং প্রতিক্রিয়া না পাওয়া পর্যন্ত প্রেরককে অন্য বার্তা পাঠাতে বাধা দেয়।
    • XMPP: অ্যাসিঙ্ক্রোনাস। অ্যাপ্লিকেশান সার্ভারগুলি অবিরাম XMPP সংযোগের মাধ্যমে সম্পূর্ণ লাইন গতিতে তাদের সমস্ত ডিভাইস থেকে বার্তা পাঠায়/গ্রহণ করে। XMPP সংযোগ সার্ভার অ্যাসিঙ্ক্রোনাসভাবে স্বীকৃতি বা ব্যর্থতার বিজ্ঞপ্তি পাঠায় (বিশেষ ACK এবং NACK JSON-এনকোডেড XMPP বার্তার আকারে)।
  • JSON
    • HTTP: JSON বার্তা HTTP POST হিসাবে পাঠানো হয়।
    • XMPP: JSON বার্তাগুলি XMPP বার্তাগুলিতে অন্তর্ভুক্ত।
  • প্লেইন টেক্সট
    • HTTP: সাধারণ পাঠ্য বার্তা HTTP POST হিসাবে পাঠানো হয়।
    • XMPP: সমর্থিত নয়।
  • মাল্টিকাস্ট ডাউনস্ট্রিম একাধিক নিবন্ধন টোকেন পাঠান.
    • HTTP: JSON বার্তা বিন্যাসে সমর্থিত।
    • XMPP: সমর্থিত নয়।

HTTP সার্ভার প্রোটোকল বাস্তবায়ন

একটি বার্তা পাঠাতে, অ্যাপ সার্ভার একটি HTTP শিরোনাম এবং JSON কী মান জোড়া নিয়ে গঠিত একটি HTTP বডি সহ একটি POST অনুরোধ জারি করে৷ শিরোনাম এবং শরীরের বিকল্পগুলির বিশদ বিবরণের জন্য, বিল্ড অ্যাপ সার্ভার অনুরোধ পাঠান দেখুন

XMPP সার্ভার প্রোটোকল বাস্তবায়ন

FCM বার্তাগুলির জন্য JSON পেলোড এই ব্যতিক্রমগুলি সহ HTTP প্রোটোকলের অনুরূপ:

  • একাধিক প্রাপকদের জন্য কোন সমর্থন নেই.
  • FCM ক্ষেত্র message_id যোগ করে, যা প্রয়োজন। এই আইডিটি একটি XMPP সংযোগে বার্তাটিকে অনন্যভাবে সনাক্ত করে। FCM থেকে ACK বা NACK অ্যাপ সার্ভার থেকে FCM-এ প্রেরিত একটি বার্তা সনাক্ত করতে message_id ব্যবহার করে। অতএব, এটি গুরুত্বপূর্ণ যে এই message_id শুধুমাত্র অনন্য ( প্রেরকের আইডি প্রতি) নয়, সর্বদা উপস্থিত থাকে৷
  • XMPP সার্ভার কী ব্যবহার করে FCM-এর সাথে একটি স্থায়ী সংযোগ অনুমোদন করতে। আরও তথ্যের জন্য অনুরোধ পাঠান অনুমোদন দেখুন.

নিয়মিত FCM বার্তা ছাড়াও, নিয়ন্ত্রণ বার্তা পাঠানো হয়, JSON অবজেক্টের message_type ক্ষেত্র দ্বারা নির্দেশিত। মানটি হয় 'ack' বা 'nack', অথবা 'নিয়ন্ত্রণ' (নীচের বিন্যাসগুলি দেখুন) হতে পারে। একটি অজানা message_type সহ যেকোনো FCM বার্তা আপনার সার্ভার উপেক্ষা করতে পারে৷

আপনার অ্যাপ সার্ভার FCM থেকে প্রাপ্ত প্রতিটি ডিভাইস বার্তার জন্য, এটি একটি ACK বার্তা পাঠাতে হবে। এটি একটি NACK বার্তা পাঠাতে হবে না. আপনি যদি কোনো বার্তার জন্য ACK না পাঠান, তাহলে পরের বার একটি নতুন XMPP সংযোগ স্থাপন করা হলে FCM এটিকে পুনরায় পাঠায়, যদি না বার্তাটি প্রথম মেয়াদ শেষ হয়৷

FCM প্রতিটি সার্ভার-টু-ডিভাইস বার্তার জন্য একটি ACK বা NACK পাঠায়। আপনি যদি উভয়ই না পান, এর মানে হল যে অপারেশনের মাঝখানে TCP সংযোগ বন্ধ হয়ে গেছে এবং আপনার সার্ভারকে বার্তাগুলি পুনরায় পাঠাতে হবে। বিস্তারিত জানার জন্য প্রবাহ নিয়ন্ত্রণ দেখুন।

সমস্ত বার্তা প্যারামিটারের তালিকার জন্য প্রোটোকল রেফারেন্স দেখুন।

বিন্যাস অনুরোধ

পেলোড সহ বার্তা — বিজ্ঞপ্তি বার্তা

এখানে একটি বিজ্ঞপ্তি বার্তার জন্য একটি XMPP স্তবক রয়েছে:

<message id="">
  <gcm xmlns="google:mobile:data">
  {
     "to":"REGISTRATION_ID",  // "to" replaces "registration_ids"
     "notification": {
        "title": "Portugal vs. Denmark”,
        "body”: "5 to 1”
      },
      "time_to_live":"600"
  }
  </gcm>
</message>

পেলোড সহ বার্তা — ডেটা বার্তা

এখানে একটি XMPP স্তবক রয়েছে যেখানে একটি অ্যাপ সার্ভার থেকে FCM-এ JSON বার্তা রয়েছে:

<message id="">
  <gcm xmlns="google:mobile:data">
  {
      "to":"REGISTRATION_ID",  // "to" replaces "registration_ids"
      "message_id":"m-1366082849205" // new required field
      "data":
      {
          "hello":"world",
      }
      "time_to_live":"600",
  }
  </gcm>
</message>

প্রতিক্রিয়া বিন্যাস

একটি FCM প্রতিক্রিয়া তিনটি সম্ভাব্য ফর্ম থাকতে পারে। প্রথমটি একটি নিয়মিত 'অ্যাক' বার্তা। কিন্তু যখন প্রতিক্রিয়াটিতে একটি ত্রুটি থাকে, তখন বার্তাটি 2টি ভিন্ন রূপ নিতে পারে, নীচে বর্ণিত।

ACK বার্তা

এখানে একটি XMPP স্তবক রয়েছে যেখানে FCM থেকে অ্যাপ সার্ভারে ACK/NACK বার্তা রয়েছে:

<message id="">
  <gcm xmlns="google:mobile:data">
  {
      "from":"REGID",
      "message_id":"m-1366082849205"
      "message_type":"ack"
  }
  </gcm>
</message>

NACK বার্তা

একটি NACK ত্রুটি হল একটি নিয়মিত XMPP বার্তা যেখানে message_type স্ট্যাটাস মেসেজ "nack"। একটি NACK বার্তায় রয়েছে:

  • একটি NACK ত্রুটি কোড।
  • একটি NACK ত্রুটি বিবরণ।

নিচে কিছু উদাহরণ দেওয়া হল।

খারাপ নিবন্ধন:

<message>
  <gcm xmlns="google:mobile:data">
  {
    "message_type":"nack",
    "message_id":"msgId1",
    "from":"SomeInvalidRegistrationToken",
    "error":"BAD_REGISTRATION",
    "error_description":"Invalid token on 'to' field: SomeInvalidRegistrationId"
  }
  </gcm>
</message>

অবৈধ JSON:

<message>
 <gcm xmlns="google:mobile:data">
 {
   "message_type":"nack",
   "message_id":"msgId1",
   "from":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
   "error":"INVALID_JSON",
   "error_description":"InvalidJson: JSON_TYPE_ERROR : Field \"time_to_live\" must be a JSON java.lang.Number: abc"
 }
 </gcm>
</message>

ডিভাইস বার্তা হার অতিক্রম করেছে:

<message id="...">
  <gcm xmlns="google:mobile:data">
  {
    "message_type":"nack",
    "message_id":"msgId1",
    "from":"REGID",
    "error":"DEVICE_MESSAGE_RATE_EXCEEDED",
    "error_description":"Downstream message rate exceeded for this registration id"
  }
  </gcm>
</message>

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

স্তবক ত্রুটি

আপনি নির্দিষ্ট ক্ষেত্রে একটি স্তবক ত্রুটি পেতে পারেন। একটি স্তবক ত্রুটি রয়েছে:

  • স্তবক ত্রুটি কোড।
  • স্তবক ত্রুটি বিবরণ (বিনামূল্যে পাঠ্য)।

উদাহরণ স্বরূপ:

<message id="3" type="error" to="123456789@fcm.googleapis.com/ABC">
  <gcm xmlns="google:mobile:data">
     {"random": "text"}
  </gcm>
  <error code="400" type="modify">
    <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
      InvalidJson: JSON_PARSING_ERROR : Missing Required Field: message_id\n
    </text>
  </error>
</message>

বার্তা নিয়ন্ত্রণ করুন

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

CONNECTION_DRAINING বার্তাটি এইরকম দেখাচ্ছে:

<message>
  <data:gcm xmlns:data="google:mobile:data">
  {
    "message_type":"control"
    "control_type":"CONNECTION_DRAINING"
  }
  </data:gcm>
</message>

CONNECTION_DRAINING বর্তমানে একমাত্র control_type সমর্থিত।

প্রবাহ নিয়ন্ত্রণ

FCM-এ প্রেরিত প্রতিটি বার্তা হয় একটি ACK বা একটি NACK প্রতিক্রিয়া পায়৷ যে বার্তাগুলি এই প্রতিক্রিয়াগুলির মধ্যে একটি পায়নি সেগুলি মুলতুবি বলে বিবেচিত হয়৷ যদি মুলতুবি থাকা বার্তার সংখ্যা 100-এ পৌঁছায়, অ্যাপ সার্ভারের উচিত নতুন বার্তা পাঠানো বন্ধ করা এবং FCM-এর কিছু বিদ্যমান মুলতুবি থাকা বার্তাগুলিকে চিত্র 1-এ দেখানো হিসাবে স্বীকার করার জন্য অপেক্ষা করা উচিত:

FCM এবং অ্যাপ সার্ভারের মধ্যে নিয়ন্ত্রণ প্রবাহের বিস্তারিত চিত্র

চিত্র 1. বার্তা/অ্যাক ফ্লো।

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

ACKs শুধুমাত্র একটি সংযোগের প্রসঙ্গে বৈধ। যদি কোনো বার্তা ACK করার আগে সংযোগটি বন্ধ হয়ে যায়, তাহলে অ্যাপ সার্ভারের FCM-এর জন্য অপেক্ষা করা উচিত যাতে এটি আবার ACK করার আগে আপস্ট্রিম বার্তাটি পুনরায় পাঠানো হয়। একইভাবে, সংযোগ বন্ধ হওয়ার আগে যে সমস্ত মুলতুবি বার্তাগুলির জন্য একটি ACK/NACK FCM থেকে পাওয়া যায়নি সেগুলি আবার পাঠানো উচিত।