Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

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

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

  • FCM Google দ্বারা সরবরাহিত ব্যাকএন্ড।
  • আপনার অ্যাপ সার্ভার বা অন্যান্য বিশ্বস্ত সার্ভার পরিবেশ যেখানে যেমন আপনার সার্ভারের যুক্তিবিজ্ঞান রান Firebase জন্য মেঘ কার্যাবলী বা অন্য ক্লাউড পরিবেশের Google দ্বারা পরিচালিত।

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

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

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

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

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

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

FCM সার্ভারের সাথে ইন্টারঅ্যাক্ট করার জন্য বিকল্পগুলির মধ্যে রয়েছে:
  • Firebase এডমিন SDK এর, যার জন্য সমর্থন আছে নোড , জাভা , পাইথন , সি # , এবং যান
  • FCM HTTP- র v1 এ এপিআই , আরো নিরাপদ, অনুমোদন এবং নমনীয় সঙ্গে যা প্রোটোকল অপশনের তারিখ থেকে সবচেয়ে আপ হয়, ক্রস-প্ল্যাটফর্ম বার্তার সক্ষমতা (Firebase এডমিন SDK এর এই প্রোটোকল উপর ভিত্তি করে এবং তার সহজাত সুবিধার সব উপলব্ধ)।
  • উত্তরাধিকার HTTP- র প্রোটোকল।
  • পাওয়া XMPP সার্ভার প্রোটোকল। মনে রাখবেন যে আপনি যদি আপনার ক্লায়েন্ট অ্যাপ্লিকেশন থেকে আপস্ট্রিম মেসেজিং ব্যবহার করতে চান, তাহলে আপনাকে অবশ্যই XMPP ব্যবহার করতে হবে।

FCM- এর জন্য Firebase Admin SDK

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

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

অ্যাডমিন 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: XMPP বার্তাগুলিতে JSON বার্তাগুলি অন্তর্ভুক্ত।
  • সরল পাঠ্য
    • HTTP: সাধারণ পাঠ্য বার্তাগুলি HTTP POST হিসাবে পাঠানো হয়।
    • XMPP: সমর্থিত নয়।
  • মাল্টিকাস্ট ডাউনস্ট্রিম একাধিক রেজিস্ট্রেশন টোকেন পাঠান।
    • HTTP: JSON বার্তা বিন্যাসে সমর্থিত।
    • XMPP: সমর্থিত নয়।

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

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

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

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

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

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

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

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

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

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

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

একটি বিজ্ঞপ্তি বার্তার জন্য এখানে একটি 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 বার্তা

একটি বস্তু ত্রুটি ঘটেছে, যা মধ্যে একজন নিয়মিত পাওয়া XMPP বার্তা message_type স্থিতি বার্তা "বস্তু" হয়। একটি ন্যাক বার্তায় রয়েছে:

  • একটি 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>

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

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. বার্তা / ACK প্রবাহিত।

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

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