เหตุใดความยาวเส้นทางซ็อกเก็ตจึง จำกัด เพียงหนึ่งร้อยตัวอักษร

บนชื่อพา ธ ของระบบ Unix มักจะไม่จำกัดความยาว (เช่น 4096 ตัวอักษรบน Linux) ... ยกเว้นเส้นทางของไฟล์ซ็อกเก็ตซึ่ง จำกัด อยู่ที่ประมาณ 100 ตัวอักษร (107 ตัวอักษรบนLinux )

• คำถามแรก: ทำไมถึงมีข้อ จำกัด ต่ำ

ผมได้ตรวจสอบว่ามันดูเหมือนเป็นไปได้ที่จะหลีกเลี่ยงข้อ จำกัด นี้โดยการเปลี่ยนไดเรกทอรีการทำงานปัจจุบันและการสร้างในไดเรกทอรีต่างๆหลายซ็อกเก็ตไฟล์ทั้งหมดที่ใช้เส้นทางเดียวกัน./myfile.sock: ใช้งานของลูกค้าดูเหมือนจะถูกต้องเชื่อมต่อกับเซิร์ฟเวอร์กระบวนการคาดว่าแม้แม้ว่าlsofการแสดงทั้งหมด ของพวกเขาฟังบนเส้นทางไฟล์ซ็อกเก็ตเดียวกัน

• วิธีนี้เป็นวิธีที่เชื่อถือได้หรือฉันแค่โชคดี?
• พฤติกรรมนี้มีเฉพาะกับ Linux หรืออาจใช้วิธีแก้ปัญหานี้กับ Unixes อื่นเช่นกัน?

ความเข้ากันได้กับแพลตฟอร์มอื่น ๆ หรือความเข้ากันได้กับสิ่งเก่าเพื่อหลีกเลี่ยงการรุกในขณะที่ใช้และsnprintf()strncpy()

Michael Kerrisk อธิบายในหนังสือของเขาที่หน้า 1165 - บทที่ 57, ซ็อกเก็ต: โดเมน Unix:

SUSv3 ไม่ได้ระบุขนาดของฟิลด์ sun_path การใช้ BSD ก่อนหน้านี้ใช้ 108 และ 104 ไบต์และหนึ่งการติดตั้งในปัจจุบัน (HP-UX 11) ใช้ 92 ไบต์ แอปพลิเคชั่นแบบพกพาควรเขียนโค้ดให้มีค่าต่ำกว่านี้และใช้ snprintf () หรือ strncpy () เพื่อหลีกเลี่ยงบัฟเฟอร์โอเวอร์รันเมื่อเขียนลงในฟิลด์นี้

พวกนักเทียบท่ายังสนุกกับมันเพราะซ็อกเก็ตบางอันมีความยาว 110 ตัวอักษร:

• ฮ่า ๆ 108 ตัวอักษร ETOOMANY

นี่คือเหตุผลที่ LINUX ใช้ซ็อกเก็ต 108 ถ่าน สิ่งนี้สามารถเปลี่ยนแปลงได้? แน่นอน. และนี่คือเหตุผลว่าทำไมข้อ จำกัด นี้จึงถูกสร้างขึ้นในระบบปฏิบัติการรุ่นเก่า:

• ทำไมความยาวพา ธ สูงสุดที่อนุญาตให้ใช้กับ unix-sockets บน linux 108

อ้างคำตอบ:

มันคือการจับคู่พื้นที่ว่างที่มีอยู่ในโครงสร้างข้อมูลเคอร์เนลที่มีประโยชน์

ข้อความ "การออกแบบและการใช้งานระบบปฏิบัติการ 4.4BSD" โดย McKusick และ อัล (หน้า 369):

เครื่องมือจัดการหน่วยความจำจะหมุนรอบโครงสร้างข้อมูลที่เรียกว่า mbuf Mbufs หรือบัฟเฟอร์หน่วยความจำมีความยาว 128 ไบต์โดย 100 หรือ 108 ไบต์ของพื้นที่นี้สงวนไว้สำหรับการจัดเก็บข้อมูล

ระบบปฏิบัติการอื่น ๆ (ซ็อกเก็ตโดเมน unix):

• OpenBSD : 104 ตัวอักษร
• FreeBSD : 104 ตัวอักษร
• Mac OS X 10.9 : 104 ตัวอักษร

เกี่ยวกับสาเหตุที่ nwildner เขียนคำตอบที่ยอดเยี่ยมแล้ว

ที่นี่ฉันจะมุ่งเน้นไปที่วิธีและการใช้เส้นทางสัมพัทธ์

ภายในขณะที่ไฟล์ซ็อกเก็ตยังสามารถค้นหาตามชื่อ (ฉันเดา) พวกเขามักจะค้นหาโดยไอโหนด ในลินุกซ์, การค้นหานี้คือมั่นใจโดยฟังก์ชั่นunix_find_socket_byinode()ที่กำหนดไว้ในสุทธิ / Unix / af_unix.c

สามารถตรวจสอบได้ง่ายดังนี้

• สร้างสองไดเรกทอรีA /และB /
• ภายใต้แต่ละไดเรกทอรีให้กระบวนการฟังไฟล์ซ็อกเก็ตที่มีชื่อเดียวกัน ด้วยsocatคุณจะใช้คำสั่งเช่น:

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

• ตอนนี้แลกเปลี่ยนไฟล์ซ็อกเก็ตโดยการย้ายA / my.sockเป็นB /และในทางกลับกัน
• จากนี้ไปหากแอปพลิเคชันไคลเอนต์เชื่อมต่อกับA / my.sockมันจะติดต่อกับเซิร์ฟเวอร์Bและถ้ามันเชื่อมต่อกับB / my.sockมันจะติดต่อกับเซิร์ฟเวอร์A (โปรดทราบว่าเมื่อการสื่อสารสิ้นสุดลงกระบวนการเซิร์ฟเวอร์อาจ ลบสิ่งที่คิดว่าเป็นไฟล์ซ็อกเก็ตของตัวเอง)

ฉันตรวจสอบพฤติกรรมนี้ในระบบ Unix จำนวนหนึ่ง (Linux Debian, FreeBSD และ OpenIndiana เพื่อให้ได้ความหลากหลาย) ดังนั้นพฤติกรรมนี้ดูเหมือนจะแพร่กระจายอย่างน้อยถ้าไม่ใช่มาตรฐาน

เส้นทางแบบสัมบูรณ์มักใช้เป็นแบบแผนระหว่างไคลเอ็นต์และกระบวนการเซิร์ฟเวอร์เนื่องจากกระบวนการไคลเอ็นต์อาจไม่ทราบวิธีสร้างการสื่อสารเริ่มต้นกับเซิร์ฟเวอร์

อย่างไรก็ตามหากการสื่อสารเริ่มต้นนี้ไม่เป็นปัญหาดูเหมือนว่าปลอดภัยที่จะใช้พา ธ สัมพัทธ์สำหรับการสร้างไฟล์ซ็อกเก็ตช่วยให้หลีกเลี่ยงปัญหาความยาวพา ธ เมื่อตำแหน่งไฟล์ซ็อกเก็ตไม่ได้ถูกควบคุมโดยตรงโดยกระบวนการเซิร์ฟเวอร์