শব্দকোষ

ফাইল, ডাউনলোড আর ট্রান্সফার

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

Sandbox

নিয়মটা যে প্রতিটা অ্যাপ শুধু নিজের স্টোরেজ দেখতে পারে। এই কারণেই একটা অ্যাপ আরেকটার ডাউনলোড খুলতে পারে না, আর কেন "ফাইলটা ভিডিওর পাশে আছে" এমন কিছু iOS-এ বিদ্যমান না।

প্রতিটা অ্যাপ একটা ব্যক্তিগত ডিরেক্টরি পায় আর আর কারো কোনো দৃশ্য পায় না। ফাইল শুধু ইচ্ছাকৃত কাজের মাধ্যমে অ্যাপের মধ্যে সরে — একটা শেয়ার শিট, একটা ডকুমেন্ট পিকার, একটা টেনে আনা — এগুলোর প্রতিটাই একটা সিদ্ধান্ত যা মানুষটা নিয়েছে, কোনো অ্যাপ নিজে থেকে নেয়নি।

খরচটা ছোট জায়গায় পড়ে। ডেস্কটপ প্লেয়ার স্বয়ংক্রিয়ভাবে film.mkv-র পাশে film.srt খুঁজে পায়; iOS-এ কোনো "পাশে" নেই, তাই একটা সাবটাইটেল ফাইল ইচ্ছাকৃতভাবে হস্তান্তর করতে হয় আর অ্যাপটাকেই সেই জিনিস হতে হয় যা জোড়াটা মনে রাখে।

আরও দেখো: App groupSecurity-scoped bookmark

App group

একটা শেয়ার করা কন্টেইনার যা একই ডেভেলপারের দুটো অ্যাপই খুলতে পারে — sandbox-এ একমাত্র অনুমোদিত ফাটল। এভাবেই একটা শেয়ার এক্সটেনশন একটা ফাইল যে অ্যাপের সেই অ্যাপে হস্তান্তর করে।

একটা শেয়ার এক্সটেনশন সেই অ্যাপ থেকে একটা আলাদা প্রোগ্রাম যার এটা অংশ বলে মনে হয়, নিজস্ব sandbox আর খুব ছোট জীবনসহ। এটা মূল অ্যাপের স্টোরেজে লিখতে পারে না।

তাই এটা এমন একটা কন্টেইনারে লেখে যা দুটোই দেখার অনুমতি পায়, আর অ্যাপটা পরের বার খোলার সময় সেই কন্টেইনারটা খালি করে। কিছুই একটা ডেভেলপার সীমানা পার হয় না, আর একটা স্পষ্ট ট্যাপ ছাড়া কিছুই পার হয় না।

আরও দেখো: Sandbox

Security-scoped bookmark

একটা টোকেন যা sandbox-এর বাইরের একটা ফোল্ডারের অনুমতি মনে রাখে — একটা বাহ্যিক ড্রাইভ, iCloud-এর একটা ফোল্ডার — যাতে অ্যাপটা পরে আবার না জিজ্ঞেস করেই এটা আবার খুলতে পারে।

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

এটাই কিছু কপি না করে একটা বাহ্যিক SSD ব্রাউজ করা সম্ভব করে তোলে, আর এটা ঠিক তুমি যা বেছেছ তার জন্যই সীমিত — একটা ফোল্ডারের একটা বুকমার্ক এর প্রতিবেশী সম্পর্কে কিছুই দেয় না।

আরও দেখো: Sandbox

Range request

পুরো জিনিসের বদলে একটা ফাইলের একটা নির্দিষ্ট অংশ — বাইট ৫,০০০,০০০ থেকে ৫,৯৯৯,৯৯৯ — একটা সার্ভারকে জিজ্ঞেস করা। এটাই একটা ডাউনলোডকে আবার শুরু করার যোগ্য বানায় আর যা একাধিক কানেকশনকে একবারে একটা ফাইল আনতে দেয়।

একটা সার্ভার যা রেঞ্জ সাপোর্ট করে ২০৬ Partial Content আর চাওয়া অংশটা দিয়ে উত্তর দেয়। যেটা করে না তা ২০০ উত্তর দেয় আর শুরু থেকে সবকিছু পাঠায়, যা একটা ডাউনলোড আবার শুরু করা আর এটা পুনরায় চালু করার মধ্যে পার্থক্য।

একটা ডাউনলোড ইঞ্জিন নিয়ে আকর্ষণীয় সবকিছু এই একটা HTTP ফিচারের ওপর নির্ভর করে। এটা ছাড়া একটা কানেকশন ছিঁড়ে গেলে কোনো আবার শুরু নেই, একটা রিবুটের পরে কোনো আবার শুরু নেই, আর একটার বেশি কানেকশন ব্যবহারের কোনো উপায় নেই।

আরও দেখো: Resumable downloadParallel connections

Resumable download

একটা ট্রান্সফার যা আবার শুরু করার বদলে ঠিক যেখানে থেমেছিল সেখান থেকে চলতে থাকে, কত বাইট নিশ্চিত হয়েছে তা রেকর্ড করে আর বাকিটা চেয়ে।

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

যে কারণে গণনাটাকে নেটওয়ার্ক থেকে পড়ার বদলে ডিস্কে লেখা অনুসরণ করতে হয়, আর কেন ফোরগ্রাউন্ড আর ব্যাকগ্রাউন্ড ট্রান্সফারের মাঝে প্রতিটা হস্তান্তরকে একটা সংখ্যায় একমত হতে হয়।

আরও দেখো: Range requestBackground transfer

Parallel connections

multi-connection, chunked download

একটা ফাইলকে রেঞ্জে ভাগ করা আর একসাথে কয়েকটা আনা। এটা সাহায্য করে যখন একটা একক কানেকশন সীমিত করা হচ্ছে, আর একদমই কিছু করে না যখন বাধাটা তোমার নিজের লাইন।

একটা সার্ভার যা প্রতিটা কানেকশনের গতি সীমিত করে তাকে প্রায়ই কয়েকটা জুড়ে মোট বেশি দিতে রাজি করানো যায়। এখানেই মাল্টি-কানেকশন ডাউনলোডিং এর খ্যাতি অর্জন করে।

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

আরও দেখো: Range requestResumable download

Background transfer

অপারেটিং সিস্টেমকে হস্তান্তর করা একটা ডাউনলোড যাতে অ্যাপ বন্ধ হওয়ার পরেও এটা চলতে থাকে। টাইমিংটা সিস্টেম ঠিক করে, যা এটা মোটেও চলতে থাকার বিনিময়।

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

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

আরও দেখো: Resumable downloadSandbox

WebDAV

HTTP-র একটা এক্সটেনশন যা একটা ওয়েব সার্ভারকে একটা ফাইল সার্ভারে পরিণত করে: তালিকা, পড়া, লেখা, সরানো, মোছা। Nextcloud আর ownCloud যা বলে আর বেশিরভাগ NAS বাক্স যা দেয়।

যেহেতু এটার নিচে HTTP, WebDAV ওয়েবের বাকি সবকিছুর মতো একই অবকাঠামোর মাধ্যমে কাজ করে — কোনো বিশেষ পোর্ট না, কোনো বিশেষ ক্লায়েন্ট প্রোটোকল না — যে কারণে আরও জটিল ফাইল প্রোটোকল টিকে না থাকতে যখন এটা টিকে ছিল।

কোম্পানির ক্লাউডে ফাইল রাখতে না চাওয়া কারো জন্য, এটাই ব্যবহারিক বিকল্প: তোমার নিজের সার্ভার, তোমার নিজের ক্রেডেনশিয়াল, সাধারণ স্ট্যান্ডার্ড।

আরও দেখো: Cloud storage

Cloud storage

অন্য কারো সার্ভারে রাখা ফাইল, সেই কোম্পানির API দিয়ে পৌঁছানো — Dropbox, OneDrive, Box, pCloud। প্রতিটার নিজস্ব ইন্টারফেস আছে, যে কারণে অ্যাপগুলো এগুলো একে একে সাপোর্ট করে।

কোনো সার্বজনীন ক্লাউড প্রোটোকল নেই। প্রতিটা প্রোভাইডার নিজস্ব API আর নিজস্ব সাইন-ইন ফ্লো ডিজাইন করেছে, তাই একটা অ্যাপে একটা প্রোভাইডার যোগ করা একটা কনফিগারেশন এন্ট্রির বদলে আসল কাজ।

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

আরও দেখো: WebDAV

WebRTC

দুটো ডিভাইসকে সরাসরি সংযুক্ত করার একটা স্ট্যান্ডার্ড, কানেকশনটা বিদ্যমান হয়ে গেলে এদের মাঝে কোনো সার্ভার ছাড়াই। ডিভাইস-থেকে-ডিভাইস ট্রান্সফার এটা একটা রুম জুড়ে একটা ফাইল সরাতে ব্যবহার করে।

একটা ছোট সিগন্যালিং সার্ভার দুটো ডিভাইসকে একে অপরের সাথে পরিচয় করায় — ছয়-সংখ্যার কোডটা এর জন্যই — আর তারপর সরে যায়। ফাইলটা সরাসরি ডিভাইসগুলোর মধ্যে ভ্রমণ করে আর মাঝে কোথাও সংরক্ষিত হয় না।

একই নেটওয়ার্কে এটা সেই নেটওয়ার্ক যতটা দ্রুত অনুমতি দেয় ততটা দ্রুত। ইন্টারনেট জুড়ে এটা নির্ভর করে দুই পক্ষই সরাসরি পৌঁছানো যায় কিনা তার ওপর, যেখানে কানেকশন মাঝেমধ্যে এমন কারণে ব্যর্থ হয় যা কোনো ডিভাইসই দেখতে পায় না।

আরও দেখো: Local HTTP server

Local HTTP server

একটা অ্যাপ তোমার নিজের নেটওয়ার্কে ওয়েব রিকোয়েস্টের উত্তর দিচ্ছে, তাই তোমার কম্পিউটারে একটা ওয়েব ব্রাউজার তোমার ফোন দেওয়া একটা পাতা খুলতে পারে। কোনো কেবল নেই, কোনো অ্যাকাউন্ট নেই এভাবেই Wi-Fi Transfer কাজ করে।

ফোনটা একটা ঠিকানা দেখায়; কম্পিউটারটা এটা খোলে; এটা যে পাতাটা পায় তা ফোনটাই দেয়। ফাইল সরাসরি লোকাল নেটওয়ার্কে যায় আর কখনো এটা ছেড়ে যায় না।

যেহেতু একই নেটওয়ার্কে যে কেউ সেই ঠিকানায় পৌঁছাতে পারে, এর একটা লক দরকার — ঢোকার জন্য একটা কোড, প্রতি অপারেশনে দেওয়া অনুমতি, আর ইচ্ছাকৃতভাবে চালু না করা পর্যন্ত বন্ধ থাকা ধ্বংসাত্মক কাজগুলো।

আরও দেখো: WebRTC

অন্য বিষয়গুলো

ভিডিও আর কোডেক স্ট্রিমিং আর IPTV প্রাইভেসি আর এনক্রিপশন সব শব্দ