NLTSS

NLTSS , сетевая Ливерморская система разделения времени , также иногда известная как Новая Ливерморская система разделения времени, была операционной системой, которая активно разрабатывалась в Ливерморской лаборатории Лоуренса (ныне Ливерморская национальная лаборатория ) с 1979 по 1988 год, хотя она продолжала запускать производственные приложения. до 1995 года. Более ранняя система, Ливерморская система разделения времени, была разработана более десяти лет назад.

Первоначально NLTSS работал на компьютере CDC 7600 , но производился только с 1985 по 1994 год на компьютерах Cray, включая модели Cray-1 , Cray X-MP и Cray Y-MP .

Характеристики [ править ]

Операционная система NLTSS во многих отношениях была необычной, а в некоторых - уникальной.

Низкоуровневая архитектура [ править ]

NLTSS был системой передачи сообщений на микроядре . Это было уникально тем, что ядро ​​системы поддерживало только один системный вызов. Этот системный вызов, который можно было бы назвать "взаимодействовать" (у него не было имени, потому что его не нужно было отличать от других системных вызовов), был принят список "буферных таблиц" (например, см. Интерфейс системы сообщений NLTSS) ^[1], который содержал управляющую информацию для передачи сообщений - отправляет или получает. Такая коммуникация, как локально в системе, так и по сети, была ядром системы, поддерживаемым непосредственно для пользовательских процессов . «Система сообщений» (поддерживающая один вызов и сетевые протоколы), а драйверы для дисков и процессора составляют все ядро ​​системы.

Архитектура среднего уровня [ править ]

NLTSS была системой клиент-сервер, основанной на возможностях . Двумя основными серверами были файловый сервер и технологический сервер. Файловый сервер был процессом, которому доверяли драйверы для локального хранилища (дисковое хранилище), а процессный сервер был процессом, которому доверял драйвер процессора (программное обеспечение, которое переключает управление разделением времени между процессами в «генераторе» , обрабатывал прерывания для процессов, помимо вызова «взаимодействия», предоставлял доступ к памяти и состоянию процесса для сервера процессов и т. д.).

NLTSS была настоящей сетевой операционной системой в том смысле, что ее запросы к ресурсам могли исходить от локальных или удаленных процессов в любом месте сети, и серверы не могли их различать. Единственным средством для серверов проводить такие различия будет сетевой адрес, и у них не было причин проводить такие различия. Все запросы к серверам выглядели как сетевые.

Связь между процессами в NLTSS по соглашению использует набор протоколов LINCS ( Livermore Interactive Network Communication System ), который определяет стек протоколов в соответствии со стеками , определенными эталонной моделью OSI . Протокол транспортного уровня для NLTSS и LINCS назывался Delta-T . На уровне представления LINCS определила стандарты для передачи пронумерованных параметров в виде токенов (например, целых чисел, возможностей и т. Д.), Которые хранились в записи уровня сеанса для обработки в механизме удаленного вызова процедур .

Понятие « пользователь » было определено в NLTSS лишь периферийно. Существовал «сервер учетных записей», который отслеживал, какие пользователи использовали какие ресурсы (например, запросы на создание таких объектов, как файл или процессы, требовали такой возможности учетной записи). Контроль доступа полностью управлялся с помощью возможностей (передаваемые токены полномочий).

Файловый сервер [ править ]

Любой процесс может делать запросы к файловому серверу для создания файлов (возвращая возможности файла ), запрашивать чтение или запись файлов (представляя возможности файла) и т. Д. Например, для чтения файла обычно требуется три буфера. таблицы, одна для отправки запроса на файловый сервер, одна для получения ответа от файлового сервера и одна для получения данных из файла. Эти три запроса обычно отправлялись в систему сообщений за один раз, иногда вместе с другими запросами. Управляющие биты могут быть установлены в буферных таблицах для пробуждения (разблокирования) процесса всякий раз, когда любая из представленных буферных таблиц была помечена как «Готово». Вызов библиотеки для чтения файла обычно блокируется до тех пор, пока не будет получен ответ управления от файлового сервера, хотя асинхронный ввод-выводконечно, не будет блокировать и может проверить или заблокировать позже. Любые подобные различия на стороне пользователя были невидимы для файлового сервера.

Сервер обработки [ править ]

В NLTSS сервер процессов был очень похож на файловый сервер в том, что пользовательские процессы могли запрашивать создание процессов, запуск или остановку процессов, чтение или запись памяти процесса или регистров и получать уведомления о сбоях процесса. Сервер процессов был обычным процессом пользовательского режима, которому просто доверяли связь с драйвером ЦП , точно так же, как файловому серверу доверяли связь с драйвером диска. Сервер процессов сохранял состояние процесса в файлах, предоставленных файловым сервером, и в этом отношении выглядел как любой другой пользовательский процесс для файлового сервера.

Сервер каталогов [ править ]

Примером сервера более высокого уровня в NLTSS был сервер каталогов. Задача этого сервера заключалась в том, чтобы по существу превратить файлы (невидимые для пользователя) в каталоги, которые можно было использовать для хранения и извлечения возможностей по имени. Поскольку возможности были просто данными, это не было особенно сложной задачей - она ​​заключалась в основном в управлении правами доступа к возможностям в соответствии с соглашениями, определенными в наборе протоколов LINCS. Одно место, где это стало немного интересным, касалось разрешения доступа, называемого «наследование». Если этот бит установлен (разрешен), тогда возможности можно будет получить с полным доступом из каталога.Если этот бит был отключен (запрещен), то все разрешения, отключенные в возможности каталога, в свою очередь, были отключены в функции, которая была запущена, прежде чем она была возвращена запрашивающему приложению. Этот механизм позволял людям хранить, например, файлы для чтения / записи в каталоге, но давал другим пользователям только разрешение на выборку их экземпляров только для чтения.

Развитие [ править ]

Основная часть программирования для NLTSS была сделана в расширении Pascal, разработанном в Национальной лаборатории Лос-Аламоса, известном как «Модель». Модель расширила Pascal, чтобы включить механизм абстрактного типа данных (объект) и некоторые другие функции.

NLTSS была обременена наследием совместимости. NLTSS следил за разработкой и развертыванием LTSS (Ливерморской системы разделения времени) в Ливерморском компьютерном центре в LLNL (~ 1968–1988?). Разработка NLTSS началась примерно в то же время, когда LTSS был перенесен на Cray-1 и стал системой разделения времени Cray . Чтобы оставаться обратно совместимой со многими научными приложениями в LLNL, NLTSS был вынужден эмулировать системные вызовы предыдущей операционной системы LTSS. Эта эмуляция была реализована в виде библиотеки совместимости под названием «baselib». В качестве одного примера, хотя структура каталогов и, следовательно, структура процесса для NLTSS, естественно, была ориентированным графом(возможности процессов могут храниться в каталогах так же, как возможности файлов или возможности каталогов), библиотека baselib эмулировала простую линейную (контроллер - элемент управления) структуру процесса (даже не древовидную структуру, как в Unix ), чтобы оставаться совместимой с предыдущей LTSS. Поскольку научные пользователи никогда не обращались к службам NLTSS за пределами библиотеки baselib, NLTSS в конечном итоге выглядел почти так же, как LTSS для своих пользователей. Большинство пользователей не знали о возможностях, не осознавали, что могут получать доступ к ресурсам в сети, и, как правило, не знали, что NLTSS предлагает какие-либо услуги, помимо LTSS. NLTSS действительно поддерживал симметричную многопроцессорную обработку с общей памятью , разработка, которая шла параллельно с аналогичной разработкой вСистема разделения времени Cray .

Даже название NLTSS было чем-то вроде наследия. Название «Новая Ливерморская система разделения времени» изначально считалось временным именем для использования во время разработки. Как только система начала запускать некоторые приложения в режиме «двойной системы» (своего рода виртуальная машина, совместно использующая драйверы с LTSS), разработчики выбрали более постоянное имя - LINOS (сетевая операционная система LIncs). К сожалению, руководство LLNL решило, что имя не может быть изменено на этом этапе (по-видимому, потому, что предыдущий термин использовался в бюджетных запросах), поэтому имя временного развития «NLTSS» оставалось в системе на протяжении всего срока ее службы.

Запоминающая система была также разработана параллельно с NLTSS , которые используются протоколы Lincs ( тот же файл и протоколы каталогов , как NLTSS). Эта система / программное обеспечение позже было коммерциализировано как продукт Unitree. На смену Unitree в целом пришла высокопроизводительная система хранения данных (HPSS), которую можно смело рассматривать как наследие LINCS и NLTSS. Например, LINCS и NLTSS представили форму передачи третьими сторонами (для копирования файла в файл в NLTSS процесс может отправлять два запроса на файловые серверы, один на чтение и один на запись, и направлять файловые серверы для передачи данных между собой) в модифицированном виде это реализовано в Unitree и HPSS.

Проблемы реализации и проектирования [ править ]

Самым большим ударом по NLTSS в течение всего срока его службы была производительность. Единственная проблема производительности, которая больше всего влияла на пользователей, - это задержка доступа к файлам . Обычно это не было серьезной проблемой для дискового ввода-вывода, но системы, на которых работала NLTSS, также поддерживали значительный набор твердотельных дисков с очень малой задержкой.со временем доступа до 10 микросекунд. Начальные задержки для файловых операций в рамках NLTSS были сопоставимы с задержкой для доступа к твердотельному диску и значительно превышали задержку LTSS для такого доступа. Чтобы уменьшить задержку доступа к файлам в рамках NLTSS, реализация была значительно изменена, чтобы поместить наиболее чувствительные к задержке процессы (в частности, файловый сервер) «в ядро». Эти усилия не были столь значительными, как может показаться на первый взгляд, поскольку все серверы NLTSS работали в многопоточном режиме.модель. В действительности это изменение сводилось к перемещению потоков, отвечающих за службы файлового сервера, из отдельного процесса файлового сервера в «процесс» ядра. Связь с пользователями не изменилась (все еще через буферные таблицы, токены LINCS и т. Д.), Но файловые операции позволили избежать некоторых существенных изменений контекста, которые были основной причиной более высоких задержек по сравнению с тем, что предоставляли более старые LTSS и конкурирующая система разделения времени Cray . Это изменение значительно (примерно в 3 раза) улучшило задержку операций ввода-вывода файлов, но также означало, что файловый сервер стал доверенной частью ядра (по реализации, а не по дизайну).

Вторая проблема реализации NLTSS связана с безопасностью / целостностью его возможностей как реализации данных. Эта реализация использовала модель возможностей пароля (например, см. Управление паролем). ^[2] В этой модели любой человек или процесс, который может получить доступ к пространству памяти процесса, будет иметь право доступа к возможности, представленной данными, находящимися в этой памяти. Некоторые системные архитекторы (например, Эндрю С. Таненбаум , архитектор распределенной операционной системы Amoeba ) предположили, что это свойство доступа к памяти, подразумевающее доступ к возможностям, не является внутренней проблемой. В среде NLTSS иногда случалось, что люди делали дампы памяти программ.другим для анализа. Из-за этой и других проблем такие возможности пароля считались уязвимостью в NLTSS. Для защиты от этой уязвимости был разработан механизм управления шифрованием открытого ключа ^[3] . Этот механизм не был запущен в производство в NLTSS как из-за его значительной стоимости производительности, так и из-за того, что пользователи не знали об уязвимости, связанной с возможностями пароля. Современные достижения в области криптографии сделали бы такую ​​защиту для возможностей практической, особенно для возможностей Интернета / Web (например, см. YURL ^[4] или WideWORD). ^[5]

Проблемой проектирования NLTSS, которая не рассматривалась до тех пор, пока она не была снята с производства, была открытая сетевая архитектура. В NLTSS процессы рассматривались как виртуальные процессоры в сети без межсетевых экранов или других ограничений. Любой процесс может свободно общаться с любым другим. Это означало , что нельзя было сделать заключение , даже в смысле ограничения прямой связи (например , против ограничения скрытых каналов , таких , как «стена стук»). Чтобы решить эту проблему, NLTSS потребуются возможности для обеспечения связи. Поздние разработки по NLTSS, такие как "номера потоков", приближались к такому объекту, но к моменту прекращения активной разработки в 1988 году связь в NLTSS все еще не была ограничена.

См. Также [ править ]

• Ливерморская система разделения времени

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Дж. Э. Доннелли, Компоненты сетевой операционной системы , Четвертая конференция по локальным сетям, Миннеаполис, 1979. Также в Computer Networks 3 (1979) 389–399.
• Дж. Э. Доннелли, Управление доменами в сетевой операционной системе , Труды конференции по локальным сетям и распределенным офисным системам, Лондон, май 1981 г., стр. 345–361.
• С.Т. Брюггер, М. Ганди и Г. Стрелец, Сетевая система разделения времени Ливермора (NLTSS) , 2001

Внешние ссылки [ править ]

• Возможности вычислений в LLNL Обсуждение истории использования возможностей вычислений в LLNL, включая краткое упоминание о системе RATS и о том, как разработка привела к NLTSS
• Истории развития крупномасштабных научных вычислений в Ливерморской национальной лаборатории Лоуренса
• Мультфильмы NLTSS Chronicles от разработки NLTSS и LINCS