दूरस्थ सॉकेट

Question

क्या diff, लाभ और दूरस्थ और सॉकेट ... के बीच नुकसान जो सर्वर-क्लाइंट कार्यक्षमता ....

Answer 1

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

रिमोटिंग एक .NET विशिष्ट उपकरण है, और यह बहुत भंगुर पुनः संस्करण है। मैं क्लाइंट/सर्वर के लिए रिमोटिंग की अनुशंसा नहीं करता - इसके बजाय डब्ल्यूसीएफ जैसी चीजों का उपयोग करें।

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

---

संपादित जानकारी के लिए, protobuf-net भी एक RPC ढेर प्रदान करता है; फिलहाल केवल एक HTTP कार्यान्वयन प्रदान किया गया है, लेकिन किसी बिंदु पर मैं कच्चे टीसीपी/आईपी जोड़ूंगा।

Answer 2

मैक ग्रेवेल ने लिखा कि दूसरा सबसे महत्वपूर्ण है - विशेष रूप से रिमोटिंग और आंतरिक धारावाहिकता "आसान" है, लेकिन तोड़ना बहुत आसान है और अक्सर सार्वजनिक नेटवर्क पर अच्छा नहीं होता है (मैं .NET remoting से परिचित नहीं हूं, लेकिन मुझे लगता है कि इसे एक अच्छी तरह से ज्ञात रजिस्ट्री सेवा की आवश्यकता है जो क्लीन लैब पर्यावरण से बाहर निकलने पर अक्सर समस्याग्रस्त हो)।

एक मानक या यहां तक ​​कि रोल-अप-आरपीसी लागू करना लंबे समय तक कठिन लेकिन सुरक्षित है: आपको कोड संशोधन (या उन्हें नियंत्रित करने में आसान) के साथ समस्या नहीं है, स्केलिंग पूरी तरह से आपके कोड द्वारा नियंत्रित होती है, और विभिन्न तकनीकों का उपयोग कर घटकों को विकसित करना आसान है।

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

Answer 3

मैं कहूंगा कि सॉकेट के बीच चयन करना और आपको रिमोट करना बेहतर तरीके से विचार करें कि आप किस प्रकार के आवेदन को विकसित कर रहे हैं। सॉकेट निश्चित रूप से आपके प्रोटोकॉल कार्यान्वयन, निम्न स्तर के प्रोग्रामिंग और अन्य टीसीपी/आईपी अनुप्रयोगों के साथ संवाद करने के लिए जाने का एकमात्र तरीका है। रीमोटिंग नए .NET संचार अनुप्रयोगों को विकसित करने का एक पसंदीदा तरीका है, जहां आपको टीसीपी/आईपी स्टैक पर आने की आवश्यकता नहीं है और सुनिश्चित करें कि आपका एप्लिकेशन दूसरों (शायद विरासत अनुप्रयोगों) से बात करता है। यदि आप केवल .NET के साथ जा सकते हैं तो .NET 2.0 और WCF फ्रेमवर्क को .NET 2.0 रीमोटिंग के बजाय चुनना बेहतर है, आखिरी वाला मृत और असमर्थित तकनीक है।

Answer 4

डायरेक्ट सॉकेट मैनिपुलेशन आपको रिमोटिंग या डब्ल्यूसीएफ की तुलना में अधिक शक्ति, लचीलापन, प्रदर्शन, और दुर्भाग्य से जटिलता प्रदान कर सकता है। हालांकि, यदि आपको निम्न-स्तरीय टीसीपी/आईपी, जैसे गैर-अवरुद्ध आईओ और कस्टम प्रोटोकॉल, Ragel जैसे टूल और Mina जैसे ढांचे जटिलता बोझ को कम कर सकते हैं, के लाभों की आवश्यकता है। मैं पहले डब्ल्यूसीएफ जैसे उच्च स्तरीय एपीआई को आजमाने की सलाह देता हूं और यदि आपकी आवश्यकताओं को पूरा नहीं करता है तो केवल प्रत्यक्ष सॉकेट का उपयोग करें।