स्थानीय आईपीसी, पॉज़िक्स संदेश कतार (mqueues) या यूनिक्स डोमेन (स्थानीय) सॉकेट के लिए कौन सा बेहतर है?

Question

स्थानीय आईपीसी संचार के लिए POSIX संदेश कतार या यूनिक्स डोमेन सॉकेट का उपयोग करना बेहतर है?

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

मेरी वर्तमान परियोजना में हमें स्थानीय आईपीसी की आवश्यकता है। मेरी पहली प्रतिक्रिया POSIX MQueues का उपयोग करना था, क्योंकि मैंने उन्हें स्थानीय संदेश के लिए पहले उपयोग किया था। हालांकि, एक सहकर्मी इसके बजाय यूनिक्स डोमेन सॉकेट का सुझाव दे रहा है।

क्या एक दूसरे से बेहतर है, या यह प्रोग्रामिंग परिचितता का मामला है? या शायद यह बनाया जा रहा आवेदन पर निर्भर करता है?

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

भेजने पक्ष के लिए बुनियादी तर्क है:

connect to server 
send request 
note if the send worked or not 
disconnect from server 

एक सर्वर से ग्राहकों के सैकड़ों हो सकता है।

हम लिनक्स ओएस चलाने वाले एक एसएमपी सिस्टम (4-8 कोर) पर निष्पादित कर रहे हैं।

अग्रिम धन्यवाद।

Answer 1

यूनिक्स डोमेन सॉकेट को TIME_WAIT-जैसी स्थिति में "लंबा" होना नहीं है, क्योंकि उस प्रतीक्षा समय का उपयोग तब किया जाता है जब कनेक्शन से भटकने वाले पैकेट इंटरनेट के चारों ओर घूमते रहते हैं। चिंता स्थानीय रूप से लागू नहीं होती है।

यूनिक्स डोमेन सॉकेट या तो SOCK_STREAM (टीसीपी की तरह) या SOCK_DGRAM (यूडीपी की तरह) हो सकता है, अतिरिक्त गारंटी के साथ कि यूनिक्स डोमेन डेटाग्राम सॉकेट विश्वसनीय हैं और डेटाग्राम को फिर से ऑर्डर नहीं करते हैं।

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

मैं मानता हूं कि पसंद अनिवार्य रूप से प्रोग्रामिंग परिचितता का विषय है।

Answer 2

क्या एक दूसरे से बेहतर है, या यह प्रोग्रामिंग परिचितता का मामला है? या शायद यह बनाया जा रहा आवेदन पर निर्भर करता है?

• आप poll() सॉकेट, लेकिन आप नहीं कर सकते हैं संदेश कतार कर सकते हैं:

SysV संदेश यूनिक्स डोमेन आंकड़ारेख सॉकेट की तुलना में कतारों प्रमुख मतभेद मैं के बारे में पता कर रहा हूँ है।

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

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

man msgrcv पर देखकर मुझे सॉकेट के MSG_PEEK का एनालॉग दिखाई नहीं देता है। शायद ही कभी जरूरत है, लेकिन कई बार काफी आसान आता है।

अधिकांश समय, उपयोगकर्ता कॉन्फ़िगरेशन प्रतीकात्मक नामों में उपयोग करना पसंद करते हैं, न कि संख्यात्मक कुंजी आईडी। प्रतीकात्मक कुंजी की कमी आईएमओ एसआईएसवी इंटरफेस डिजाइनरों के हिस्से पर काफी गंभीर निगरानी है।

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

सब कुछ, मैं संभव होने पर एसआईएसवी संसाधनों से बचता हूं: poll() की कमी सबसे आम परिस्थितियों में सहायता एक सौदा ब्रेकर है।

हालांकि, ग्राहक "इसकी पूर्ण" प्रतिक्रिया की प्रतीक्षा नहीं करता है - हालांकि वे जानना चाहते हैं कि उनका अनुरोध प्राप्त हुआ है या नहीं।

यह लेनदेन संबंधी प्रक्रिया का एक आम दुविधा है। सामान्य प्रतिक्रिया (जैसा कि आरडीबीएमएस में है) आप संचार बाधा (क्रैश या जो कुछ भी) के बाद और बाद में आवेदन कर सकते हैं कि एप्लिकेशन को पहले ही संसाधित किया गया हो या नहीं।

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

Answer 3

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