सिल्वरलाइट + नेगनेक्स = रेज़्यूमेबल ब्राउज़र फ़ाइल डाउनलोड

यह आलेख Files@mail.ru परियोजना पर अक्षय फ़ाइल डाउनलोड के संगठन के लिए सिल्वरलाइट-क्लाइंट को लागू करने के अनुभव पर चर्चा करता है।



इसकी आवश्यकता क्यों है? मुझे लगता है कि यह बताने की आवश्यकता नहीं है कि सर्वर पर फाइलें अपलोड करना और उन्हें संग्रहीत करना अब बहुत बड़ी संख्या में वेब परियोजनाएं प्रदान करता है, छोटे से बहुत बड़े पैमाने पर। इसके अलावा, डाउनलोड आमतौर पर सामान्य <input type=file/>



के रूप में लागू किया जाता है, कम अक्सर - फ्लैश का उपयोग करना, यहां तक ​​कि कम - अन्य तरीकों से (हम इस लेख में एफ़टीपी डाउनलोड पर विचार नहीं करते हैं)।



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



क्या करें?

हमें ऐसी जिंदगी कैसे मिली

एक फ़ाइल की सामग्री को पढ़ने के लिए FileReference.load () विधि के समर्थन के साथ एडोब फ्लैश 10 के नए संस्करण के बारे में पहली अफवाहों ने हमें प्रेरित किया। लेकिन वहाँ यह था: Adobe "हर किसी को पछाड़ दिया"। FileReference.load () विधि पूरी तरह से फ़ाइल की संपूर्ण सामग्री को कंप्यूटर की मेमोरी में लोड करती है, जिससे एक बड़ी फ़ाइल (प्रयोगों में, फ़ाइल पहले से ही "बड़े" 2 जीबी रैम वाले कंप्यूटर पर 500 एमबी के बारे में पढ़ने की कोशिश करते हुए "मशीन को निलंबित" करती है)। इसके अलावा, फ़्लैश 2GB से बड़ी फ़ाइलों का समर्थन नहीं करता है।



हम दुखी और निराश थे। इसके अलावा, सर्वर साइड से आंशिक लोडिंग के लिए समर्थन की तत्काल आवश्यकता थी, और यह स्वयं करने के लिए बहुत आलसी था।



और एक बार जब हमने सोचा: "और चलो सिल्वरलाइट को देखते हैं, तो शायद यह हमें फ्लैश से अधिक कुछ देगा?" - और हमसे गलती नहीं हुई थी।



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



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



Valery के समर्थन से, हमने एक सिल्वरलाइट क्लाइंट लिखना शुरू किया और सर्वर मॉड्यूल के साथ "डॉक" किया ...

सुखद अंत

क्लाइंट कोड को फिर से लिखने और इसका परीक्षण करने के घंटों के बाद, हमें अंत में पहला काम करने का विकल्प मिला।



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



अपने मॉड्यूल में कीड़े को जल्दी से ठीक करने के लिए वैलेरी के लिए बहुत धन्यवाद, और सिल्वरलाइट और सी # से लड़ने के लिए।



अगस्त के एक दिन में, हमने आखिरकार पाए गए सभी बगों का परीक्षण किया और उन्हें ठीक किया और मेल का उपयोग करने में विफल रहे।



और अंत में - स्टूडियो में एक निर्णय!

क्लाइंट-सर्वर इंटरैक्शन के बारे में थोड़ा

डाउनलोड निम्नानुसार है।



क्लाइंट प्रत्येक अपलोड की गई फ़ाइल के लिए एक अद्वितीय सत्र पहचानकर्ता बनाता है।

SessionId = (1100000000 + new Random ().Next(10000000, 99999999)).ToString();



* This source code was highlighted with Source Code Highlighter .

इसके अलावा, प्रत्येक फ़ाइल के लिए, एक हैश माना जाता है, जिसका उद्देश्य विशिष्ट रूप से उपयोगकर्ता के कंप्यूटर के भीतर एक अद्वितीय फ़ाइल की पहचान करना है।

UniqueKey = "" ;

try

{

if (FileLength < Constants.MinFilesizeToAdd)

{

throw new Exception();

}

// Adler32 version to compute "unique" file hash

// UniqueKey will be Constants.NumPoints * sizeof(uint) length

int part_size = ( int )((file.Length / Constants.NumPoints) < Constants.MaxPartSize ? file.Length / Constants.NumPoints : Constants.MaxPartSize);

byte [] buffer = new Byte [part_size];

byte [] adler_sum = new Byte [Constants.NumPoints * sizeof ( uint ) / sizeof ( byte )];

int current_point = 0;

int bytesRead = 0;

Stream fs = file.OpenRead();

AdlerChecksum a32 = new AdlerChecksum();

while (current_point < Constants.NumPoints && (bytesRead = fs.Read(buffer, 0, part_size)) != 0)

{

a32.MakeForBuff(buffer, bytesRead);

int mask = 0xFF;

for ( int i = 0; i < sizeof ( uint ) / sizeof ( byte ); i++)

{

UniqueKey += ( char )((mask << (i * sizeof ( byte )) & a32.ChecksumValue) >> (i * sizeof ( byte )));

}

fs.Position = ++current_point * file.Length / Constants.NumPoints;

}

}

catch (Exception) { }



* This source code was highlighted with Source Code Highlighter .

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



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

UriBuilder ub = new UriBuilder(UploadUrl);

HttpWebRequest webrequest = (HttpWebRequest)WebRequest.Create(ub. Uri );

webrequest.Method = "POST" ;

webrequest.ContentType = "application/octet-stream" ;

// Some russian letters in filename lead to exception, so we do uri encode on client side

// and uri decode on server side

webrequest.Headers[ "Content-Disposition" ] = "attachment; filename=\"" + HttpUtility.UrlEncode( File .Name) + "\"" ;

webrequest.Headers[ "X-Content-Range" ] = "bytes " + currentChunkStartPos + "-" + currentChunkEndPos + "/" + FileLength;

webrequest.Headers[ "Session-ID" ] = SessionId;

webrequest.BeginGetRequestStream( new AsyncCallback(WriteCallback), webrequest);



* This source code was highlighted with Source Code Highlighter .

सर्वर से रेंज प्रतिक्रिया के हेडर में इस फाइल की बाइट रेंज की एक सूची आती है जो पहले से ही सर्वर पर अपलोड होती है। यह सूची उत्तर की बॉडी में भी डुप्लिकेट है (क्या डुप्लिकेट के लिए - नीचे देखें)।



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



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

सिल्वरलाइट की सीमाएँ जिन्हें हमें काम करना था:

1. आप कंटेंट-रेंज हेडर सेट नहीं कर सकते हैं, इसलिए हम एक्स-कंटेंट-रेंज हेडर का उपयोग करते हैं



2. सर्वर रिस्पांस कोड को मज़बूती से निर्धारित करना असंभव है, हम केवल 200 या 404 कोड देखते हैं (सिल्वरलाइट में ब्राउज़र HTTP स्टैक का उपयोग करते समय)



3. सिल्वरलाइट में क्लाइंट HTTP स्टैक का उपयोग करते समय, हम प्रॉक्सी प्राधिकरण खो देते हैं और मैन्युअल रूप से कुकीज़ सेट करने के लिए मजबूर होते हैं, लेकिन हम सर्वर प्रतिक्रिया कोड को सटीक रूप से निर्धारित कर सकते हैं - इसलिए, हम 201 प्रतिक्रिया कोड को निर्धारित करने के लिए कुछ ट्रिक्स के साथ HTTP ब्राउज़र स्टैक का उपयोग करते हैं:

if (ResponseText != null && ResponseText.Length != 0)

{

// We cannot check response.StatusCode, see comments in constructor of FileUploadControl

if (Regex.IsMatch(ResponseText, @"^\d+-\d+/\d+" )) // we got 201 response

{

...

}

else // we got 200 response

{

BytesUploaded = FileLength;

}

}



* This source code was highlighted with Source Code Highlighter .

4. बड़ी फ़ाइलों पर "सही" फ़ाइल हैश (उदाहरण के लिए, md5) की गणना में बहुत समय लगता है - दसियों सेकंड - जो अस्वीकार्य है, इसलिए हम 100KB की फ़ाइल के 50 भागों को लेते हैं, प्रत्येक भाग के लिए हम Adler32 एल्गोरिदम का उपयोग करके राशि की गणना करते हैं (यह एल्गोरिथ्म चुना गया था) एक परिचित हैकर की सलाह पर इसकी उच्च गति के कारण) और फिर अलग-अलग मात्राओं को सम्‍मिलित करें - यह "विशिष्ट" फ़ाइल हैश है



5. फ़ाइल नाम में कुछ रूसी अक्षरों की उपस्थिति में सिल्वरलाइट (अक्षर "z" निश्चित रूप से Microsoft के विश्वास में गिर गया) ने लाइन में एक अपवाद फेंक दिया ...

webrequest.Headers[ "Content-Disposition" ] = "attachment; filename=\"" + File .Name + "\"" ;



* This source code was highlighted with Source Code Highlighter .

... इसलिए मुझे एक संशोधन करना पड़ा - फ़ाइल का नाम बूट पर सांकेतिक शब्दों में बदलना और सर्वर पर डिकोड करना

webrequest.Headers[ "Content-Disposition" ] = "attachment; filename=\"" + HttpUtility.UrlEncode( File .Name) + "\"" ;



* This source code was highlighted with Source Code Highlighter .

6. भले ही बफ़र्स को एक निश्चित संख्या में बाइट्स लोड करने के बाद रीसेट किया जाता है, सिल्वरलाइट POST अनुरोध को कैश करता है और इसे पूरी तरह से भेजता है। यह पूरी फ़ाइल (विखंडू के बिना) डाउनलोड करना असंभव बनाता है, क्योंकि बड़ी फ़ाइलों पर, क्लाइंट की मेमोरी अनुरोध को बफर करने के लिए पर्याप्त नहीं है। यह सुविधा पर्याप्त रूप से डाउनलोड प्रगति को प्रदर्शित करना असंभव बना देती है।



इसलिए, हम 0% से 100% तक की प्रगति को प्रदर्शित करने के लिए फ़ाइल को 100 चंक्स में विभाजित करने का प्रयास कर रहे हैं, लेकिन साथ ही साथ क्रमशः बहुत बड़ी और बहुत छोटी फाइलों के मामलों के लिए ऊपर और नीचे के चंक के आकार को सीमित करते हैं, जिससे 100 से अधिक विखंडन हो सकते हैं, इतना कम।

public long FileLength

{

get { return fileLength; }

set

{

fileLength = value ;

ChunkSize = ( long )(fileLength / (100 / Constants.PercentPrecision));

if (ChunkSize < Constants.MinChunkSize)

ChunkSize = Constants.MinChunkSize;

if (ChunkSize > Constants.MaxChunkSize)

ChunkSize = Constants.MaxChunkSize;

}

}



* This source code was highlighted with Source Code Highlighter .

7. ओपेरा में एक अप्रिय बग है (यह पहले से ही भटक जाना संभव है, जो एक): यदि सर्वर से प्रतिक्रिया में शून्य-लंबाई वाला शरीर है, तो सिल्वरलाइट प्रतिक्रिया रीडर रीडिंग हैंडलर को नहीं बुलाता है। यही कारण है कि हमने Valery को सर्वर प्रतिक्रिया के शरीर में डाउनलोड बाइट्स की सीमा को डुप्लिकेट करने के लिए कहा।



हमने बहुत सारी अप्रिय रेक पर कदम रखा, और हम चाहते हैं कि अन्य डेवलपर्स का रास्ता कम कांटेदार हो। इसलिए, हमने क्लाइंट पार्ट कोड खोलने का फैसला किया। मिलिए MrUploader से । साथ में Valery Kholodkov के nginx-upload मॉड्यूल, यह विशेष रूप से स्वादिष्ट है।