मैं प्रॉक्सी बनाने पर काम कर रहा हूं जो आने वाले कनेक्शन के लिए किसी विशेष पोर्ट पर सुनता है। कनेक्शन आमतौर पर एचटीपी अनुरोध (जीईटी/पोस्ट) होते हैं। मुझे तय नहीं करना चाहिए कि मैं एचटीपी लिस्टर या सॉकेट चुनूं। मैं प्रॉक्सी में HttpRequests संशोधित कर रहा हूं और फिर इसे अंतिम गंतव्य पर रिले कर दूंगा।सॉकेट बनाम HttpListener
आप सॉकेट पर HttpListener को कब पसंद करते हैं। प्रत्येक के क्या फायदे हैं?
नवंबर वर्ष 2016 अद्यतन: HttpListener बहुत अच्छी तरह से काम करता है जब दूरदराज मशीनों से ट्रैफ़िक मिल रहा। हालांकि, जब ग्राहक स्थानीयहोस्ट पर होता है तो बड़े पेलोड के लिए एचटीपी लिस्टनर खराब विकल्प होता है। इसका कारण आंशिक रूप से है क्योंकि HttpListener http.sys का उपयोग करता है, जो एक कर्नेल मॉड्यूल है, और स्पष्ट रूप से कार्यान्वयन शरीर डेटा के कई अतिरिक्त प्रतियों का कारण बनता है। उदाहरण के लिए, सी # में एक सरणी से दूसरे सरणी में 100 एमबी की प्रतिलिपि बनाना 35 एमएस लेता है जबकि स्थानीय क्लाइंट से 100 एमबी पोस्ट करने के लिए एचटीपी लिस्टनर 350 एमएस (हाँ, 10x लंबा) लेता है। इस मामले में मोनो के एचटीपी लिस्टर को स्विच करने से समय 250 एमएस तक गिर जाता है। सॉकेट क्लाइंट के साथ टीसीपीलिस्टर का उपयोग 180 एमएस लेता है। MemoryMappedFiles का उपयोग कर सर्कुलर बफर के लिए सॉकेट के उपयोग को स्वैप करना 55 एमएस लेता है। इस प्रकार स्थानीय मशीन से एक्सेस होने पर एचटीपी लिस्टनर बड़े पेलोड के लिए इतना अच्छा काम नहीं करता है। नोट: यदि आप इस परीक्षण को पुन: पेश करने का प्रयास करते हैं तो आपको समय अंतर को मापने के लिए सावधानी बरतनी होगी। स्टर्न डेटा भेजना शुरू कर देता है और जब सरणी प्राप्त करने की प्रक्रिया में आबादी को पूरा कर रही है क्योंकि कुछ भेजें/लिखने के तरीके लगभग किसी भी डेटा को भेजने के बिना लगभग तुरंत लौटते हैं (जिसे आप शून्यों की एक सरणी भेजकर साबित कर सकते हैं और फिर से लिख सकते हैं सरणी के पीछे की ओर की ओर; आप लगभग सभी को प्राप्त करेंगे, साबित करते हैं कि फ़ंक्शन लौटने के बाद तक डेटा नहीं भेजा गया था)। अपने सहयोगियों यहाँ से एक से बनाम मोनो HttpListener HttpListener की स्थानीय मशीन प्रदर्शन घाटा पर
अधिक विवरण: https://www.linkedin.com/pulse/http-inefficiency-dominika-blach
अच्छा जवाब। मेरे मामले में मैं सोच रहा हूं कि क्यों मेरे ग्राहक कुछ सौ कनेक्शन के बाद संदेश भेजना बंद कर देते हैं। मैं सर्वर के लिए एक WebRequest सर्वर के लिए एक HttpListener का उपयोग करें। थोड़ी देर के बाद वे बस सरल स्टॉप, कोई त्रुटि नहीं, ऐसा लगता है कि कोई संसाधन उपलब्ध नहीं था। 'ServicePointManager.DefaultConnectionLimit' और 'ServicePointManager.MaxServicePoints' के साथ खेलना कुछ सौ कनेक्शनों के बाद मदद नहीं करता है, मुझे एक ही त्रुटि मिली है। मैंने KeepAlive के साथ प्रयास किया है लेकिन कोई भाग्य नहीं है। कोई उपाय? धन्यवाद। – GBrian
अधिकतर आप एक या दोनों सिरों पर अनुरोध और प्रतिक्रिया को सही तरीके से बंद नहीं कर रहे हैं, या आपने क्लाइंट साइड पर थ्रेड पूल (जैसे टाइमर का उपयोग करके) का उपयोग किया है और आप उस थ्रेड पूल थ्रेड से अपवाद फेंक रहे हैं। एक बार धागा पूल धागा करता है यह कभी भी पुनर्निर्मित नहीं होता है। एक बार जब आप थ्रेड पूल धागे से बाहर निकलते हैं तो उन्हें उपयोग करने वाले कुछ भी जैसे टाइमर ऑब्जेक्ट्स अब काम नहीं करते हैं। – huntharo
नीचे दिए गए प्रश्न के उत्तर के रूप में पोस्ट किए गए HttpListener नमूना कोड की जांच करें। देखें कि क्या आप अनुरोधों को एक ही तरीके से संभालने या अपने सर्वर का एक नया संस्करण बनाने के लिए इसका उपयोग कर रहे हैं और देखें कि समस्या बनी रहती है या नहीं। http://stackoverflow.com/questions/10485985/bad-performance-when-offering-files-to-download-with-httplistener/19202175#19202175 – huntharo
पार्सिंग/HTTP शीर्ष लेख में संशोधन करना, सामग्री पढ़ने, chunked हस्तांतरण से निपटने आदि HttpListener साथ बहुत सरल कर रहे हैं। –
आप HttpRequests को किस प्रकार के संशोधन करने जा रहे हैं? –
मैं होस्टहेडर बदल रहा हूं, कुछ अनुरोधों को पुनर्निर्देशित कर रहा हूं आदि – NewUnhandledException