फ़ाइलें, डाउनलोड और ट्रांसफ़र
iPhone पर फ़ाइलों के बारे में जो मनमाना लगता है उसका ज़्यादातर हिस्सा अलगाव के एक नियम से निकलता है, और डाउनलोड को भरोसेमंद बनाने वाली ज़्यादातर बातें HTTP की एक ख़ासियत से निकलती हैं। यहां ये दोनों हैं, साथ ही वे तरीक़े जिनसे फ़ाइलें एक डिवाइस से दूसरे तक पहुंचती हैं।
-
सैंडबॉक्स
-
वह नियम कि हर ऐप सिर्फ़ अपना ख़ुद का स्टोरेज देख सकता है। यही वजह है कि एक ऐप दूसरे के डाउनलोड नहीं खोल सकता, और यही वजह है कि "फ़ाइल वीडियो के बग़ल में है" कोई ऐसी चीज़ नहीं जो iOS पर मौजूद है।
हर ऐप को एक निजी डायरेक्टरी मिलती है और किसी और की कोई झलक नहीं। फ़ाइलें ऐप के बीच सिर्फ़ जान-बूझकर किए गए कामों से चलती हैं — एक शेयर शीट, एक डॉक्युमेंट पिकर, एक ड्रैग — इनमें से हर एक वह फ़ैसला है जो इंसान ने लिया, न कि जो किसी ऐप ने ख़ुद ले लिया।
क़ीमत छोटी जगहों पर पड़ती है। डेस्कटॉप प्लेयर
film.mkvके बग़ल में अपने आपfilm.srtढूंढ लेते हैं; iOS पर कोई "बग़ल" है ही नहीं, तो एक सबटाइटल फ़ाइल जान-बूझकर सौंपनी पड़ती है और ऐप को ही वह चीज़ होना पड़ता है जो जोड़ी याद रखे।यह भी देखें: ऐप ग्रुपसिक्योरिटी-स्कोप्ड बुकमार्क
-
ऐप ग्रुप
-
एक साझा कंटेनर जिसे एक ही डेवलपर के दो ऐप खोल सकते हैं — सैंडबॉक्स में इकलौती मंज़ूरशुदा दरार। यही वह तरीक़ा है जिससे एक शेयर एक्सटेंशन एक फ़ाइल उस ऐप को सौंपता है जिसकी वह है।
एक शेयर एक्सटेंशन उस ऐप से एक अलग प्रोग्राम है जिसका हिस्सा यह दिखता है, इसका अपना सैंडबॉक्स है और बहुत छोटी ज़िंदगी। यह मुख्य ऐप के स्टोरेज में नहीं लिख सकता।
तो यह एक ऐसे कंटेनर में लिखता है जिसे दोनों देख सकते हैं, और ऐप अगली बार खुलने पर उस कंटेनर को ख़ाली कर देता है। कुछ भी डेवलपर की सीमा नहीं लांघता, और बिना साफ़ टैप के कुछ भी नहीं लांघता।
यह भी देखें: सैंडबॉक्स
-
सिक्योरिटी-स्कोप्ड बुकमार्क
-
एक टोकन जो सैंडबॉक्स के बाहर एक फ़ोल्डर की अनुमति याद रखता है — एक एक्सटर्नल ड्राइव, iCloud में एक फ़ोल्डर — ताकि ऐप बाद में बिना दोबारा पूछे इसे फिर से खोल सके।
जब आप सिस्टम फ़ाइल पिकर से कोई जगह चुनते हैं, दी गई अनुमति सिर्फ़ उस पल के लिए होती है। एक बुकमार्क इसे लॉन्च के पार सुरक्षित रखता है, और ऐप को साफ़ तौर पर उस एक्सेस का इस्तेमाल शुरू और बंद करना पड़ता है जिसे यह दर्शाता है।
यही वह चीज़ है जो एक एक्सटर्नल SSD को बिना कुछ कॉपी किए ब्राउज़ करना संभव बनाती है, और यह बिल्कुल उसी तक सीमित है जो आपने चुना — एक फ़ोल्डर का बुकमार्क इसके पड़ोसी के बारे में कुछ नहीं देता।
यह भी देखें: सैंडबॉक्स
-
रेंज रिक्वेस्ट
-
सर्वर से पूरी चीज़ के बजाय फ़ाइल का एक ख़ास टुकड़ा मांगना — बाइट 5,000,000 से 5,999,999 तक। यही वह चीज़ है जो डाउनलोड को दोबारा शुरू करने लायक़ बनाती है और जो कई कनेक्शन को एक साथ एक फ़ाइल लाने देती है।
रेंज सपोर्ट करने वाला सर्वर 206 Partial Content और मांगे गए टुकड़े के साथ जवाब देता है। जो नहीं करता वह 200 जवाब देता है और शुरुआत से सब कुछ भेजता है, और यही फ़र्क़ है डाउनलोड दोबारा शुरू करने और इसे नए सिरे से शुरू करने में।
डाउनलोड इंजन के बारे में हर दिलचस्प बात इसी एक HTTP ख़ासियत पर टिकी है। इसके बिना, टूटे कनेक्शन के बाद कोई फिर से शुरुआत नहीं, रीबूट के बाद कोई फिर से शुरुआत नहीं, और एक से ज़्यादा कनेक्शन इस्तेमाल करने का कोई तरीक़ा नहीं।
यह भी देखें: दोबारा शुरू होने लायक़ डाउनलोडसमानांतर कनेक्शन
-
दोबारा शुरू होने लायक़ डाउनलोड
-
एक ट्रांसफ़र जो नए सिरे से शुरू होने के बजाय ठीक वहीं से जारी रहता है जहां यह रुका था, यह रिकॉर्ड करके कि कितने बाइट पक्के हो चुके हैं और बाक़ी मांगकर।
शर्त यह है कि रिकॉर्ड की गई गिनती कभी आशावादी न हो। एक बाइट जो लिखी गई मान ली गई पर अब भी बफ़र में बैठी है, ऐप बंद होने पर फ़ाइल में एक छेद बन जाती है — और वीडियो के बीच एक छेद एक ऐसी ख़राबी है जो सिर्फ़ इसे देखते एक घंटे बाद सामने आती है।
यही वजह है कि गिनती को नेटवर्क से पढ़ने के बजाय डिस्क पर लिखने के पीछे चलना पड़ता है, और फ़ोरग्राउंड व बैकग्राउंड ट्रांसफ़र के बीच हर हैंडओवर को एक नंबर पर सहमत होना पड़ता है।
यह भी देखें: रेंज रिक्वेस्टबैकग्राउंड ट्रांसफ़र
-
समानांतर कनेक्शन
multi-connection, chunked download -
एक फ़ाइल को रेंज में बांटना और कई एक साथ लाना। यह तब मदद करता है जब एक अकेला कनेक्शन सीमित किया जा रहा हो, और कुछ नहीं करता जब रुकावट आपकी अपनी लाइन हो।
एक सर्वर जो हर कनेक्शन की स्पीड सीमित करता है, अक्सर कई कनेक्शन में मिलाकर ज़्यादा कुल स्पीड देने के लिए राज़ी किया जा सकता है। यहीं मल्टी-कनेक्शन डाउनलोडिंग अपनी साख कमाती है।
यह जादू नहीं है और अक्सर ग़लत समझा जाता है। अगर आपका कनेक्शन पहले ही भरा है, ज़्यादा कनेक्शन उसी क्षमता को छोटे टुकड़ों में बांट देते हैं और ओवरहेड जोड़ देते हैं। कुछ सर्वर एक पते से कई रिक्वेस्ट को मना भी कर देते हैं या धीमा कर देते हैं।
यह भी देखें: रेंज रिक्वेस्टदोबारा शुरू होने लायक़ डाउनलोड
-
बैकग्राउंड ट्रांसफ़र
-
एक डाउनलोड जो ऑपरेटिंग सिस्टम को सौंपा जाता है ताकि ऐप बंद होने के बाद भी यह जारी रहे। टाइमिंग सिस्टम तय करता है, और यही वह क़ीमत है जो इसके किसी भी सूरत में पूरा होने के बदले चुकाई जाती है।
एक iOS ऐप आपके इसे छोड़ने के थोड़ी देर बाद चलना बंद कर देता है। सिस्टम की बैकग्राउंड सर्विस को सौंपा गया एक ट्रांसफ़र इससे बच जाता है, ऐप के बंद किए जाने से बच जाता है, और रीबूट के बाद दोबारा शुरू होता है।
जो यह छोड़ता है वह नियंत्रण है। सिस्टम इन ट्रांसफ़र को पावर और नेटवर्क हालात के अपने नज़रिए के हिसाब से बैच करता है, तो एक बैकग्राउंड डाउनलोड उन तरीक़ों से रुक और शुरू हो सकता है जो इन-ऐप डाउनलोड नहीं करेगा — और यह पूरा होगा।
यह भी देखें: दोबारा शुरू होने लायक़ डाउनलोडसैंडबॉक्स
-
WebDAV
-
HTTP का एक एक्सटेंशन जो एक वेब सर्वर को फ़ाइल सर्वर बना देता है: लिस्ट करना, पढ़ना, लिखना, हटाना, ले जाना। यही वह है जो Nextcloud और ownCloud बोलते हैं, और जो ज़्यादातर NAS बॉक्स देते हैं।
क्योंकि इसके नीचे HTTP है, WebDAV वेब की बाक़ी हर चीज़ जैसे उसी ढांचे से काम करता है — कोई ख़ास पोर्ट नहीं, कोई ख़ास क्लाइंट प्रोटोकॉल नहीं — यही वजह है कि यह बच गया जबकि ज़्यादा पेचीदा फ़ाइल प्रोटोकॉल नहीं बचे।
ऐसे किसी के लिए जो अपनी फ़ाइलें किसी कंपनी के क्लाउड में नहीं डालना चाहता, यह व्यावहारिक विकल्प है: आपका अपना सर्वर, आपकी अपनी साख, आम मानक।
यह भी देखें: क्लाउड स्टोरेज
-
क्लाउड स्टोरेज
-
फ़ाइलें किसी और के सर्वर पर रखी हुई, उस कंपनी के API से पहुंची — Dropbox, OneDrive, Box, pCloud। हर एक का अपना इंटरफ़ेस है, यही वजह है कि ऐप इन्हें एक-एक करके सपोर्ट करते हैं।
कोई सार्वभौमिक क्लाउड प्रोटोकॉल नहीं है। हर प्रोवाइडर ने अपना ख़ुद का API और अपना ख़ुद का साइन-इन फ़्लो डिज़ाइन किया, तो किसी प्रोवाइडर को ऐप में जोड़ना एक कॉन्फ़िगरेशन एंट्री के बजाय असली काम है।
साइन-इन आमतौर पर OAuth होता है, जिसका मतलब है ऐप कभी पासवर्ड नहीं देखता: प्रोवाइडर इंसान की पहचान पक्की करता है और एक टोकन वापस देता है जिसे प्रोवाइडर की अपनी सेटिंग से किसी भी समय रद्द किया जा सकता है।
यह भी देखें: WebDAV
-
WebRTC
-
दो डिवाइस को सीधे जोड़ने का एक मानक, कनेक्शन बनने के बाद इनके बीच कोई सर्वर नहीं। यही वह है जो डिवाइस-टू-डिवाइस ट्रांसफ़र किसी फ़ाइल को कमरे के आर-पार ले जाने के लिए इस्तेमाल करता है।
एक छोटा सिग्नलिंग सर्वर दोनों डिवाइस को एक-दूसरे से मिलवाता है — छह अंकों का कोड इसी के लिए है — फिर हट जाता है। फ़ाइल सीधे डिवाइस के बीच जाती है और बीच में कहीं स्टोर नहीं होती।
एक ही नेटवर्क पर यह उतना ही तेज़ है जितना वह नेटवर्क इजाज़त दे। पूरे इंटरनेट पर यह इस पर निर्भर करता है कि दोनों तरफ़ सीधे पहुंचा जा सके या नहीं, जहां कनेक्शन कभी-कभी उन वजहों से फेल हो जाते हैं जो कोई भी डिवाइस नहीं देख सकता।
यह भी देखें: लोकल HTTP सर्वर
-
लोकल HTTP सर्वर
-
एक ऐप आपके अपने नेटवर्क पर वेब रिक्वेस्ट का जवाब देता है, तो आपके कंप्यूटर का वेब ब्राउज़र आपके फ़ोन द्वारा परोसा एक पेज खोल सकता है। Wi-Fi ट्रांसफ़र इसी तरह काम करता है, बिना केबल और बिना किसी अकाउंट के।
फ़ोन एक पता दिखाता है; कंप्यूटर इसे खोलता है; जो पेज मिलता है वह ख़ुद फ़ोन परोसता है। फ़ाइलें सीधे लोकल नेटवर्क पर चलती हैं और इसे कभी नहीं छोड़तीं।
चूंकि एक ही नेटवर्क पर कोई भी उस पते तक पहुंच सकता है, इसे एक लॉक चाहिए — डालने के लिए एक कोड, हर ऑपरेशन के लिए दी गई अनुमतियां, और जब तक जान-बूझकर चालू न करें, विनाशकारी काम बंद।
यह भी देखें: WebRTC