Check out what’s new from Firebase at Google I/O 2022. Learn more

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

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

  • 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 প্রোটোকল।
  • XMPP সার্ভার প্রোটোকল। মনে রাখবেন যে আপনি যদি আপনার ক্লায়েন্ট অ্যাপ্লিকেশনগুলি থেকে আপস্ট্রিম মেসেজিং ব্যবহার করতে চান তবে আপনাকে অবশ্যই XMPP ব্যবহার করতে হবে।

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

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

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