Google 致力于为黑人社区推动种族平等。查看具体举措

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

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

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

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

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

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

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

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

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

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

FCM- এর জন্য Firebase Admin SDK

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

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

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

Firebase এডমিন SDK এর সেট আপ করতে, দেখতে আপনার সার্ভারে Firebase এডমিন SDK এর যোগ করুন । যদি আপনি ইতিমধ্যেই একটি Firebase প্রকল্পের থাকে, তাহলে দিয়ে শুরু SDK এর যোগ করুন । এর পরে, একবার Firebase এডমিন SDK এর ইনস্টল করা, আপনি যুক্তিবিজ্ঞান লেখা শুরু করতে পারেন বিল্ড পাঠান অনুরোধ

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

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

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

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

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

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

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

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

এফসিএম বার্তাগুলির জন্য জেএসএন পে-লোড এই ব্যতিক্রমগুলির সাথে এইচটিটিপি প্রোটোকলের অনুরূপ:

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

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

আপনার অ্যাপ্লিকেশন সার্ভার এফসিএম থেকে প্রাপ্ত প্রতিটি ডিভাইসের বার্তার জন্য, এটি একটি এসকে বার্তা প্রেরণ করা প্রয়োজন। এটি কখনই একটি 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>

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

একটি এফসিএম প্রতিক্রিয়াতে তিনটি সম্ভাব্য ফর্ম থাকতে পারে। প্রথমটি হ'ল নিয়মিত 'আক্ক' বার্তা। কিন্তু যখন প্রতিক্রিয়াটিতে একটি ত্রুটি রয়েছে, নীচে বর্ণিত বার্তাটি নিতে পারে এমন দুটি পৃথক রূপ রয়েছে।

ACK বার্তা

এফসিএম থেকে অ্যাপ সার্ভারে ACK / NACK বার্তা সম্বলিত একটি এক্সএমপিপি স্তম্ভ রয়েছে:

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

NACK বার্তা

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

  • একটি ন্যাক ত্রুটি কোড।
  • একটি ন্যাক ত্রুটি বর্ণনা।

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

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

<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 সংযোগ বার্তা পাঠানোর একটি নতুন সংযোগ প্রয়োজন হলে খোলার শুরু হবে। তবে আপনাকে মূল সংযোগটি উন্মুক্ত রাখতে হবে এবং সংযোগের উপরে আসা বার্তাগুলি গ্রহণ করা চালিয়ে যাওয়া উচিত (এবং সেগুলি ACCing করা হয়) —এফসিএম যখন প্রস্তুত থাকে তখন একটি সংযোগ শুরু করা পরিচালনা করে।

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

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