एपोल और विंडोज आईओ कम्प्लीशन पोर्ट्स: व्यावहारिक अंतर

परिचय

इस लेख में, हम यह समझने की कोशिश करेंगे कि अभ्यास में पूर्ण पोर्ट (विंडोज I / O पूर्णता पोर्ट या IOCP) से एपोल तंत्र कैसे भिन्न होता है। यह सिस्टम आर्किटेक्ट्स के लिए दिलचस्प हो सकता है जो उच्च-प्रदर्शन नेटवर्क सेवाओं या प्रोग्रामर्स को विंडोज से लिनक्स या इसके विपरीत नेटवर्क कोडिंग पोर्टिंग डिजाइन करते हैं।

ये दोनों प्रौद्योगिकियां बड़ी संख्या में नेटवर्क कनेक्शन को संभालने के लिए बहुत प्रभावी हैं।

वे निम्नलिखित बिंदुओं में अन्य विधियों से भिन्न हैं:

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

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

(अपडेट: यह लेख एक अनुवाद है )

सूचनाओं का प्रकार

एपोल और IOCP के बीच पहला और सबसे महत्वपूर्ण अंतर यह है कि आप किसी घटना से कैसे अवगत होते हैं।

• एपोल आपको बताता है कि जब डिस्क्रिप्टर इसके साथ कुछ करने में सक्षम होने के लिए तैयार है - " अब आप डेटा पढ़ना शुरू कर सकते हैं "
• IOCP आपको बताता है कि अनुरोधित ऑपरेशन पूरा होने पर - " आपने डेटा पढ़ने के लिए कहा है और यहाँ यह पढ़ा है "

एपोल एप्लिकेशन का उपयोग करते समय:

• यह तय करता है कि कौन सा ऑपरेशन किसी डिस्क्रिप्टर के साथ करना चाहता है (पढ़ें, लिखें, या दोनों)
• Epoll_ctl का उपयोग करके उपयुक्त मास्क सेट करता है
• कॉल epoll_wait, जो वर्तमान थ्रेड को ब्लॉक करता है जब तक कि कम से कम एक अपेक्षित घटना नहीं होती (या समय समाप्त हो जाता है)
• प्राप्त घटनाओं पर पाबंदी, संदर्भ के लिए एक सूचक लेती है (data.ptr फ़ील्ड से)
• अपने प्रकार (पढ़ने, लिखने, या दोनों कार्यों) के अनुसार घटना प्रसंस्करण की पहल करता है
• ऑपरेशन पूरा होने के बाद (तुरंत क्या होना चाहिए), यह डेटा प्राप्त / भेजे जाने की प्रतीक्षा करता रहता है

IOCP एप्लिकेशन का उपयोग करते समय:

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

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

डेटा उपलब्धता

यदि आप डेटा पढ़ने की योजना बनाते हैं, तो आपके कोड में किसी प्रकार का बफर होना चाहिए, जहां आप इसे पढ़ने की योजना बनाते हैं। यदि आप डेटा भेजने की योजना बनाते हैं, तो भेजने के लिए तैयार डेटा के साथ एक बफर होना चाहिए।

• एपोल इन बफ़र्स की उपस्थिति के बारे में बिल्कुल चिंतित नहीं है और किसी भी तरह से उनका उपयोग नहीं करता है
• IOCP इन बफ़र्स की जरूरत है। IOCP का उपयोग करने का पूरा बिंदु "मुझे इस बकेट में इस सॉकेट से 256 बाइट्स पढ़ने" की शैली में काम है। हमने इस तरह के अनुरोध का गठन किया, इसे ओएस को दिया, हम ऑपरेशन के पूरा होने की अधिसूचना की प्रतीक्षा कर रहे हैं (और इस समय बफर को स्पर्श न करें!)

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

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

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

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

epoll उपयोगकर्ता कोड से इसे पारित किसी भी बफ़र्स का उपयोग नहीं करता है, इसलिए इन सभी समस्याओं का इससे कोई लेना-देना नहीं है।

प्रतीक्षा की स्थिति बदलें

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

हालांकि, अपेक्षित घटनाओं को बदलना या हटाना अलग है। epoll अभी भी आपको epoll_ctl (अन्य थ्रेड्स सहित) कॉल करके स्थिति को संशोधित करने की अनुमति देता है। IOCP कठिन हो रहा है। यदि I / O ऑपरेशन की योजना बनाई गई थी, तो इसे CancelIo () फ़ंक्शन को कॉल करके रद्द किया जा सकता है। इससे भी बदतर, केवल वही धागा जिसने प्रारंभिक ऑपरेशन शुरू किया था, इस फ़ंक्शन को कॉल कर सकता है। इस सीमा के बारे में एक अलग नियंत्रण प्रवाह के आयोजन के सभी विचार टूट गए हैं। इसके अलावा, CancelIo () को कॉल करने के बाद भी, हम यह सुनिश्चित नहीं कर सकते हैं कि ऑपरेशन तुरंत रद्द हो जाएगा (यह पहले से ही प्रगति में हो सकता है, यह OVERLAPPED संरचना और पढ़ने / लिखने के लिए पारित बफर का उपयोग करता है)। ऑपरेशन पूरा होने तक हमें अभी भी इंतजार करना होगा (इसका परिणाम GetOverlappedResult () फ़ंक्शन द्वारा वापस किया जाएगा) और उसके बाद ही हम बफर को मुक्त कर सकते हैं।

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

गैर-अवरुद्ध कनेक्शन

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

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

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

दिलचस्प है, स्वीकार () हमेशा की तरह IOCP के साथ काम करता है। एक एक्सेप्ट फ़ंक्शन है, लेकिन इसकी भूमिका पूरी तरह से गैर-अवरोधक कनेक्शन से असंबंधित है। यह एक "गैर-अवरोधक स्वीकार" नहीं है, जैसा कि आप कनेक्ट / ConnectEx के साथ सादृश्य द्वारा सोच सकते हैं।

घटना की निगरानी

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

एपोल का उपयोग करना संभव है। आपको घटना "कुछ पढ़ा जा सकता है" - और आप सॉकेट से पढ़ी जा सकती है (जब तक कि आपको ईगन त्रुटि नहीं मिल जाती)। डेटा भेजने के साथ एक ही बात - जब आपको एक संकेत मिलता है कि सॉकेट डेटा भेजने के लिए तैयार है, तो आप इसमें कुछ लिख सकते हैं जब तक कि राइट फंक्शन EAGAIN न लौटे।

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

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

इस मामले में सिंक्रनाइज़ेशन ऑब्जेक्ट्स के साथ यह आम तौर पर मुश्किल है। खैर, अगर वह अकेला है। लेकिन अगर हमारे पास 100,000 कनेक्शन हैं और उनमें से प्रत्येक में किसी प्रकार का सिंक्रनाइज़ेशन ऑब्जेक्ट होगा, तो यह सिस्टम के संसाधनों को गंभीरता से हिट कर सकता है। और अगर आप अभी भी 2 रखते हैं (पढ़ने और लिखने के लिए प्रसंस्करण अनुरोधों को अलग करने के मामले में)? और भी बुरा।

यहां सामान्य समाधान एक कनेक्शन प्रबंधक वर्ग बनाना है जो कनेक्शन वर्ग के लिए ReadFile या WriteFile को कॉल करने के लिए जिम्मेदार होगा। यह बेहतर काम करता है, लेकिन कोड को अधिक जटिल बनाता है।

निष्कर्ष

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

जब एक प्लेटफ़ॉर्म से दूसरे प्लेटफ़ॉर्म पर पोर्टिंग कोड होता है, तो आमतौर पर IOCP कोड को पोर्ट करना आसान होता है।

सुझाव:

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