📟 🤟🏻 ⚾️ एक परीक्षण कार्य के रूप में WebServer 🕎 👨‍👩‍👦 ⬛️

यह सब कैसे शुरू हुआ

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

एक बिंदु पर जब मैं अंत में दिनचर्या से काम से ऊब गया था, मैंने एक प्रसिद्ध नौकरी खोज संसाधनों की जांच की, कि मैं बाजार को देखते हुए बुरा नहीं मानता, अचानक, क्या दिलचस्प होगा ... विषय के आधार पर, नौकरी की एक निश्चित संख्या प्रदान करता है: "शायद यह आपको ब्याज देगा।" ऐसे प्रस्तावों के बीच, एक परीक्षण कार्य के साथ एक प्रस्ताव आया। परीक्षण कार्य HTTP प्रोटोकॉल के कार्यान्वयन के साथ लिनक्स के तहत C ++ में वेबसर्वर लिखना है; स्पष्ट है ...

परीक्षण कार्य से वाक्यांश लेना और इसे Google में चलाना, मुझे इस बारे में अधिक समीक्षाएँ मिलीं कि RSDN फोरम पर सबसे छोटा परीक्षण कार्य नहीं है। कार्य मेरे मेलर में एक से एक झूठ बोल रहा था। असाइनमेंट के रूप में, उन्होंने नहीं किया। सिद्धांत सरल है: यदि परीक्षण कार्य इसके लायक है, तो इसे बिना काम के 4 घंटे से अधिक समय के लिए डिज़ाइन किया जाना चाहिए। लेकिन उन सभी चीज़ों के बारे में जानने के लिए जिन्हें जगहों पर पढ़ा गया और आजमाया गया। यह एक प्रोत्साहन बन गया, अर्थात् एक दिलचस्प समस्या का बयान। मैं यह नहीं कह सकता कि यह कार्य किस कार्यालय का है, क्योंकि यह एक भर्ती एजेंसी से आया था, लेकिन यह इतना महत्वपूर्ण भी नहीं है।

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

एपीआई और पुस्तकालयों का अवलोकन

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

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

यदि हम सर्वर के कार्य को बहुत ही सामान्य तरीके से करते हैं, तो हमें निम्नलिखित अनुक्रम मिलते हैं:

सॉकेट बनाएं
एक नेटवर्क इंटरफ़ेस के लिए एक सॉकेट को बांधें
एक विशिष्ट नेटवर्क इंटरफेस के लिए बाध्य सॉकेट को सुनें
आने वाले कनेक्शन स्वीकार करें
सॉकेट पर घटनाओं का जवाब

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

यदि आप विंडोज को देखते हैं, तो आप निम्नलिखित तरीके देख सकते हैं:

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

विंडोज के लिए नेटवर्क सॉफ्टवेयर विकसित करने पर एक उत्कृष्ट पुस्तक है - "माइक्रोसॉफ्ट विंडोज नेटवर्क में प्रोग्रामिंग।"

अब, यदि आप * निक्स सिस्टम को देखते हैं, तो ईवेंट चयनकर्ताओं का एक छोटा समूह भी है:

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

वर्णनकर्ताओं पर घटनाओं की प्रतीक्षा करने के लिए कार्यों के अलावा, कुछ और छोटे, लेकिन बहुत उपयोगी चीजें हैं:

Sendfile (Linux) और TransmitFile (Windows) उन्हें डेटा भेजने के लिए "और" जहाँ "से कुछ विवरणों को खिलाने की अनुमति देते हैं। HTTP सर्वर में एक बहुत उपयोगी चीज जब आपको फ़ाइलों को स्थानांतरित करने की आवश्यकता होती है, क्योंकि यह बफर आवंटन और रीड / राइटिंग फ़ंक्शन को कॉल करने की आवश्यकता को समाप्त करता है, जो प्रदर्शन को सकारात्मक रूप से प्रभावित करता है।
aio - आपको ऑपरेटिंग सिस्टम में काम की एक निश्चित राशि को स्थानांतरित करने की अनुमति देता है, क्योंकि यह फ़ाइल डिस्क्रिप्टर पर अतुल्यकालिक संचालन करना संभव बनाता है। उदाहरण के लिए, सिस्टम को आपके लिए बफर बताएं, इसे इस फाइल डिस्क्रिप्टर पर लिखें कि आप सिग्नल कैसे पूरा करेंगे (इसी तरह रीडिंग के साथ)।
Neigl एल्गोरिथ्म एक उपयोगी चीज है जब एप्लिकेशन लिखते हैं जो नेटवर्क को छोटे हिस्से में डेटा भेजने की आवश्यकता होती है और बफरिंग के लिए देरी के बिना, लेकिन यह हमेशा उपयोगी नहीं होता है। एक HTTP सर्वर जैसे एप्लिकेशन में, आउटगोइंग डेटा को बफर करने के लिए सिस्टम को बताना और उपयोगी जानकारी के साथ इसे टीसीपी फ्रेम पर भेजना बेहतर होता है (इसके लिए आप TCP_CORK जैसे सॉकेट विकल्प का उपयोग कर सकते हैं)।
और हां, गैर-ब्लॉकिंग सॉकेट। कोई टिप्पणी नहीं ...
राइटवे (nix) (और विंडोज के समान WSA फ़ंक्शंस) जैसे फ़ंक्शंस भी हैं जो आपको एक ही बार में कई बफ़र्स भेजने की अनुमति देते हैं, जो तब उपयोगी होता है जब आपको HTTP पैकेट हेडर और उससे जुड़ा डेटा भेजने की आवश्यकता होती है और उसी समय सिस्टम कॉल की संख्या पर बचत होती है।

शुरुआत के लिए एक कोड के साथ पुस्तकालयों का उपयोग करने के बारे में कहना बेहतर है, जो कि उदाहरण के रूप में बूस्ट.आसियो और लिबवेंट का उपयोग करके नीचे किया जाएगा। boost.asio नेटवर्क अनुप्रयोगों के विकास को बहुत सरल करता है, libevent एक सर्वर क्लासिक है।

एपोल कार्यान्वयन

नेटवर्क ईवेंट्स, पोल, सेलेक्ट का जवाब देने के लिए जो भी तंत्र चुना जाता है, वहाँ अभी भी कई अन्य बारीकियाँ हैं।

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

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

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

class TCPServer : private Common::NonCopyable { public: TCPServer(InetAddress const &locAddr, int backlog, int maxThreadsCount, int maxConnectionsCount, UserSessionCreator sessionCreator); private: typedef std::tr1::shared_ptr<Common::IDisposable> IDisposablePtr; typedef std::vector<IDisposablePtr> IDisposablePool; Private::ClientItemQueuePtr AcceptedItems; IDisposablePool Threads; };

यह शायद सबसे छोटा सर्वर वर्ग कार्यान्वयन है जिसे मुझे लिखना था। यह वर्ग केवल कई सूत्र बनाता है: श्रोता और कई कार्यकर्ता, और उनके धारक हैं।

कार्यान्वयन

 TCPServer::TCPServer(InetAddress const &locAddr, int backlog, int maxThreadsCount, int maxConnectionsCount, UserSessionCreator sessionCreator) : AcceptedItems(new Private::ClientItemQueue(backlog)) { int EventsCount = maxConnectionsCount / maxThreadsCount; for (int i = 0 ; i < maxThreadsCount ; ++i) { Threads.push_back(IDisposablePtr(new Private::WorkerThread( EventsCount + (i <= maxThreadsCount - 1 ? 0 : maxConnectionsCount % maxThreadsCount), AcceptedItems ))); } Threads.push_back(IDisposablePtr(new Private::ListenThread(locAddr, backlog, AcceptedItems, sessionCreator))); }

महान भी नहीं। दोनों वर्ग समान हैं

सुनने की धारा

 class ListenThread : private TCPServerSocket , public Common::IDisposable { public: ListenThread(InetAddress const &locAddr, int backlog, ClientItemQueuePtr acceptedClients, UserSessionCreator sessionCreator) : TCPServerSocket(locAddr, backlog) , AcceptedClients(acceptedClients) , SessionCreator(sessionCreator) , Selector(1, WaitTimeout, std::tr1::bind(&ListenThread::OnSelect, this, std::tr1::placeholders::_1, std::tr1::placeholders::_2)) { Selector.AddSocket(GetHandle(), Network::ISelector::stRead); } private: enum { WaitTimeout = 100 }; ClientItemQueuePtr AcceptedClients; UserSessionCreator SessionCreator; SelectorThread Selector; void OnSelect(SocketHandle handle, Network::ISelector::SelectType selectType) { //  ,  -      } };

और

काम प्रवाह

 class WorkerThread : private Common::NonCopyable , public Common::IDisposable { public: WorkerThread(int maxEventsCount, ClientItemQueuePtr acceptedClients) : MaxConnections(maxEventsCount) , AcceptedClients(acceptedClients) , Selector(maxEventsCount, WaitTimeout, std::tr1::bind(&WorkerThread::OnSelect, this, std::tr1::placeholders::_1, std::tr1::placeholders::_2), SelectorThread::ThreadFunctionPtr(new SelectorThread::ThreadFunction(std::tr1::bind( &WorkerThread::OnIdle, this)))) { } private: enum { WaitTimeout = 100 }; typedef std::map<SocketHandle, ClientItemPtr> ClientPool; unsigned MaxConnections; ClientItemQueuePtr AcceptedClients; ClientPool Clients; SelectorThread Selector; void OnSelect(SocketHandle handle, Network::ISelector::SelectType selectType) { //  ,      ( ,  ,  ) } void OnIdle() { //   .         -  epoll. } };

इवेंट फ़्लो क्लास का उपयोग करें

SelectorThread

 class SelectorThread : private EPollSelector , private System::ThreadLoop { public: using EPollSelector::AddSocket; typedef System::Thread::ThreadFunction ThreadFunction; typedef std::tr1::shared_ptr<ThreadFunction> ThreadFunctionPtr; SelectorThread(int maxEventsCount, unsigned waitTimeout, ISelector::SelectFunction onSelectFunc, ThreadFunctionPtr idleFunc = ThreadFunctionPtr()); virtual ~SelectorThread(); private: void SelectItems(ISelector::SelectFunction &func, unsigned waitTimeout, ThreadFunctionPtr idleFunc); };

। यह धागा उपयोग करता है

EPollSelector

 class EPollSelector : private Common::NonCopyable , public ISelector { public: EPollSelector(int maxSocketCount); ~EPollSelector(); virtual void AddSocket(SocketHandle handle, int selectType); virtual void Select(SelectFunction *function, unsigned timeout); private: typedef std::vector<epoll_event> EventPool; EventPool Events; int EPoll; static int GetSelectFlags(int selectType); };

स्वीकृत यौगिकों के विवरणकों पर होने वाली घटनाओं के लिए प्रतिक्रियाओं के आयोजन के लिए।
यदि आप सर्वर के स्रोत वर्ग को देखते हैं, तो आप देख सकते हैं कि अंतिम सत्र पैरामीटर के रूप में उपयोगकर्ता सत्र कक्षाएं बनाने के लिए फ़ंक्टर पारित किया गया है। एक उपयोगकर्ता सत्र एक इंटरफ़ेस का कार्यान्वयन है

 struct IUserSession { virtual ~IUserSession() {} virtual void Init(IConnectionCtrl *ctrl) = 0; virtual void Done() = 0; virtual unsigned GetMaxBufSizeForRead() const = 0; virtual bool IsExpiredSession(std::time_t lastActionTime) const = 0; virtual void OnRecvData(void const *buf, unsigned bytes) = 0; virtual void OnIdle() = 0; };

इस इंटरफ़ेस के कार्यान्वयन के आधार पर, विभिन्न प्रोटोकॉल लागू किए जा सकते हैं। Init और Done के तरीकों को क्रमशः सत्र की शुरुआत में और इसके अंत में कहा जाता है। GetMaxBufSizeForRead को डेटा रीड ऑपरेशंस के दौरान आवंटित किए जाने वाले अधिकतम बफर आकार को वापस करना चाहिए। रीड डेटा OnRecvData में आता है। सत्र को यह कहने के लिए कि यह समाप्त हो गया है, उचित तरीके से IsExpiredSession को लागू करना आवश्यक है। OnIdle को कुछ क्रियाओं के बीच में बुलाया जाता है, यहां सत्र कार्यान्वयन कुछ पृष्ठभूमि क्रियाएं कर सकता है और इंटरफ़ेस के माध्यम से बंद करने के उद्देश्य से खुद को चिह्नित कर सकता है

 struct IConnectionCtrl { virtual ~IConnectionCtrl() { } virtual void MarkMeForClose() = 0; virtual void UpdateSessionTime() = 0; virtual bool SendData(void const *buf, unsigned *bytes) = 0; virtual bool SendFile(int fileHandle, unsigned offset, unsigned *bytes) = 0; virtual InetAddress const& GetAddress() const = 0; virtual SocketTuner GetSocketTuner() const = 0; };

IConnectionCtrl इंटरफ़ेस को पारित किया गया है ताकि उपयोगकर्ता सत्र नेटवर्क (SendData और SendFile विधियों) को डेटा भेज सके, खुद को बंद करने के उद्देश्य से चिह्नित करें (MarkMeForClose पद्धति), कहते हैं कि यह "जीवित" है (UpdateSessionTime पद्धति; अद्यतन समय पर आता है; IsExpiredSession), एक ही सत्र में आने वाले कनेक्शन (GetAddress पद्धति) और सॉकेट सेटिंग्स के लिए सॉकेटट्यूनर ऑब्जेक्ट - वर्तमान कनेक्शन (GetSocketTuner विधि) का पता मिल सकता है।
HTTP प्रोटोकॉल का कार्यान्वयन HttpUserSession वर्ग में है। जैसा कि मैंने ऊपर कहा, HTTP कार्यान्वयन मेरे लिए सबसे दिलचस्प और प्राथमिकता नहीं था, इसलिए मैंने इसके बारे में ज्यादा नहीं सोचा; मैंने सोचा कि वास्तव में जितना लिखना पर्याप्त था :)

Libevent कार्यान्वयन

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

Event_base_new पर कॉल करके कुछ मूल ऑब्जेक्ट बनाएं (सरल मामलों के लिए एक सरलीकृत भी है - event_init)। किसी ऑब्जेक्ट को हटाने के लिए युग्मित फ़ंक्शन event_base_free है।
Evhttp_new पर कॉल करके एक HTTP इंजन ऑब्जेक्ट बनाएं। Evhttp_free ऑब्जेक्ट को हटाने के लिए एक युग्मित फ़ंक्शन।
आप उन तरीकों को निर्दिष्ट कर सकते हैं जो सर्वर फ्लैग के संयोजन के साथ evhttp_set_allowed_methods फ़ंक्शन का समर्थन करेंगे। इसलिए, उदाहरण के लिए, केवल GET पद्धति का समर्थन करने के लिए, यह कुछ इस तरह दिखेगा: evhttp_set_allowed_methods (Http, EVHTTP_REQ_GET), जहां Http चरण (2) में बनाया गया वर्णनकर्ता है।
Evhttp_set_gencb कॉल करके आने वाले अनुरोधों को संभालने के लिए कॉलबैक फ़ंक्शन सेट करें।
Evhttp_accept_socket फ़ंक्शन को कॉल करके HTTP सर्वर ऑब्जेक्ट के उदाहरण के साथ सुनने वाले सॉकेट को संबद्ध करें। एक सुनने वाला सॉकेट बनाया जा सकता है और उसी सॉकेट / बाइंड / सुन के माध्यम से कॉन्फ़िगर किया जा सकता है।
Event_base_loop फ़ंक्शन को कॉल करके ईवेंट लूप प्रारंभ करें। एक सरलीकृत विकल्प है - event_base_dispatch। event_base_loop को लूप में बुलाया जाना चाहिए। यह फ़ंक्शन या तो पुस्तकालय के आंत्रों में कुछ उपयोगी करता है, जिसे स्थापित कॉलबैक फ़ंक्शंस में कॉल आता है, या जब कुछ करने के लिए कुछ नहीं होता है, तो यह नियंत्रण वापस कर देता है और आप इस पल में कुछ उपयोगी कर सकते हैं; यह संदेश प्रसंस्करण चक्र के जीवन काल को और अधिक आसानी से नियंत्रित करना संभव बनाता है।
अनुरोध हैंडलर में, आप evbuffer_add_printf फ़ंक्शन को कॉल करके कुछ लाइब्रेरी डेटा भेज सकते हैं या लाइब्रेरी को एक फ़ाइल विवरणक दे सकते हैं और इसे evbuffer_add_file पर कॉल करके भेज सकते हैं। ये फ़ंक्शंस कुछ बफर ऑब्जेक्ट के साथ काम करते हैं जो आप खुद बना सकते हैं (और समय में इसे हटाना न भूलें) या अनुरोध क्षेत्र का उपयोग करें: evhttp_request :: output_buffer। सभी आकर्षण यह है कि ये कार्य एसिंक्रोनस हैं, अर्थात्। फ़ाइल भेजने के साथ उदाहरण में, आप फ़ाइल डिस्क्रिप्टर को उसी evbuffer_add_file पर दे सकते हैं और यह तुरंत नियंत्रण लौटा देगा, और फ़ाइल भेजे जाने के बाद, यह फ़ाइल को स्वयं बंद कर देगा।

सब कुछ एक धागे में बहुत खूबसूरती से निकलता है, लेकिन जैसा कि यह निकला, मल्टी-थ्रेडेड सर्वर बनाना भी मुश्किल नहीं है। यदि आप बढ़ावा का उपयोग करते हैं :: थ्रेड या आपका क्रॉस-प्लेटफ़ॉर्म वर्ग जो स्ट्रीम के काम को रोकता है, या कुछ इसी तरह का है, तो आप पूरी तरह से क्रॉस-प्लेटफॉर्म समाधान प्राप्त कर सकते हैं, क्योंकि libevent एक क्रॉस-प्लेटफॉर्म लाइब्रेरी है। अपने स्वयं के कार्यान्वयन में, मैं केवल लिनक्स के लिए धाराओं पर कुछ आवरण ले लूंगा। लेकिन यह इतना महत्वपूर्ण नहीं है।
प्रत्येक वर्कफ़्लो के लिए मुख्य धागा अपने स्वयं के विवरणकों को बनाना होगा, अर्थात्। पूर्ण चरण 1-5। वर्कफ़्लोज़ को केवल संदेश प्रसंस्करण चक्रों को मोड़ना चाहिए - चरण 6. प्रत्येक वर्कफ़्लो में चरण 7 का प्रदर्शन किया जाएगा। संक्षेप में, हम कह सकते हैं: हम एक सुनने वाला सॉकेट बनाते हैं और हम इसके प्रसंस्करण को कई वर्कर थ्रेड पर लगाते हैं।
इसलिए मेरे कार्यान्वयन में, यह देखते हुए कि धाराओं, फ़ाइलों और कमांड लाइन पार्सिंग के लिए मेरे पास पहले से ही कुछ आदिम हैं, मुझे C # / Java शैली में लगभग 200 लाइनों की केवल GET विधि के लिए एक HTTP सर्वर मिला। जो हो रहा है उसके पूर्ण नियंत्रण के साथ कोड लिखने के काम में यह कमी नहीं बल्कि आनन्द हो सकता है। इसके अलावा, विषय के अनुसार, परिणामी सर्वर थोड़ा तेज़ काम करता है, लेकिन आइए अंत में परीक्षणों को देखें ...

Libevent पर एक HTTP सर्वर को लागू करना

 #include <event.h> #include <evhttp.h> #include <unistd.h> #include <string.h> #include <signal.h> #include <vector> #include <iostream> #include <tr1/functional> #include <tr1/memory> #include "tcp_server_socket.h" #include "inet_address_v4.h" #include "thread.h" #include "command_line.h" #include "logger.h" #include "file_holder.h" namespace Network { namespace Private { DECLARE_RUNTIME_EXCEPTION(EventBaseHolder) class EventBaseHolder : private Common::NonCopyable { public: EventBaseHolder() : EventBase(event_base_new()) { if (!EventBase) throw EventBaseHolderException("Failed to create new event_base"); } ~EventBaseHolder() { event_base_free(EventBase); } event_base* GetBase() const { return EventBase; } private: event_base *EventBase; }; DECLARE_RUNTIME_EXCEPTION(HttpEventHolder) class HttpEventHolder : public EventBaseHolder { public: typedef std::tr1::function<void (char const *, evbuffer *)> RequestHandler; HttpEventHolder(SocketHandle sock, RequestHandler const &handler) : Handler(handler) , Http(evhttp_new(GetBase())) { evhttp_set_allowed_methods(Http, EVHTTP_REQ_GET); evhttp_set_gencb(Http, &HttpEventHolder::RawHttpRequestHandler, this); if (evhttp_accept_socket(Http, sock) == -1) throw HttpEventHolderException("Failed to accept socket for http"); } ~HttpEventHolder() { evhttp_free(Http); } private: RequestHandler Handler; evhttp *Http; static void RawHttpRequestHandler(evhttp_request *request, void *prm) { reinterpret_cast<HttpEventHolder *>(prm)->ProcessRequest(request); } void ProcessRequest(evhttp_request *request) { try { Handler(request->uri, request->output_buffer); evhttp_send_reply(request, HTTP_OK, "OK", request->output_buffer); } catch (std::exception const &e) { evhttp_send_reply(request, HTTP_INTERNAL, e.what() ? e.what() : "Internal server error.", request->output_buffer); } } }; class ServerThread : private HttpEventHolder , private System::Thread { public: ServerThread(SocketHandle sock, std::string const &rootDir, std::string const &defaultPage) : HttpEventHolder(sock, std::tr1::bind(&ServerThread::OnRequest, this, std::tr1::placeholders::_1, std::tr1::placeholders::_2)) , Thread(std::tr1::bind(&ServerThread::DispatchProc, this)) , RootDir(rootDir) , DefaultPage(defaultPage) { } ~ServerThread() { IsRun = false; } private: enum { WaitTimeout = 10000 }; bool volatile IsRun; std::string RootDir; std::string DefaultPage; void DispatchProc() { IsRun = true; while(IsRun) { if (event_base_loop(GetBase(), EVLOOP_NONBLOCK)) { Common::Log::GetLogInst() << "Failed to run dispatch events"; break; } usleep(WaitTimeout); } } void OnRequest(char const *resource, evbuffer *outBuffer) { std::string FileName; GetFullFileName(resource, &FileName); try { System::FileHolder File(FileName); if (!File.GetSize()) { evbuffer_add_printf(outBuffer, "Empty file"); return; } evbuffer_add_file(outBuffer, File.GetHandle(), 0, File.GetSize()); File.Detach(); } catch (System::FileHolderException const &) { evbuffer_add_printf(outBuffer, "File not found"); } } void GetFullFileName(char const *resource, std::string *fileName) const { fileName->append(RootDir); if (!resource || !strcmp(resource, "/")) { fileName->append("/"); fileName->append(DefaultPage); } else { fileName->append(resource); } } }; } class HTTPServer : private TCPServerSocket { public: HTTPServer(InetAddress const &locAddr, int backlog, int maxThreadsCount, std::string const &rootDir, std::string const &defaultPage) : TCPServerSocket(locAddr, backlog) { for (int i = 0 ; i < maxThreadsCount ; ++i) { ServerThreads.push_back(ServerThreadPtr(new Private::ServerThread(GetHandle(), rootDir, defaultPage))); } } private: typedef std::tr1::shared_ptr<Private::ServerThread> ServerThreadPtr; typedef std::vector<ServerThreadPtr> ServerThreadPool; ServerThreadPool ServerThreads; }; } int main(int argc, char const **argv) { if (signal(SIGPIPE, SIG_IGN) == SIG_ERR) { std::cerr << "Failed to call signal(SIGPIPE, SIG_IGN)" << std::endl; return 0; } try { char const ServerAddr[] = "Server"; char const ServerPort[] = "Port"; char const MaxBacklog[] = "Backlog"; char const ThreadsCount[] = "Threads"; char const RootDir[] = "Root"; char const DefaultPage[] = "DefaultPage"; // Server:127.0.0.1 Port:5555 Backlog:10 Threads:4 Root:./ DefaultPage:index.html Common::CommandLine CmdLine(argc, argv); Network::HTTPServer Srv( Network::InetAddressV4::CreateFromString( CmdLine.GetStrParameter(ServerAddr), CmdLine.GetParameter<unsigned short>(ServerPort)), CmdLine.GetParameter<unsigned>(MaxBacklog), CmdLine.GetParameter<unsigned>(ThreadsCount), CmdLine.GetStrParameter(RootDir), CmdLine.GetStrParameter(DefaultPage) ); std::cin.get(); } catch (std::exception const &e) { Common::Log::GetLogInst() << e.what(); } return 0; }

बढ़ावा देने पर लागू करें

boost.asio बढ़ावा देने का हिस्सा है, जो नेटवर्क अनुप्रयोगों के विकास को कम करने में मदद कर सकता है, और क्रॉस-प्लेटफॉर्म वाले भी। लाइब्रेरी डेवलपर से बहुत सारी दिनचर्या छुपाती है।
मैंने बढ़ावा देने पर HTTP सर्वर के कार्यान्वयन को नहीं लिखा। मैंने बूस्ट का उदाहरण लिया। उदाहरण मल्टीथ्रेडेड HTTP सर्वर। HTTP सर्वर 3 इस उदाहरण का कार्यान्वयन उपरोक्त उदाहरणों के साथ संयोजन में परीक्षण के लिए काफी उपयुक्त है।
परीक्षण के लिए एक HTTP सर्वर का कार्यान्वयन है, लेकिन सामान्य सिद्धांतों के बारे में थोड़ी सी बात करना बुरा नहीं होगा ... दुर्भाग्य से, libevent के विपरीत, boost.asio HTTP और अन्य के समान किसी भी उच्च-स्तरीय प्रोटोकॉल का समर्थन नहीं करता है। पुस्तकालय इस मामले में टीसीपी पर नेटवर्क के साथ काम छिपाएगा, लेकिन प्रोटोकॉल हेडर को इकट्ठा करने और पार्स करने के लिए HTTP कार्यान्वयन खुद डेवलपर द्वारा किया जाना होगा।
नीचे एक विवरण के साथ एक बहु-थ्रेडेड इको सर्वर का एक छोटा उदाहरण है, क्योंकि इस विषय के प्रकाश में HTTP हेडर को पार्स / इकट्ठा करना मेरे लिए कम दिलचस्प था। एक बहु-पिरोया सर्वर को बढ़ावा देने के लिए चरणों का क्रम बढ़ा रहा है। कुछ इस तरह है:

बढ़ावा देने की वस्तुओं बनाएँ :: asio :: io_service और बढ़ावा :: asio :: ip :: tcp :: स्वीकर्ता वर्ग।
बूस्ट का उपयोग कर :: asio :: ip :: tcp :: resolver and boost :: asio :: ip :: tcp :: endpoint स्थानीय पते का अनुवाद करें जिससे सुनने वाला सॉकेट लाइब्रेरी द्वारा उपयोग किए जाने वाले ढांचे में बंध जाएगा।
कॉल को बांधें और वर्ग को बढ़ावा देने की वस्तु पर सुनें :: asio :: ip :: tcp :: स्वीकर्ता।
कुछ वर्ग "कनेक्शन" बनाएं; उर्फ "सत्र", जिसके उदाहरणों का उपयोग आने वाले उपयोगकर्ता कनेक्शन प्राप्त करते समय किया जाएगा।
आने वाले कनेक्शन प्राप्त करने, डेटा प्राप्त करने के लिए उपयुक्त कॉलबैक फ़ंक्शन कॉन्फ़िगर करें।
मैसेज प्रोसेसिंग लूप को बढ़ावा देकर कॉल करें :: asio :: io_service :: run।

और libevent उदाहरण के साथ, एक बहु-थ्रेडेड सर्वर ऊपर वर्णित चरणों के सेट का उपयोग करके एकल-थ्रेडेड सर्वर से बनाना बहुत सरल है। इस स्थिति में, एकल-थ्रेडेड और बहु-थ्रेडेड सर्वर के बीच का अंतर केवल इतना है कि बढ़ावा :: asio :: io_service :: रन पद्धति को बहु-थ्रेडेड कार्यान्वयन के लिए प्रत्येक थ्रेड में कॉल करने की आवश्यकता होती है।

Echo server कार्यान्वयन को boost.asio पर

 #include <boost/noncopyable.hpp> #include <boost/asio.hpp> #include <boost/shared_ptr.hpp> #include <boost/thread.hpp> #include <boost/make_shared.hpp> #include <boost/bind.hpp> #include <boost/enable_shared_from_this.hpp> #include <boost/array.hpp> namespace Network { namespace Private { class Connection : private boost::noncopyable , public boost::enable_shared_from_this<Connection> { public: Connection(boost::asio::io_service &ioService) : Strand(ioService) , Socket(ioService) { } boost::asio::ip::tcp::socket& GetSocket() { return Socket; } void Start() { Socket.async_read_some(boost::asio::buffer(Buffer), Strand.wrap( boost::bind(&Connection::HandleRead, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred) )); } void HandleRead(boost::system::error_code const &error, std::size_t bytes) { if (error) return; std::vector<boost::asio::const_buffer> Buffers; Buffers.push_back(boost::asio::const_buffer(Buffer.data(), bytes)); boost::asio::async_write(Socket, Buffers, Strand.wrap( boost::bind(&Connection::HandleWrite, shared_from_this(), boost::asio::placeholders::error) )); } void HandleWrite(boost::system::error_code const &error) { if (error) return; boost::system::error_code Code; Socket.shutdown(boost::asio::ip::tcp::socket::shutdown_both, Code); } private: boost::array<char, 4096> Buffer; boost::asio::io_service::strand Strand; boost::asio::ip::tcp::socket Socket; }; } class EchoServer : private boost::noncopyable { public: EchoServer(std::string const& locAddr, std::string const& port, unsigned threadsCount) : Acceptor(IoService) , Threads(threadsCount) { boost::asio::ip::tcp::resolver Resolver(IoService); boost::asio::ip::tcp::resolver::query Query(locAddr, port); boost::asio::ip::tcp::endpoint Endpoint = *Resolver.resolve(Query); Acceptor.open(Endpoint.protocol()); Acceptor.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true)); Acceptor.bind(Endpoint); Acceptor.listen(); StartAccept(); std::generate(Threads.begin(), Threads.end(), boost::bind( &boost::make_shared<boost::thread, boost::function<void ()> const &>, boost::function<void ()>(boost::bind(&boost::asio::io_service::run, &IoService)) )); } ~EchoServer() { std::for_each(Threads.begin(), Threads.end(), boost::bind(&boost::asio::io_service::stop, &IoService)); std::for_each(Threads.begin(), Threads.end(), boost::bind(&boost::thread::join, _1)); } private: boost::asio::io_service IoService; boost::asio::ip::tcp::acceptor Acceptor; typedef boost::shared_ptr<Private::Connection> ConnectionPtr; ConnectionPtr NewConnection; typedef boost::shared_ptr<boost::thread> ThreadPtr; typedef std::vector<ThreadPtr> ThreadPool; ThreadPool Threads; void StartAccept() { NewConnection = boost::make_shared<Private::Connection, boost::asio::io_service &>(IoService); Acceptor.async_accept(NewConnection->GetSocket(), boost::bind(&EchoServer::HandleAccept, this, boost::asio::placeholders::error)); } void HandleAccept(boost::system::error_code const &error) { if (!error) NewConnection->Start(); StartAccept(); } }; } int main() { try { Network::EchoServer Srv("127.0.0.1", "5555", 4); std::cin.get(); } catch (std::exception const &e) { std::cerr << e.what() << std::endl; } return 0; }

परीक्षण

यह प्राप्त शिल्प की तुलना करने का समय है ...
जिस प्लेटफ़ॉर्म पर सब कुछ विकसित और परीक्षण किया गया, वह एक नियमित लैपटॉप है जिसमें 4GB RAM और 2-कोर प्रोसेसर वाला Ubuntu 12.04 डेस्कटॉप चल रहा है।
सबसे पहले, मैंने परीक्षण के लिए उपयोगिता रखी:

 sudo apt-get install apache2-utils

और इस तरह से परीक्षण करें:

 ab -c 100 -k -r -t 5 "http://127.0.0.1:5555/test.jpg"

सभी सर्वरों के लिए, 4 वर्कफ़्लो सेट किए गए, 100 समानांतर कनेक्शन, 2496629 बाइट्स में ट्रांसमिशन के लिए एक फ़ाइल और 5 सेकंड का अनुमानित समय अंतराल।
परिणाम:

एपोल कार्यान्वयन

बेंचमार्किंग 127.0.0.1 (धैर्य रखें)
2150 अनुरोधों को पूरा किया

सर्वर सॉफ्टवेयर: MyTestHttpServer
सर्वर होस्टनाम: 127.0.0.1
सर्वर पोर्ट: 5555

दस्तावेज़ पथ: /test.jpg
दस्तावेज़ की लंबाई: 2496629 बाइट्स

सम्‍मिलन स्तर: 100
परीक्षणों के लिए लिया गया समय: 5.017 सेकंड
पूर्ण अनुरोध: 2150
विफल अनुरोध: 0
त्रुटियों को लिखें: 0
रख-रखाव अनुरोध: 0
कुल स्थानांतरित: 5389312814 बाइट्स
HTML स्थानांतरित: 5388981758 बाइट्स
प्रति सेकंड अनुरोध: 428.54 [# / सेकंड] (मतलब)
अनुरोध के अनुसार समय: 233.348 [एमएस] (मतलब)
अनुरोध के अनुसार समय: 2.333 [एमएस] (मतलब, सभी समवर्ती अनुरोधों के पार)
स्थानांतरण दर: 1049037.42 [Kbytes / sec] प्राप्त किया

कनेक्शन टाइम्स (एमएस)
मिन का मतलब है [] sd] माध्यिका अधिकतम
कनेक्ट: 0 0 0.5 0 3
प्रसंस्करण: 74 226 58.2 229 364
प्रतीक्षा: 2 १३३ ६४. 141 १४१ २६४
कुल: 77 226 58.1 229 364

Libevent कार्यान्वयन

बेंचमार्किंग 127.0.0.1 (धैर्य रखें)
1653 अनुरोधों को पूरा किया

सर्वर सॉफ्टवेयर:
सर्वर होस्टनाम: 127.0.0.1
सर्वर पोर्ट: 5555

दस्तावेज़ पथ: /test.jpg
दस्तावेज़ की लंबाई: 2496629 बाइट्स

सम्‍मिलन स्तर: 100
परीक्षणों के लिए लिया गया समय: 5.008 सेकंड
पूर्ण अनुरोध: 1653
विफल अनुरोध: 0
त्रुटियों को लिखें: 0
Keep-Alive अनुरोध: 1653
कुल हस्तांतरित: 4263404830 बाइट्स
HTML स्थानांतरित: 4263207306 बाइट्स
प्रति सेकंड अनुरोध: 330.05 [# / सेकंड] (मतलब)
अनुरोध के अनुसार समय: 302.987 [एमएस] (मतलब)
अनुरोध के अनुसार समय: 3.030 [एमएस] (मतलब, सभी समवर्ती अनुरोधों के पार)
स्थानांतरण दर: 831304.15 [Kbytes / sec] प्राप्त किया

कनेक्शन टाइम्स (एमएस)
मिन का मतलब है [] sd] माध्यिका अधिकतम
कनेक्ट: 0 53 223.3 0 1000
प्रसंस्करण: 3 228 275.5 62 904
प्रतीक्षा: ० ११ ४२.५ ५ ६३ ९
कुल: ३ २ 3० ४१ :.९ ६२ १ .६४

बढ़ावा देने पर लागू करें

बेंचमार्किंग 127.0.0.1 (धैर्य रखें)
639 अनुरोधों को पूरा किया

सर्वर सॉफ्टवेयर:
सर्वर होस्टनाम: 127.0.0.1
सर्वर पोर्ट: 5555

दस्तावेज़ पथ: /test.jpg
दस्तावेज़ की लंबाई: 2496629 बाइट्स

सम्‍मिलन स्तर: 100
परीक्षणों के लिए लिया गया समय: 5.001 सेकंड
पूर्ण अनुरोध: 639
विफल अनुरोध: 0
त्रुटियों को लिखें: 0
रख-रखाव अनुरोध: 0
कुल हस्तांतरित: 1655047414 बाइट्स
HTML स्थानांतरित: 1654999464 बाइट्स
प्रति सेकंड अनुरोध: 127.78 [# / सेकंड] (मतलब)
अनुरोध के अनुसार समय: 782.584 [एमएस] (मतलब)
अनुरोध के अनुसार समय: 7.826 [एमएस] (मतलब, सभी समवर्ती अनुरोधों के पार)
स्थानांतरण दर: 323205.36 [Kbytes / sec] प्राप्त किया

कनेक्शन टाइम्स (एमएस)
मिन का मतलब है [] sd] माध्यिका अधिकतम
कनेक्ट: 0 0 1.1 0 4
प्रसंस्करण: 286 724 120.0 689 1106
प्रतीक्षा: 12 364 101.0 394 532
कुल: 286 724 120.0 689 1106

परिणाम तालिका में संक्षेपित हैं।

	epoll	libevent	boost.asio
पूर्ण अनुरोध	2150	1653	639
कुल हस्तांतरित (बाइट्स)	5389312814	4263404830	1655047414
HTML स्थानांतरित (बाइट्स)	5388981758	4263207306	1654999464
प्रति सेकंड अनुरोध [सेकंड] (मतलब)	428.54	330.05	127.78
अनुरोध के अनुसार समय [एमएस] (मतलब)	233,348	302,987	782,584
स्थानांतरण दर [Kbytes / sec] प्राप्त की	1,049,037.42	831,304.15	323,205.36

झूठ तीन प्रकार के होते हैं: झूठ, झूठ और झूठ। हालाँकि, मुझे स्वीकार करना चाहिए, लेकिन परिणाम मुझे नहीं मिल सकता। मुझे लगता है कि आपको परिणामों पर विशेष ध्यान नहीं देना चाहिए, लेकिन आप उन्हें कुछ सहायक जानकारी के रूप में देख सकते हैं जो आपके सर्वर सॉफ़्टवेयर के विकास उपकरण की पसंद पर निर्णय लेने में उपयोगी हो सकती हैं। परिणामों की सटीकता के लिए, सर्वर हार्डवेयर, नेटवर्क पर अन्य मशीनों पर चलने वाले क्लाइंट आदि पर कई रन की व्यवस्था करना उचित है।
100 समानांतर क्वेरियाँ - यह छोटी सी प्रतीत होगी, लेकिन ऐसी मामूली परिस्थितियों में परीक्षण के लिए काफी पर्याप्त है। बेशक, मैं हजारों समानांतर प्रश्नों पर परिणामों की जांच करना चाहूंगा, लेकिन पहले से ही अन्य कारक हैं। ऐसा एक कारक एक प्रक्रिया के लिए एक साथ खुले फ़ाइल डिस्क्रिप्टर की संख्या है। आप getrlimit और setrlimit फ़ंक्शन को कॉल करके कुछ प्रक्रिया पैरामीटर पता कर सकते हैं और सेट कर सकते हैं। प्रति प्रक्रिया में कितने फ़ाइल डिस्क्रिप्टर आवंटित किए गए हैं, यह जानने के लिए, आप रिप्लिट संरचना के RLIMIT_NOFILE के फ्लैग के साथ गेटलिमिट को कॉल कर सकते हैं। इसके ऑपरेटिंग सिस्टम के लिए, ये डिफ़ॉल्ट रूप से प्रति प्रोसेस 1024 फाइल डिस्क्रिप्टर हैं और अधिकतम 4096 प्रक्रिया पर सेट किए जा सकते हैं।आपको इस मानदंड से अधिक नहीं होना चाहिए ... वैकल्पिक रूप से, आपके सर्वर को एक प्रक्रिया में बड़ी संख्या में फ़ाइल डिस्क्रिप्टर के साथ काम करने के लिए, आप सिस्टम को तदनुसार कॉन्फ़िगर कर सकते हैं। लिनक्स पर बढ़ते सॉकेट प्रदर्शन में लेख का एक अच्छा वर्णन है

निष्कर्ष और निष्कर्ष

अपनी वेबसर्वर को नंगे सॉकेट पर लिखना निश्चित रूप से दिलचस्प है, लेकिन यह मत भूलो कि शैतान विवरण में है। जैसा कि वे महसूस कर रहे हैं, ये बहुत विवरण, एक स्नोबॉल की तरह, अधिक से अधिक रोल कर रहे हैं। सूचना प्रौद्योगिकी के क्षेत्र में साइकिल उद्योग के लिए मेरे बहुत प्यार के बावजूद, मैं इस मामले को तब भी छोड़ दूंगा, जब आपको कुछ विशिष्ट लिखने की आवश्यकता होगी, कुछ सामान्यीकरणों का त्याग करना होगा और अधिकतम प्रदर्शन प्राप्त करने के पक्ष में कुछ उच्च-स्तर का होगा। सर्वर। एपोल पर कार्यान्वयन के साथ लेख से जुड़ा कोड अभी भी सुधार और सुधार किया जा सकता है। औद्योगिक कार्यान्वयन में लाना और इस तरह के विकास का समर्थन करना बहुत महंगा होगा, क्रमशः, ऐसी प्रणाली पर नियोजित रिटर्न भी छोटा नहीं होना चाहिए। लेकिन "ज़बरदस्त झूठ"सारांश तालिका में ऊपर, लेकिन इस तथ्य के बावजूद खुशी नहीं हो सकती है कि सर्वर सी ++ में लिखा गया था, और शुद्ध सी में नहीं, अपवाद के साथ, स्टाल का उपयोग करके इसके कार्यान्वयन का तिरस्कार नहीं किया गया था और यह प्रत्येक चरण के लिए बहुत अधिक विचार के बिना लिखा गया था।
जैसा कि पहले ही ऊपर उल्लेख किया गया है, परिवाद पुस्तकालय मेरा पसंदीदा बन गया है, यह एक त्वरित शुरुआत के लिए बहुत सरल है, यह प्रदर्शन में बहुत अच्छे परिणाम देता है, क्रॉस-प्लेटफॉर्म, यह बहुत कुछ छुपाता है। अधिकांश परियोजनाओं के लिए, मैं पहले इस पर विचार करूंगा।
मेरे व्यक्तिपरक राय में, बढ़ावा बहुत अजीब है। यह विभिन्न सॉफ्टवेयर के विकास में कई फायदे देता है और कुछ जगहों पर बहुत आकर्षक है। boost.asio नेटवर्क सॉफ़्टवेयर विकसित करते समय अधिकांश आवश्यक चीज़ों से काफी उच्च स्तर की अमूर्तता प्रदान करता है। मुझे सर्वर सॉफ़्टवेयर के विकास में इस लाइब्रेरी के उपयोग के बारे में "अनुभवी" की राय सुनना पसंद है, और अधिमानतः एक उच्च भार के साथ।
अभी भी एक दिलचस्प तंत्र हैलिनक्स (aio) में अतुल्यकालिक इनपुट आउटपुट , लेकिन अभी तक अन्य कार्यान्वयन के साथ तुलना के लिए एक ही "नंगे" सॉकेट पर इसे लागू करने के लिए पर्याप्त समय नहीं है। एसवीएन

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

इसलिए "छोटा" परीक्षण कार्य ऑपरेटिंग सिस्टम और पुस्तकालयों के एपीआई के कुछ अवलोकन के लिए मेरे लिए एक दिलचस्प प्रोत्साहन बन गया।

आपका ध्यान के लिए धन्यवाद!

एक परीक्षण कार्य के रूप में WebServer