xinetd + netcat → नुकसान

यदि आपको दूरस्थ सर्वर पर कुछ करने की आवश्यकता है, लेकिन नेटवर्क सेवा लिखने के साथ परेशान करने के लिए बहुत आलसी हैं, तो xinetd बचाव में आता है।

Xinetd के लिए सर्वर लिखने में आसानी आकर्षक है, यह वास्तव में सरल है: हम किसी भी भाषा में एक सरल स्क्रिप्ट लिख सकते हैं जो स्टड और स्टडआउट के साथ काम करती है (सरलतम मामले में यह एक नियमित REPL है ) और हमें एक बोतल में कंसोल उपयोगिता और नेटवर्क सर्वर दोनों मिलते हैं।
एक मिनट के बाद xinetd कॉन्फिग को एडिट करने के लिए, हमें एक वर्किंग सर्वर मिलता है, जिसमें आप टेलनेट या नेटकैट से कनेक्ट कर सकते हैं और कंसोल पर रिजल्ट देख सकते हैं।



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

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

इस तरह के "सर्वर" और "क्लाइंट" स्क्रिप्ट के बाद, हमें उन्हें स्थानीय रूप से बोनस के रूप में चलाने का अवसर मिलता है। इस तथ्य का उल्लेख नहीं करने के लिए कि कोडिंग के दौरान हमने नेटवर्क के साथ काम करने के संबंध में एक भी लाइन नहीं लिखी।

ज्यादातर मामलों में, यह बाद में खुशी से काम करने के लिए पर्याप्त है।

लेकिन बारीकियां हैं ।

जश्न मनाने के लिए कुछ ऐसी दूरस्थ उपयोगिताओं को लिखने के बाद, मैंने पाया कि कभी-कभी इस तरह से लिखे गए क्लाइंट और सर्वर के बीच संचार की प्रक्रिया लटक जाती है।

मैं इस विषय पर कुछ भी नहीं कर सकता, मुझे स्वयं इसका पता लगाना था, मैं आपको परिणाम प्रस्तुत करता हूं।

किसे दोष देना है?

Xinetd कैसे काम करता है: एक सॉकेट खोलता है, इसे मानक इनपुट / आउटपुट स्ट्रीम पर हुक करता है और एक बाहरी प्रोग्राम लिंक लॉन्च करता है।

नेटकाट कैसे काम करता है (-ई, उदाहरण के लिए): एक सॉकेट खोलता है, इसे मानक इनपुट / आउटपुट स्ट्रीम में हुक करता है और एक बाहरी प्रोग्राम लिंक लॉन्च करता है।

जो है, वही है।

तदनुसार, यदि दोनों कार्यक्रम टर्मिनल के साथ काम करने की दिशा में सक्षम हैं, तो कोई भी लिखने या पढ़ने की क्षमता की जांच नहीं करता है। यदि आपको पढ़ने की आवश्यकता है, तो बस पढ़ें; लिखने की जरूरत है - बस लिखें।
केवल टर्मिनल के बजाय पहले से ही एक नेटवर्क सॉकेट है, और कोई भी उस तरह के नेटवर्क के साथ काम नहीं करता है।

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

डेटा की अधिकतम मात्रा को घटाकर समस्या को सस्ते में हल करने का प्रयास समस्या को ठीक नहीं करता है, लेकिन केवल इसे स्थगित करता है।

लेकिन इस कहानी में सबसे मुझे नेटसीट ने परेशान किया।
नॉन-ब्लॉकिंग मोड को सेट करने के लिए स्ट्रेस एनसी में कोई कॉल नहीं मिलने के बाद, मैंने apt-get source में देखा और ... वास्तव में ऐसा कुछ नहीं मिला।
Netcat सिंक्रोनस मोड में सॉकेट्स के साथ काम करता है, ठंड की संभावना को भड़काने, यहां तक ​​कि किसी भी "कंसोल के लिए लिखे गए बाहरी कार्यक्रम" के बिना।
दुःख इस तथ्य से जोड़ा जाता है कि नेटकैट वास्तव में एक मानक है, हालांकि, वास्तव में, सामान्य मामले में उपयोग के लिए अनुपयुक्त।

क्या करें?

दो आउटपुट हैं:

1. xinetd के सर्वर को ध्यान में रखते हुए लिखें कि यह एक नेटवर्क है (fcntl O_NONBLOCK, स्टड और stdout पर चयन करें और वह सब), लेकिन तब xinetd का अर्थ साधारण चीजों के लिए एक साधारण आवरण के रूप में खो जाता है। आप पहले से ही एक पूर्ण सर्वर लिख सकते हैं।

2. एक समकालिक ग्राहक लिखें जो सर्वर के जवाब देने के लिए प्रतीक्षा करेगा और पढ़ने और लिखने के लिए बफर ओवरफ्लो को रोकेगा - यहाँ netcat की सरलता खो गई है और आपको प्रदर्शन के साथ कुछ करने की आवश्यकता है ताकि आप बफर को ओवर किए बिना एक ही समय में कई अनुरोध भेज सकें और कई को संसाधित करने में सक्षम हो सकें प्रतिक्रियाओं।

मेरे मामले में, मैंने सेमी-सेकंड सिंक्रोनस विकल्प चुना:
• 10 अनुरोध भेजें
• जबकि भेजने के लिए कुछ है {एक अनुरोध भेजें; एक उत्तर पढ़ें}
• 10 उत्तर पढ़ें
... जो मेरे विशेष मामले में काम किया, लेकिन एक सामान्य समाधान के रूप में, निश्चित रूप से अच्छा नहीं है।