विश्वसनीय/लगातार आउटबाउंड सॉकेट की आवश्यकता है, विकल्प?

Question

मेरे पास एक स्कैला एप्लिकेशन है जो एक समय में विभिन्न सर्वरों (संभवतः> 24) के लिए विभिन्न सर्वरों के लिए टीसीपी कनेक्शन बनाए रखता है (या कोशिश करता है)। प्रत्येक सर्वर एक छोटा, ~ 30 वर्ण संदेश दो बार एक सेकंड भेजता है। इन संदेशों को एक पुनरावृत्त में खिलाया जाता है जहां उन्हें पार्स किया जाता है और अंत में डेटाबेस में राज्य परिवर्तन करने को समाप्त होता है।

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

यह कल्पना की जा सकती है कि इनमें से 300 कनेक्शन एक बार में होंगे। वास्तव में कोई उच्च लोड परिदृश्य नहीं है, इसलिए मुझे नहीं लगता कि एनआईओ की आवश्यकता है, हालांकि यह अच्छा हो सकता है? ऐप के अन्य बिट्स उच्च लोड हैं।

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

क्या एनआईओ कोई वास्तविक लाभ प्रदान करेगा?

क्या नेटी यहां सबसे अच्छा विकल्प होगा? मैंने Uptime उदाहरण here देखा है, और बस इसे डुप्लिकेट करने की सोच रहा था, लेकिन निम्न स्तर के नेटवर्किंग के लिए नया होने के नाते मुझे यकीन नहीं था कि बेहतर विकल्प हैं या नहीं।

Answer 1

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

यूप। जेएमएस एक उदाहरण है।

मुझे लगता है कि इसमें से बहुत समय एक अनुमान लगाने की रणनीति के लिए नीचे आ जाएगा? एक सॉकेट को बहुत जल्दी बंद करें और फिर से खोलें और आप जो भी पैकेट एन-रूट खो चुके हैं, खो चुके हैं।

यह सही है। वह दृष्टिकोण विश्वसनीय नहीं होगा, खासकर यदि कनेक्शन नियमित रूप से ऊपर और नीचे जाते हैं।

एक वास्तविक समाधान में दूसरे छोर को प्राप्त करने के बारे में पता चलता है, और प्रेषक को यह पता चल जाता है कि कनेक्शन कब फिर से स्थापित किया जाता है। यदि ऐसा नहीं किया जा सकता है, तो आपके पास कितना खो जाता है इसे नियंत्रित करने का कोई वास्तविक तरीका नहीं है। (यह विश्वसनीय संदेश सेवा है ...)

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

यूप। और यदि आप हाथ से इसे लागू करने का प्रयास करते हैं तो वही लागू होता है। दूसरे छोर को सहयोग करना है।

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