আমি বুঝতে পেরেছি যে "সবকিছুই একটি ফাইল" ইউনিক্সের অন্যতম প্রধান ধারণা, তবে সকেটগুলি বিভিন্ন এপিআই ব্যবহার করে যা কার্নেল দ্বারা সরবরাহ করা হয় (যেমন সকেট, সেন্ডো, আরসিভি, ইত্যাদি), সাধারণ ফাইল সিস্টেম ইন্টারফেসের মতো নয়।
এই "সবকিছুই একটি ফাইল" কীভাবে এখানে প্রয়োগ হয়?
উত্তর:
সকেট বিভিন্ন এপিআই ব্যবহার করে
এটি সম্পূর্ণ সত্য নয়। সকেটগুলির সাথে ব্যবহারের জন্য কিছু অতিরিক্ত ফাংশন রয়েছে তবে আপনি সাধারণ read()এবং write()সকেট এফডি ব্যবহার করতে পারেন ।
এই "সবকিছুই একটি ফাইল" কীভাবে এখানে প্রয়োগ হয়?
এই অর্থে যে কোনও ফাইল বর্ণনাকারী জড়িত।
যদি আপনার "ফাইল" এর সংজ্ঞাটি একটি ফাইল সিস্টেমে সঞ্চিত বাইটগুলির একটি পৃথক ক্রম হয়, তবে সমস্ত কিছুই একটি ফাইল নয়। তবে, যদি আপনার ফাইলটির সংজ্ঞাটি আরও বেশি হ্যান্ডেল হয় যেমন - তথ্যের জন্য একটি জলবাহী, যেমন একটি I / O সংযোগ - তবে "সবকিছুই একটি ফাইল" আরও বোধগম্য হতে শুরু করে। এই জিনিসগুলি অনিবার্যভাবে বাইটের ক্রম জড়িত, কিন্তু তারা কোথা থেকে আসে বা যায় সেগুলি প্রসঙ্গে পৃথক হতে পারে।
এটি আসলে আক্ষরিক অর্থে নয়, তবে। একটি ডেমন একটি ফাইল, একটি ডেমন একটি প্রসেস নয়; আপনি যদি আইপিসি করছেন তবে অন্য কোনও প্রক্রিয়া সম্পর্কিত আপনার পদ্ধতিটি ফাইল স্টাইল সত্তা দ্বারা ভালভাবে প্রশমিত হতে পারে।
"সবকিছুই একটি ফাইল" কেবলমাত্র ওভারস্টেটমেন্ট। এটা তোলে ছিল 1970 সালে উপন্যাস এবং এটি ছিল ইউনিক্স এর একটি প্রাথমিক পার্থক্য চরিত্রগত। তবে এটি কেবল একটি বিপণন ধারণা, ইউনিক্সের আসল ভিত্তি নয়, কারণ এটি অবশ্যই সত্য নয়। সমস্ত কিছু ফাইল হিসাবে বিবেচনা করা উপকারী বা বুদ্ধিমান নয়।
সিপিইউ কি একটি ফাইল? আপনার প্রোগ্রামটি কোনও নতুন নির্দেশ পাওয়ার জন্য () একটি সিপিইউ পড়ে? র্যাম কি ফাইল? আপনার প্রোগ্রামটি পরের বাইট () পড়বে?
তারপরে, এমন ধরণের ওএস ছিল যা আপনাকে ফ্লপি ডিস্কের জন্য একটি এপিআই এবং একটি হার্ড ডিস্কের জন্য একটি পৃথক এপিআই, চৌম্বকীয় টেপের জন্য একটি পৃথক এপিআই এবং বিভিন্ন টার্মিনালগুলির জন্য বিভিন্ন এপিআইয়ের একগুচ্ছ দেয়। আইবিএম মেইনফ্রেম সিস্টেমে হার্ড ডিস্কে বিভিন্ন ধরণের ফাইল ছিল এবং তাদের প্রত্যেককে একটি আলাদা এপিআই দিয়েছিল, বিশ্বাস করুন বা না করুন! সুতরাং ইউনিক্স "এটি একটি ফাইল" পদ্ধতির সাথে "স্টিডিন / স্টাডিআউট / স্ট্ডার" পদ্ধতির সাথে ব্যবহারকারী এবং প্রোগ্রামার উভয়ের জন্য খুব মার্জিত বিমূর্ততা এনেছে।
নেটওয়ার্কের সাথে, এই নির্দিষ্ট বিমূর্ততাটি কার্যকর হয়নি। এবং কোনও ক্ষতি নেই, কেবল সামান্য কম সামগ্রিক কমনীয়তা এবং ওএসের সমন্বয়। কিন্তু এটি কাজ করে. আপনি কি /dev/myinternetz/www/google/com/tcp/80আজ আপনার সিস্টেমে কোথাও ফোন করা ফাইল দেখতে পাচ্ছেন ? আপনি কি এটি খুলতে (), একটি কোয়েরি () লিখতে এবং () উত্তরটি সুন্দর HTML এ পড়তে পারেন? কোন? এটি কারণ এটি "একটি ফাইল" অ্যাবস্ট্রাকশন নেটওয়ার্কের চারপাশে কথোপকথনের জন্য খুব সহজ ছিল না। এটি অনুশীলনে খুব বেশি কাজ করবে না। কার্যক্রমে ফাঁসযুক্ত বিমূর্তনের আইন ।
/dev/tcp/www.google.com/80। এটি যদিও আসল ফাইল নয় - বাশ কেবল এটি নকল করছে।
/dev/memবা /dev/kmemআপনি চাইলে।
সকেট ফাইল হয়। আপনি readএবং writeসকেটে ব্যবহার করতে পারেন : এগুলি কল recvএবং এর sendসাথে সমান flags=0। আপনি তাদের সাথে বন্ধ করুন close। আপনার dupযদি ফাইল বর্ণনাকারীদের বদলানো দরকার হয় তবে আপনি তাদের সাথে এবং বন্ধুদের সাথে এদিক ওদিক ঘুরাতে পারেন। আপনি কিছু পতাকা সেট করতে পারেন fcntlএবং কল করার পরে স্টডিও বাফারিং ব্যবহার করতে পারেন fdopen। তালিকাটি এগিয়ে যায়। খুব গুরুত্বপূর্ণভাবে, আপনি কল করতে পারেন selectএবং pollসকেট সহ যে কোনও ধরণের ফাইলের উপর, তাই এই ফাংশনগুলি কোনও প্রোগ্রামকে কেবল ফাইল বর্ণনাকারীদের তালিকাভুক্ত করে কোনও উপায়ের মাধ্যমে ইনপুট না পাওয়া পর্যন্ত ব্লক করার অনুমতি দেয়।
কিছু সকেট প্রকার (জন্য অতিরিক্ত সিস্টেম কল হয় recvএবং send, shutdownইত্যাদি), সেখানে ডিভাইসের জন্য একটি অতিরিক্ত সিস্টেম কল (মত ioctl)।
সমস্ত ফাইলের নাম থাকে না এবং যাগুলি করে সেগুলি সবসময় ডিরেক্টরি কাঠামোয় থাকে না। pipe(যেমন শেল পাইপলাইনে তৈরি) পাইপগুলির দ্বারা তৈরি এবং সকেটগুলির দ্বারা তৈরির socketpairনাম নেই তবে তারা এখনও ফাইল। তৈরি করা সকেটের socketএকটি নাম রয়েছে যার বাক্য গঠন ডোমেনের উপর নির্ভর করে। এই নামটি একটি পাস করা হয়েছে struct sockaddrথেকে bindএবং অন্যান্য ফাংশন। ইউনিক্স ( AF_UNIX) সকেটের জন্য, নামটি একটি struct sockaddr_un, যা একটি পরিবার এবং একটি স্ট্রিং; স্ট্রিংয়ের উপর নির্ভর করে, এটি কোনও ফাইলের নাম (নামযুক্ত সকেটগুলি mknodঅনেকগুলি ইউনিক্স বৈকল্পের সাথে তৈরি করা যেতে পারে ) হতে পারে না (বিমূর্ত নামের স্থান)। একটি আইপিভি 4 ( AF_INET) সকেটের জন্য, নামটি হ'ল একটি struct sockaddr_in, একটি পোর্ট নম্বর এবং আইপি ঠিকানা যুক্ত protocolকরে socketকল থেকে প্রাপ্ত ।
আপনি যদি statসকেট হন তবে আপনি দেখতে পাবেন যে এটিতে একটি ইনোড নম্বর এবং নিয়মিত ফাইলগুলির অন্যান্য বৈশিষ্ট্য রয়েছে, তাই আমি এটি ফাইল সিস্টেমে ফাইল হিসাবে শ্রেণিবদ্ধ করব। উদাহরণ:
# file live
live: socket
# stat live
File: `live'
Size: 0 Blocks: 0 IO Block: 4096 socket
Device: fc03h/64515d Inode: 198817 Links: 1
Access: (0660/srw-rw----) Uid: (23129/ icinga) Gid: (23130/icinga-cmd)
Access: 2014-11-07 09:27:59.000000000 -0800
Modify: 2014-11-05 09:27:03.000000000 -0800
Change: 2014-11-05 09:27:03.000000000 -0800
11/17। লিনাক্সের জন্য অতিরিক্ত তথ্য (ext3): একটি সকেটের একটি ইনোড থাকে (যা ডিস্কের 256-বাইট ব্লক) তবে কোনও ডেটা ব্লক নেই (আপনি ইনোডটি বের করে এবং ডেটা ব্লক পয়েন্টারগুলি পরীক্ষা করে এটি যাচাই করতে পারেন; বা দ্বারা চলমান ডিবাগ্স 'স্ট্যাট' যা 0 এর একটি ব্লককઉન્ટ দেখায়)। সুতরাং, এতে ফাইলের মেটাডেটা রয়েছে (মালিক, গোষ্ঠী, অনুমতি ইত্যাদি) তবে ডিস্কে কোনও ডেটা সামগ্রী নেই। এটি একটি নিয়মিত খালি ফাইলের সমান ( touch /tmp/foo) যা 0 এর একটি ব্লককাউন্টও করে the প্রথম ক্ষেত্রে, ইনোডের "টাইপ" ক্ষেত্রটি "সকেট" দেখায়; দ্বিতীয় ক্ষেত্রে এটি "নিয়মিত ফাইল" দেখায়।
তথ্যসূত্র: ext2 ইনোড কাঠামো ; stat, dumpe2fsএবং debugfsআদেশগুলি।
fileবা statএটি একটি ফাইল করে।