সকেটের পাথের দৈর্ঘ্য কেন একশ অক্ষরে সীমাবদ্ধ?

Question

ইউনিক্স সিস্টেমে পাথের নামগুলির সাধারণত কোনও দৈর্ঘ্যের সীমাবদ্ধতা থাকে না (ভাল, লিনাক্সে 4096 অক্ষর) ... সকেট ফাইলের পাথ ব্যতীত যা প্রায় 100 টি অক্ষর ( লিনাক্সে 107 অক্ষর ) এর মধ্যে সীমাবদ্ধ ।

• প্রথম প্রশ্ন: এত কম সীমাবদ্ধতা কেন?

আমি পরীক্ষা করে দেখেছি যে বর্তমানের ডিরেক্টরিটি পরিবর্তন করে এবং বিভিন্ন ডিরেক্টরিতে একই পাথ ব্যবহার করে বিভিন্ন সকেট ফাইল তৈরি করে এই সীমাবদ্ধতার আশপাশে কাজ করা সম্ভব বলে মনে হচ্ছে ./myfile.sock: ক্লায়েন্ট অ্যাপ্লিকেশনগুলি প্রত্যাশিত সার্ভার প্রক্রিয়াগুলির সাথে সঠিকভাবে সংযুক্ত বলে মনে হচ্ছে যদিও lsofসমস্ত দেখায় তাদের মধ্যে একই সকেট ফাইলের পথে শুনছি।

• এই কর্মক্ষেত্র নির্ভরযোগ্য বা আমি কি ভাগ্যবান?
• এই আচরণটি কি লিনাক্সের সাথে নির্দিষ্ট বা অন্য ইউনিক্সের ক্ষেত্রেও এই প্রয়োগটি প্রযোজ্য?

Comments

সীমা বর্তমান ওপেনবিএসডি সিস্টেম বা ম্যাক ওএস এক্স 10.11-এ আরও কম (104)।

— ই

গুরুত্বপূর্ণ বিষয়, এটি সামঞ্জস্যের জন্য 108 এর চেয়ে কম হতে হবে :)

আফাইক এটি লিনাক্সের 108 টি অক্ষর। আপনার মেশিনে /usr/incolve/ludearch-linux-gnu/sys/un.h পরীক্ষা করুন।

— স্কাইবা

@ শাইইবা: ১০৮ বাইট, যার অর্থ 107 টি অক্ষরের স্ট্রিং নাল টার্মিনেটর দ্বারা শেষ হয়।

— হোয়াইটউইন্টারওয়াল্ফ

Answer 1

অন্য প্ল্যাটফর্মে, বা পুরোনো কাপড় সাথে সামঞ্জস্যের সঙ্গে সামঞ্জস্যের ব্যবহার করার সময় overruns এড়াতে snprintf()এবং strncpy()।

মাইকেল Kerrisk ব্যাখ্যা তার বই এ পৃষ্ঠা 1165 - অধ্যায় 57, সকেটস: ইউনিক্স ডোমেন:

SUSv3 সূর্য_পাঠ ক্ষেত্রের আকার নির্দিষ্ট করে না। প্রাথমিক বিএসডি বাস্তবায়নগুলি 108 এবং 104 বাইট ব্যবহার করেছিল এবং একটি সমসাময়িক বাস্তবায়ন (এইচপি-ইউএক্স 11) 92 বাইট ব্যবহার করে। পোর্টেবল অ্যাপ্লিকেশনগুলির এই নিম্ন মানের কোড করা উচিত এবং এই ক্ষেত্রে লেখার সময় বাফারকে ছাড়িয়ে যাওয়ার জন্য স্নপ্রিন্টফ () বা স্ট্রান্সপি () ব্যবহার করা উচিত।

ডকার ছেলেরা এমনকি এটি নিয়ে মজাও করেছিল, কারণ কিছু সকেট ১১০ টি অক্ষর দীর্ঘ ছিল:

• LOL 108 অক্ষর স্বয়ংক্রিয়ভাবে

এই কারণেই লিনাক্স একটি 108 চর সকেট ব্যবহার করে। এটি কি পরিবর্তন করা যায়? অবশ্যই. পুরানো অপারেটিং সিস্টেমগুলিতে এই সীমাবদ্ধতাটি প্রথম স্থানে তৈরি করার কারণ হ'ল:

• লিনাক্স 108 এ ইউনিক্স-সকেটের সর্বাধিক পাথের দৈর্ঘ্য কেন অনুমোদিত?

উত্তরটি উদ্ধৃত করে:

এটি একটি সহজ কার্নেল ডেটা স্ট্রাকচারে উপলব্ধ স্থানটির সাথে মিল ছিল to

ম্যাককুসিক এট দ্বারা "4.4BSD অপারেটিং সিস্টেমের নকশা ও বাস্তবায়ন" উদ্ধৃত করা হয়েছে। অল। (পৃষ্ঠা 369):

মেমরি পরিচালনার সুবিধাগুলি একটি এমবুফ নামে পরিচিত একটি ডেটা স্ট্রাকচারের চারপাশে ঘোরে। এমবুফস বা মেমরি বাফারগুলি 128 বাইট দীর্ঘ, এই স্থানের 100 বা 108 বাইট ডেটা স্টোরেজের জন্য সংরক্ষিত রয়েছে।

অন্যান্য ওএস (ইউনিক্স ডোমেন সকেট):

• ওপেনবিএসডি : 104 টি অক্ষর
• ফ্রিবিএসডি : 104 টি অক্ষর
• ম্যাক ওএস এক্স 10.9 : 104 টি অক্ষর

Comments

SUSv3 XNET নীরব ছিল কারণ ইস্যুতে sensক্যমত্য নেই।

— এফএমপুরফি

আপনার দৃষ্টিভঙ্গি প্রমাণ করার জন্য আপনার কি কোনও লিঙ্ক আছে?

এই উত্তরের জন্য ধন্যবাদ। এটা ভিন্ন পরিশ্রমী ডিরেক্টরি (উদাহরণস্বরূপ, নামে একজন সকেট ফাইল তৈরি করতে আপেক্ষিক অভিন্ন নাম জন্মদান বিভিন্ন সকেট ফাইল ব্যবহার নির্ভরযোগ্য হয় ./my.socketডিরেক্টরির নীচের A/, এবং অন্য সকেট ফাইল এছাড়াও নামে ./my.socketডিরেক্টরির নিচের B/)? lsofদুটি সকেট ফাইলের মধ্যে কোনও পার্থক্য তৈরি করে না, তবে এটি এখনও কাজ করে বলে মনে হচ্ছে তবে আমি ভাগ্যবান যে আমি ভাগ্যবান বলেই এটি হয় কিনা I অনুমোদনের আকারের চেয়ে লম্বা একটি পাথের নীচে সকেট ফাইলগুলি তৈরি করা ভাল কাজ হবে।

— হোয়াইটউইন্টারওয়াল্ফ

আমার মেইল ​​সার্ভারে ইউনিক্স সকেটগুলি অনুসন্ধান করা পুরো পথের নামটি নিয়ে আসে বলে মনে হচ্ছে lsof -U| grep amavis(নিউলাইন)amavis-se 2708 zimbra 17u unix 0xffff8806c0a95400 0t0 310330411 /opt/zimbra/data/tmp/amavisd-zmq.sock

হ্যাঁ, আমি জানি এটি অস্বাভাবিক, সুতরাং এখানে আমার প্রশ্ন;)! আমি যা যা পরীক্ষা করেছি তার জন্য আপেক্ষিক নামগুলি কাজ করে তবে এটি এখনও আমার কাছে অদ্ভুত বলে মনে হয় ... তবে এটি কার্যকর হয়। আমার অ্যাপ্লিকেশন সিস্টেম-ব্যাপী নয়, সুতরাং সকেট ফাইলগুলি হয় ব্যবহারকারী-নিয়ন্ত্রিত স্থানে অন্য সমস্ত অ্যাপ্লিকেশন ডেটার সাথে সঞ্চিত থাকে, যা দৃ strongly়ভাবে পছন্দ করা হয় তবে সম্ভাব্য দীর্ঘ দীর্ঘ পথের সাথে, অথবা আমি /tmpপ্রতিটি অনন্যর নামযুক্ত মুছে ফেলা ডিরেক্টরিগুলির সাথে বিশৃঙ্খলা করতে পারি each একটি একক সকেট ফাইল (সম্পূর্ণ কুৎসিত, তবে পোর্টেবল এবং সুরক্ষিত) রয়েছে।

— হোয়াইটওয়ানটারওয়াল্ফ 24:37

Answer 2

এর কারণ সম্পর্কে, উত্তরওয়ানদার ইতিমধ্যে একটি দুর্দান্ত উত্তর লিখেছিলেন ।

এখানে আমি কীভাবে এবং আপেক্ষিক পাথের ব্যবহারের দিকে মনোনিবেশ করব।

অভ্যন্তরীণভাবে, সকেট ফাইলটি নাম দ্বারাও দেখা যায় (আমার ধারনা), সাধারণত ইনোড দ্বারা সন্ধান করা হয়। লিনাক্সে, এই চেহারাটি নেট / ইউনিক্স / আফ_উনিক্স.সি . এ unix_find_socket_byinode()সংজ্ঞায়িত ফাংশন দ্বারা নিশ্চিত করা হয়েছে ।

এটি সহজে অনুসরণ অনুসরণ করা যেতে পারে:

• এ / এবং বি / দুটি ডিরেক্টরি তৈরি করুন ।
• প্রতিটি ডিরেক্টরিের অধীনে, একই নাম সহ সকেট ফাইলগুলিতে একটি প্রক্রিয়া শোনান। আপনার সাথে socatএকটি কমান্ড ব্যবহার করা হবে যেমন:

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

• এখন সরিয়ে সকেট ফাইল বিনিময় এ / my.sock করার বি / এবং ভাইস বিপরীতভাবে।
• এখন থেকে, ক্লায়েন্ট অ্যাপ্লিকেশন যদি এ / মাই.সক এর সাথে সংযুক্ত হয় তবে এটি সার্ভার বি'র সাথে যোগাযোগ করবে , এবং এটি বি / মাই.সক এর সাথে সংযুক্ত হলে এটি সার্ভার এ-এর সাথে যোগাযোগ করবে (নোট করুন যে যোগাযোগটি শেষ হয়ে গেলেও সার্ভার প্রক্রিয়াটি হতে পারে) এটি নিজের সকেট ফাইল হিসাবে যা মনে করে বৈধভাবে মুছুন।

আমি এই আচরণটি মুষ্টিমেয় ইউনিক্স সিস্টেমে পরীক্ষা করেছি (লিনাক্স দেবিয়ান, ফ্রিবিএসডি এবং ওপেন ইন্ডিয়ানা কিছুটা বৈচিত্র্য পেতে), তাই এই আচরণটি স্ট্যান্ডার্ড না হলেও কমপক্ষে বিস্তৃত বলে মনে হয়।

নিখুঁত পাথগুলি সাধারণত ক্লায়েন্ট এবং সার্ভার প্রক্রিয়াগুলির মধ্যে একটি কনভেনশন হিসাবে ব্যবহৃত হয়, কারণ ক্লায়েন্ট প্রক্রিয়া অন্যথায় সার্ভারের সাথে প্রাথমিক যোগাযোগ কীভাবে প্রতিষ্ঠিত করতে হয় তা না জানতে পারে।

তবে, যদি এই প্রাথমিক যোগাযোগটি কোনও সমস্যা না হয় তবে সকেট ফাইল তৈরির জন্য আপেক্ষিক পাথগুলি ব্যবহার করা নিরাপদ বলে মনে হয়, যখন সকেট ফাইলের অবস্থানটি সার্ভার প্রক্রিয়া দ্বারা সরাসরি নিয়ন্ত্রণ না করা হয় তখন পাথ দৈর্ঘ্যের সমস্যাগুলি এড়াতে দেয়।