আপলোড অপশন
অ্যান্ড্রয়েড ওভার দ্য এয়ার API আপনাকে একটি নতুন প্যাকেজ সংস্থান তৈরি করতে প্যাকেজ ডেটা আপলোড করার অনুমতি দেয়। এইগুলি হল ওটিএ প্যাকেজ যা এক বা একাধিক কনফিগারেশনের সাথে যুক্ত হতে পারে যাতে আপডেটটি ডিভাইসগুলিতে বিতরণ করা হয়।
আমরা লিনাক্স এবং উইন্ডোজের জন্য একটি বাইনারি সরবরাহ করি যাতে আপনি নীচে বর্ণিত প্রোটোকলগুলি প্রয়োগ করার পরিবর্তে পুনরায় ব্যবহারযোগ্য প্যাকেজ আপলোডগুলি ব্যবহার করতে পারেন। আপনি যদি আরও গভীর সংহতকরণের জন্য চান তবে অনুগ্রহ করে নীচে বর্ণিত প্রোটোকলগুলির একটি ব্যবহার করুন৷
লিনাক্স
Linux এর জন্য Android Over The Air API v1 আপলোডার ক্লায়েন্ট ডাউনলোড করুন ।
উইন্ডোজ
Windows এর জন্য Android Over The Air API v1 আপলোডার ক্লায়েন্ট ডাউনলোড করুন ।
এটি ব্যবহার করার জন্য, আপনাকে প্রথমে একটি পরিষেবা অ্যাকাউন্ট তৈরি করতে হবে এবং সেই অ্যাকাউন্টের জন্য একটি JSON কী ফাইল পেতে হবে। এখানে অ্যাকাউন্ট তৈরি করার জন্য আমাদের গাইড দেখুন।
একবার আপনার কাছে বাইনারি এবং কী ফাইলটি হয়ে গেলে, আপনি কী ফাইল, আপনার স্থাপনা এবং আপনি যে প্যাকেজ আপলোড করছেন তা নির্দিষ্ট করতে কমান্ড লাইন বিকল্পগুলির সাথে এটি চালাতে পারেন। অনুগ্রহ করে সব অপশন দেখতে --help
ব্যবহার করুন।
প্রোটোকল আপলোড করুন
আপনি নিম্নলিখিত উপায়ে আপলোড অনুরোধ করতে পারেন. X-Goog-Upload-Protocol
অনুরোধ শিরোনামের সাথে আপনি যে পদ্ধতিটি ব্যবহার করছেন তা নির্দিষ্ট করুন।
- মাল্টিপার্ট আপলোড :
X-Goog-Upload-Protocol: multipart
। ছোট ফাইল এবং মেটাডেটা দ্রুত স্থানান্তরের জন্য; ফাইলটিকে মেটাডেটা সহ স্থানান্তর করে যা এটি বর্ণনা করে, সমস্ত একটি একক অনুরোধে। - পুনঃসূচনাযোগ্য আপলোড :
X-Goog-Upload-Protocol: resumable
। নির্ভরযোগ্য স্থানান্তরের জন্য, বিশেষ করে বড় ফাইলগুলির সাথে গুরুত্বপূর্ণ। এই পদ্ধতির সাহায্যে, আপনি একটি সেশন শুরু করার অনুরোধ ব্যবহার করেন, যা ঐচ্ছিকভাবে মেটাডেটা অন্তর্ভুক্ত করতে পারে। এটি বেশিরভাগ অ্যাপ্লিকেশনের জন্য ব্যবহার করার জন্য একটি ভাল কৌশল, কারণ এটি আপলোড প্রতি একটি অতিরিক্ত HTTP অনুরোধের খরচে ছোট ফাইলগুলির জন্যও কাজ করে।
মাল্টিপার্ট আপলোড
সংযোগ ব্যর্থ হলে আপনি যে ডেটা পাঠাচ্ছেন তা সম্পূর্ণরূপে আবার আপলোড করার জন্য যথেষ্ট ছোট হলে এটি একটি ভাল পছন্দ।
মাল্টিপার্ট আপলোড ব্যবহার করতে, /upload/package URI-তে একটি POST
অনুরোধ করুন এবং X-Goog-Upload-Protocol
multipart
সেট করুন।
মাল্টিপার্ট আপলোড রিকোয়েস্ট করার সময় ব্যবহার করা টপ-লেভেল HTTP হেডারগুলির মধ্যে রয়েছে:
-
Content-Type
. মাল্টিপার্ট/সম্পর্কিত সেট করুন এবং অনুরোধের অংশগুলি সনাক্ত করতে আপনি যে সীমানা স্ট্রিং ব্যবহার করছেন তা অন্তর্ভুক্ত করুন। -
Content-Length
। অনুরোধের অংশে মোট বাইট সংখ্যা সেট করুন।
অনুরোধের মূল অংশটি একটি multipart/related
বিষয়বস্তুর প্রকার [ RFC2387 ] হিসাবে ফর্ম্যাট করা হয়েছে এবং ঠিক দুটি অংশ রয়েছে৷ অংশগুলি একটি সীমানা স্ট্রিং দ্বারা চিহ্নিত করা হয়, এবং চূড়ান্ত সীমানা স্ট্রিং দুটি হাইফেন দ্বারা অনুসরণ করা হয়।
মাল্টিপার্ট অনুরোধের প্রতিটি অংশের জন্য একটি অতিরিক্ত Content-Type
শিরোনাম প্রয়োজন:
- মেটাডেটা অংশ: প্রথমে আসতে হবে, এবং
Content-Type
অবশ্যইapplication/json
হতে হবে। - মিডিয়া অংশ: দ্বিতীয় আসতে হবে, এবং
Content-Type
অবশ্যইapplication/zip
হতে হবে।
উদাহরণ: মাল্টিপার্ট আপলোড
নীচের উদাহরণটি Android ওভার দ্য এয়ার API-এর জন্য একটি মাল্টিপার্ট আপলোড অনুরোধ দেখায়।
POST /upload/package HTTP/1.1 Host: androidovertheair.googleapis.com Authorization: Bearer your_auth_token Content-Type: multipart/related; boundary=BOUNDARY Content-Length: number_of_bytes_in_entire_request_body --BOUNDARY Content-Type: application/json; charset=UTF-8 {"deployment": "id", "package_title": "title" } --BOUNDARY Content-Type: application/zip; charset=UTF-8 Package ZIP --BOUNDARY--
অনুরোধ সফল হলে, সার্ভার HTTP 200 OK
স্ট্যাটাস কোড ফেরত দেয়
HTTP/1.1 200
এটি সহজে সম্পন্ন করার একটি উপায় হল curl এবং oauth2l ব্যবহার করা। নীচে একটি নমুনা অনুরোধ রয়েছে যা ধরে নেয় আপনি একটি পরিষেবা কী ব্যবহার করছেন (আরও তথ্যের জন্য কীভাবে আমাদের অনুমোদন দেখুন)।
উদাহরণ কার্ল অনুরোধ
JSON={"deployment": "id", "package_title": "title" } SERVICE_KEY_FILE=path to your service key json file curl \ -H "$(./oauth2l header --json $SERVICE_KEY_FILE android_partner_over_the_air)" \ -H "Host: androidovertheair.googleapis.com" \ -H "X-Goog-Upload-Protocol: multipart" \ -H "Content-Type: multipart/form-data" \ -F "json=$JSON;type=application/json" \ -F "data=@update.zip;type=application/zip" \ androidovertheair.googleapis.com/upload/package
পুনরায় শুরুযোগ্য আপলোড
আরও নির্ভরযোগ্যভাবে ডেটা ফাইল আপলোড করতে, আপনি পুনরায় শুরু করা আপলোড প্রোটোকল ব্যবহার করতে পারেন। এই প্রোটোকল আপনাকে একটি আপলোড ক্রিয়াকলাপ পুনরায় শুরু করার অনুমতি দেয় যোগাযোগ ব্যর্থতার পরে ডেটা প্রবাহে ব্যাঘাত ঘটায়। এটি বিশেষভাবে উপযোগী যদি আপনি বড় ফাইল স্থানান্তর করেন এবং নেটওয়ার্ক বাধা বা অন্য কিছু ট্রান্সমিশন ব্যর্থতার সম্ভাবনা বেশি থাকে, উদাহরণস্বরূপ, মোবাইল ক্লায়েন্ট অ্যাপ থেকে আপলোড করার সময়। এটি নেটওয়ার্ক ব্যর্থতার ক্ষেত্রে আপনার ব্যান্ডউইথের ব্যবহার কমাতে পারে কারণ আপনাকে শুরু থেকে বড় ফাইল আপলোডগুলি পুনরায় চালু করতে হবে না।
পুনরায় শুরুযোগ্য আপলোড প্রোটোকল বিভিন্ন কমান্ড ব্যবহার করে:
- একটি পুনরায় শুরু করা সেশন শুরু করুন । আপলোড URI-তে একটি প্রাথমিক অনুরোধ করুন যাতে মেটাডেটা অন্তর্ভুক্ত থাকে এবং একটি অনন্য পুনঃসূচনাযোগ্য আপলোড অবস্থান স্থাপন করে।
- পুনরায় শুরু করা সেশন URI সংরক্ষণ করুন । প্রাথমিক অনুরোধের প্রতিক্রিয়ায় ফিরে আসা সেশন URI সংরক্ষণ করুন; আপনি এই সেশনে অবশিষ্ট অনুরোধের জন্য এটি ব্যবহার করবেন।
- ফাইলটি আপলোড করুন । জিপ ফাইলের সমস্ত বা অংশ পুনরায় শুরু করা সেশন ইউআরআই-এ পাঠান।
এছাড়াও, যে অ্যাপগুলি পুনঃসূচনাযোগ্য আপলোড ব্যবহার করে একটি বাধাপ্রাপ্ত আপলোড পুনরায় শুরু করার জন্য কোড থাকতে হবে৷ যদি একটি আপলোড বাধাপ্রাপ্ত হয়, তাহলে কতটা ডেটা সফলভাবে প্রাপ্ত হয়েছে তা খুঁজে বের করুন এবং তারপর সেই বিন্দু থেকে আপলোড পুনরায় শুরু করুন৷
দ্রষ্টব্য: একটি আপলোড ইউআরআই 3 দিন পরে শেষ হয়ে যায়।
ধাপ 1: একটি পুনরায় শুরু করা সেশন শুরু করুন
একটি পুনঃসূচনাযোগ্য আপলোড শুরু করতে, /upload/package URI-তে একটি POST
অনুরোধ করুন এবং X-Goog-Upload-Protocol
resumable
সেট করুন৷
এই সূচনাকারী অনুরোধের জন্য, শরীরে শুধুমাত্র মেটাডেটা থাকতে হবে; আপনি পরবর্তী অনুরোধে যে ফাইলটি আপলোড করতে চান তার প্রকৃত বিষয়বস্তু স্থানান্তর করবেন।
প্রাথমিক অনুরোধের সাথে নিম্নলিখিত HTTP শিরোনামগুলি ব্যবহার করুন:-
X-Goog-Upload-Header-Content-Type
। এটি আপলোড করা ফাইলের বিষয়বস্তু-প্রকার এবংapplication/zip
এ সেট করা আবশ্যক। -
X-Goog-Upload-Command
।start
করতে সেট করুন -
X-Goog-Upload-Header-Content-Length
। পরবর্তী অনুরোধে স্থানান্তরিত করার জন্য আপলোড ডেটার বাইটের সংখ্যা সেট করুন। এই অনুরোধের সময় দৈর্ঘ্য অজানা হলে, আপনি এই শিরোনামটি বাদ দিতে পারেন। -
Content-Type
. এটি মেটাডেটার বিষয়বস্তু-প্রকার এবং অবশ্যইapplication/json
এ সেট করতে হবে। -
Content-Length
। এই প্রাথমিক অনুরোধের মূল অংশে প্রদত্ত বাইটের সংখ্যা সেট করুন।
উদাহরণ: পুনঃসূচনাযোগ্য অধিবেশন শুরুর অনুরোধ
নিম্নলিখিত উদাহরণটি দেখায় যে কীভাবে অ্যান্ড্রয়েড ওভার দ্য এয়ার এপিআই-এর জন্য একটি পুনঃসূচনাযোগ্য সেশন শুরু করতে হয়।
POST /upload/package HTTP/1.1 Host: android/over-the-air.googleapis.com Authorization: Bearer your_auth_token Content-Length: 38 Content-Type: application/json; charset=UTF-8 X-Goog-Upload-Command: start X-Goog-Upload-Header-Content-Type: application/zip X-Goog-Upload-Header-Content-Length: 2000000 {"deployment": "id", "package_title": "title" }
পরবর্তী বিভাগ বর্ণনা করে কিভাবে প্রতিক্রিয়া পরিচালনা করতে হয়।
ধাপ 2: পুনরায় শুরু করা সেশন URI সংরক্ষণ করুন
সেশন শুরুর অনুরোধ সফল হলে, API সার্ভার একটি HTTP 200 OK
স্ট্যাটাস কোড দিয়ে সাড়া দেয়। উপরন্তু, এটি একটি X-Goog-Upload-URL
শিরোনাম প্রদান করে যা আপনার পুনরায় শুরু করা সেশন URI নির্দিষ্ট করে। নীচের উদাহরণে দেখানো X-Goog-Upload-URL
শিরোনামটিতে একটি upload_id
ক্যোয়ারী প্যারামিটার অংশ রয়েছে যা এই সেশনের জন্য ব্যবহার করার জন্য অনন্য আপলোড আইডি দেয়৷ প্রতিক্রিয়াটিতে একটি X-Goog-Upload-Status
শিরোনামও রয়েছে, যা আপলোডের অনুরোধ বৈধ এবং গৃহীত হলে active
হবে৷ আপলোড প্রত্যাখ্যান করা হলে এই অবস্থা final
হতে পারে.
উদাহরণ: পুনরায় শুরু করা সেশন শুরুর প্রতিক্রিয়া
এখানে 1 ধাপে অনুরোধের প্রতিক্রিয়া রয়েছে:
HTTP/1.1 200 OK X-Goog-Upload-Status: active X-Goog-Upload-URL: androidovertheair.googleapis.com/?upload_id=xa298sd_sdlkj2 Content-Length: 0
X-Goog-Upload-URL
শিরোনামের মান, উপরের উদাহরণের প্রতিক্রিয়া হিসাবে দেখানো হয়েছে, প্রকৃত ফাইল আপলোড করার জন্য বা আপলোডের স্থিতি জিজ্ঞাসা করার জন্য আপনি HTTP এন্ডপয়েন্ট হিসাবে যে সেশন URI ব্যবহার করবেন।
সেশন URI কপি করুন এবং সংরক্ষণ করুন যাতে আপনি পরবর্তী অনুরোধের জন্য এটি ব্যবহার করতে পারেন।
ধাপ 3: ফাইলটি আপলোড করুন
ফাইলটি আপলোড করতে, আপলোড URI-তে একটি POST
অনুরোধ পাঠান যা আপনি আগের ধাপে পেয়েছেন। আপলোড অনুরোধের বিন্যাস হল:
POST session_uri
পুনঃসূচনাযোগ্য ফাইল আপলোডের অনুরোধ করার সময় ব্যবহার করা HTTP শিরোনামগুলির মধ্যে রয়েছে:
-
Content-Length
। আপনি এই অনুরোধে আপলোড করছেন এমন বাইটের সংখ্যায় এটি সেট করুন, যা সাধারণত আপলোড ফাইলের আকার। -
X-Goog-Upload-Command
।upload
এবংfinalize
করতে এটি সেট করুন। -
X-Goog-Upload-Offset
। এটি অফসেট নির্দিষ্ট করে যা বাইট লিখতে হবে। নোট করুন যে ক্লায়েন্টদের অবশ্যই সিরিয়ালি বাইট আপলোড করতে হবে।
উদাহরণ: পুনরায় শুরুযোগ্য ফাইল আপলোডের অনুরোধ
বর্তমান উদাহরণের জন্য সম্পূর্ণ 2,000,000 বাইট জিপ ফাইল আপলোড করার জন্য এখানে একটি পুনরায় শুরু করার অনুরোধ রয়েছে।
POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1 Host: androidovertheair.googleapis.com X-Goog-Upload-Protocol: resumable X-Goog-Upload-Command: upload, finalize X-Goog-Upload-Offset: 0 Content-Length: 2000000 Content-Type: application/zip bytes 0-1999999
অনুরোধটি সফল হলে, সার্ভার একটি HTTP 200 Ok
দিয়ে প্রতিক্রিয়া জানায়।
আপলোডের অনুরোধ বাধাগ্রস্ত হলে বা আপনি যদি একটি HTTP 503 Service Unavailable
বা সার্ভার থেকে অন্য কোনো 5xx
প্রতিক্রিয়া পান, তাহলে একটি বাধাপ্রাপ্ত আপলোড পুনরায় শুরু করুন- এ বর্ণিত পদ্ধতি অনুসরণ করুন।
খণ্ডে ফাইল আপলোড করা হচ্ছে
পুনঃসূচনাযোগ্য আপলোডের মাধ্যমে, আপনি একটি ফাইলকে খণ্ডে বিভক্ত করতে পারেন এবং প্রতিটি খণ্ডকে ক্রমানুসারে আপলোড করার জন্য একাধিক অনুরোধ পাঠাতে পারেন। এটি পছন্দের পদ্ধতি নয় কারণ অতিরিক্ত অনুরোধের সাথে কর্মক্ষমতা খরচ যুক্ত থাকে এবং এটি সাধারণত প্রয়োজন হয় না। আমরা সুপারিশ করি যে ক্লায়েন্টরা পেলোডের অবশিষ্ট সমস্ত বাইট আপলোড করুন এবং প্রতিটি upload
কমান্ডের সাথে finalize
কমান্ড অন্তর্ভুক্ত করুন।
যাইহোক, যেকোন একক অনুরোধে স্থানান্তরিত ডেটার পরিমাণ কমাতে আপনাকে চঙ্কিং ব্যবহার করতে হতে পারে। এটি আপনাকে লিগ্যাসি ব্রাউজারগুলির জন্য আপলোড অগ্রগতির ইঙ্গিত প্রদান করার মতো জিনিসগুলিও করতে দেয় যেখানে ডিফল্টরূপে আপলোড অগ্রগতি সমর্থন নেই৷
একটি বাধাপ্রাপ্ত আপলোড পুনরায় শুরু করুন
যদি একটি আপলোড অনুরোধ একটি প্রতিক্রিয়া পাওয়ার আগে বন্ধ করা হয় বা আপনি যদি সার্ভার থেকে একটি HTTP 503 Service Unavailable
প্রতিক্রিয়া পান, তাহলে আপনাকে বাধাপ্রাপ্ত আপলোড পুনরায় শুরু করতে হবে৷ এটা করতে:
- অনুরোধ স্ট্যাটাস.
X-Goog-Upload-Command
query
করে আপলোড URI-তে একটি অনুরোধ জারি করে আপলোডের বর্তমান স্থিতি জিজ্ঞাসা করুন।দ্রষ্টব্য: আপনি অংশগুলির মধ্যে স্থিতির জন্য অনুরোধ করতে পারেন, শুধুমাত্র আপলোড বাধাগ্রস্ত হলে নয়৷ এটি দরকারী, উদাহরণস্বরূপ, আপনি যদি লিগ্যাসি ব্রাউজারগুলির জন্য আপলোডের অগ্রগতির ইঙ্গিতগুলি দেখাতে চান৷
- আপলোড করা বাইট সংখ্যা পান. স্ট্যাটাস কোয়েরি থেকে প্রতিক্রিয়া প্রক্রিয়া করুন। সার্ভারটি এখন পর্যন্ত কত বাইট পেয়েছে তা উল্লেখ করতে তার প্রতিক্রিয়াতে
X-Goog-Upload-Size-Received
শিরোনাম ব্যবহার করে৷ - অবশিষ্ট ডেটা আপলোড করুন। অবশেষে, এখন আপনি যেখানে অনুরোধটি পুনরায় শুরু করবেন তা জানেন, অবশিষ্ট ডেটা বা বর্তমান অংশ পাঠান। মনে রাখবেন যে উভয় ক্ষেত্রেই আপনাকে অবশিষ্ট ডেটাকে একটি পৃথক অংশ হিসাবে বিবেচনা করতে হবে, তাই আপনি যখন আপলোড পুনরায় শুরু করবেন তখন আপনাকে সঠিক অফসেটে
X-Goog-Upload-Offset
হেডার সেট করতে হবে।
উদাহরণ: একটি বাধাপ্রাপ্ত আপলোড পুনরায় শুরু করা
1) আপলোড স্থিতি অনুরোধ.
POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1 Host: androidovertheair.googleapis.com X-Goog-Upload-Command: query
সমস্ত কমান্ডের মতো, ক্লায়েন্টকে অবশ্যই একটি ক্যোয়ারী কমান্ডের HTTP প্রতিক্রিয়াতে X-Goog-Upload-Status
শিরোনামটি পরীক্ষা করতে হবে। যদি শিরোনামটি উপস্থিত থাকে এবং মান active
না হয়, তাহলে আপলোড ইতিমধ্যেই বন্ধ হয়ে গেছে।
2) প্রতিক্রিয়া থেকে এখন পর্যন্ত আপলোড করা বাইটের সংখ্যা বের করুন।
সার্ভারের প্রতিক্রিয়া X-Goog-Upload-Size-Received
হেডার ব্যবহার করে নির্দেশ করে যে এটি এখন পর্যন্ত ফাইলের প্রথম 43 বাইট পেয়েছে।
HTTP/1.1 200 OK X-Goog-Upload-Status: active X-Goog-Upload-Size-Received: 42
3) আপলোডটি যেখান থেকে ছেড়ে গেছে সেখান থেকে পুনরায় শুরু করুন।
নিম্নলিখিত অনুরোধটি ফাইলের অবশিষ্ট বাইট পাঠিয়ে আপলোড পুনরায় শুরু করে, বাইট 43 থেকে শুরু হয়।
POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1 Host: androidovertheair.googleapis.com X-Goog-Upload-Command: upload, finalize Content-Length: 1999957 X-Goog-Upload-Offset: 43 bytes 43-1999999
সেরা অনুশীলন
মিডিয়া আপলোড করার সময়, ত্রুটি পরিচালনার সাথে সম্পর্কিত কিছু সেরা অনুশীলন সম্পর্কে সচেতন হওয়া সহায়ক।
- সংযোগ বিঘ্ন বা যেকোনো
5xx
ত্রুটির কারণে ব্যর্থ হওয়া আপলোডগুলি পুনরায় শুরু করুন বা পুনরায় চেষ্টা করুন:-
500 Internal Server Error
-
502 Bad Gateway
-
503 Service Unavailable
-
504 Gateway Timeout
-
- আপলোডের অনুরোধগুলি পুনরায় শুরু করার সময় বা পুনরায় চেষ্টা করার সময় কোনো
5xx
সার্ভার ত্রুটি ফেরত হলে একটি সূচকীয় ব্যাকঅফ কৌশল ব্যবহার করুন। একটি সার্ভার ওভারলোড হচ্ছে যদি এই ত্রুটি ঘটতে পারে. সূচকীয় ব্যাকঅফ উচ্চ পরিমাণের অনুরোধ বা ভারী নেটওয়ার্ক ট্র্যাফিকের সময়কালে এই ধরণের সমস্যাগুলি উপশম করতে সহায়তা করতে পারে। - অন্যান্য ধরণের অনুরোধগুলি সূচকীয় ব্যাকঅফ দ্বারা পরিচালনা করা উচিত নয়, তবে আপনি এখনও তাদের অনেকগুলি পুনরায় চেষ্টা করতে পারেন৷ এই অনুরোধগুলি পুনরায় চেষ্টা করার সময়, আপনি তাদের পুনরায় চেষ্টা করার সংখ্যা সীমিত করুন। উদাহরণস্বরূপ, একটি ত্রুটি রিপোর্ট করার আগে আপনার কোড 10 বার বা তার কম চেষ্টা করতে পারে।
- শুরু থেকে সম্পূর্ণ আপলোড শুরু করে পুনরায় শুরুযোগ্য আপলোড করার সময়
404 Not Found
ত্রুটিগুলি হ্যান্ডেল করুন।
সূচকীয় ব্যাকঅফ
এক্সপোনেনশিয়াল ব্যাকঅফ হল নেটওয়ার্ক অ্যাপ্লিকেশনগুলির জন্য একটি স্ট্যান্ডার্ড ত্রুটি পরিচালনার কৌশল যেখানে ক্লায়েন্ট পর্যায়ক্রমে একটি ক্রমবর্ধমান সময়ের সাথে একটি ব্যর্থ অনুরোধ পুনঃপ্রচার করে। যদি উচ্চ পরিমাণে অনুরোধ বা ভারী নেটওয়ার্ক ট্র্যাফিক সার্ভারের ত্রুটিগুলি ফেরত দেয়, তাহলে সূচকীয় ব্যাকঅফ সেই ত্রুটিগুলি পরিচালনা করার জন্য একটি ভাল কৌশল হতে পারে। বিপরীতভাবে, এটি নেটওয়ার্ক ভলিউম বা প্রতিক্রিয়া সময়ের সাথে সম্পর্কিত নয় এমন ত্রুটিগুলি মোকাবেলার জন্য একটি প্রাসঙ্গিক কৌশল নয়, যেমন অবৈধ অনুমোদনের শংসাপত্র বা ফাইল পাওয়া যায়নি ত্রুটি৷
সঠিকভাবে ব্যবহার করা হলে, সূচকীয় ব্যাকঅফ ব্যান্ডউইথ ব্যবহারের দক্ষতা বাড়ায়, সফল প্রতিক্রিয়া পাওয়ার জন্য প্রয়োজনীয় অনুরোধের সংখ্যা হ্রাস করে এবং সমসাময়িক পরিবেশে অনুরোধের থ্রুপুট সর্বাধিক করে।
সাধারণ সূচকীয় ব্যাকঅফ বাস্তবায়নের জন্য প্রবাহ নিম্নরূপ:
- API এ একটি অনুরোধ করুন।
- একটি
HTTP 503
প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত। - 1 সেকেন্ড + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার চেষ্টা করুন।
- একটি
HTTP 503
প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত। - 2 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
- একটি
HTTP 503
প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত। - 4 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
- একটি
HTTP 503
প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত। - 8 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
- একটি
HTTP 503
প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত। - 16 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
- থামো। একটি ত্রুটি রিপোর্ট বা লগ.
উপরের প্রবাহে, এলোমেলো_সংখ্যা_মিলিসেকেন্ড হল 1000 এর চেয়ে কম বা সমান মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা। এটি প্রয়োজনীয়, কারণ একটি ছোট এলোমেলো বিলম্ব প্রবর্তন লোডকে আরও সমানভাবে বিতরণ করতে সাহায্য করে এবং সার্ভারের স্ট্যাম্পিং হওয়ার সম্ভাবনা এড়াতে সহায়তা করে। এলোমেলো_সংখ্যা_মিলিসেকেন্ডের মান প্রতিটি অপেক্ষার পরে পুনরায় সংজ্ঞায়িত করা আবশ্যক।
দ্রষ্টব্য: অপেক্ষা সর্বদা (2 ^ n) + এলোমেলো_সংখ্যা_মিলিসেকেন্ড, যেখানে n হল একটি একঘেয়ে ক্রমবর্ধমান পূর্ণসংখ্যা যা প্রাথমিকভাবে 0 হিসাবে সংজ্ঞায়িত করা হয়। প্রতিটি পুনরাবৃত্তির (প্রতিটি অনুরোধ) জন্য পূর্ণসংখ্যা 1 দ্বারা বৃদ্ধি করা হয়।
n 5 হলে অ্যালগরিদম শেষ হতে সেট করা হয়। এই সিলিং ক্লায়েন্টদের অসীমভাবে পুনরায় চেষ্টা করতে বাধা দেয় এবং একটি অনুরোধ "একটি পুনরুদ্ধারযোগ্য ত্রুটি" বলে গণ্য হওয়ার আগে প্রায় 32 সেকেন্ডের মোট বিলম্ব হয়। একটি বৃহত্তর সর্বাধিক সংখ্যক পুনঃপ্রয়াস ঠিক আছে, বিশেষ করে যদি একটি দীর্ঘ আপলোড চলছে; শুধু যুক্তিসঙ্গত কিছুতে পুনঃপ্রচেষ্টা বিলম্ব ক্যাপ করতে ভুলবেন না, বলুন, এক মিনিটেরও কম।