लगातार टीसीपी लिंग-परिवर्तक प्रॉक्सी कैसे सेट करें?

Question

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

इसे हल करने का एक तरीका एक ऐसी सेवा होगी जो आने वाली टीसीपी ए पोर्ट को दूसरे टीसीपी पोर्ट बी से जोड़ती है, ताकि उपभोक्ता बी से एक आउटबाउंड बना सके।

यह एक अनोखी समस्या नहीं है [1] [२] , और समाज के साथ मैं जो चाहता हूँ, उसके बहुत करीब आ सकता हूँ:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

हालाँकि, इसमें निम्न समस्याएं हैं:

• यदि B डिस्कनेक्ट हो जाता है, तो यह पुनः कनेक्ट नहीं हो सकता है। इसके साथ TCP4-LISTEN:PORT-B,reuseaddr,fork, यह कनेक्ट हो सकता है लेकिन डेटा प्राप्त नहीं करता है।
• A कनेक्शन स्थापित करने से पहले B कनेक्ट नहीं कर सकता (अधिगम योग्य)
• केवल एक कनेक्शन स्थापित किया जा सकता है PORT-B(अधिगम योग्य)

क्या कमांड को समायोजित करने का एक तरीका है ताकि "परमिट" बन जाए और विफलताओं का प्रतिरोध हो?

Answer 1

महत्वपूर्ण सवाल यह है कि ए कनेक्शन के नुकसान पर प्रतिक्रिया कैसे करेगा, या कनेक्शन से इनकार कर दिया जाएगा? जो कुछ भी बस मानता है कि एक एकल टीसीपी कनेक्शन हमेशा के लिए रहने वाला है वह नाजुक होने वाला है; यह सिर्फ इंटरनेट की प्रकृति है।

कैसे socatएक [x]inetdसेवा के रूप में स्थापित करने के बारे में ?

आप xinetdPORT-B में सुनने के लिए सेट होंगे , और socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOजैसे ही बी-साइड कनेक्ट होगा , शुरू हो जाएगा।

xinetdआने वाले ट्रैफ़िक को B-side से मानक इनपुट तक पास करेगा socat, और मानक आउटपुट को पकड़कर socatB-side को पास करेगा।

यदि बी डिस्कनेक्ट हो जाता है, तो socatप्रक्रिया को समाप्त करने की अनुमति दी जा सकती है; xinetdजैसे ही B फिर से जुड़ता है एक नया शुरू करेगा। जबकि बी काट दिया गया है, ए को "कनेक्शन मना कर दिया" त्रुटियां हो रही हैं।

मुझे एक बार पुराने एचपी-यूएक्स सिस्टम पर काफी कुछ करना था।

Comments

ए कनेक्शन के नुकसान पर एक अंतराल पर फिर से कनेक्ट करने का प्रयास करेगा, ताकि कवर किया जाए। xinetd लगता है कि यह काम कर सकता है। कोशिश करेंगे और वापस रिपोर्ट करेंगे, धन्यवाद!

— dtech

यह सबसे महत्वपूर्ण समस्या को हल करता है: कि सेवा विफलता पर कनेक्शन को फिर से स्थापित कर सकती है। धन्यवाद!

— dtech

Answer 2

असली दुनिया गड़बड़ है।

वास्तविक दुनिया में कभी-कभी टीसीपी कनेक्शन मर जाते हैं, उदाहरण के लिए ऐसा हो सकता है यदि कोई स्टेटफुल फ़ायरवॉल या NAT रिबूट किया जाता है, यदि कनेक्शन ट्रैफ़िक के बिना बहुत लंबा चला जाता है, यदि अंतर्निहित कनेक्शन बहुत लंबे समय तक नीचे है।

इसके अलावा कभी-कभी जब कनेक्शन मर जाते हैं तो वे सममित रूप से नहीं मरते हैं। यदि बहुत अधिक डेटा ले जाने वाला कनेक्शन मर जाता है, तो संभावना है कि प्रेषक यह नोटिस करेगा कि प्राप्तकर्ता ऐसा करने से बहुत पहले मर चुका है। इसके कुछ दुष्प्रभाव हैं।

• यदि कनेक्शन को प्रेषक से प्राप्तकर्ता तक शुरू किया जाता है तो एक नया कनेक्शन आ सकता है जबकि पुराना कनेक्शन स्पष्ट रूप से अभी भी जीवित है।
• यदि कनेक्शन प्राप्तकर्ता से प्रेषक के लिए शुरू किया जाता है, तो प्रेषक का पता लगाने में कनेक्शन टूट जाने और उस तथ्य का पता लगाने वाले और पुन: संयोजन को ट्रिगर करने वाले के बीच काफी देरी हो सकती है।

इसके अलावा टीसीपी कनेक्शन बाइट्स की एक धारा है, संदेशों की एक धारा नहीं है, इसलिए जब आपका कनेक्शन मर जाता है तो आपको एक आंशिक संदेश प्राप्त हो सकता है।

इसका शुद्ध परिणाम मुझे यह निष्कर्ष निकालने के लिए प्रेरित करता है कि एक मजबूत समाधान के लिए एप्लिकेशन प्रोटोकॉल की समझ की आवश्यकता होती है ताकि आपका समाधान समझ सके।

1. जब एक नया कनेक्शन आता है तो धाराओं को कैसे विभाजित करना है।
2. जब डेटा स्रोत डेटा प्राप्तकर्ता द्वारा कनेक्ट नहीं किया जाता है, तो संदेशों को संग्रहीत किया जाना चाहिए या नहीं।
3. संदेश की हानि को रोकने के लिए एंड टू एंड पावती तंत्र उपयुक्त है या नहीं।
4. मृत कनेक्शन का पता लगाने के लिए किसी प्रकार के अनुप्रयोग स्तर "पिंग" तंत्र की आवश्यकता है या नहीं।

Comments

सभी अच्छे अंक, लेकिन इस मामले में एप्लिकेशन प्रोटोकॉल बहुत सरल है। आंशिक संदेशों को आसानी से पता लगाया जाता है और खारिज कर दिया जाता है। संदेश खोना कोई बड़ी समस्या नहीं है यदि कनेक्शन को जल्दी से फिर से स्थापित किया जा सकता है।

— dtech