سیستم اشتراک زمانی شبکه‌ی لیورمور
 | این مقاله، سیستم اشتراک زمانی شبکه‌ی لیورمور، اخیراً بهواسطهٔ فرایند ایجاد مقاله ایجاد شده‌است. بازبینیکننده در حال بستن درخواست است و این برچسب احتمالاً بهزودی برداشته می‌شود.
ابزارهای بازبینی: پیشبارگیری بحث اعلان به نگارنده |
خطای اسکریپتی: پودمان «AfC submission catcheck» وجود ندارد.سیستم اشتراک زمانی شبکهٔ لیورمور NLTSS، که به عنوان سیستم اشتراک زمانی جدید لیورمور نیز شناخته می‌شود، سیستم عاملی است که از سال ۱۹۷۹ تا حدود سال ۱۹۸۸، در آزمایشگاه لارنس لیورمور (اکنون: آزمایشگاه ملی لارنس لیورمور) به‌طور فعال وجود داشت؛ اگرچه تا سال ۱۹۹۵ به اجرای برنامه‌های کاربردی ادامه داد.
NLTSS در ابتدا بر روی یک کامپیوتر CDC 7600 اجرا شد؛ اما از سال ۱۹۸۵ تا ۱۹۹۴ برای کامپیوترهای Cray، از جمله مدل‌های Cray-1 ،Cray X-MP و Cray Y-MP تولید شد.
مشخصات[ویرایش]
سیستم عامل NLTSS، در بسیاری از موارد غیرعادی و حتی منحصر به فرد عمل می‌کند.
معماری سطح پایین[ویرایش]
NLTSS، به عنوان یک سیستم ارسال پیام ریزهسته شناخته می‌شد و از آن به عنوان سیستم منحصر به فرد نیز یاد می‌کردند؛ زیرا تنها یک فراخوانی سیستم توسط هستهٔ سیستم پشتیبانی می‌شد. این فراخوانی که یک لیست از جدول‌های بافر را می‌پذیرفت (مثلاً به رابط سیستم پیام NLTSS مراجعه کنید)[۱] «ارتباط» می‌نامند (در حقیقت نامی ندارد؛ زیرا نیازی به تمایز با سایر تماس‌های سیستمی وجود نداشت). چنین ارتباطی، چه به صورت محلی در داخل سیستم و چه در سراسر یک شبکه، تمام هستهٔ سیستم است که مستقیماً برای فرآیندهای کاربران پشتیبانی می‌شدند. «سیستم پیام» (با پشتیبانی از یک تماس و پروتکل‌های شبکه) و درایورها برای دیسک‌ها و پردازنده، تمام هستهٔ یک سیستم را تشکیل می‌دادند.
معماری سطح متوسط[ویرایش]
NLTSS یک سیستم مشتری-سرور مبتنی بر قابلیت است. دو سرور اصلی در آن، سرور فایل و سرور پردازش هستند. سرور فایل فرآیندی است که توسط درایورها برای ذخیره‌سازی محلی قابل اعتماد (ذخیره‌سازی دیسک) وسرور پردازش امتیازی است که توسط درایور پردازنده قابل اعتماد است (نرم‌افزاری که کنترل اشتراک گذاری زمانی را بین فرآیندهای موجود در آلترنیتور تغییر می‌دهد؛ وقفه‌های فرایند را علاوه بر تماس ارتباط مدیریت می‌کند و علاوه بر آن دسترسی به حافظه و وضعیت پردازش را برای سرور پردازش فراهم می‌کند).
NLTSS، یک سیستم عامل شبکه واقعی بود؛ زیرا درخواست‌های منابع آن می‌توانستند از پردازش‌های محلی یا پردازش‌های راه دور از هر کجای شبکه باشند و سرورها آن‌ها را متمایز نمی‌کردند. تنها نیاز شبکه برای ایجاد چنین تمایزهایی، از طریق آدرس شبکه خواهد بود و آن‌ها هیچ دلیلی برای ایجاد چنین تمایزهایی نداشتند. همهٔ درخواست‌ها به سرورها به عنوان درخواست‌های شبکه ظاهر شدند.
ارتباط بین پردازش‌ها در NLTSS، به صورت قراردادی از مجموعهٔ پروتکل‌های سیستم ارتباطی شبکهٔ تعاملی لیورمور(LINCS) استفاده می‌کند، که یک پشته پروتکل را در امتداد خطوط تعریف‌شده توسط مدل مرجع OSI تعریف می‌کند. پروتکل سطح انتقال برای NLTSS و Delta-T ،LINCS نام داشت. در سطح ارائه، LINCS استانداردهایی را برای برقراری ارتباط با پارامترهای شماره‌گذاری‌شده به عنوان نشانه‌ها (مانند اعداد صحیح، قابلیت‌ها و غیره) تعریف کرد که در یک رکورد، سطح جلسه برای پردازش در یک مکانیسمفراخوانی روش راه دور ذخیره می‌شدند.
مفهوم کاربر در NLTSS تنها به صورت پیرامونی تعریف شده‌است. یک «سرور حساب» وجود داشت که ردیابی و کنترل می‌کرد که کدام کاربران از چه منابعی استفاده می‌کردند. (مثلاً درخواست‌ها برای ایجاد اشیایی مانند فایل یا فرآیندهایی که به چنین قابلیت حسابی نیاز دارند). کنترل دسترسی به‌طور کامل با قابلیت‌ها (توکن‌های مرجع قابل ارتباط) مدیریت می‌شد.
سرور فایل[ویرایش]
هر فرآیندی می‌توانست برای ایجاد فایل‌ها (برگرداندن قابلیت فایل‌ها)، درخواست خواندن یا نوشتن فایل‌ها (با ارائه‌ی قابلیت فایل) و غیره، به سرور فایل درخواست بدهد. برای مثال، خواندن یک فایل، به‌طور کلی به سه جدول بافر نیاز داشت؛ یکی برای فرستادن درخواست به سرور فایل، یکی برای دریافت پاسخ درخواست از سرور و دیگری برای دریافت اطلاعات از فایل. این سه درخواست عموماً با هم و در یک زمان به سیستم پیام ارسال می‌شدند و گاهی اوقات نیز با درخواست‌های دیگر همراه می‌شدند. این امکان وجود داشت که بیت‌های کنترل را در جدول بافر تنظیم کرد تا هر زمان که هر یک از جداول بافر ارسال‌شده با نشانهٔ «Done» یک فرایند را راه‌اندازی کند. معمولاً فراخوانی یک کتابخانه برای خواندن یک فایل تا زمانی که پاسخ کنترل از سرور فایل دریافت نمی‌شد، مسدود می‌شد؛ اگرچه ورودی و خروجی ناهمگام مسدود نمی‌شدند و می‌توانستند بعداً بررسی شوند. چنین تفاوت‌هایی در سمت کاربر برای سرور فایل غیرقابل مشاهده بود.
سرور پردازش[ویرایش]
در NLTSS سرور پردازش (فرایند) کاملاً شبیه به سرور فایل بود. این شباهت از این نظر بود که کاربران می‌توانستند درخواست ایجاد فرایندها و پزدازش‌های دیگر، یا شروع و پایان پردازش‌ها، خواندن یا نوشتن حافظهٔ فرایند یا رجیسترها را داشته‌باشند و همچنین از خطاهای فرایند مطلع شوند. سرور پردازش، یک فضای کاربری معمولی بود که برای برقراری ارتباط با واحد پردازش مرکزی به سادگی قابل اعتماد بود؛ درست مانند سرور فایل برای برقراری ارتباط با درایور دیسک. سرور پردازش وضعیت پردازش را در فایل‌های ارائه‌شده توسط سرور فایل ذخیره می‌کرد و از این نظر مانند هر فرایند کاربر دیگری در سرور فایل ظاهر می‌شد.
سرور دایرکتوری[ویرایش]
یک مثال سطح بالاتر از سرور در NLTSS سرور دایرکتوری بود. وظیفهٔ سرور اساساً این بود که فایل‌هایی را که غیرقابل مشاهده برای کاربر بود به دایرکتوری‌هایی تبدیل کند که بتوان از آن‌ها برای ذخیره و بازیابی قابلیت‌ها به همراه نام استفاده کرد. از آن‌جا که قابلیت‌ها صرفاً برای داده‌ها بودند، این کار چندان دشواری نبود زیرا بیشتر شامل دستکاری در مجوزهای دسترسی به قابلیت‌ها بر اساس قراردادهای تعریف شده در مجموعه پروتکل LINCS بود. جایی که این موضوع کمی جالب‌تر می‌شود، مربوط به مجوز دسترسی به نام ارث است. اگر این بیت روشن یا مجاز بود، این امکان وجود دارد که قابلیت‌ها را با دسترسی کامل آن‌ها از دایرکتوری واکشی کرد. اگر این بیت خاموش یا غیرمجاز بود، هر مجوزی که در قابلیت دایرکتوری غیرفعال شده‌بود، به نوبهٔ خود در قابلیتی که واکشی شده‌بود، قبل از این که به برنامهٔ درخواست‌کننده بازگردانده شود، غیرفعال می‌شد. این مکانیسم به افراد اجازه می‌داد که مثلاً فایل‌ها را در یک فهرست بخوانند یا بنویسند اما به سایر کاربران فقط اجازهٔ واکشی نمونه‌های فقط خواندنی آن‌ها را می‌داد.
توسعه[ویرایش]
بخش عمده‌ای از برنامه‌نویسی برای NLTSS، در آزمایشگاه ملی لوس آلاموس با پاسکال به نام مدل انجام شد. «مدل»، پاسکال را گسترش داد تا مکانیزم نوع داده انتزاعی و برخی ویژگی‌های دیگر را دربرگیرد.
ٔNLTSS بسیار سازگار بود. NLTSS توسعه و استقرار LTSS(سیستم به اشتراک‌گذاری زمان لیورمور) را در مرکز کامپیوتر لیورمور در آزمایشگاه ملی لارنس لیورمور دنبال کرد. توسعهٔ NLTSS تقریباً هم‌زمان با انتقال LTSS به Cray-1 آغاز شد تا به سیستم اشتراک‌گذاری زمان Cray تبدیل شود. برای سازگاری با بسیاری از کاربردهای علمی در آزمایشگاه ملی لارنس لیورمور، LLNL مجبور به تقلید از تماس‌های سیستم عامل قبلی LTSS شد. این شبیه‌سازی در قالب یک کتابخانه‌ی سازگاری به نام "baselib" پیاده‌سازی می‌شد. به عنوان مثال، در حالی که ساختار دایرکتوری و بنابراین ساختار پردازش برای NLTSS به‌طور طبیعی یک گراف جهتدار بود (این امکان وجود داشت که قابلیت‌های پردازش و فرایند را مانند قابلیت‌های فایل یا قابلیت‌های فهرست در دایرکتوری‌ها ذخیره کرد)، کتابخانه‌ی baselib یک فرایند خطی ساده(کنترل‌کننده – کنترل‌کننده) را شبیه‌سازی می‌کرد. منظور از ساختار حتماً یک ساختار درختی مانند یونیکس نیست بلکه ساختاری است که با LTSS قبلی سازگار بماند.از آن‌جا که کاربران علمی هرگز به خدمات NLTSS خارج از کتابخانهٔ baselib دسترسی نداشتند، نهایتاً NLTSS برای کاربرانش تقریباً شبیه LTSS بود. بیشتر کاربران از قابلیت‌ها آگاه نبودند و نمی‌دانستند که می‌توانند به منابع در سراسر شبکه دسترسی داشته‌باشند و به‌طور کلی نمی‌دانستند که NLTSS خدماتی فراتر از LTSS ارائه می‌دهد. NLTSS از چندپردازشی متقارن حافظهٔ مشترک پشتیبانی می‌کند؛ توسعه ای که به موازات توسعه مشابه در سیستم اشتراک گذاری زمان Cray بود.
حتی نام NLTSS چیزی شبیه به میراث بود. نام "New Livermore Time Sharing System" در ابتدا یک نام موقت در طول توسعه در نظر گرفته‌شد. هنگامی که سیستم شروع به اجرای برنامه‌ها در حالت «سیستم دوگانه» کرد (نوعی ماشین مجازی که درایورها را با LTSS به اشتراک می‌گذاشت، نام دائمی ترِ LINOS («سیستم عامل شبکهٔ LINCS») توسط توسعه‌دهندگان انتخاب شد. متأسفانه مدیریت LNLL با تغییر نام مخالفت کرد (به نظر می‌رسد دلیل آن بود که عبارت قبلی در درخواست‌های بودجه به کار گرفته‌شده‌بود. بنا بر این، نام توسعهٔ موقت "NLTSS" در طول عمر خود در سیستم باقی‌ماند.
یک سیستم حافظه انبوه نیز به موازات NLTSS توسعه داده‌شد که از پروتکل‌های LINCS(همان پروتکل‌های فایل و دایرکتوری‌های NLTSS) استفاده می‌کرد. این سیستم/نرم‌افزار بعداً به عنوان محصول Unitree تجاری شد. Unitree به‌طور کلی توسط سیستم ذخیره‌سازی با کارایی بالا (HPSS) جایگزین شد که می‌توان آن را میراثی از LINCS و NLTSS در نظر گرفت. برای مثال، LINCS و NLTSS شکلی از انتقال شخص ثالث را برای کپی کردن فایل به فایل در NLTSS، و هدایت سرورهای فایل برای انتقال داده‌ها بین خود که به شکل اصلاح شده به Unitree و HPSS(سیستم ذخیره‌سازی با کارایی بالا) تبدیل شد، معرفی کردند.
مسائل اجرا و طراحی[ویرایش]
بزرگ‌ترین آسیب به NLTSS در طول عمر تولید آن، عملکرد بود. یکی از مشکلات عملکردی که بیشتر کابران را تحت تأثیر قرار می‌داد، تاخیر دسترسی به فایل‌ها بود. این، به‌طور کلی مشکل مهمی برای ورودی یا خروجی دیسک نبود؛ اما سیستم‌هایی که NLTSS روی آن‌ها اجرا می‌شد، مکمل قابل توجهی از دیسک‌های حالت جامد با تأخیر بسیار کم با زمان دسترسی کمتر از ۱۰ میکروثانیه را نیز پشتیبانی می‌کردند. تأخیر اولیه برای عملیات فایل در NLTSS قابل مقایسه با تأخیر دسترسی به دیسک حالت جامد و به‌طور قابل توجهی بالاتر از تأخیر LTSS برای چنین دسترسی‌هایی بود. برای بهبود تأخیر دسترسی به فایل در NLTSS پیاده‌سازی به‌طور قابل توجهی تغییر کرد تا حساس‌ترین فرآیندهای تاخیر (به ویژه سرور فایل) در هسته قرار بگیرند. این تلاش مهمی نبود؛ زیرا همهٔ سرورهای NLTSS روی یک مدل چند نخی کار می‌کردند.انتقال رشته‌های خدمات سرور فایل از یک پردازش سرور فایل جداگانه به پردازش هسته قسمت مهم این تغییر بود. ارتباط با کاربران بدون تغییر بود (فعلا از طریق جداول بافر، نشانه‌های LINCS و غیره)، اما عملیات فایل از برخی تغییرات با زمینه و محتوای مهم که علت اصلی تاخیرهای بالاتر نسبت به آنچه که LTSS قدیمی و سیستم اشتراک‌گذاری زمان رقیب Cray ارائه می‌کردند، جلوگیری کرد. این تأخیر به‌طور قابل توجهی تأخیر عملیات ورودی و خروجی فایل را بهبود بخشید؛ اما این معنی را هم داشت که سرور فایل به بخش قابل اعتمادی از هسته با پیاده‌سازی نه با طراحی تبدیل می‌شد.
دومین مشکل پیاده‌سازی با NLTSS مربوط به امنیت یا یکپارچگی آن به عنوان پیاده‌سازی است. این پیاده‌سازی از یک مدل دارای رمز عبور استفاده می‌کرد. با این مدل، هر شخص یا فرآیندی که می‌توانست به فضای حافظهٔ یک پردازش دسترسی داشته‌باشد، این اختیار را داشت که به قابلیتی که توسط داده‌های موجود در آن حافظه ارائه می‌شد، دسترسی داشته‌باشد. برخی معماران سیستم (مانند اندرو تننبام، معمار سیستم عامل توزیع‌شدهٔ آمیب)گفتند که مشکل دسترسی به حافظه، که مستلزم دسترسی به قابلیت‌ها است، یک مشکل ذاتی نیست. به دلیل اینکه در محیط NLTSS گاهی افراد حافظهٔ برنامه را به دلیل تجزیه و تحلیل به دیگران می‌سپردند و به دلیل نگرانی‌های دیگر، قابلیت‌هایی مثل رمز عبور، به عنوان یک آسیب‌پذیری در NLTSS در نظر گرفته‌شد. یک طراحی برای مقابله با این آسیب‌پذیری مکانیزم کنترل با رمزنگاری کلید عمومی انجام شد.[۲]البته این مکانیزم در NLTSS تولید نشد زیرا هزینهٔ عملکرد آن بسیار قابل توجه بود و همچنین کاربران NLTSS از این آسیب‌پذیری آگاه نبودند. پیشرفت‌های مدرن در رمرنگاری، چنین حفاظتی را برای این قابلیت‌ها، به ویژه برای قابلیت‌های اینترنت یا وب عملی می‌سازد (به YURLs[۳]یا WideWORD مراجعه کنید[۴]).
یک مشکل طراحی NLTSS که تا سال‌ها پس از حذف آن از تولید هم مورد توجه قرار نگرفت، معماری شبکه باز آن بود. در NLTSS پردازش‌ها به عنوان پردازنده‌های مجازی در یک شبکه بدون دیوار آتش یا محدودیت‌های دیگر در نظر گرفته می‌شدند. هر فرآیندی می‌توانست به راحتی با فرایند دیگر ارتباط برقرار کند. این بدان معنا بود که حتی به معنای محدود کردن ارتباط مستقیم (مثلاً در مقابل محدود کردن کانال‌های مخفی مانند "کوبیدن دیوار") امکان حبس وجود نداشت. برای اصلاح این مشکل، NLTSS یه قابلیت‌هایی برای فعال کردن ارتباط نیاز داشت. آخرین توسعه در NLTSS مانند "اعداد جریان" به چنین تأسیساتی نزدیک می‌شد؛ اما زمانی که توسعهٔ فعال در سال ۱۹۸۸ متوقف شد، ارتباطات در NLTSS هنوز محدود نشده‌بود.
منابع[ویرایش]
- ↑ "Components of a Network Operating System". webstart.com.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ "Managing Domains in a Network Operating System". webstart.com.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ "YURL – Waterken Inc". waterken.com.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
- ↑ https://wideword.net/
مشارکت‌کنندگان ویکی‌پدیا. «NLTSS». در دانشنامهٔ ویکی‌پدیای انگلیسی، بازبینی‌شده در ۴ ژانویه ۲۰۲۲.
برای مطالعه بیشتر[ویرایش]
- JE Donnelley, اجزای یک سیستم عامل شبکه، چهارمین کنفرانس شبکه‌های محلی، مینیاپولیس، ۱۹۷۹. همچنین در شبکه‌های کامپیوتری 3 (1979) ۳۸۹–۳۹۹.
- JE Donnelley, مدیریت دامنه‌ها در یک سیستم عامل شبکه، مجموعه مقالات شبکه‌های محلی و کنفرانس سیستم‌های اداری توزیع شده، لندن، می ۱۹۸۱، صفحات ۳۴۵–۳۶۱.
- ST Brugger, M. Gandhi، و G. Streletz, شبکه Livermore Time Sharing System (NLTSS)، ۲۰۰۱
پیوند به بیرون[ویرایش]
- قابلیت محاسبات در LLNL بحث در مورد تاریخچه استفاده از قابلیت‌ها در محاسبات در LLNL، از جمله اشاره مختصری به سیستم RATS و چگونگی توسعه منجر به NLTSS
- داستان‌های توسعه محاسبات علمی در مقیاس بزرگ در آزمایشگاه ملی لارنس لیورمور
- NLTSS Chronicles Cartoons از توسعه NLTSS و LINCS
رده:ریزهسته‌ها رده:سیستم‌عامل‌های مبتنی بر ریزهسته رده:سیستم‌عامل‌های اشتراک زمانی رده:صفحات با ترجمه بازبینی‌نشده
This article "سیستم اشتراک زمانی شبکه‌ی لیورمور" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:سیستم اشتراک زمانی شبکه‌ی لیورمور. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
