एफ़टीपी प्रोटोकॉल + ASM पर एक साधारण एफ़टीपी क्लाइंट (दर्पण) के उदाहरण पर WinSocks!

यह इंटरनेट पर एक और लेख "लंबा चलना" है, और फिर से, लेखक के रूप में, मैं फिर से तैयार करूंगा। मुझे लगता है कि यह यहां उपयोगी है।

परिचय

इस लेख में मैंने अपने आप को FTP प्रोटोकॉल से संबंधित सभी RFC को वापस लेने का लक्ष्य निर्धारित नहीं किया है, जिनमें से कई हैं, आप उनमें बहुत अधिक जानकारी प्राप्त कर सकते हैं, मैं केवल आपको सामान्य शब्दों में FTP प्रोटोकॉल और क्लाइंट से इसके साथ काम करने की बुनियादी तकनीकों से परिचित कराने का प्रयास करूंगा।

एफ़टीपी अवलोकन

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



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



नियंत्रण कनेक्शन स्थापित होने के बाद, क्लाइंट इसके माध्यम से सर्वर को विभिन्न कमांड भेज सकता है। प्रत्येक कमांड में 3 या 4 अपरकेस ASCII वर्ण होते हैं, इसके बाद एक या अधिक रिक्त स्थान होते हैं, कुछ कमांड में वैकल्पिक तर्क होते हैं। कोई भी आदेश सीआर, एलएफ की एक जोड़ी के साथ समाप्त होता है - यह निस्संदेह सभी 0dh, 0ah के लिए जाना जाता है - अगर यह डॉस / विंडोज के लिए आता है। सामान्य शब्दों में, कमांड स्कीम इस प्रकार है:



कमांड [तर्क (एस)] सीआर, एलएफ।



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



उपयोगकर्ता नाम

उपयोगकर्ता नाम निर्दिष्ट करता है



पासवर्ड पास करें

उपयोगकर्ता पासवर्ड निर्दिष्ट करता है



सूची फ़ाइल सूची

फ़ाइल सूची अनुरोध



PORT n1, n2, n3, n4, n5, n6

डेटा कनेक्शन के लिए IP और पोर्ट निर्दिष्ट करें



RETR फ़ाइल का नाम

सर्वर से फाइल प्राप्त करें



STOR फ़ाइल का नाम

सर्वर पर फ़ाइल रखो



प्रकार

प्रेषित डेटा का प्रकार



QUIT

सर्वर से डिस्कनेक्ट करें



ABOR

पिछला आदेश रद्द करें। डेटा ट्रांसफर की समाप्ति।





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

• 1xx कमांड निष्पादन की प्रक्रिया में है, अगली कमांड देने से पहले किसी अन्य संदेश की प्रतीक्षा करना आवश्यक है।
• 2xx टीम पूरी हुई। सर्वर अगले एक का इंतजार कर रहा है।
• 3xx कमांड पूरी हो गई है, लेकिन जारी रखने के लिए एक और कमांड की आवश्यकता है
• 4xx कमांड पूरी नहीं हुई थी, आपको कमांड को दोहराना और दोहराना होगा
• 5xx आदेश निष्पादित नहीं किया गया है और दोहराते समय निष्पादित नहीं किया जाएगा।

प्रतिक्रिया का दूसरा अंक आपको न्याय करने की अनुमति देता है कि किस स्थिति में प्रतिक्रिया हुई:

• x0x सिंटेक्स त्रुटि।
• X1x जानकारी।
• x2x प्रतिक्रिया प्रबंधक या डेटा कनेक्शन की स्थिति को संदर्भित करता है।
• x3x रिस्पांस उपयोगकर्ता प्रमाणीकरण या बजट स्थिति को संदर्भित करता है।
• x4x निश्चित रूप से नहीं।
• x5x रिस्पांस फ़ाइल सिस्टम की स्थिति को संदर्भित करता है।

और अंत में, प्रतिक्रिया के तीसरे अंक में अतिरिक्त जानकारी होती है।



इस तथ्य पर विशेष रूप से ध्यान दिया जाना चाहिए कि यद्यपि सर्वर एक प्रतिक्रिया के साथ अधिकांश कमांड का जवाब देता है, लेकिन व्यापक रूप से उपयोग किए जाने वाले कमांड भी हैं, जिसके जवाब में सर्वर कई प्रतिक्रियाएं उत्पन्न करता है। इस स्थिति में, पहली प्रतिक्रिया का पहला अंक "1" होगा - अर्थात यदि आप ऊपर दी गई तालिकाओं को देखते हैं, तो सर्वर हमें बताता है कि अगली कमांड भेजने से पहले उसके लिए दूसरे संदेश की प्रतीक्षा करना आवश्यक है। इस तरह के कमांड का एक उदाहरण RETR कमांड है, जब सर्वर इसे प्राप्त करता है और डेटा भेजना शुरू करता है, तो यह हमारे साथ कुछ इस तरह से प्रतिक्रिया करता है: "HIDE.ASM (958 बाइट्स) के लिए 150 ओपनिंग बैनरी मोड डेटा कनेक्शन।" - संदेश का अर्थ "डेटा ट्रांसफर" कम हो गया है। "। फिर, जब डेटा पहले ही उन्हें भेजा जा चुका है (लेकिन फिर से मैं ध्यान केंद्रित करना चाहता हूं - इस तथ्य को नहीं कि क्लाइंट ने इसे प्राप्त किया), तो वह नियंत्रण कनेक्शन के माध्यम से एक और प्रतिक्रिया भेजेगा - "226 फ़ाइल ठीक है।" - i.e. "फ़ाइल भेजी गई।" लेकिन इस मामले में, केवल दूसरा संदेश प्राप्त करने के बाद ही सर्वर अगले कमांड को निष्पादित करने के लिए तैयार है। अंतिम संदेश के बजाय, हमें "4" से शुरू होने वाला त्रुटि संदेश मिल सकता है - अगर फ़ाइल स्थानांतरण में कोई समस्या है।



सामान्य शब्दों में, यह सब नियंत्रण कनेक्शन के बारे में है।



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



आमतौर पर, एक डेटा कनेक्शन निम्नानुसार खोला जाता है:

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

एक छोटा विषयांतर: यदि आप ध्यान से दूसरे पैराग्राफ को पढ़ते हैं, तो सवाल उठ सकता है - "यदि हम सर्वर को डमी एड्रेस और पोर्ट देते हैं तो क्या होगा?" उत्तर अस्पष्ट है, सर्वर आईपी पते की जांच कर सकता है, लेकिन यह हमेशा नहीं होता है, इसलिए डमी पते का उपयोग करके कुछ दिलचस्प "परेशानियां" होती हैं।



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



यह सभी मुख्य बात है जो मैं डेटा कनेक्शन के बारे में बात करना चाहता था।



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



Txxxxxxxxx [] uk [] उपयोगकर्ता [] समूह [] आकार [] मिमी [] dd [] yytt [] नाम CR, LF



जहां,



टी - तत्व का प्रकार ("डी" - निर्देशिका, "-" - फ़ाइल, "एल" - लिंक, आदि);

xxxxxxxxx - फ़ाइल सुरक्षा विशेषताएँ;

उपयोगकर्ता - उपयोगकर्ता, फ़ाइल स्वामी;

समूह - मालिक समूह;

आकार - तत्व का आकार;

मिमी - पाठ के रूप में एक तत्व बनाने का महीना, उदाहरण के लिए, "जूल";

dd - महीने का दिन आइटम बनाया गया था;

yytt - यहां वह वर्ष या समय हो सकता है जब आइटम बनाया गया था;

नाम - तत्व का नाम (फ़ाइल, निर्देशिका, लिंक);

[] - एक या एक से अधिक रिक्त स्थान।



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

यह कैसे काम करना चाहिए?

आइए थोड़ा सा खुदाई करें और देखें कि "अंदर से" फ़ाइल प्राप्त करने के लिए एफ़टीपी सत्र कैसा दिखना चाहिए। तो, हम क्लाइंट शुरू करते हैं। इस समय सर्वर पहले से ही निष्क्रिय रूप से खोला गया है और 21 वें पोर्ट पर सुनता है। सबसे पहले, हमें एक नियंत्रण कनेक्शन बनाने की आवश्यकता है - हम पोर्ट 21 पर एक सर्वर से कनेक्ट कर रहे हैं। आगे क्या? जैसे ही हम सफलतापूर्वक बनाए गए नियंत्रण कनेक्शन के माध्यम से सर्वर के साथ लॉग इन करते हैं, हमें सर्वर से एक ग्रीटिंग प्राप्त होता है, यह कुछ ऐसा होगा जैसे "Alt VS 2.2 पर Shpakovsky" 220 वीएसएफटीपी बहरा आधार।



अगला चरण पंजीकरण होना चाहिए - मान लें कि हम एक अनाम सर्वर से कनेक्ट होते हैं - एक नियंत्रण कनेक्शन के माध्यम से, क्लाइंट सर्वर को USER अनाम कमांड भेजता है, जिससे, यदि सर्वर किसी अनाम उपयोगकर्ता का समर्थन करता है, तो हमें जवाब मिलता है: "331 कृपया पासवर्ड निर्दिष्ट करें।" - "कृपया एक पासवर्ड प्रदान करें", ध्यान दें। सर्वर की प्रतिक्रिया में संख्या "3", जिसका अर्थ है कि आगे एक आदेश जारी रखने के लिए आवश्यक है, जो कि ग्राहक वास्तव में करता है - पासवर्ड 1 @ 1 कमांड - डमी ई-मेल को पासवर्ड के रूप में निर्दिष्ट करें। हम सर्वर की प्रतिक्रिया क्या प्राप्त करते हैं «230 लॉगिन सफल। मज़े करो। "-" पंजीकरण सफल रहा। "



यही है, अब हमारी क्रियाएं इस बात पर निर्भर करती हैं कि हम क्या चाहते हैं, और जैसा कि ऊपर उल्लेख किया गया है, हम सर्वर से एक फ़ाइल प्राप्त करना चाहते हैं, उदाहरण के लिए, इसे सर्वर की रूट डायरेक्टरी में स्थित "HIDE.EXE" फाइल होने दें। सर्वर को डेटा प्राप्त करने या प्रसारित करने से पहले, यह इंगित करना आवश्यक है कि किस प्रकार का डेटा संचारित किया जाएगा, यह TYPE N कमांड के साथ किया जाता है, जहां N = "A" यदि टाइप ASCII और N = "I" है यदि फाइल बाइनरी है। क्लाइंट सर्वर को एक TYPE I कमांड भेजता है, जिससे उसे प्रतिक्रिया मिलती है - "बाइनरी मोड में 200 स्विचिंग।"।



तो, यह केवल फ़ाइल प्राप्त करने के लिए बनी हुई है। ऐसा करने के लिए, क्लाइंट को डेटा कनेक्शन खोलना होगा। क्लाइंट द्वारा एक मुफ्त पोर्ट चुना जाता है, निष्क्रिय उद्घाटन किया जाता है, अर्थात। ग्राहक उसे सुनता है। इसके बाद, क्लाइंट को सर्वर को अपना आईपी पता और पोर्ट नंबर बताने की जरूरत है कि यह सिर्फ निष्क्रिय रूप से खोला गया है (मान लीजिए क्लाइंट का होस्ट आईपी पता 10.21.23.10 है, और पोर्ट नंबर 2000 है)। क्लाइंट एक PORT कमांड 10,21,23,10,7,208 - "किस तरह का 7,208?" - सर्वर से कंट्रोल कनेक्शन के माध्यम से भेजता है - आप पूछते हैं। यह पोर्ट नंबर है; इसे इस तरह बनाया गया है - 7 * 256 + 208 = 2000। इस कमांड को प्राप्त करने के बाद, सर्वर सक्रिय रूप से निर्दिष्ट पोर्ट को खोलने का प्रयास करेगा और, यदि सफल होता है, तो कुछ ऐसा लौटाएगा जैसे “200 पोर्ट कमांड सफल। PASV का उपयोग करने पर विचार करें। "



सब कुछ, डेटा कनेक्शन स्थापित है, यह सर्वर को डेटा स्थानांतरित करने के लिए कमांड देने के लिए बना हुआ है, जो क्लाइंट करता है - RETR HIDE.EXE, जिसके लिए यदि सब कुछ ठीक है (फ़ाइल मौजूद है और स्थानांतरित किया जा सकता है), तो सर्वर HIDE.EXE के लिए 150 ओपनिंग बैनरी मोड डेटा कनेक्शन के साथ प्रतिक्रिया करता है। (4096 बाइट्स)। ”और डेटा कनेक्शन पर फ़ाइल को मर्ज करना शुरू करता है। फिर से मैं उत्तर के पहले अंक पर आपका ध्यान आकर्षित करता हूं। जब फ़ाइल पूरी तरह से भेज दी जाती है, तो सर्वर "226 फ़ाइल को भेजें ओके" संदेश भेज देगा और डेटा कनेक्शन बंद कर देगा।



क्लाइंट अपनी तरफ से डेटा प्राप्त करने के अंत की प्रतीक्षा करता है (जैसा कि सर्वर से एक संदेश प्राप्त होने से प्राप्त होता है + डेटा कनेक्शन बंद करना, बारीकियां हैं, लेकिन बाद में उनके बारे में अधिक) और फिर उसके हिस्से के लिए डेटा कनेक्शन पोर्ट बंद कर देता है।



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



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

बोध।

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



तो चलिए शुरू करते हैं। मुख्य एप्लिकेशन विंडो बनाते समय, हम प्रोग्राम के मुख्य आरंभीकरण को पूरा करते हैं, मुख्य बिंदुओं को समझाते हैं:



call VirtualAlloc,ebx,1024000,MEM_COMMIT+MEM_RESERVE,PAGE_READWRITE

mov ReciveDataBufferOffset,eax

call VirtualAlloc,ebx,10240,MEM_COMMIT+MEM_RESERVE,PAGE_READWRITE

mov ReciveCommandBufferOffset,eax

(1 ) (10 ).



call CreateEventA,ebx,ebx,ebx,ebx

mov HDataReciveEvent,eax

……

event () .



call CreateThread,ebx,ebx,offset ReciveThread,offset ReciveDataThreadStruc, \

NORMAL_PRIORITY_CLASS,offset ThreadID_data

call CreateThread,ebx,ebx,offset ReciveThread,offset ReciveCommandThreadStruc,\

NORMAL_PRIORITY_CLASS,offset ThreadID_command

2 – , . , .



call gethostname, offset HostName,64

call gethostbyname,offset HostName

…..

mov PortInPort,esi

ret 0







उपरोक्त पंक्तियों का अर्थ हमारे होस्ट का आईपी पता, थोड़ा रूपांतरण और इसे एक अलग स्थान पर लिखना है, हमें PORT कमांड निष्पादित करने के लिए होस्ट एड्रेस की आवश्यकता है।



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



मुख्य विंडो प्रक्रिया में, एप्लिकेशन का मुख्य प्रवाह बनाया जाता है, इसके प्रमुख बिंदुओं पर विचार करें।



प्रारंभ में, हम डेटा प्राप्त करने से संबंधित चर को आरंभ करते हैं और संवाद बॉक्स से उपयोगकर्ताओं (सर्वर, पासवर्ड, आदि) द्वारा दर्ज किए गए कनेक्शन मापदंडों को प्राप्त करते हैं। उसके बाद, हमें सर्वर के साथ एक कंट्रोल कनेक्शन बनाने की जरूरत है, जो हम करते हैं:



- ;

call socket, AF_INET, SOCK_STREAM, IPPROTO_TCP

mov ReciveCommandSock,eax

- ,

,

.

call WSAAsyncSelect, ReciveCommandSock, newhwnd, WM_COMMANDSOCK,FD_READ+FD_CONNECT

-

…..

call connect,ReciveCommandSock,offset sockaddr_in,16

- FD_CONNECT,

call SetEvent,HWaitConnectEvent ,

,

5 , .

call WaitForSingleObject,HWaitConnectEvent,5000

call ResetEvent,HWaitConnectEvent

- , 5

, - . WaitAnswerRecive .

call WaitAnswerRecive,5000

or eax,eax

jnz errorwithregisration







- फ़ंक्शन के लिए इनपुट पैरामीटर अंतराल है, जिसके दौरान फ़ंक्शन होगा

सर्वर प्रतिक्रिया की प्रतीक्षा करें, यदि निर्दिष्ट अंतराल, फ़ंक्शन के लिए कोई प्रतिक्रिया नहीं मिली है

त्रुटि संदेश प्रदर्शित करता है और ईगल रजिस्टर के गैर-शून्य मान से बाहर निकलता है।



WaitAnswerRecive proc TimeToWait:dword

call WaitForSingleObject,HWaitCommandEvent,TimeToWait

- HWaitCommandEvent,

, .

or eax,eax

jz NoTimeOutGet

call MessageBoxA,newhwnd,offset ErrTimeOutCommand,offset ErrorCap,40h

call ResetEvent,HWaitCommandEvent

- HWaitCommandEvent .. ,

.

NoTimeOutGet:

ret

WaitAnswerRecive endp







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



नियंत्रण और डेटा कनेक्शन पर डेटा प्राप्त करने के लिए एक सार्वभौमिक व्यापार नीचे दिया गया है।



- ReciveDataThreadStruc

ReciveCommandThreadStruc .

ReciveCommandThreadStruc :

- ;

HCommandReciveEvent dd ?

- , ;

HWaitCommandEvent dd ?

- ;

ReciveCommandBufferOffset dd ?

- ;

BytesCommandRecived dd 0

- , ;

ReciveCommandSock dd ?



ReciveThread proc parametr:dword

mov edi,parametr

InfinityLoop:

- , ;

call WaitForSingleObject,dword ptr [edi],-1

- esi , - +

;

mov esi,[edi+8]

add esi,[edi+12]

- 4096 ;

call recv,dword ptr [edi+16],esi,4096,0

- , ;

add [edi+12],eax

- ebx , , ;

mov ebx,[edi+4]

-

, -

;

cmp edi,offset ReciveDataThreadStruc

je comparefordata

-

0dh, 0ah, ;

mov eax,[edi+12]

mov esi,[edi+8]

cmp byte ptr [esi+eax-1],10

je short CallEvent

jmp InfinityLoop

comparefordata:

- , = ;

mov eax,[edi+12]

cmp FileLenght,eax

jne InfinityLoop

CallEvent:

- ;

call SetEvent,ebx

jmp InfinityLoop

ReciveThread endp







चलो मुख्य धागे पर वापस जाते हैं, हमें सर्वर से सफलतापूर्वक प्रतिक्रिया मिली, जिसमें वह कमांड प्राप्त करने के लिए तैयार है, अब हम इसे कमांड भेज सकते हैं, इस कार्यान्वयन में, SendCommandInSocket फ़ंक्शन सर्वर को कमांड भेजने के लिए जिम्मेदार है, मुख्य सूत्र में हम इस फ़ंक्शन को भेजने के लिए कहते हैं। सर्वर क्रमिक रूप से आदेश देता है: USER, PASS, TYPE, CWD, PORT और LIST। फ़ंक्शन स्वयं इस तरह दिखता है:



- , , ,

;

SendCommandInSocket proc uses ebx ecx esi edi, hSocket:dword, OutBufOffset:dword

- ;

mov edi,OutBufOffset

push edi

mov eax,0ah

mov ecx,100

repne scasb

sub edi,OutBufOffset

mov ecx,edi

pop esi

push edi

- , ,

;

mov edi,ReciveCommandBufferOffset

add edi,BytesCommandRecived

rep movsb

pop edi

add BytesCommandRecived,edi

- ;

call send,hSocket,OutBufOffset,edi,ebx

- , WaitAnswerRecive;

mov eax,5001

Wait2Answer:

dec eax

push eax

call WaitAnswerRecive

or eax,eax

jnz ErrorProcessed

- , , ,

, ,

.

.

mov edi,ReciveCommandBufferOffset

mov ecx,BytesCommandRecived

dec ecx

dec ecx

add edi,ecx

mov al,0ah

std

repne scasb

cld

xor eax,eax

- ;

mov cl,[edi+2]

cmp cl,'1'

- "1"

jz Wait2Answer

cmp cl,'3'

- "3" - ;

jna NoErrorProcessed

call MessageBoxA,newhwnd,edi,offset ErrorCap,40h

ErrorProcessed:

xor eax,eax

inc eax

NoErrorProcessed:

ret

SendCommandInSocket endp







एक और बात पर विचार करें: PORT कमांड भेजने से पहले, हमें एक सुनने वाला सॉकेट बनाने की आवश्यकता है, हम CreateListenSock प्रक्रिया को कॉल करके ऐसा करते हैं।



CreateListenSock proc

pushad

- ;

call socket, AF_INET, SOCK_STREAM, IPPROTO_TCP

mov datasock,eax

- - , ,

,

, ;

call WSAAsyncSelect, datasock, newhwnd, WM_DATASOCK, FD_ACCEPT+FD_READ+FD_CLOSE

- ;

mov sin_port,0 ; ,

;

mov sin_family,AF_INET

mov sin_addr,INADDR_ANY

call bind, datasock, offset sockaddr_in, 16

- ;

call getsockname,datasock,offset sockaddr_in,offset szSockaddr_in

- ;

xor eax,eax

mov ax,sin_port

call ntohs,eax

push eax

shr eax,8

- ASCII;

call DECtoASCII,eax,PortInPort

- PORT

mov al,','

stosb

pop eax

and eax,0ffh

call DECtoASCII,eax,edi

mov ax,0a0dh

stosw

mov esi,PortInPort

- ;

call listen, datasock, 1

popad

ret

CreateListenSock endp







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



-

, , .

WaitTransferComplete proc uses ecx edi, TimeToWaitEndTransfer:dword

WaitProgress:

- ,

;

call WaitForSingleObject,HWaitCloseEvent,-1

- , ,

;

call WaitForSingleObject,HWaitDataEvent,TimeToWaitEndTransfer

or eax,eax

jz CloseDataSocks

- , , , ..

, ,

;

cmp TimeToWaitEndTransfer,1000 ;

jz CloseDataSocks

call MessageBoxA,newhwnd,offset ErrTimeOutCommand,offset ErrorCap,40h



CloseDataSocks:

- ;

call ResetEvent,HWaitDataEvent

- ;

call closesocket,ReciveDataSock

call closesocket,datasock

ret

WaitTransferComplete endp







ऊपर की प्रक्रिया के सफल समापन के मामले में, निर्देशिका तालिका डेटा रिसेप्शन बफर में झूठ होगी। कार्यक्रम के नीचे, हम परिणामी तालिका को संसाधित करते हैं और इसमें प्राप्त सभी फाइलों को प्राप्त करते हैं, एक फाइल प्राप्त करना निर्देशिका प्राप्त करने से अलग नहीं है, इसलिए मैं यहां इसका वर्णन नहीं करूंगा। सभी फाइलें प्राप्त होने और सहेजे जाने के बाद, हम नियंत्रण कनेक्शन को बंद कर देते हैं और स्ट्रीम को समाप्त कर देते हैं।

निष्कर्ष।

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