दूरस्थ प्रक्रियाओं आरपीसी अल्ट्रासाउंड स्कैनर को कॉल करें। दूरस्थ प्रक्रिया कॉल तंत्र - आरपीसी

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

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

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

RPC सर्वर और क्लाइंट के बीच नेटवर्क संचार थोड़ा विशेष है। एक RPC सर्वर एक या अधिक सिस्टम प्रक्रियाएँ प्रदान करता है, ऐसी प्रक्रियाओं के प्रत्येक सेट को एक प्रोग्राम कहा जाता है ( कार्यक्रम) और प्रोग्राम संख्या द्वारा विशिष्ट रूप से पहचाना जाता है ( कार्यक्रम क्रमांक). सेवा नामों की एक सूची आमतौर पर /etc/rpc में रखी जाती है, जिसका एक उदाहरण नीचे दिया गया है।

उदाहरण 12-4. नमूना /आदि/आरपीसी फ़ाइल

टीसीपी/आईपी नेटवर्क में, आरपीसी के लेखकों को प्रोग्राम नंबरों को सामान्य नेटवर्क सेवाओं में मैप करने के कार्य का सामना करना पड़ा। प्रत्येक सर्वर प्रत्येक प्रोग्राम और प्रत्येक संस्करण के लिए एक टीसीपी और यूडीपी पोर्ट प्रदान करता है। सामान्य तौर पर, आरपीसी एप्लिकेशन डेटा संचारित करने के लिए यूडीपी का उपयोग करते हैं और जब प्रसारित किया जाने वाला डेटा एकल यूडीपी डेटाग्राम में फिट नहीं होता है तो टीसीपी पर वापस आ जाते हैं।

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

इस पद्धति का नुकसान यह है कि यह विफलता का एक ही बिंदु प्रस्तुत करती है, बहुत कुछ inetdडेमन हालाँकि, यह मामला थोड़ा ख़राब है क्योंकि जब पोर्टमैपर विफल हो जाता है, तो पोर्ट के बारे में सभी RPC जानकारी खो जाती है। इसका आम तौर पर मतलब यह है कि आपको सभी आरपीसी सर्वरों को मैन्युअल रूप से पुनरारंभ करना होगा या मशीन को रीबूट करना होगा।

लिनक्स पर, पोर्टमैपर को /sbin/portmap या /usr/sbin/rpc.portmap कहा जाता है। इस तथ्य के अलावा कि इसे नेटवर्क स्टार्टअप स्क्रिप्ट से लॉन्च किया जाना चाहिए, पोर्टमैपर को किसी कॉन्फ़िगरेशन कार्य की आवश्यकता नहीं है।

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

कार्यान्वयन

ऐसी कई प्रौद्योगिकियाँ हैं जो RPC प्रदान करती हैं:

• सन आरपीसी (टीसीपी और यूडीपी और एक्सडीआर पर आधारित बाइनरी प्रोटोकॉल) आरएफसी-1831 दूसरा नाम ओएनसी आरपीसी आरएफसी-1833
• .नेट रिमोटिंग (टीसीपी, यूडीपी, HTTP पर आधारित बाइनरी प्रोटोकॉल)
• SOAP - सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल (HTTP-आधारित टेक्स्ट प्रोटोकॉल) विनिर्देश देखें: RFC-4227
• XML RPC (HTTP आधारित टेक्स्ट प्रोटोकॉल) विशिष्टता देखें: RFC-3529
• जावा आरएमआई - जावा रिमोट मेथड इनवोकेशन - विशिष्टता देखें: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC जावास्क्रिप्ट ऑब्जेक्ट नोटेशन रिमोट प्रोसीजर कॉल (HTTP-आधारित टेक्स्ट प्रोटोकॉल) विनिर्देश देखें: RFC-4627
• डीसीई/आरपीसी - वितरित कंप्यूटिंग पर्यावरण/दूरस्थ प्रक्रिया कॉल (विभिन्न परिवहन प्रोटोकॉल पर आधारित बाइनरी प्रोटोकॉल, जिसमें टीसीपी/आईपी और एसएमबी/सीआईएफएस प्रोटोकॉल से नामित पाइप शामिल हैं)
• डीसीओएम - वितरित घटक ऑब्जेक्ट मॉडल जिसे एमएसआरपीसी माइक्रोसॉफ्ट रिमोट प्रोसीजर कॉल या "नेटवर्क ओएलई" के रूप में जाना जाता है (डीसीई आरपीसी के लिए एक ऑब्जेक्ट-ओरिएंटेड एक्सटेंशन जो आपको ऑब्जेक्ट्स के संदर्भों को पारित करने और ऐसे संदर्भों के माध्यम से ऑब्जेक्ट विधियों को कॉल करने की अनुमति देता है)

सिद्धांत

रिमोट प्रोसीजर कॉल (आरपीसी) का विचार एक नेटवर्क पर नियंत्रण और डेटा स्थानांतरित करने के लिए एक मशीन पर चल रहे प्रोग्राम के भीतर नियंत्रण और डेटा स्थानांतरित करने के लिए प्रसिद्ध और समझे जाने वाले तंत्र का विस्तार करना है। दूरस्थ प्रक्रिया कॉल उपकरण वितरित कंप्यूटिंग के संगठन और वितरित क्लाइंट-सर्वर के निर्माण की सुविधा के लिए डिज़ाइन किए गए हैं जानकारी के सिस्टम. आरपीसी का उपयोग करने की सबसे बड़ी दक्षता उन अनुप्रयोगों में हासिल की जाती है जिनमें तेजी से प्रतिक्रिया समय और अपेक्षाकृत कम मात्रा में डेटा स्थानांतरित होने के साथ दूरस्थ घटकों के बीच इंटरैक्टिव संचार होता है। ऐसे अनुप्रयोगों को आरपीसी-उन्मुख कहा जाता है।

स्थानीय प्रक्रिया कॉल लागू करने की तुलना में दूरस्थ कॉल लागू करना कहीं अधिक जटिल है। हम निम्नलिखित समस्याओं और कार्यों की पहचान कर सकते हैं जिन्हें आरपीसी लागू करते समय हल करने की आवश्यकता है:

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

उपप्रणालियाँ

• परिवहन उपप्रणाली

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

• थ्रेड पूल (केवल कैली)। नेटवर्क पर लागू किए गए कोड के लिए निष्पादन संदर्भ प्रदान करता है।

• मार्शलिंग (जिसे "क्रमबद्धता" भी कहा जाता है)। कॉल पैरामीटर को मानक तरीके से बाइट स्ट्रीम में पैक करना, आर्किटेक्चर से स्वतंत्र (विशेष रूप से, किसी शब्द में बाइट्स का क्रम)। विशेष रूप से, यह पॉइंटर पैरामीटर द्वारा इंगित सरणियों, स्ट्रिंग्स और संरचनाओं को प्रभावित कर सकता है।

• पैकेजों को एन्क्रिप्ट करना और उन पर डिजिटल हस्ताक्षर लागू करना।

• सत्यापन और प्राधिकरण। कॉल करने वाले विषय की पहचान करने वाली सूचना के नेटवर्क पर प्रसारण।

कुछ RPC (.NET रिमोटिंग) कार्यान्वयन में, सबसिस्टम सीमाएँ खुले बहुरूपी इंटरफ़ेस हैं, और लगभग सभी सूचीबद्ध सबसिस्टमों का अपना स्वयं का कार्यान्वयन लिखना संभव है। अन्य कार्यान्वयनों में (विंडोज़ पर डीसीई आरपीसी) ऐसा नहीं है।

यह सभी देखें

रिमोट प्रोसीजर कॉल (आरपीसी) रिमोट प्रोसीजर कॉल अवधारणा

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

स्थानीय प्रक्रियाओं को कॉल करने की विशिष्ट विशेषताएं हैं:

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

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

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

इन और कुछ अन्य समस्याओं का समाधान व्यापक आरपीसी तकनीक द्वारा किया जाता है, जो कई वितरित ऑपरेटिंग सिस्टमों का आधार है। बुनियादी संचालनआरपीसी

यह समझने के लिए कि आरपीसी कैसे काम करती है, आइए पहले ऑफ़लाइन चलने वाली एक सामान्य मशीन पर स्थानीय प्रक्रिया कॉल करने पर विचार करें। उदाहरण के लिए, इसे एक सिस्टम कॉल होने दें

गिनती=पढ़ें(fd, buf, nbytes);

जहां fd एक पूर्णांक है, buf वर्णों की एक सरणी है, nbytes एक पूर्णांक है।

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

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

एक अन्य पैरामीटर पासिंग मैकेनिज्म भी है जिसका उपयोग सी में नहीं किया जाता है। इसे कॉल-बाय-कॉपी/रिस्टोर कहा जाता है, जिसके लिए कॉल करने वाले को वेरिएबल्स को मान के रूप में स्टैक पर कॉपी करने की आवश्यकता होती है, और फिर कॉल करने के बाद उन्हें वापस कॉपी करना होता है। कॉलिंग प्रक्रिया के मूल मूल्य।

किस पैरामीटर पासिंग तंत्र का उपयोग करना है इसका निर्णय भाषा डेवलपर्स द्वारा किया जाता है। कभी-कभी यह स्थानांतरित किए जा रहे डेटा के प्रकार पर निर्भर करता है। उदाहरण के लिए, C में, पूर्णांक और अन्य स्केलर डेटा हमेशा मान द्वारा पारित किए जाते हैं, और सरणियाँ हमेशा संदर्भ द्वारा पारित की जाती हैं।

आवेदन

उपकरणों का एक महत्वपूर्ण हिस्सा रिमोट कंट्रोलविंडोज़ ऑपरेटिंग सिस्टम (इवेंट व्यूअर, सर्वर मैनेजर, प्रिंट प्रबंधन, उपयोगकर्ता सूची) प्रबंधित सेवा और उपयोगकर्ता इंटरफ़ेस नियंत्रण एप्लिकेशन के बीच नेटवर्क पर संचार के साधन के रूप में डीसीई आरपीसी का उपयोग करता है। DCE RPC समर्थन Windows NT में पहले संस्करण 3.1 से ही मौजूद है। डीसीई आरपीसी क्लाइंट को लाइट लाइन में भी समर्थन दिया गया था ऑपरेटिंग सिस्टमविंडोज़ 3.x/95/98/मी.

विंडोज़ सिस्टम लाइब्रेरीज़ जो ऐसी नियंत्रण क्षमताएं प्रदान करती हैं और उपयोगकर्ता इंटरफ़ेस नियंत्रण अनुप्रयोगों (netapi32.dll और आंशिक रूप से advapi32.dll) के लिए आधार परत के रूप में कार्य करती हैं, उनमें वास्तव में DCE RPC इंटरफ़ेस के लिए क्लाइंट कोड होता है जो इस नियंत्रण को निष्पादित करता है।

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

DCE RPC के अलावा, विंडोज़ सक्रिय रूप से DCOM तकनीक का उपयोग करता है। उदाहरण के लिए, इसका उपयोग IIS वेब सर्वर प्रबंधन टूल और स्वयं प्रबंधित किए जा रहे सर्वर के बीच संचार के साधन के रूप में किया जाता है। MS एक्सचेंज सर्वर मेल सिस्टम - MAPI - के साथ संचार करने के लिए एक पूरी तरह कार्यात्मक इंटरफ़ेस भी DCOM पर आधारित है।

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

आरपीसी का उपयोग करने की सबसे बड़ी दक्षता उन अनुप्रयोगों में हासिल की जाती है जिनमें यह मौजूद है दूरस्थ घटकों के बीच इंटरैक्टिव संचारसाथ कम प्रतिक्रिया समयऔर प्रेषित डेटा की अपेक्षाकृत कम मात्रा।ऐसे अनुप्रयोगों को आरपीसी-उन्मुख कहा जाता है।

स्थानीय प्रक्रियाओं को कॉल करने की विशिष्ट विशेषताएं हैं:

विषमता,अर्थात्, बातचीत करने वाले पक्षों में से एक आरंभकर्ता है;

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

स्थानीय प्रक्रिया कॉल लागू करने की तुलना में दूरस्थ कॉल लागू करना कहीं अधिक जटिल है।

1. आइए इस तथ्य से शुरू करें कि चूंकि कॉलिंग और कॉल की गई प्रक्रियाएं विभिन्न मशीनों पर निष्पादित की जाती हैं, इसलिए वे अलग-अलग पता स्थान हैं, और यह बनाता है पैरामीटर और परिणाम स्थानांतरित करते समय समस्याएं, खासकर यदि मशीनें समान नहीं हैं.

चूँकि RPC साझा मेमोरी पर भरोसा नहीं कर सकती, इसका मतलब यह है आरपीसी पैरामीटर में गैर-स्टैक मेमोरी स्थानों के लिए पॉइंटर्स नहीं होने चाहिएतो क्या हुआ पैरामीटर मानों को एक कंप्यूटर से दूसरे कंप्यूटर में कॉपी किया जाना चाहिए.

2. आरपीसी और स्थानीय कॉल के बीच अगला अंतर यह है कि यह आवश्यक रूप से अंतर्निहित संचार प्रणाली का उपयोग करता है, तथापि यह प्रक्रियाओं की परिभाषा में या स्वयं प्रक्रियाओं में स्पष्ट रूप से दिखाई नहीं देनी चाहिए .

दूरदर्शिता अतिरिक्त समस्याएँ प्रस्तुत करती है। कॉलिंग प्रोग्राम और कॉल की गई स्थानीय प्रक्रिया को एक ही मशीन पर निष्पादित करना के भीतर कार्यान्वित किया गयाअकेला प्रक्रिया. लेकिन आरपीसी के कार्यान्वयन में शामिलकम से कम दो प्रक्रियाएँ - प्रत्येक कार में एक. यदि उनमें से एक विफल हो जाता है, तो निम्नलिखित स्थितियाँ उत्पन्न हो सकती हैं:

यदि कॉलिंग प्रक्रिया क्रैश हो जाती है, तो दूरस्थ रूप से कॉल की गई प्रक्रियाएं "अनाथ" हो जाएंगी और

यदि दूरस्थ प्रक्रियाएँ असामान्य रूप से समाप्त हो जाती हैं, तो कॉलिंग प्रक्रियाएँ "बेसहारा माता-पिता" बन जाएंगी और दूरस्थ प्रक्रियाओं से प्रतिक्रिया की प्रतीक्षा करने से कोई फायदा नहीं होगा।

इसके अलावा, वहाँ है प्रोग्रामिंग भाषाओं और ऑपरेटिंग वातावरण की विविधता से जुड़ी कई समस्याएं : किसी एक प्रोग्रामिंग भाषा में समर्थित डेटा संरचनाएं और प्रक्रिया कॉल संरचनाएं अन्य सभी भाषाओं में उसी तरह समर्थित नहीं हैं।

इन और कुछ अन्य समस्याओं का समाधान व्यापक आरपीसी तकनीक द्वारा किया जाता है, जो कई वितरित ऑपरेटिंग सिस्टमों का आधार है।

आरपीसी के पीछे का विचार दूरस्थ प्रक्रिया कॉल को यथासंभव स्थानीय प्रक्रिया कॉल के समान बनाना है। दूसरे शब्दों में, आरपीसी को पारदर्शी बनाएं: कॉलिंग प्रक्रिया को यह जानने की आवश्यकता नहीं है कि कॉल की गई प्रक्रिया किसी अन्य मशीन पर है, और इसके विपरीत।

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

चावल. 3.2. सुदूर प्रणाली संदेश

इस लेख का उद्देश्य शब्दावली पर चर्चा करना है। लेख कैसे और क्यों के बारे में नहीं है, बल्कि केवल शब्दावली के उपयोग के बारे में है। लेख लेखक की राय को दर्शाता है और वैज्ञानिक होने का दिखावा नहीं करता है।

परिचय

अगर आप प्रोग्रामिंग में काम करते हैं वितरित प्रणालीया में सिस्टम एकीकरण, तो यहां जो कुछ भी प्रस्तुत किया गया है उसमें से अधिकांश आपके लिए नया नहीं है।

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

शब्दावली

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

मैंने शब्दावली को तीन क्षेत्रों में विभाजित किया है: RPC (रिमोट प्रोसीजर कॉल), मैसेजिंग और REST। इन क्षेत्रों की जड़ें ऐतिहासिक हैं।

आरपीसी

आरपीसीप्रौद्योगिकियाँ - सबसे पुरानी प्रौद्योगिकियाँ। आरपीसी के सबसे प्रमुख प्रतिनिधि हैं - कोरबाऔर डीसीओएम.

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

इसलिए आप स्थानीय फ़ंक्शन को कॉल करने और रिमोट फ़ंक्शन को कॉल करने के बीच कोई अंतर नहीं देखेंगे, आपको ध्यान नहीं देना चाहिए।
अब एक प्रकार का RPC पुनर्जागरण है, जिसके सबसे प्रमुख प्रतिनिधि हैं: Google ProtoBuf, थ्रिफ्ट, एवरो।

संदेश

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

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

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

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

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

आराम

कोड जटिलता के साथ निरंतर संघर्ष में, प्रोग्रामर ने अगला कदम उठाया और बनाया आराम.

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

EntityAddress ReadEntityAddress(स्ट्रिंग परम1, स्ट्रिंग परम2)

इस प्रकार व्यक्त किया गया:

प्राप्त करें: इकाईपता?param1=value1¶m2=value2

निष्कर्ष

वितरित प्रणालियों या एकीकरण पर चर्चा शुरू करने से पहले, शब्दावली को परिभाषित करें। यदि विभिन्न संदर्भों में प्रॉक्सी का हमेशा एक ही मतलब होगा, तो, उदाहरण के लिए, RPC के संदर्भ में अनुरोध का कोई मतलब नहीं होगा, और REST प्रौद्योगिकियों पर चर्चा करते समय मार्शलिंग से भ्रम पैदा होगा।

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

माइक्रोसॉफ्ट की अनुशंसा के अनुसार, सबसे पहली चीज़ जो मैंने करने की कोशिश की वह थी रजिस्ट्री कुंजी को ढूंढना और हटाना . मेरे पास यह नहीं था, शायद कुछ स्थापित अद्यतनों के परिणामस्वरूप।

अगला, रजिस्ट्री में सेवा मापदंडों को पुनर्स्थापित करने का प्रयास। चूँकि regedit.exe केवल पढ़ा/हटाया गया था (एक अन्य दुष्प्रभाव), परिवर्तन करना संभव नहीं था। हां, उनकी जरूरत नहीं थी, क्योंकि... सब कुछ सही था. इसे ऐसा दिखना चाहिए:

विंडोज़ रजिस्ट्री संपादक संस्करण 5.00 "विवरण" = "एंडपॉइंट और अन्य आरपीसी सेवाओं की मैपिंग प्रदान करता है।" "DisplayName"='रिमोट प्रोसीजर कॉल (RPC)' 'ErrorControl'=dword:00000001 'Group'='COM इंफ्रास्ट्रक्चर' 'ImagePath'=hex(2):25,00,53,00,79,00,73, 00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\ 74,00,25,00,5c,00,73,00,79,00,73,00 ,74,00,65,00,6d,00,33,00,32,00,5c,00,73,\ 00,76,00,63,00,68,00,6f,00,73,00, 74,00,20,00,2डी,00,6बी,00,20,00,72,00,70,00,\ 63,00,73,00,73,00,00,00 "ऑब्जेक्टनेम"='एनटी AUTHORITY\\NetworkService" "Start"=dword:00000002 "Type"=dword:00000010 "FialureActions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,01 ,00,00,00,00,00,00,\ 00,02,00,00,00,60,ea,00,00 "ServiceSidType"=dword:00000001 "ServiceDll"=hex(2):25.00 ,53 ,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\ 00,74,00,25,00,5c,00, 73, 00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\ 72,00,70,00,63,00,73 ,00 ,73,00,2e,00,64,00,6c,00,6c,00,00,00 "सुरक्षा"=हेक्स:01,00,14,80,a8,00,00,00,b4, 00, 00,00,14,00,00,00,30,00,00,00,02,\ 00,1c,00,01,00,00,00,02,80,14,00,ff,01 ,0f ,00,01,01,00,00,00,00,00,01,00,00,\ 00,00,02,00,78,00,05,00,00,00,00,00, 14, 00,8d,00,02,00,01,01,00,00,00,00,00,\ 05,0,00,00,00,00,00,18,00,ff,01,0f ,00 ,01,02,00,00,00,00,00,05,20,00,00,00,\ 20,02,00,00,00,00,18,00,8d,00,02, 00, 01,02,00,00,00,00,00,05,20,00,00,00,23,\ 02,00,00,00,00,14,00,9d,00,00,00 ,01 ,01,00,00,00,00,00,05,04,00,00,00,00,00,\ 18,00,9d,00,00,00,01,02,00,00, 00, 00,00,05,20,00,00,00,21,02,00,00,01,01,00,\ 00,00,00,00,05,12,00,00,00,01 ,01 ,00,00,00,00,00,05,12,00,00,00 "0"='रूट\\LEGACY_RPCS\\0000' 'गणना'=dword:00000001 'NextInstance'=dword:00000001

पैरामीटर मान शुरूभिन्न हो सकते हैं। आप अभी भी रजिस्ट्री बदल सकते हैं, लेकिन आपको इससे बूट करना होगा एमएस ईआरडी कमांडर.

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

• कंसोल लॉन्च करें (प्रारंभ> चलाएँ: अध्यक्ष एवं प्रबंध निदेशक)
• सीडी जेड:\i386(विंडोज़ वितरण वहाँ)
• explorer.ex_ %TEMP%\explorer.exe का विस्तार करें
• svchost.ex_ %TEMP%\svchost.exe का विस्तार करें
• टास्क मैनेजर लॉन्च करें (Ctrl+Shift+Esc)
• exlporer.exe प्रक्रिया रोकें
• %TEMP%\explorer.exe %SYSTEMROOT% /y कॉपी करें
• सभी svchost.exe प्रक्रियाओं को रोकें। ध्यान! इसके बाद मशीन रीबूट होने तक आपके पास 60 सेकंड का समय होगा।
• %TEMP%\svchost.exe %systemroot%\system32 /y कॉपी करें

इस प्रयास का भी कोई परिणाम नहीं निकला। दूसरा विकल्प: सभी संरक्षित का स्कैन चलाएँ सिस्टम फ़ाइलेंप्रतिस्थापन के साथ ग़लत संस्करणसही। कंसोल रन में:

इससे मदद नहीं मिली.. फिर सुरक्षा सेटिंग्स को बहाल करना एक पूरी तरह से क्रूर कदम है। कंसोल में फिर से:

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

फिर आपको प्रत्येक खाते के अधिकारों को मैन्युअल रूप से परिभाषित करने की आवश्यकता है। या उन्हें दोबारा बनाएं, जो भी आसान हो।

मेरे मामले में, मैंने बस एक्सेस का उपयोग करके संपूर्ण सिस्टम डिस्क पर समान अधिकार निर्दिष्ट किए हैं। मैंने अपने डोमेन खाते को डिस्क पर पूर्ण अधिकारों के साथ मानक में जोड़ा। हो सकता है कि सुरक्षा की दृष्टि से यह गलत हो, लेकिन मेरे पास प्रत्येक निर्देशिका को अलग से समझने का समय नहीं है।

और क्या किया जा सकता था

जबकि कंप्यूटर ख़राब था, यह रजिस्ट्री में नहीं था:

"एक्टिवसर्विस"='आरपीसीएस'

शायद मैन्युअल जोड़ से किसी तरह स्थिति बदल जाएगी।

सेवा को मैन्युअल रूप से प्रारंभ करने का प्रयास, उदाहरण के लिए कमांड के माध्यम से " नेट स्टार्ट आरसीपीएस"त्रुटि में समाप्त हुआ" त्रुटि 5: पहुँच अस्वीकृत". मेरा मानना ​​है कि पहुंच अस्वीकार कर दी गई है क्योंकि सेवा को सिस्टम खाते - "एनटी अथॉरिटी" के तहत लॉन्च किया जाना चाहिए। रजिस्ट्री में निम्नलिखित पैरामीटर है:

"ऑब्जेक्टनाम"='एनटी प्राधिकरण\\नेटवर्कसेवा'

मैं यहां व्यवस्थापक खाते में प्रवेश करने और सेवा फिर से शुरू करने का प्रयास करूंगा। लेकिन यह केवल एक विचार है जो कार्यान्वयन तक नहीं पहुंच पाया।

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

संबंधित सामग्री: