सॉकेट पथ की लंबाई सौ वर्णों तक सीमित क्यों है?

Question

यूनिक्स सिस्टम पथ नामों में आमतौर पर कोई लंबाई सीमा नहीं होती है (अच्छी तरह से, लिनक्स पर 4096 वर्ण) ... सॉकेट फ़ाइल पथों को छोड़कर जो लगभग 100 वर्णों ( लिनक्स पर 107 वर्ण ) तक सीमित हैं ।

• पहला सवाल: इतनी कम सीमा क्यों?

मैंने जाँच की है कि वर्तमान कार्यशील निर्देशिका को बदलकर और विभिन्न निर्देशिकाओं में कई सॉकेट फ़ाइलों को एक ही पथ का उपयोग करके इस सीमा के आसपास काम करना संभव लगता है ./myfile.sock: क्लाइंट अनुप्रयोग सही-सही सर्वर प्रक्रियाओं से जुड़ने के लिए प्रतीत होते हैं, हालांकि lsofसभी दिखाता है उनमें से एक ही सॉकेट फ़ाइल पथ पर सुन रहा है।

• क्या यह वर्कअराउंड विश्वसनीय है या मैं सिर्फ भाग्यशाली था?
• क्या यह व्यवहार लिनक्स के लिए विशिष्ट है या यह वर्कअराउंड अन्य यूनिक्स के साथ भी लागू हो सकता है?

Comments

वर्तमान OpenBSD सिस्टम या Mac OS X 10.11 पर सीमा और भी कम (104) है।

— thrig

महत्वपूर्ण बात यह है कि, संगतता की खातिर इसे 108 से कम होना चाहिए :)

AFAIK यह लिनक्स पर 108 वर्ण है। कृपया अपनी मशीन पर /usr/include/$arch-linux-gnu/sys/un.h देखें।

— schaiba

@ स्चैबा: 108 बाइट्स, जिसका अर्थ है कि 107 अक्षर स्ट्रिंग एक शून्य टर्मिनेटर द्वारा समाप्त होते हैं।

— व्हाइटवर्थवॉल्फ

Answer 1

अन्य प्लेटफार्मों के साथ संगतता, या पुराने सामान के साथ संगतता का उपयोग करते समय ओवररन से बचने के लिए snprintf()और strncpy()।

माइकल केरिस्क ने पृष्ठ 1165 में अपनी पुस्तक में समझाया - अध्याय 57, सॉकेट: यूनिक्स डोमेन:

SUSv3 सूर्य_पथ क्षेत्र के आकार को निर्दिष्ट नहीं करता है। प्रारंभिक बीएसडी कार्यान्वयन 108 और 104 बाइट्स का उपयोग करता है, और एक समकालीन कार्यान्वयन (एचपी-यूएक्स 11) 92 बाइट्स का उपयोग करता है। पोर्टेबल अनुप्रयोगों को इस कम मूल्य पर कोड करना चाहिए, और इस क्षेत्र में लिखते समय बफर ओवररन से बचने के लिए स्निप्रफ () या strncpy () का उपयोग करना चाहिए।

डॉकर लोगों ने भी इसका मज़ाक उड़ाया, क्योंकि कुछ सॉकेट 110 वर्ण लंबे थे:

• योग्य 108 वर्ण ETOOMANY

यही कारण है कि LINUX 108 char सॉकेट का उपयोग करता है। क्या इसे बदला जा सकता है? बेशक। और यह, यही कारण है कि पहली बार में यह सीमा पुराने ऑपरेटिंग सिस्टम पर बनाई गई थी:

• लिनक्स 108 पर यूनिक्स-सॉकेट्स के लिए अधिकतम पथ लंबाई की अनुमति क्यों है?

जवाब उद्धृत करते हुए:

यह एक आसान कर्नेल डेटा संरचना में उपलब्ध स्थान का मिलान करना था।

McKusick एट द्वारा "द डिजाइन एंड इंप्लीमेंटेशन ऑफ द 4.4BSD ऑपरेटिंग सिस्टम" का हवाला देते हुए। अल। (पेज 369):

स्मृति प्रबंधन सुविधाएं एक डेटा संरचना के चारों ओर घूमती हैं जिसे mbuf कहा जाता है। डेटा भंडारण के लिए आरक्षित इस स्थान के 100 या 108 बाइट्स के साथ Mbufs, या मेमोरी बफ़र्स, 128 बाइट्स लंबे होते हैं।

अन्य OSs (यूनिक्स डोमेन सॉकेट):

• OpenBSD : 104 वर्ण
• FreeBSD : 104 वर्ण
• मैक ओएस एक्स 10.9 : 104 वर्ण

Comments

इस मुद्दे पर सर्वसम्मति नहीं होने के कारण SUSv3 XNET चुप था।

— fpmurphy

क्या आपके पास अपनी बात को प्रमाणित करने के लिए कोई लिंक है?

इस उत्तर के लिए धन्यवाद। क्या विभिन्न कार्य निर्देशिकाओं के सापेक्ष समान नाम वाली कई सॉकेट फ़ाइलों का उपयोग करना विश्वसनीय है (उदाहरण के लिए, ./my.socketनिर्देशिका के नीचे एक सॉकेट फ़ाइल बनाएँ A/, और दूसरी सॉकेट फ़ाइल को भी ./my.socketनिर्देशिका नाम दिया गया है B/)? lsofदो सॉकेट फ़ाइलों के बीच कोई अंतर नहीं करता है, हालांकि यह अभी भी काम करने लगता है लेकिन मुझे आश्चर्य है कि अगर यह सिर्फ इसलिए कि मैं भाग्यशाली हूं। यह एक पथ के नीचे सॉकेट फ़ाइलों को बनाने के लिए एक अच्छा समाधान होगा जो पहले से ही अनुमत आकार से अधिक लंबा है।

— व्हाइटवूडवुल्फ

मेरे lsof -U| grep amavisamavis-se 2708 zimbra 17u unix 0xffff8806c0a95400 0t0 310330411 /opt/zimbra/data/tmp/amavisd-zmq.sock

हाँ, मुझे पता है कि यह असामान्य है, इसलिए मेरा सवाल यहाँ;) मैंने जो परीक्षण किया, उसके लिए सापेक्ष नाम काम करते हैं, लेकिन यह अभी भी मुझे अजीब लगता है ... लेकिन यह काम करता है। मेरा एप्लिकेशन सिस्टम-वाइड नहीं है, इसलिए सॉकेट फ़ाइलें या तो उपयोगकर्ता-नियंत्रित स्थान में अन्य सभी एप्लिकेशन डेटा के साथ संग्रहीत की जाती हैं, जो दृढ़ता से पसंद की जाती है, लेकिन संभावित रूप से बहुत लंबा रास्ता है, या मैं /tmpविशिष्ट रूप से नामित निर्देशिकाओं के टन के साथ अव्यवस्था कर सकता हूं एक एकल सॉकेट फ़ाइल (पूरी तरह से बदसूरत, लेकिन पोर्टेबल और सुरक्षित) युक्त।

— व्हाइटवूडवुल्फ

Answer 2

क्यों के बारे में, nwildner ने पहले से ही एक उत्कृष्ट उत्तर लिखा था ।

यहाँ मैं केवल कैसे और सापेक्ष पथ उपयोग पर ध्यान केंद्रित करूंगा।

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

इसे आसानी से फॉलो किया जा सकता है:

• दो निर्देशिका A / B और बनाएँ ।
• प्रत्येक निर्देशिका के तहत, एक प्रक्रिया को एक ही नाम वाले सॉकेट फाइलों पर सुनें। साथ socatआप इस तरह के रूप में एक कमांड का प्रयोग करेंगे:

$ socat UNIX-LISTEN:./my.sock -

• अब A / my.sock को B / और इसके विपरीत ले जाकर सॉकेट फ़ाइलों का आदान-प्रदान करें ।
• अब से, यदि क्लाइंट एप्लिकेशन A / my.sock से कनेक्ट होता है, तो वह सर्वर B से संपर्क करेगा , और यदि वह B / my.sock से कनेक्ट होता है, तो वह सर्वर A से संपर्क करेगा (ध्यान दें कि संचार समाप्त होने पर, सर्वर प्रक्रिया हो सकती है वैध रूप से वह हटाएं जो वह अपनी सॉकेट फ़ाइल समझता है)।

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

निरपेक्ष रास्तों का उपयोग आमतौर पर क्लाइंट और सर्वर प्रक्रियाओं के बीच एक सम्मेलन के रूप में किया जाता है, क्योंकि क्लाइंट प्रक्रिया अन्यथा सर्वर के साथ प्रारंभिक संचार स्थापित करने का तरीका नहीं जान सकती है।

हालाँकि, यदि यह प्रारंभिक संचार कोई समस्या नहीं है, तो इसलिए सॉकेट फ़ाइलों के निर्माण के लिए सापेक्ष पथों का उपयोग करना सुरक्षित लगता है, जब सॉकेट फ़ाइल स्थान सीधे सर्वर प्रक्रिया द्वारा नियंत्रित नहीं होता है, तो पथ लंबाई के मुद्दों से बचने की अनुमति देता है।