हमने Yandex.Disk में WebDAV का चयन और कार्यान्वयन कैसे किया

लॉन्च के समय पहले से ही, Yandex.Disk ने कई डेवलपर्स को अपने अनुप्रयोगों और कार्यक्रमों में इसका उपयोग करने का अवसर दिया। और यह सुनिश्चित करता है कि हमने WebDAV को ड्राइव के डेस्कटॉप डेस्कटॉप क्लाइंट के लिए प्रोटोकॉल के रूप में चुना।

चूंकि प्रोटोकॉल यह निर्धारित करता है कि प्रोग्राम और सर्वर एक दूसरे के साथ कैसे संवाद करते हैं, लगभग सब कुछ इसकी पसंद पर निर्भर करता है। और ग्राहकों को कैसे व्यवस्थित किया जाएगा, और फाइलों के साथ काम करने में उनकी क्या क्षमता होगी।



आज हम उन कारणों के बारे में बात करना चाहते हैं जिन्होंने WebDAV पर अपनी पसंद बनाई और इसे Yandex.Disk ग्राहकों के लिए एक प्रोटोकॉल बनाया।

इसके आधार पर कार्यान्वित एपीआई के लिए धन्यवाद, एबीबीवाई फाइनस्कैनर , हैंडी बैकअप 7 , ईएस एक्सप्लोरर और लिनक्स के लिए एक अनौपचारिक Yandex.Disk ग्राहक हमारी सेवा के साथ पहले से ही काम कर रहे हैं।

प्रोटोकॉल चुनने से पहले, हमने अपने लिए इसकी सबसे महत्वपूर्ण आवश्यकताओं की पहचान की:

1. काम की गति;
2. खुला लाइसेंस;
3. सभी आवश्यक कार्यों को लागू करने की क्षमता: प्रमाणीकरण, फ़ाइल संचालन के लिए समर्थन, फ़ाइलों के लिए प्रतिस्पर्धात्मक पहुंच, सर्वर से फिर से शुरू और सर्वर पर डाउनलोड फिर से शुरू;
4. व्यापकता - यह लक्ष्य ऑपरेटिंग सिस्टम (मुख्य रूप से विंडोज, मैक ओएस एक्स, लिनक्स) "बॉक्स से बाहर" या न्यूनतम संशोधनों के साथ काम करना चाहिए।

हम अपने स्वयं के प्रोटोकॉल को विकसित करने के लिए भी तैयार थे यदि मौजूदा वाले हमें सूट नहीं करते। लॉन्च के बाद प्रोटोकॉल बदलने के लिए बहुत सारे काम के घंटों की आवश्यकता होगी, इसलिए आपको विभिन्न विकल्पों का अध्ययन करना होगा और अपनी आवश्यकताओं को पूरा करने वाले सर्वश्रेष्ठ को चुनना होगा।

एफ़टीपी । फ़ाइलों के साथ दूरस्थ कार्य के लिए यह प्रोटोकॉल समय-परीक्षण है। लेकिन यह सूचना सुरक्षा आवश्यकताओं को ध्यान में रखे बिना बनाया गया था, जो हमारे लिए इसकी महत्वपूर्ण खामी बन गया। इसके अलावा, यह हमारे द्वारा आवश्यक कई ऑपरेशनों का समर्थन नहीं करता है, उदाहरण के लिए, फ़ाइल की सामग्री के साथ मेटाडेटा का स्थानांतरण। और इसे कनेक्ट करने के लिए विशेष एप्लिकेशन की आवश्यकता होती है।

BitTorrent । चूंकि हम तुरंत उपकरणों के बीच सिंक्रनाइज़ेशन के बारे में बात कर रहे थे, इसलिए सर्वर पर लोड बनाए बिना उनके बीच एक कनेक्शन का उपयोग करना बहुत उपयोगी होगा, लेकिन इसके लिए ग्राहक विकास पर दोहरे काम की आवश्यकता होगी। इसके अलावा, NAT और फ़ायरवॉल के माध्यम से काम करते समय समस्याएं होंगी, जो इस प्रोटोकॉल का उपयोग करने के लाभों को बहुत कम कर देगा।

अमेज़न S3 । यह रिपॉजिटरी अपने HTTP- आधारित प्रोटोकॉल का उपयोग करती है। हमने एपीआई एस 3 का उपयोग करने की संभावना पर विचार किया, हालांकि, हमने इस विचार को छोड़ दिया क्योंकि इसमें निर्देशिकाओं के साथ सामान्य काम की कमी और एक्सेस के लिए विशेष अनुप्रयोगों का उपयोग करने की आवश्यकता के कारण।

WebDAV । HTTP और XML और आसानी से एक्स्टेंसिबल के आधार पर, यह लगभग हर उस चीज का समर्थन करता है जिसकी हमें विनिर्देशों में आवश्यकता होती है। सभी लक्ष्य ऑपरेटिंग सिस्टम पर पहले से स्थापित पैकेज इसके साथ काफी अच्छी तरह से काम करते हैं। इसके अलावा, Yandex.Disk डेस्कटॉप क्लाइंट डेवलपमेंट डिपार्टमेंट, जो कि Yandex XMPP सर्वर से निपटता है, उस समय पहले से ही XML- आधारित ओपन प्रोटोकॉल के साथ काम करने का अनुभव था।

मुख्य कारण कि हम अपना स्वयं का प्रोटोकॉल नहीं बनाना चाहते थे, केवल यह था कि केवल हमारे अनुप्रयोग ही इसके साथ काम कर पाएंगे, और हम खुलेपन को चाहते थे।

परिणामस्वरूप, सभी विकल्पों पर चर्चा की, हमने WebDAV को चुना। प्रोटोकॉल में गायब एकमात्र चीज क्लाइंट को सर्वर पर परिवर्तनों के बारे में सूचित कर रही थी, जो सिंक्रनाइज़ेशन की एक बहुत महत्वपूर्ण विशेषता थी। लेकिन चूंकि प्रोटोकॉल एक्स्टेंसिबल है, इसलिए यह समस्या नहीं बनी।

प्रोटोकॉल का चयन करने के बाद, Yandex.Disk प्रोटोटाइप पर काम शुरू हुआ। हमने Erlang में अपना WebDAV सर्वर लिखा। वेब सर्वर के लिए रूपरेखा के रूप में, मोचीवब को चुना गया था, हमारे डेवलपर्स के लिए एक काफी हल्का और प्रसिद्ध पुस्तकालय। यह एक प्रसिद्ध लेख में एक मिलियन उपयोगकर्ताओं को एक सर्वर से कनेक्ट करने के बारे में भी इस्तेमाल किया गया था - एक मिलियन उपयोगकर्ता धूमकेतु अनुप्रयोग । हमने Yaws वेब सर्वर का उपयोग करने के बारे में भी सोचा, जिसकी तुलना Apache से की जा सकती है। यह एक पूर्ण वेब सर्वर है जो स्टेटिक्स को प्रस्तुत कर सकता है, CGI स्क्रिप्ट चला सकता है और सर्वर स्क्रिप्ट के साथ विशेष पृष्ठों को प्रोसेस कर सकता है। लेकिन यह सब हमें जरूरत नहीं थी। यदि हमने अभी प्रोजेक्ट करना शुरू किया है, तो विकल्प काउबॉय होगा, क्योंकि यह कनेक्शन समस्याओं की पहचान करने के लिए अधिक अवसर प्रदान करता है।

WebDAV प्रोटोकॉल का अध्ययन करने के बाद, सर्वर पर फ़ाइलों और निर्देशिकाओं को सूचीबद्ध करने के संचालन पर काम शुरू हुआ। प्रोटोटाइप के लिए भंडार के रूप में, एक mysql डेटाबेस का उपयोग किया गया था, जिसमें मेटा जानकारी और फ़ाइल सामग्री संग्रहीत करने के लिए एक नियमित फ़ाइल सिस्टम शामिल था। इस स्तर पर स्केलिंग और उच्च विश्वसनीयता की आवश्यकता नहीं थी।

लेआउट काफी सरल था, क्योंकि यह एक प्रोटोटाइप था। जैसा कि आमतौर पर फ़ाइल सिस्टम के साथ होता है, सवाल इस तरह से सीमाओं पर उठता है। चूंकि प्रोटोकॉल में संसाधन की अधिकतम पथ लंबाई निर्दिष्ट नहीं की गई थी, इसलिए पथ घटक की लंबाई 255 वर्ण और नेस्टिंग स्तर की संख्या को असीमित बनाने का निर्णय लिया गया था। मोटे तौर पर फ़ाइल संग्रहण तालिका इस तरह दिखती थी:

आईडी	संख्या, ऑटो वेतन वृद्धि, अद्वितीय संसाधन पहचानकर्ता
uid	उपयोगकर्ता, संसाधन स्वामी
पथ	स्ट्रिंग की लंबाई 255, संसाधन का नाम
टाइप	संसाधन प्रकार, फ़ाइल या निर्देशिका
माता-पिता	नंबर, मालिक आईडी
गहराई	नंबर, संसाधन नेस्टिंग स्तर क्वेरी प्रश्नों को अनुकूलित करने के लिए उपयोग किया जाता है

पहले गैर-तुच्छ कार्यों में से एक रूट को सूचीबद्ध कर रहा था, जिसमें कुछ भी नहीं है। कठिनाई यह है कि PROPFIND विधि , केवल लिस्टिंग के अलावा, संसाधन के गुणों को पढ़ने का कार्य भी करती है। अनुरोध को ठीक से जुदा करना आवश्यक था, यह समझने के लिए कि हम क्या जारी कर सकते हैं और क्या नहीं; सही उत्तर दें। पहले ग्राहक के रूप में, निर्मित उबंटू gvfs का उपयोग किया गया था। इसके साथ काम डिबग करने के बाद, हमने विंडोज 7 से कनेक्शन की जांच करने का फैसला किया और पाया कि यह हमारे साथ काम नहीं करता है। अन्य सर्वरों के साथ काम करने के एक अध्ययन से पता चला है कि अंतर्निहित विंडोज क्लाइंट "डीएवी:" नामस्थान को संसाधित नहीं करते हैं यदि यह उपसर्ग के बिना डिफ़ॉल्ट घोषित किया जाता है। अन्य मानक ग्राहक अधिक सहिष्णु निकले और विशेष रूप से विंडोज क्लाइंट के लिए निर्मित आउटपुट को आसानी से पचा लिया। सौभाग्य से, यह एकमात्र असंगतता थी जिसे हम खोजने में सक्षम थे।

जब लिस्टिंग पूरी हो गई, तो हमने निर्देशिका बनाने और संसाधनों को हटाने के तुच्छ कार्यों को लागू किया।

फिर मुझे फ़ाइलों को अपलोड करने का तरीका सीखने की जरूरत थी, लेकिन यह ऑपरेशन इतना सरल नहीं था। और क्यों - अगर यह विषय आपकी रुचि का है - हम अगली पोस्ट में बताएंगे।