আবার শুরু করা যায় এমন আপলোড

Google API-এর জন্য আবার শুরু করা যায় এমন আপলোড প্রোটোকল ব্যবহার করে আপনি আরও নির্ভরযোগ্যভাবে ভিডিও আপলোড করতে পারবেন। এই প্রোটোকল আপনাকে নেটওয়ার্ক ইন্টারাপশন বা অন্যান্য ট্রান্সমিশন ব্যর্থতার পরে আপলোড অপারেশন আবার শুরু করতে দেয়, এর ফলে নেটওয়ার্ক ব্যর্থ হলে সময় ও ব্যান্ডউইথ সাশ্রয় হয়।

নিম্নলিখিত যেকোনও ক্ষেত্রে আবার শুরু করা যায় এমন আপলোড ব্যবহার করা বিশেষভাবে উপযোগী:

• আপনি বড় ফাইল ট্রান্সফার করছেন।
• নেটওয়ার্ক বিঘ্নিত হওয়ার সম্ভাবনা বেশি।
• মোবাইল ডিভাইসের মতো কম ব্যান্ডউইথ বা ইন্টারনেট কানেকশন ঠিকভাবে কাজ করছে না এমন ডিভাইস থেকে আপলোড করা হচ্ছে।

এই নির্দেশিকা থেকে জানা যায় যে, কোনও অ্যাপ্লিকেশন, আপলোড করার প্রসেস আবার চালু করার সুবিধা ব্যবহার করে ভিডিও আপলোড করার জন্য HTTP অনুরোধের কোন ক্রম ব্যবহার করে। এই নির্দেশিকাটি মূলত সেইসব ডেভেলপারদের জন্য যারা Google API ক্লায়েন্ট লাইব্রেরি ব্যবহার করতে পারেন না, যার মধ্যে কিছু আবার আপলোড আবার শুরু করার জন্য নেটিভ সহায়তা প্রদান করে। আসলে, YouTube Data API - ভিডিও আপলোড করা সংক্রান্ত গাইড থেকে আপনি জানতে পারবেন যে কীভাবে Python-এর জন্য Google APIs ক্লায়েন্ট লাইব্রেরি ব্যবহার করে, আপলোড করার প্রসেস আবার চালু করার মাধ্যমে ভিডিও আপলোড করতে হয়।

মনে রাখবেন: HTTPS লগিং চালু থাকা Google API ক্লায়েন্ট লাইব্রেরির কোনও একটি ব্যবহার করে আপনি রিজুম করা যায় এমন আপলোডিং বা অন্য কোনও API অপারেশনের জন্য করা অনুরোধের সিরিজও দেখতে পাবেন। যেমন, Python-এর জন্য HTTP ট্রেস চালু করতে, httplib2 লাইব্রেরি ব্যবহার করুন:

httplib2.debuglevel = 4

ধাপ ১ - আবার শুরু করা যায় এমন সেশন শুরু করুন

আবার চালু করা যায় এমন ভিডিও আপলোড শুরু করতে, নিম্নলিখিত URL-এ POST অনুরোধ পাঠান। URL-এ, আপনার অনুরোধের জন্য উপযুক্ত মান হিসেবে part প্যারামিটারের মান সেট করুন। মনে রাখবেন যে প্যারামিটারের মান সেইসব অংশ শনাক্ত করে যেগুলিতে আপনার সেট করা প্রপার্টি আছে এবং এটি সেইসব অংশও শনাক্ত করে যেগুলি আপনি API রেসপন্সে অন্তর্ভুক্ত করতে চান। অনুরোধ URL-এ প্যারামিটার ভ্যালু অবশ্যই URL-এনকোড করা হতে হবে।

https://www.googleapis.com/upload/youtube/v3/videos?uploadType=resumable&part=PARTS

অনুরোধের বডি video রিসোর্সে সেট করুন। এছাড়াও, নিম্নলিখিত HTTP অনুরোধ হেডার সেট করুন:

• Authorization – অনুরোধের জন্য অনুমোদন টোকেন।
• Content-Length – অনুরোধের বডিতে দেওয়া বাইটের সংখ্যা। মনে রাখবেন, আপনি চাঙ্কড ট্রান্সফার এনকোডিং ব্যবহার করলে এই হেডার দেওয়ার প্রয়োজন নেই।
• Content-Type – ভ্যালু application/json; charset=UTF-8 হিসেবে সেট করুন।
• X-Upload-Content-Length – পরবর্তী অনুরোধে আপলোড করা বাইটের সংখ্যা। আপনি যে ফাইল আপলোড করছেন সেটির সাইজ অনুযায়ী এই ভ্যালু সেট করুন।
• x-upload-content-type – আপনি যে ফাইল আপলোড করছেন সেটির MIME টাইপ। আপনি যেকোনও ভিডিও MIME টাইপ (video/*) বা application/octet-stream MIME টাইপের ফাইল আপলোড করতে পারবেন।

ভিডিও আপলোড করার জন্য কীভাবে একটি রেজুমেবল সেশন শুরু করতে হয় তা নিম্নলিখিত উদাহরণে দেখানো হয়েছে। অনুরোধটি video রিসোর্সের snippet এবং status অংশে প্রপার্টি সেট করে (এবং পুনরুদ্ধার করবে) এবং এটি রিসোর্সের contentdetails অংশেও প্রপার্টি পুনরুদ্ধার করবে।

post /upload/youtube/v3/videos?uploadType=resumable&part=parts http/1.1
host: www.googleapis.com
authorization: bearer auth_token
content-length: content_length
content-type: application/json; charset=utf-8
x-upload-content-length: x_upload_content_length
X-Upload-Content-Type: X_UPLOAD_CONTENT_TYPE

video resource

নিচের উদাহরণে এমন একটি POST অনুরোধ দেখানো হয়েছে যেখানে যাচাইকরণ টোকেন ছাড়া বাকি সব ভ্যালু পূরণ করা আছে। উদাহরণে categoryId ভ্যালু ভিডিওর বিভাগের সাথে সম্পর্কিত। API-এর videoCategories.list পদ্ধতি ব্যবহার করে কাজ করে এমন বিভাগের তালিকা ফিরিয়ে আনা যাবে।

POST /upload/youtube/v3/videos?uploadType=resumable&part=snippet,status,contentDetails HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer AUTH_TOKEN
Content-Length: 278
Content-Type: application/json; charset=UTF-8
X-Upload-Content-Length: 3000000
X-Upload-Content-Type: video/*

{
  "snippet": {
    "title": "My video title",
    "description": "This is a description of my video",
    "tags": ["cool", "video", "more keywords"],
    "categoryId": 22
  },
  "status": {
    "privacyStatus": "public",
    "embeddable": True,
    "license": "youtube"
  }
}

ধাপ ২ - আবার চালু করা যাবে এমন সেশন URI সেভ করুন

আপনার অনুরোধ সফল হলে, API সার্ভার 200 (OK) HTTP স্ট্যাটাস কোড সহ উত্তর দেবে এবং উত্তরে একটি Location HTTP হেডার অন্তর্ভুক্ত থাকবে যা আবার শুরু করা যায় এমন সেশনের জন্য URI নির্দিষ্ট করে। আপনার ভিডিও ফাইল আপলোড করার জন্য এই URI ব্যবহার করবেন।

ধাপ ১-এ করা অনুরোধের জন্য নিচে একটি নমুনা API রেসপন্স দেখানো হয়েছে:

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/youtube/v3/videos?uploadType=resumable&upload_id=xa298sd_f&part=snippet,status,contentDetails
Content-Length: 0

ধাপ ৩ - ভিডিও ফাইল আপলোড করা

API রেসপন্স থেকে সেশন URI এক্সট্র্যাক্ট করার পরে, আপনাকে সেই লোকেশনে আসল ভিডিও ফাইলের কন্টেন্ট আপলোড করতে হবে। অনুরোধের বডিতে আপনি যে ভিডিও আপলোড করছেন তার বাইনারি ফাইল কন্টেন্ট থাকে। নিচের উদাহরণে অনুরোধের ফর্ম্যাট দেখানো হয়েছে।

PUT UPLOAD_URL HTTP/1.1
Authorization: Bearer AUTH_TOKEN
Content-Length: CONTENT_LENGTH
Content-Type: CONTENT_TYPE

BINARY_FILE_DATA

অনুরোধটি নিম্নলিখিত HTTP অনুরোধ হেডার সেট করে:

• Authorization – অনুরোধের জন্য অনুমোদনের টোকেন।
• Content-Length – আপনি যে ফাইল আপলোড করছেন সেটির সাইজ। এই ভ্যালু, ধাপ ১-এ উল্লেখ করা X-Upload-Content-Length HTTP অনুরোধ হেডারের ভ্যালুর সাথে এক হতে হবে।
• Content-Type – আপনার আপলোড করা ফাইলের MIME-এর প্রকার। এই ভ্যালু ধাপ ১-এ X-Upload-Content-Type HTTP অনুরোধ হেডারের ভ্যালুর সমান হতে হবে।

ধাপ ৪ - আপলোড করার প্রসেস সম্পূর্ণ করুন

আপনার অনুরোধের ফলে নিম্নলিখিত পরিস্থিতিগুলির মধ্যে একটি ঘটবে:

• আপনার আপলোড সফল হয়েছে।

  API সার্ভার HTTP 201 (Created) রেসপন্স কোড সহ উত্তর দেয়। উত্তরের বডিতে video আপনার তৈরি করা রিসোর্স থাকে।

• আপনার আপলোড সম্পূর্ণ হয়নি, তবে আবার শুরু করা যাবে।

  আপনি নিম্নলিখিত যেকোনও একটি ক্ষেত্রে আপলোড আবার শুরু করতে পারবেন:

  • আপনার অনুরোধ সম্পূর্ণ করা যায়নি কারণ আপনার অ্যাপ্লিকেশন ও API সার্ভারের মধ্যে কানেকশন বিচ্ছিন্ন হয়ে গেছে। এই ক্ষেত্রে, আপনি কোনও API উত্তর পাবেন না।

  • API রেসপন্স নিম্নলিখিত 5xx রেসপন্স কোডের যেকোনও একটি নির্দিষ্ট করে। এইসব রেসপন্স কোডের যেকোনও একটি পাওয়ার পরে আপলোড আবার শুরু করার সময় আপনার কোডে এক্সপোনেনশিয়াল ব্যাকঅফ স্ট্র্যাটেজি ব্যবহার করা উচিত।

    • 500 – Internal Server Error
    • 502 – Bad Gateway
    • 503 – Service Unavailable
    • 504 – Gateway Timeout

  আপলোড আবার শুরু করতে, নিচে দেওয়া আপলোডের স্ট্যাটাস চেক করা এবং আপলোড আবার শুরু করা সংক্রান্ত নির্দেশাবলী অনুসরণ করুন। মনে রাখবেন যে প্রতিটি রিজুমেবল সেশন URI-এর একটি নির্দিষ্ট লাইফটাইম থাকে এবং অবশেষে মেয়াদ শেষ হয়ে যায়। এই কারণে, সেশন URI পাওয়ার সাথে সাথেই আমরা আপনাকে আবার শুরু করা যায় এমন আপলোড শুরু করার এবং আপলোড করার সময় কোনও বাধা আসলে, বাধা আসার অল্প সময়ের মধ্যেই আপলোড আবার শুরু করার সাজেশন দিই।

• আপনার আপলোড স্থায়ীভাবে বন্ধ হয়ে গেছে।

  আপলোড করা না গেলে, উত্তরে একটি ত্রুটি সংক্রান্ত উত্তর থাকে যা আপলোড না হওয়ার কারণ ব্যাখ্যা করতে সাহায্য করে। কোনও আপলোড স্থায়ীভাবে ব্যর্থ হলে, API রেসপন্সে 4xx রেসপন্স কোড বা উপরে তালিকাভুক্ত কোড ছাড়া অন্য কোনও 5xx রেসপন্স কোড থাকবে।

  আপনি যদি মেয়াদ শেষ হয়ে যাওয়া সেশন URI সহ একটি অনুরোধ পাঠান, তাহলে সার্ভার একটি 404 HTTP রেসপন্স কোড (Not Found) রিটার্ন করে। এই ক্ষেত্রে, আপনাকে একটি নতুন আবার শুরু করা যায় এমন আপলোড শুরু করতে হবে, একটি নতুন সেশন URI পেতে হবে এবং নতুন URI ব্যবহার করে শুরু থেকে আপলোড শুরু করতে হবে।

ধাপ ৪.১: আপলোডের স্ট্যাটাস চেক করা

বাধাগ্রস্ত হওয়া আবার শুরু করা যায় এমন আপলোডের স্ট্যাটাস চেক করতে, আপলোড URL-এ একটি খালি PUT অনুরোধ পাঠান যা আপনি ২ নম্বর ধাপে পেয়েছেন এবং ৩ নম্বর ধাপেও ব্যবহার করেছেন। আপনার অনুরোধে, Content-Range হেডার ভ্যালু bytes */CONTENT_LENGTH হিসেবে সেট করুন, যেখানে CONTENT_LENGTH হল আপনার আপলোড করা ফাইলের সাইজ।

PUT UPLOAD_URL HTTP/1.1
Authorization: Bearer AUTH_TOKEN
Content-Length: 0
Content-Range: bytes */CONTENT_LENGTH

ধাপ ৪.২: API রেসপন্স প্রসেস করা

আপলোড সম্পূর্ণ হয়ে গেলে, সেটি সফল হোক বা না হোক, API সেই একই উত্তর রিটার্ন করবে যা আপলোড সম্পূর্ণ হওয়ার সময় পাঠানো হয়েছিল।

তবে, আপলোড করার সময় কোনও বাধা এলে বা আপলোড এখনও সম্পূর্ণ না হলে, API রেসপন্সে HTTP 308 (Resume Incomplete) রেসপন্স কোড থাকবে। উত্তরে, Range হেডার নির্দিষ্ট করে যে ফাইলের কত বাইট ইতিমধ্যেই সফলভাবে আপলোড করা হয়েছে।

• হেডারের ভ্যালু 0 থেকে ইন্ডেক্স করা হয়। যেমন, 0-999999-এর হেডার ভ্যালু থেকে বোঝা যায় যে ফাইলের প্রথম 1,000,000 বাইট আপলোড করা হয়েছে।
• এখনও কিছু আপলোড করা না হয়ে থাকলে, API-এর উত্তরে Range হেডার থাকবে না।

নিচে দেওয়া স্যাম্পেল রেসপন্স থেকে, আবার চালু করা যায় এমন আপলোডের জন্য API রেসপন্সের ফর্ম্যাট সম্পর্কে জানতে পারবেন:

308 Resume Incomplete
Content-Length: 0
Range: bytes=0-999999

API রেসপন্সে Retry-After হেডারও অন্তর্ভুক্ত থাকলে, কখন আপলোড আবার শুরু করার চেষ্টা করতে হবে তা নির্ধারণ করতে সেই হেডারের ভ্যালু ব্যবহার করুন।

ধাপ ৪.৩: আপলোড আবার শুরু করা

আপলোড আবার শুরু করতে, ধাপ ২-এ ক্যাপচার করা আপলোড URL-এ আরেকটি PUT অনুরোধ পাঠান। ভিডিও ফাইলের যে অংশ এখনও আপলোড করা হয়নি, সেটির বাইনারি কোডে অনুরোধের বডি সেট করুন।

PUT UPLOAD_URL HTTP/1.1
Authorization: Bearer AUTH_TOKEN
Content-Length: REMAINING_CONTENT_LENGTH
Content-Range: bytes FIRST_BYTE-LAST_BYTE/TOTAL_CONTENT_LENGTH

PARTIAL_BINARY_FILE_DATA

আপনাকে নিম্নলিখিত HTTP অনুরোধ হেডার সেট করতে হবে:

• Authorization – অনুরোধের জন্য অনুমোদনের টোকেন।

• Content-Length – এখনও আপলোড করা হয়নি এমন কন্টেন্টের সাইজ, বাইটে। আপনি যদি কোনও ফাইলের বাকি অংশ আপলোড করেন, তাহলে TOTAL_CONTENT_LENGTH ভ্যালু থেকে FIRST_BYTE ভ্যালু বিয়োগ করে এই ভ্যালু গণনা করতে পারবেন। Content-Range হেডারে দুটি ভ্যালুই ব্যবহার করা হয়।

• Content-Range – আপনি যে ফাইল আপলোড করছেন তার অংশ। হেডার ভ্যালুতে তিনটি ভ্যালু থাকে:

  • FIRST_BYTE – বাইট নম্বরের ০-ভিত্তিক সংখ্যাসূচক ইনডেক্স যেখান থেকে আপনি আপলোড আবার শুরু করছেন। এই ভ্যালুটি আগের ধাপে পাওয়া Range হেডারের দ্বিতীয় নম্বরের চেয়ে এক নম্বর বেশি। আগের উদাহরণে, Range হেডার ভ্যালু ছিল 0-999999, তাই পরবর্তী আপলোড আবার শুরু করার সময় প্রথম বাইট হবে 1000000।

  • LAST_BYTE – আপনি যে বাইনারি ফাইল আপলোড করছেন তার শেষ বাইটের ০-ভিত্তিক সংখ্যাসূচক ইনডেক্স। সাধারণত, এটি ফাইলের শেষ বাইট। যেমন, ফাইলের সাইজ 3000000 বাইট হলে, ফাইলের শেষ বাইটটি হবে 2999999 নম্বর।

  • TOTAL_CONTENT_LENGTH – বাইটে ভিডিও ফাইলের মোট সাইজ। এই ভ্যালু আপলোড করার মূল অনুরোধে উল্লেখ করা Content-Length হেডার ভ্যালুর মতোই।

  মনে রাখবেন: আপনি বাইনারি ফাইলের নন-কন্টিনিউয়াস ব্লক আপলোড করতে পারবেন না। আপনি যদি নন-কন্টিনিউয়াস ব্লক আপলোড করার চেষ্টা করেন, তাহলে বাকি বাইনারি কন্টেন্টের কোনওটিই আপলোড করা হবে না।
  
  এই কারণে, আবার শুরু করা আপলোডে আপলোড করা প্রথম বাইটটি অবশ্যই শেষ বাইটের পরের বাইট হতে হবে যা ইতিমধ্যেই YouTube-এ সফলভাবে আপলোড করা হয়েছে। (ধাপ ৪.২-এ Range হেডার সংক্রান্ত আলোচনা দেখুন।
  
  সুতরাং, Range হেডারের শেষ বাইট 999999 হলে, আপলোড আবার শুরু করার অনুরোধের প্রথম বাইট অবশ্যই ১০০০০০০ বাইট হতে হবে। (দুটি সংখ্যাতেই ০-ভিত্তিক ইনডেক্স ব্যবহার করা হয়।) আপনি যদি ৯৯৯৯৯৯ বা তার কম বাইট (ওভারল্যাপ করা বাইট) অথবা ১০০০০০১ বা তার বেশি বাইট (বাদ দেওয়া বাইট) থেকে আপলোড আবার শুরু করার চেষ্টা করেন, তাহলে কোনও বাইনারি কন্টেন্ট আপলোড করা হবে না।

ছোট ছোট ভাগে ফাইল আপলোড করা

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

এই নির্দেশিকায় আগে ব্যাখ্যা করা চারটি ধাপের প্রসেসের সাথে, ফাইলকে ছোট ছোট অংশে আপলোড করার নির্দেশাবলী প্রায় একই রকম। তবে, ফাইল আপলোড শুরু করার অনুরোধ (উপরে ৩ নম্বর ধাপ) এবং আপলোড আবার শুরু করার অনুরোধ (উপরে ৪.৩ নম্বর ধাপ) উভয় ক্ষেত্রেই Content-Length এবং Content-Range হেডার ভ্যালু আলাদাভাবে সেট করা হয় যখন কোনও ফাইল চাঙ্কে আপলোড করা হয়।

• Content-Length হেডার ভ্যালু থেকে বোঝা যায় যে অনুরোধটি কত বড় চাঙ্ক পাঠাচ্ছে। চাঙ্ক সাইজের উপর নিম্নলিখিত বিধিনিষেধগুলি মনে রাখবেন:

  • চাঙ্ক সাইজ ২৫৬ কেবির গুণিতক হতে হবে। (এই বিধিনিষেধ শেষ চঙ্কের ক্ষেত্রে প্রযোজ্য হয় না, কারণ সম্পূর্ণ ফাইলের সাইজ ২৫৬ কেবির মাল্টিপল নাও হতে পারে।) মনে রাখবেন, বড় চাঙ্ক বেশি কার্যকর।

  • আপলোড সিকোয়েন্সে প্রতিটি অনুরোধের জন্য চ্যাঙ্ক সাইজ একই হতে হবে, তবে শেষ অনুরোধের ক্ষেত্রে এটি প্রযোজ্য নয়, কারণ এটি ফাইনাল চ্যাঙ্কের সাইজ নির্দিষ্ট করে।

• Content-Range হেডারটি ফাইলের বাইট নির্দিষ্ট করে যা অনুরোধটি আপলোড করছে। এই মান সেট করার সময় ৪.৩ ধাপে Content-Range হেডার সেট করার নির্দেশাবলী প্রযোজ্য হয়।

  যেমন, bytes 0-524287/2000000 ভ্যালু দেখায় যে অনুরোধটি ২,০০০,০০০ বাইটের ফাইলে প্রথম ৫২৪,২৮৮ বাইট (২৫৬ x ২০৪৮) পাঠাচ্ছে।

নিচের উদাহরণে, অনুরোধের সিরিজের প্রথমটির ফর্ম্যাট দেখানো হয়েছে, যা চাঙ্কে ২,০০০,০০০ বাইটের ফাইল আপলোড করবে:

PUT UPLOAD_URL HTTP/1.1
Authorization: Bearer AUTH_TOKEN
Content-Length: 524888
Content-Type: video/*
Content-Range: bytes 0-524287/2000000

{bytes 0-524287}

ফাইনাল অনুরোধ ছাড়া অন্য কোনও অনুরোধ সফল হলে, API সার্ভার 308 (Resume Incomplete) উত্তর দেয়। উত্তরের ফর্ম্যাট উপরে ধাপ ৪.২: API রেসপন্স প্রসেস করুন-এ বর্ণিত ফর্ম্যাটের মতোই হবে।

পরবর্তী চাঙ্ক কোথা থেকে শুরু করতে হবে তা নির্ধারণ করতে API রেসপন্সের Range হেডারে দেখানো উপরের ভ্যালু ব্যবহার করুন। সম্পূর্ণ ফাইল আপলোড না হওয়া পর্যন্ত, ধাপ ৪.৩: আপলোড আবার শুরু করুন-এ বর্ণিত পদ্ধতি অনুযায়ী, পরবর্তী ফাইল চ্যাঙ্ক আপলোড করার জন্য PUT অনুরোধ পাঠানো চালিয়ে যান।

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

কোনও অনুরোধ বাধা পেলে বা আপনার অ্যাপ্লিকেশন কোনও 5xx রেসপন্স কোড পেলে, আপলোড সম্পূর্ণ করতে ধাপ ৪-এ ব্যাখ্যা করা পদ্ধতি অনুসরণ করুন। তবে, ফাইলের বাকি অংশ আপলোড করার চেষ্টা না করে, যেখান থেকে আপলোড আবার শুরু করছেন, সেখান থেকে চ্যাঙ্ক আপলোড করা চালিয়ে যান। ফাইল আপলোড কোথা থেকে আবার শুরু করবেন তা নির্ধারণ করতে আপলোডের স্ট্যাটাস চেক করতে ভুলবেন না। আগের অনুরোধে পাঠানো সব (বা কোনও) বাইট সার্ভার পেয়েছে বলে ধরে নেবেন না।

মনে রাখবেন: এছাড়াও, আপলোড করা চ্যাঙ্কের মধ্যে অ্যাক্টিভ আপলোডের স্ট্যাটাস জানতে অনুরোধ করতে পারেন। (আপলোড করার সময় কোনও বাধা না এলেও আপনি স্ট্যাটাস জানতে পারবেন।)