ইভেন্ট-ফটো অ্যাপের ডেভেলপারদের কাছে এখন ভিড়যুক্ত ভেন্যুতে ব্রাউজার আপলোড সচল রাখার জন্য একটি সুনির্দিষ্ট চেকলিস্ট রয়েছে। একজন ব্যবহারকারী ওয়াই-ফাই থেকে সেলুলারে চলে যেতে পারেন, যখন ডজন ডজন ডিভাইস একই হটস্পটের জন্য প্রতিযোগিতা করে। গাইডটি দেখায় কীভাবে একটি “upload complete” টোস্ট মেসেজ আসার পরেও একটি ছবি হারিয়ে যাওয়া রোধ করা যায়, এমনকি যদি গেস্ট ফোনটি লক করে ফেলেন বা নেটওয়ার্কে সমস্যা হয়।

কেন সাধারণ আপলোড বিয়ে বা উৎসবে ব্যর্থ হয়

একটি অফিসে ল্যাপটপ একটি স্থিতিশীল ইথারনেট লিঙ্কে থাকে এবং একজন ব্যবহারকারী “send” ক্লিক করেন। একটি বিয়ে বা মিউজিক ফেস্টিভ্যালে একই কাজ সমস্যার একটি ধারাবাহিকতা তৈরি করতে পারে: গেস্ট অনুষ্ঠান হল থেকে পার্কিং লটে হেঁটে যাচ্ছেন, শত শত ফোনের চাপে রাউটারটি হিমশিম খাচ্ছে, অথবা ফোনটি ওয়াই-ফাই ছেড়ে সেলুলারে চলে যাচ্ছে। ব্রাউজার সার্ভারে প্রতিটি বাইট স্ট্রিম করে থাকতে পারে, কিন্তু সার্ভার এখনও ফাইলটি স্টোরেজে সেভ করেনি। যদি প্রোগ্রেস বার ১০০% হওয়ার সাথে সাথেই UI সফলতার ঘোষণা দেয়, তবে গেস্ট ছবিটি মুছে ফেলতে পারেন, যার ফলে আয়োজকের কাছে একটি ফাইলটি অনুপস্থিত থেকে যায়।

“শুধু আপলোড করুন” এর লুকানো খরচ

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

একটি resumable, chunked আপলোড সিস্টেম তৈরি করা

নিচে একটি ব্যবহারিক, ধাপে ধাপে নির্দেশিকা দেওয়া হলো।

১. ব্রাউজার থেকে কোনো ডেটা পাঠানোর আগেই একটি আপলোড ID তৈরি করুন

লোকালি একটি ইউনিভার্সালি ইউনিক আইডেন্টিফায়ার (UUID) তৈরি করুন এবং প্রথম রিকোয়েস্ট হিসেবে এটি সার্ভারে পাঠান। সার্ভার সেই ID-র অধীনে একটি সেশন রেকর্ড করে। যদি ব্রাউজার পরে টাইমআউটের কারণে পুনরায় চেষ্টা করে, তবে এটি একই UUID অন্তর্ভুক্ত করবে, যা সার্ভারকে সেশনটি চিনতে এবং ডুপ্লিকেট এন্ট্রি এড়াতে সাহায্য করবে। এটি ওয়ার্কফ্লোটিকে idempotent করে তোলে—একই রিকোয়েস্ট বারবার পাঠালেও কোনো ক্ষতিকারক প্রভাব পড়ে না।

২. ফাইলটিকে ৫ – ১০ MB চাঙ্কে ভাগ করুন

চাঙ্ক সাইজ একটি ভারসাম্য রক্ষার বিষয়। ছোট চাঙ্ক (১ MB-এর নিচে) HTTP রিকোয়েস্টের সংখ্যা এবং সংশ্লিষ্ট হেডার ওভারহেড বাড়িয়ে দেয়। খুব বড় চাঙ্ক যেকোনো বাধা বা ইন্টারাপশনকে ব্যয়বহুল করে তোলে কারণ ক্লায়েন্টকে একটি বড় অংশ আবার পাঠাতে হয়। সাধারণ ছবি এবং ছোট ভিডিওর জন্য ৫ – ১০ MB একটি ভারসাম্য বজায় রাখে: প্রতিটি রিকোয়েস্ট UI-কে রেসপন্সিভ রাখতে যথেষ্ট দ্রুত শেষ হয়, আবার রিকোয়েস্টের সংখ্যাও নিয়ন্ত্রণে থাকে।

৩. প্যারালাল আপলোডের সংখ্যা সীমিত করুন

মোবাইল ব্রাউজার অনেক কানেকশন খুলতে পারে, কিন্তু একটি জনাকীর্ণ ওয়াই-ফাই নেটওয়ার্কে প্রতিটি অতিরিক্ত স্ট্রিম সীমিত ব্যান্ডউইথের জন্য প্রতিযোগিতা করে। আটটি প্রতিযোগিতামূলক স্ট্রিমের চেয়ে দুটি স্থিতিশীল স্ট্রিম বেশি কার্যকর। কম ব্যান্ডউইথের অবস্থা শনাক্ত করতে এবং স্বয়ংক্রিয়ভাবে concurrency কমাতে navigator.connection API ব্যবহার করুন।

৪. IndexedDB-তে আপলোড স্টেট সংরক্ষণ করুন

আপলোড ID, ইতিমধ্যে পাঠানো চাঙ্কগুলোর তালিকা এবং সার্ভার কর্তৃক স্বীকৃত অফসেটগুলো ব্রাউজারের IndexedDB-তে সংরক্ষণ করুন। যদি পেজটি রিলোড হয় বা ব্যবহারকারী ট্যাবটি বন্ধ করে দেন, তবে ক্লায়েন্ট পরবর্তী লোডে স্টেটটি পুনরুদ্ধার করতে পারে। যখন ব্যবহারকারী পেজটি আবার খুলবেন, তাদের একই ফাইলটি নির্বাচন করতে বলুন; সংরক্ষিত মেটাডেটা আপলোডটিকে আবার শুরু করার পরিবর্তে শেষ নিশ্চিত করা চাঙ্ক থেকে পুনরায় শুরু করতে সাহায্য করবে।

৫. শুধুমাত্র navigator.onLine নয়, প্রকৃত নেটওয়ার্ক পরিবর্তন শনাক্ত করুন

navigator.onLine ফ্ল্যাগটি প্রায়শই সংযোগটি ব্যবহার অনুপযোগী থাকা সত্ত্বেও “online” রিপোর্ট করে। পরিবর্তে, প্রতিটি চাঙ্কের জন্য একটি ছোট রিকোয়েস্ট টাইমআউট (যেমন, ৫ সেকেন্ড) সেট করুন। যদি টাইমআউট ঘটে, তবে নেটওয়ার্কটি বিচ্ছিন্ন হিসেবে গণ্য করুন। সংযোগ ফিরে আসলে, সার্ভারকে জিজ্ঞাসা করুন তার কাছে কোন কোন চাঙ্ক আছে, তারপর শুধুমাত্র অনুপস্থিত অংশগুলো আপলোড করা চালিয়ে যান। এটি সংক্ষিপ্ত বিভ্রাটের পরে ডুপ্লিকেট ডেটা পাঠানো এড়িয়ে চলে।

৬. রিট্রাই করার জন্য jitter সহ exponential backoff প্রয়োগ করুন

যখন অনেক গেস্টের ডিভাইস লক্ষ্য করে যে নেটওয়ার্ক ফিরে এসেছে, তখন তারা সবাই একই মুহূর্তে রিট্রাই শুরু করতে পারে, যা সার্ভারকে অতিরিক্ত চাপে ফেলে দিতে পারে। Exponential backoff প্রতিটি রিট্রাইকে আগেরটির চেয়ে দীর্ঘ সময় অপেক্ষা করতে বাধ্য করে, আর jitter একটি র‍্যান্ডম ছোট অফসেট যোগ করে। এই সমন্বয় রিট্রাই ট্রাফিককে কয়েক সেকেন্ডের মধ্যে ছড়িয়ে দেয়, যা হঠাৎ স্পাইক বা চাপ রোধ করে।

৭. লেয়ার্ড এবং সহজলভ্য ফিডব্যাক দেখান

একটি তিন-স্তরের স্ট্যাটাস বার ফাইলের প্রকৃত অবস্থা প্রকাশ করে:

  • Received – সার্ভার প্রতিটি চাঙ্ক সংরক্ষণ করেছে এবং ফাইলটিকে সম্পন্ন হিসেবে চিহ্নিত করেছে।
  • Preparing – সার্ভার থাম্বনেইল তৈরি করছে বা ভিডিও ট্রান্সকোড করছে।
  • Available – আয়োজক ফাইলটি দেখতে বা ডাউনলোড করতে পারবেন।

শুধুমাত্র রঙের ওপর নির্ভর করা এড়িয়ে চলুন; আইকনের সাথে ছোট টেক্সট যুক্ত করুন যাতে স্ক্রিন-রিডার ব্যবহারকারীরাও প্রগতি বুঝতে পারেন।

কী কী সমস্যা হতে পারে?

এমনকি একটি সুপরিকল্পিত রেজুমেবল আপলোডও কিছু এজ কেস (edge cases)-এর কারণে সমস্যায় পড়তে পারে।

পরবর্তীতে কী খেয়াল রাখতে হবে

ওয়েব প্ল্যাটফর্ম ক্রমাগত বিবর্তিত হচ্ছে।

সারসংক্ষেপ

একটি রেজুমেবল, চাঙ্কড আপলোড যা প্রতিটি অংশ ট্র্যাক করে, লোকালি স্টেট (state) সংরক্ষণ করে এবং বুদ্ধিমত্তার সাথে পুনরায় চেষ্টা (retry) করে, সেটি একটি অস্থির ইভেন্ট নেটওয়ার্ককে অতিথিদের ছবির জন্য একটি নির্ভরযোগ্য মাধ্যমে পরিণত করে। উপরের চেকলিস্টটি অনুসরণ করুন।