NLTSS

خطای اسکریپتی: پودمان «AfC submission catcheck» وجود ندارد. NLTSS، سیستم اشتراک زمانی شبکه‌ی لیورمور، که به عنوان سیستم اشتراک زمانی جدید لیورمور نیز شناخته می‌شود، سیستم عاملی است که از سال 1979 تا حدود سال 1988، در آزمایشگاه لارنس لیورمور(اکنون: آزمایشگاه ملی لارنس لیورمور) به طور فعال وجود داشت؛ اگر‌چه تا سال 1995 به اجرای برنامه‌های کاربردی ادامه داد.

NLTSS در ابتدا بر روی یک کامپیوتر CDC7600 اجرا شد؛ اما از سال 1985 تا 1994 برای کامپیوتر‌های Cray، از جمله مدل‌های MP، Cray-1، Cray-X و Y-MP تولید شد.

مشخصات[ویرایش]

سیستم عامل NLTSS، در بسیاری از موارد غیر‌عادی و حتی منحصر‌به‌فرد عمل می‌کند.

معماری سطح پایین[ویرایش]

NLTSS، به عنوان یک سیستم ارسال پیام ریز‌هسته شناخته می شد و از آن به عنوان سیستم منحصر به فرد نیز یاد می برند زیرا تنها یک فراخوانی سیستم توسط هسته‌ی سیستم پشتیبانی می شد. این فراخوانی که یک لیست از جدول های بافر را می پذیرفت "ارتباط" می نامند(در حقیقت نامی ندارد زیرا نیازی به تمایز با سایر تماس های سیستمی وجود نداشت).

چنین ارتباطی، چه به صورت محلی در داخل سیستم و چه در سراسر یک شبکه، تمام هسته سیستم است که مستقیماً برای فرآیندهای کاربران پشتیبانی می شدند. "سیستم پیام" (با پشتیبانی از یک تماس و پروتکل های شبکه) و درایورها برای دیسک ها و پردازنده، تمام هسته یک سیستم را تشکیل می دادند.

معماری سطح متوسط[ویرایش]

NLTSS یک سیستم سرور-مشتری مبتنی بر قابلیت بود. دو سرور اصلی در آن، سرور فایل و سرور پردازش هستند. سرور فایل فرآیندی است که توسط درایور‌ها برای ذخیره‌سازی محلی قابل اعتماد (ذخیره‌سازی دیسک) وسرور پردازش امتیازی است که توسط درایور پردازنده قابل اعتماد است(نرم‌افزاری که کنترل اشتراک زمانی را بین فرآیند‌های موجود در آلترنیتور تغییر می‌ دهد؛ وقفه‌های فرآیند زا علاوه بر تماس ارتباط مدیریت می‌کند و علاوه بر آن دسترسی به حافظه و وضعیت پردازش را برای سرور پردازش فراهم می‌ کند.) NLTSS، یک سیستم عامل شبکه‌ی واقعی است؛ زیرا درخواست‌های منابع آن می‌توانند از پردازش‌های محلی یا پردازش‌های راه دور از هر کجای شبکه باشد و سرور‌ها آن‌ها را متمایز نمی کند.) تنها نیاز شبکه برای ایجاد چنین تمایز‌هایی، از طریق آدرس شبکه خواهد بود و آن‌ها هیچ دلیلی برای ایجاد چنین تمایز‌هایی نداشتند. همه‌ی درخواست‌ها به سرور‌ها به عنوان درخواست‌ها شبکه ظاهر شدند. ارتباط بین پردازش‌ها در NLTSS، به صورت قراردادی از مجموعه‌ی پروتکل‌های LINCS(سیستم ارتباطی شبکه‌ی تعاملی لیورمور) استفاده می‌کند، که یک پشته پروتکل را در امتداد خطوط تعریف‌شده توسط مدل مرجع OSI تعریف می‌کند. پروتکل سطح انتقال برای NLTSS و Delta-T، LINCS نام داشت. در سطح ارائه، LINCS استاندارد‌هایی را برای برقراری ارتباط با پارامتر‌های شماره‌گذاری‌شده به عنوان نشانه‌ها(مانند اعداد صحیح، قابلیت‌ها و غیره) تعریف کرد که در یک رکورد، سطح جلسه برای پردازش در یک مکانیس فراخوانی روش راه دور ذخیره می‌شدند. مفهوم کاربر در NLTSS نتها به صورت پیرامونی تعریف شده‌بود. یک «سرور حساب» وجود داشت که ردیابی و کنترل می‌کرد که کدام کاربران از چه منابعی استفاده می‌کردند.

سرور فایل[ویرایش]

هر فرآیندی می‌توند برای ایجاد فایل‌ها(برگرداندن قابلیت فایل‌ها)، درخواست خواندن یا نوشتن فایل‌ها(با ارائه‌ی قابلیت فایل)و غیره، به سرور فایل درخواست بدهد.برای مثال، عمل خواندن یک فایل، به طور کلی به سه جدول بافر نیاز دارد؛ یکی برای فرستادن درخواست به سرور فایل، دیگری برای دریافت پاسخ درخواست از سرور و آن یکی نیز برای دریافت اطلاعات از فایل است. این سه درخواست عموما با هم و در یک زمان به سیستم پیام ارسال میشدند و گاهی اوقات نیز با درخواست‌های دیگر همراه می‌شدند. بیت‌های کنترل را می‌توان در جدول بافر تنظیم کرد تا هر زمان که هر یک از جداول بافر ارسال‌شده با نشانه‌ی «Done» یک فرآیند را راه‌اندازی کند. فراخوانی یک کتابخانه برای خواندن یک فایل معمولا تا زمانی که پاسخ کنترل از سرور فایل دریافت نشود مسدود می‌شود؛ اگر‌چه ورودی و خروجی همزمان مسدود نمی‌شوند و می‌توانند بعدا بررسی شوند. چنین تفاوت‌هایی در سمت کاربر برای سرور فایل غیر قابل مشاهده بود.

سرور پردازش[ویرایش]

در NLTSS سرور پردازش(فرآیند) کاملا شبیه به سرور فایل بود. این شباهت از این نظر است که کاربران می‌توانند درخواست ایجاد فرآیند‌ها و پزدازش‌های دیگر، یا شروع و پایان پردازش‌ها، خواندن یا نوشتن حافظه‌ی فرآیند یا رجیستر‌ها را داشته‌باشند و هم‌چنین از خطا‌های فرآیند مطلع شوند. سرور پردازش، یک حالت فرآیند کاربر معمولی بود که برای برقراری ارتباط با درایور CPU به سادگی قابل اعتماد بود؛ درست مانند سرور فایل برای برقراری ارتباط با درایور دیسک. سرور پردازش وضعیت پردازش را در فایل‌های ارائه‌شده توسط سرور فایل ذخیره می‌کند و از این نظر مانند هر فرآیند کاربر دیگری در سرور فایل ظاهر می‌شود.

سرور دایرکتوری[ویرایش]

یک مثال سطح بالاتر از سرور در NLTSS سرور دایرکتوری است. وظیفه‌ی سرور اساسا این است که فایل‌ها(غیر قابل مشاهده برای کاربر) را به دایرکتوری‌هایی تبدیل کند که بتوان از آن‌ها برای ذخیره و بازیابی قابلیت‌ها به همراه نام استفاده کرد. از آن‌جا که قابلیت‌ه صرفا داده‌ها بودند، این کار چندان دشواری نبود که بیشتر شامل دستکاری در مجوز‌های دسترسی به قابلیت‌ها بر اساس قرارداد های تعریف شده در مجموعه پروتکل LINCS بود. جایی که این مطلب کمی جالب‌‌تر می شود، مربوط به مجوز دسترسی به نام "inheritance" است. اگر این بیت روشن(مجاز) بود، این امکان وجود دارد که قابلیت‌ها را با دسترسی کامل آن‌ها از دایرکتوری واکشی کرد. اگر این بیت خاموش(غیر مجاز) بود، هر مجوزی که در قابلیت دایرکتوری غیر فعال شده‌بود، به نوبه‌ی خود در قابلیتی که واکشی شده‌بود، قبل از این‌که به برنامه درخواست‌کننده بازگردانده شود، غیرفعال می‌شود. این مکانیسم به افراد اجازه می‌دهد که مثلا فایل‌ها را در یک فهرست بخوانند یا بنویسند اما به سایر کاربران فقط اجازه‌ی واکشی نمونه‌های فقط خواندنی آن‌ها را می‌دهد.

توسعه[ویرایش]

بخش عمده‌ای از برنامه‌نویسی برای NLTSS، در آزمایشگاه ملی لوس آلاموس با پاسکال به نام مدل انجام شد. «مدل»، پاسکال را گسترش داد تا مکانیزم نوع داده انتزاعی و برخی ویژگی‌های دیگر را دربرگیرد. NLTSS با میراث سازگاری همراه است. NLTSS توسعه و استقرار LTSS(سیستم به اشتراک‌گذاری زمان لیورمور) را در مرکز کامپیوتر لیورمور در LLNL دنبال کرد. توسعه NLTSS تقریبا همزمان با انتقال LTSS به Cray-1 آغاز شد تا به سیستم اشتراک‌گذاری زمان Cray تبدیل شود. برای سازگاری با بسیاری کاربرد‌های علمی در NLTSS، LLNL مجبور به تقلید از تماس‌های سیستم عامل قبلی LTSS شد. این شبیه‌سازی در قالب یک کتابخانه‌ی سازگاری به نام "baselib" پیاده‌سازی می شود. ‌‌‌به عنوان مثال، در حالی که ساختار دایرکتوری و بنابراین ساختار پردازش برای NLTSS به طور طبیعی یک گراف جهتدار است(قابلیت‌های پردازش و فرآیند را می‌توان مانند قابلیت‌های فایل یا قابلیت‌های فهرست در دایرکتوری‌ها ذخیره کرد)، کتابخانه‌ی baselib یک فرآیند خطی ساده(کنترل‌کننده – کنترل‌کننده) را شبیه‌سازی می کند.ساختار (نه حتی یک ساختار درختی مانند یونیکس) تا با LTSS قبلی سازگار بماند. از آن‌جا که کاربران علمی هرگز به خدمات NLTSS خارج از کتابخانه‌ی baselib دسترسی نداشتند، نهایتا NLTSS برای کاربرانش تقریبا شبیه LTSS بود. بیش‌تر کاربران از قابلیت‌ها آگاه نبودند و نمی دانستند که می‌توانند به منابع در سراسر شبکه دسترسی داشته‌باشند و به طور کلی نمی‌دانستند که NLTSS خدماتی فراتر از LTSS ارائه می‌دهد. NLTSS چند‌پردازشی متقارن حافظه‌ی مشترک پشتیبانی می‌کند؛ توسعه‌ای موازی با توسعه‌ی مشابه در سیستم اشتراک‌گذاری زمانی Cray. نام "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 روی آنها اجرا می‌شد، مکمل قابل توجهی از دیسک‌های حالت جامد با تاخیر بسیار کم با زمان دسترسی کمتر از 10 میکروثانیه را نیز پشتیبانی می‌کردند. تاخیر اولیه برای عملیات فایل در NLTSS قابل مقایسه با تاخیر دسترسی به دیسک حالت جامد و به طور قابل توجهی بالاتر از تاخیر LTSS برای چنین دسترسی‌هایی است. برای بهبود تاخیر دسترسی به فایل در NLTSS پیاده‌سازی به طور قابل توجهی تغییر کرد تا حساس‌ترین فرآیند‌های تاخیر(به ویژه سرور فایل) در هسته قرار می گیرند. این تلاش مهمی نبود؛ زیرا همه‌ی سرور‌های NLTSS روی یک مدل چند‌رشته‌ای کار می کنند.انتقال رشته‌های مسئول خدمات سرور فایل از یک پردازش سرور فایل جداگانه به پردازش هسته قسمت مهم این تغییر است. ارتباط با کاربران بدون تغییر است(فعلا از طریق جداول بافر، نشانه‌های LINCS و غیره)، اما عملیات فایل از برخی تغییرات با زمینه و محتوای مهم که علت اصلی تاخیر‌های بالاتر نسبت به آنچه که LTSS قدیمی و سیستم اشتراک‌گذاری زمان رقیب Cray ارائه می‌کردند، جلوگیری کرد. این تاخیر به طور قابل توجهی تاخیر عملیات ورودی/خروجی فایل را بهبود بخشید؛ اما این معنی را هم داشت که سرور فایل به بخش قابل اعتمادی از هسته تبدیل می شد(با پیاده‌سازی؛ نه با طراحی). دومین مشکل پیاده‌سازی با NLTSS مربوط به امنیت/یکپارچگی قابلیت آن به عنوان پیاده‌سازی است. این پیاده‌سازی از یک مدل دارای رمز عبور استفاده می‌کرد. با این مدل، هر شخص یا فرآیندی که بتواند به فضای حافظه‌ی یک پردازش دسترسی داشته‌باشد، این اختیار را دارد که به قابلیتی که توسط داده‌های موجود در آن حافظه ارائه می‌شود، دسترسی داشته‌باشد. برخی معماران سیستم(مانند Andrew S. Tanenbaum، معمار سیستم عامل توزیع‌شده‌ی آمیب)معتقدند که مشکل دسترسی به حافظه، که مستلزم دسترسی به قابلیت‌ها است، یک مشکل ذاتی نیست. در محیط NLTSS گاهی اتفاق می‌افتاد که افراد حافظه‌ی برنامه را به دلیل تجزیه و تحلیل به دیگران می‌سپردند. به این دلیل و به دلیل نگرانی‌های دیگر، قابلیت‌هایی مثل رمز عبور، به عنوان یک آسیب‌پذیری در NLTSS در نظر گرفته‌شد. یک طراحی برای مقابله با این آسیب‌پذیری مکانیزم کنترل با رمز‌نگاری کلید عمومی انجام شد . اینکه این مکانیزم در NLTSS تولید نشد، به دو دلیل هزینه‌ی عملکرد قابل توجه آن و هم به دلیل آگاه نبودن کاربران NLTSS از این آسیب‌پذیری بود. پیشرفت‌های مدرن در رمرنگاری، چنین حفاظتی را برای این قابلیت‌ها، به ویژه برای قابلیت‌های اینترنت/وب عملی می‌سازد(به YURLs یا WideWORD مراجعه کنید). یک مشکل طراحی NLTSS که تا سال‌ها پس از حذف آن از تولید هم مورد توجه قرار نگرفت، معماری شبکه باز آن بود. در NLTSS پردازش‌ها به عنوان پردازنده‌های مجازی در یک شبکه بدون فایروال یا محدودیت‌های دیگر در نظر گرفته‌ می‌ شدند. هر فرآیندی می‌تواند به راحتی با فرآیند دیگر ارتباط برقرار کند. این بدان معناست که حتی به معنای محدود کردن ارتباط مستقیم (مثلاً در مقابل محدود کردن کانال‌های مخفی مانند "کوبیدن دیوار") امکان حبس وجود ندارد.برای اصلاح این مشکل، NLTSS یه قابلیت‌هایی برای فعال کردن ارتباط نیاز داشت. آخرین توسعه در NLTSS مانند "اعداد جریان" به چنین تاسیساتی نزدیک می‌شد؛ اما زمانی که توسعه‌ی فعال در سال 1988 متوقف شد، ارتباطات در NLTSS هنوز متوقف نشده‌بود.

This article "NLTSS" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:NLTSS. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.