NDIS। NET_BUFFER वास्तुकला

हम NDIS के बारे में लेखों की आरंभिक श्रृंखला जारी रखते हैं। इस विषय में, हम NDIS के संस्करणों और "स्टैक" के ड्राइवरों और NET_BUFFER के आर्किटेक्चर के बीच पैकेट हस्तांतरण के सिद्धांतों पर विचार करते हैं।

परिचय

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

• एनडीआईएस 5.1। Windows XP, Server 2003. अधिकांश ड्राइवर इस संस्करण के लिए लिखे गए हैं और कोई भी उन्हें पोर्ट नहीं करने जा रहा है, क्योंकि वहां पोर्ट करने के लिए कुछ खास नहीं है - लगभग सब कुछ फिर से लिखना होगा;
• एनडीआईएस 5.2। विंडोज सर्वर 2003 SP2। इस संस्करण के लिए, सबसे अधिक संभावना है कि एक भी ड्राइवर नहीं लिखा गया है, क्योंकि यहाँ 5.1 से ड्राइवर ठीक काम करते हैं;
• एनडीआईएस 6.0। विंडोज विस्टा विंडोज विस्टा में एनडीआईएस सबसिस्टम में भारी बदलाव आया है, नए प्रकार के ड्राइवरों को जोड़ा गया है, प्रदर्शन में सुधार किया गया है;
• NDIS 6.1। विंडोज विस्टा SP2, सर्वर 2008. एनडीआईएस 5.2 जैसी ही कहानी;
• एनडीआईएस 6.20। विंडोज 7. एनडीआईएस 6.0 के बारे में मामूली बदलाव, अनुकरण मोड में बाद के लिए समर्थन।

मैं W2K के रूप में अपने NDIS 4.0 के साथ पुराने कूड़ेदान को नहीं छूऊंगा, क्योंकि इसका समर्थन करने का कोई मतलब नहीं है। Microsoft विंडोज 8 में NDIS 5.1 का समर्थन करना भी बंद कर देता है।
जैसा कि आप सूची से देख सकते हैं, एक बड़ा अंतर NDIS 5.x और NDIS 6.x के बीच स्थित है। वास्तव में, कुल से उनके पास केवल एक वास्तुशिल्प सुविधा और कार्यों का एक पुस्तकालय था। उत्पादकता बढ़ाने के लिए शेष फिलिंग को स्थानांतरित किया गया। वैसे, 20% ने इस वृद्धि की जांच की है, इसलिए कम से कम विस्टा अपने पूर्ववर्ती की तुलना में बेहतर है। फ़िल्टर ड्राइवरों को आर्किटेक्चर में जोड़ा गया था, जो पिछले संस्करणों में कमी थी। पैकेट ट्रांसमिशन के सिद्धांत नाटकीय रूप से बदल गए हैं, अर्थात्: यदि मध्यवर्ती चालक को पैकेट प्राप्त करने और भेजने के कम से कम तीन कार्यों को लागू करना था, तो अब इन कार्यों की संख्या किसी भी मामले में एक है। यह NET_BUFFER नामक एक नए पैकेट हस्तांतरण आर्किटेक्चर के लिए संभव बनाया गया है। हम इसके बारे में नीचे बात करेंगे।

NET_BUFFER वास्तुकला

तो क्या है? वास्तव में, NET_BUFFER पिछले NDIS_BUFFER'y के लिए एक प्रतिस्थापन है, लेकिन पहले चीजें पहले। क्या था? पैकेट भेजने और प्राप्त करने के लिए ड्राइवर तीन कार्यों को लागू करता है। रूसी में, हम इन कार्यों को इस तरह कहते हैं:

• पैकेज स्वीकार करें;
• पैकेज स्वीकार करें;
• संकुल की स्वीकृति की पुष्टि करें;
• पैकेज भेजें;
• पैकेज भेजें;
• पैकेज भेजने की पुष्टि करें।

यह स्पष्ट है कि एक पैकेट प्राप्त करने के लिए, क्रियाओं का एक गुच्छा करना आवश्यक था। और मध्यवर्ती ड्राइवरों के लिए, यह सामान्य रूप से, हड्डियों को पैकेज को अलग करने के लिए, अपना स्वयं का इकट्ठा करना है (क्योंकि आप किसी भी चीज को नहीं छू सकते हैं जो आपके पास नहीं है) और इसे भेजें। इसलिए, NET_BUFFER वास्तुकला को एनडीआईएस 6.x में पेश किया गया था।
इस वास्तुकला के अनुसार, पैकेट प्राप्त करने और भेजने के लिए 2 कार्यों को लागू करने के लिए पर्याप्त है (अब यह एक पैकेट नहीं है, लेकिन एक बफर है, इसलिए एनडीआईएस 6+ के आते ही इन शब्दों को नीचे दिए गए समानार्थक शब्द के रूप में लें)। हां, मैंने 2x के बारे में झूठ बोला था, लेकिन ये दोनों कुछ खास नहीं करते हैं और ड्राइवर से ड्राइवर में बदलाव के बिना भटकते हैं। इसलिए, मुझे प्राप्त करने और भेजने के कार्य, मैं एक सामान्य समझ के लिए उनके हस्ताक्षर यहां लिखूंगा:

VOID FilterSendNetBufferLists( IN NDIS_HANDLE FilterModuleContext, IN PNET_BUFFER_LIST NetBufferLists, IN NDIS_PORT_NUMBER PortNumber, IN ULONG SendFlags ); VOID FilterReceiveNetBufferLists( IN NDIS_HANDLE FilterModuleContext, IN PNET_BUFFER_LIST NetBufferLists, IN NDIS_PORT_NUMBER PortNumber, IN ULONG NumberOfNetBufferLists, IN ULONG ReceiveFlags ); 

पहले पैरामीटर अनिवार्य रूप से एक पॉइंटर हैं जो आपको NDIS पास करेंगे। ड्राइवर को पंजीकृत करते समय, या कतार में संलग्न करते समय, आप इस सूचक को निर्दिष्ट कर सकते हैं। इस प्रकार हमारे पास हमेशा हमारे निपटान में एक उपयोगकर्ता चर का लिंक होता है, जो कि आप जानते हैं, असीमित गुंजाइश है। बहुत सहज है।
दूसरा पैरामीटर NET_BUFFER सूचियों के संकेत हैं। हम इससे बाद में निपटेंगे।
अन्य सभी मापदंडों का उपयोग शायद ही कभी किया जाता है, इसलिए हम उन पर विचार नहीं करेंगे।

हम वास्तुकला में ही उत्तीर्ण होते हैं।
नीचे दी गई तस्वीर मोटे तौर पर वास्तुकला का वर्णन करती है:



प्रत्येक NET_BUFFER नीचे दी गई छवि के अनुसार एक पैकेज का वर्णन कर सकता है:


छायांकित स्थान में हमारा पैकेज भी संग्रहीत है। जैसा कि आप देख सकते हैं, यह जरूरी नहीं कि मेमोरी का एक निरंतर ब्लॉक है, एक पैकेट पूरे सिस्टम एड्रेस स्पेस में बिखरा हो सकता है। पैकेज को नॉनपेड मेमोरी में स्टोर करने की भी सलाह दी जाती है (संदर्भ के लिए: IRQL> = DISPATCH_LEVEL पर पृष्ठांकित मेमोरी तक पहुंचने की कोशिश करते समय, हमें कोड D1 के साथ एक नीली स्क्रीन मिलती है। DRIVER_IRQL_NOTOESS_OR_EQUAL, सबसे आम ड्राइवर-लेखक त्रुटि)।

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

एक निष्कर्ष के बजाय

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

आगे पढ़े यहां:

www.codemachine.com/article_ndis6nbls.html
msdn.microsoft.com/en-us/library/ff564881 (v = बनाम 85) .aspx

अगली बार तक।