NLTSS

NLTSS
네트워크 리버모어 타임셰어링 시스템(NLTTS)
개발자로렌스 리버모어 연구소
OS 패밀리능력 기반의
동작 상태단종
소스 모델폐쇄 소스
초기 릴리즈1979년; 43년 전 (1979년)
최종 릴리즈파이널 / 1988; 34년 전 (1988년)
마케팅 대상슈퍼컴퓨터
이용가능기간:영어
갱신 방법소스 코드에서 컴파일
플랫폼CDC 7600, Cray-1, Cray X-MP, Cray Y-MP
커널 타입마이크로커널
면허증.독자 사양

네트워크 리버모어 타임셰어링 시스템(NLTSS, 때때로 새로운 리버모어 타임셰어링 시스템)은 1979년부터 1988년까지 로렌스 리버모어 연구소(현 로렌스 리버모어 국립 연구소)에서 활발하게 개발된 운영 체제입니다. 그러나 1995년까지 생산 애플리케이션을 계속 실행했습니다.이전 시스템인 리버모어 타임 셰어링 시스템은 10년 이상 전에 개발되었습니다.

NLTSS는 처음에는 CDC 7600 컴퓨터에서 실행되었지만 1985년부터 1994년까지 Cray-1, Cray X-MP 및 Cray Y-MP 모델을 포함한 Cray 컴퓨터에서만 실행되었습니다.

특성.

NLTSS 운영체제는 많은 면에서 특이하고 일부에서는 독특했습니다.

저레벨 아키텍처

NLTSS는 마이크로커널 메시지 전달 시스템입니다.시스템 커널에서 지원되는 시스템콜은 1개뿐이라는 점이 특이했습니다."communicate"(다른 시스템콜과 구별할 필요가 없었기 때문에 이름이 붙지 않았습니다)라고 불릴 수 있는 이 시스템콜은 메시지 통신의 제어 정보를 포함한 "버퍼 테이블"(예를 들어 "NLTSS 메시지시스템 인터페이스"[1] 참조) 목록을 받아들였습니다.이러한 통신은 시스템 내 및 네트워크를 통해 로컬로 이루어지며 사용자 프로세스에서 직접 지원되는 시스템의 커널이었습니다.디스크와 프로세서의 「메시지 시스템」(원콜과 네트워크 프로토콜을 서포트)과 드라이버는, 시스템의 커널 전체를 구성했습니다.

미드레벨 아키텍처

NLTTS는 기능 기반의 보안 클라이언트 서버 시스템입니다.두 개의 주 서버는 파일 서버와 프로세스 서버입니다.파일 서버는 로컬 스토리지(디스크 스토리지)용 드라이버에 의해 신뢰될 수 있는 특권이 부여된 프로세스이며 프로세스 서버는 프로세서 드라이버('대체'에서 프로세스 간의 시간 공유 제어를 전환하는 소프트웨어)에 의해 신뢰될 수 있는 특권이 부여된 프로세스로, "통신" 호출 이외의 프로세스에 대해 인터럽트를 처리하는 소프트웨어입니다.프로세스 서버의 메모리 및 프로세스 상태에 액세스합니다).

NLTSS는 진정한 네트워크 운영체제였습니다.리소스 요구는 네트워크상의 로컬 프로세스 또는 리모트 프로세스에서 얻을 수 있으며 서버는 이를 구별하지 못했습니다.서버가 이러한 구별을 하는 유일한 방법은 네트워크주소에 의한 것이며, 그러한 구별을 할 이유가 없습니다.서버에 대한 모든 요청은 네트워크 요청으로 표시되었습니다.

관례상 NLTSS의 프로세스 간 통신에는 Livermore Interactive Network Communication System(LINCS) 프로토콜 스위트가 사용되었으며, 이 프로토콜 스위트는 OSI 참조 모델에서 정의된 프로토콜 스택을 따라 정의했습니다.NLTTS 및 LINCS의 전송 수준 프로토콜은 Delta-T로 명명되었습니다.프레젠테이션레벨에서 LINCS는 리모트프로시저 콜 종류의 메커니즘으로 처리하기 위해 세션레벨 레코드에 저장되어 있는 토큰(정수, 기능 등)으로서 번호부 파라미터를 통신하기 위한 표준을 정의했습니다.

"사용자"라는 개념은 NLTSS에서 다소 주변적으로 정의되었을 뿐입니다.어떤 사용자가 어떤 리소스를 사용하고 있는지 추적하는 "계정 서버"가 있었습니다(예를 들어, 파일이나 프로세스 등의 개체를 생성하기 위한 요청에는 이러한 계정 기능이 필요합니다).액세스 제어는 기능(통신 가능한 권한 토큰)으로 완전히 관리되었습니다.

파일 서버

모든 프로세스에서 파일 서버에 파일 생성 요청(파일 기능 되돌리기), 파일 읽기 또는 쓰기 요청(파일 기능 제공) 등을 할 수 있습니다.예를 들어 파일을 읽기 위해서는 일반적으로 3개의 버퍼 테이블이 필요합니다.하나는 파일 서버에 요구를 송신하기 위해서, 1개는 파일 서버로부터 응답을 수신하기 위해서, 1개는 파일로부터 데이터를 수신하기 위해서입니다.이들 3가지 요구는 일반적으로 한 번에 메시지시스템에 송신되어 다른 요구와 번들 되는 경우가 있습니다.제출된 버퍼 테이블 중 하나가 "완료"로 표시될 때마다 프로세스를 웨이크업(차단 해제)하도록 버퍼 테이블에서 제어 비트를 설정할 수 있습니다.파일을 읽기 위한 라이브러리 호출은 일반적으로 파일 서버로부터 제어 응답을 수신할 때까지 차단되지만, 비동기 I/O는 물론 차단되지 않으며 나중에 확인 또는 차단될 수 있습니다.유저측의 이러한 차이는, 파일 서버에서는 보이지 않습니다.

프로세스 서버

NLTSS에서 프로세스 서버는 사용자 프로세스가 프로세스의 작성, 프로세스의 시작 또는 정지, 프로세스의 메모리 또는 레지스터의 읽기 또는 쓰기, 프로세스 장애에 대한 통지를 요구할 수 있다는 점에서 파일 서버와 매우 유사했습니다.프로세스 서버는 파일 서버가 디스크 드라이버와 통신할 수 있도록 신뢰된 것과 마찬가지로 CPU 드라이버와 통신할 수 있도록 신뢰된 일반적인 사용자 모드 프로세스입니다.프로세스 서버는 파일 서버에서 제공하는 파일에 프로세스 상태를 저장했으며, 이 점에서 파일 서버에 대한 다른 사용자 프로세스와 동일하게 보입니다.

디렉토리 서버

NLTSS의 상위 레벨서버의 예로는 디렉토리 서버가 있습니다.이 서버의 작업은 기본적으로 파일(사용자에게 보이지 않음)을 이름으로 기능을 저장 및 검색하는 데 사용할 수 있는 디렉토리로 변환하는 것이었습니다.기능은 단순한 데이터이기 때문에, LINCS 프로토콜 스위트에 정의된 규칙에 따라 기능에 대한 액세스 권한을 조작하는 것이 대부분이기 때문에, 특별히 어려운 작업은 아니었습니다.이것이 조금 흥미로워진 것은 상속이라는 이름의 접근 권한에 관한 것이었습니다.이 비트가 온(허용)일 경우 디렉토리에서 풀액세스를 사용하여 기능을 가져올 수 있습니다.이 비트가 꺼진 경우(허용되지 않은 경우), 디렉토리 기능에서 꺼진 권한은 요청 응용 프로그램으로 반환되기 전에 가져올 기능에서 꺼집니다.이 메커니즘은 예를 들어 읽기/쓰기 파일을 디렉토리에 저장할 수 있지만 다른 사용자는 읽기 전용 인스턴스를 가져올 수 있는 권한만 부여합니다.

발전

NLTTS용 프로그래밍의 대부분은 "모델"로 알려진 로스앨러모스 국립연구소에서 개발한 파스칼 확장으로 이루어졌다.모델 확장 Pascal은 추상 데이터 유형(객체) 메커니즘 및 기타 기능을 포함하도록 확장되었습니다.

NLTSS에는 호환성 레거시가 할당되어 있었습니다.NLTTS는 LLNL의 리버모어 컴퓨터 센터에서 LTSS(Livermore Time Sharing System, LTSS)의 개발과 배치를 따랐다.NLTSS의 개발은 LTSS가 Cray-1에 이식되어 Cray Time Sharing System이 된 것과 거의 같은 시기에 시작되었습니다.LLNL의 많은 과학 애플리케이션과 하위 호환성을 유지하기 위해 NLTSS는 이전 LTSS 운영 체제의 시스템 호출을 에뮬레이트해야 했습니다.이 에뮬레이션은 "baselib"라는 이름의 호환성 라이브러리의 형태로 구현되었습니다.예를 들어 디렉토리 구조 및 NLTSS의 프로세스 구조는 당연히 방향 그래프였지만(프로세스 기능은 파일 기능이나 디렉토리 기능과 마찬가지로 디렉토리에 저장 가능), 바젤리브 라이브러리는 단순한 선형(컨트롤러 – controllee) 프로세스 구조를 에뮬레이트했습니다(의 트리 구조도 아닙니다).Unix)는 이전 LTSS와의 호환성을 유지합니다.과학 사용자는 바젤리브 라이브러리 밖에서 NLTTS 서비스에 액세스한 적이 없기 때문에 NLTSS는 사용자에게 LTTS와 거의 동일하게 보입니다.대부분의 사용자는 기능을 인식하지 못했고, 네트워크를 통해 리소스에 액세스할 수 있다는 사실을 몰랐으며, 일반적으로 NLTSS가 LTSS 이외의 서비스를 제공한다는 사실을 알지 못했습니다. NLTSS는 공유 메모리 대칭 멀티 프로세싱을 지원했습니다.이것은 Cray Time Sharing System의 유사한 개발입니다.

NLTTS라는 이름조차 유산이었습니다."New Livermore Time Sharing System"이라는 이름은 처음에는 개발 중에 사용하는 임시 이름으로 간주되었습니다.시스템이 듀얼 시스템 모드(LTSS와 드라이버를 공유하는 가상 머신의 일종)로 일부 애플리케이션을 실행하기 시작하면 개발자는 LINOS(Lincs Network Operating System)라는 보다 영속적인 이름을 선택했습니다.유감스럽게도 LLNL의 경영진은 그 시점에서 이름을 변경할 수 없다고 판단했기 때문에(이전 용어가 예산 요청에서 사용된 것으로 추정됨), 임시 개발 NLTSS 이름은 평생 동안 시스템에 남아 있었습니다.

대용량 스토리지 시스템도 LINCS 프로토콜(NLTSS와 파일 및 디렉토리 프로토콜)을 사용하는 NLTSS와 병렬로 개발되었습니다.이 시스템/소프트웨어는 나중에 Unitree 제품으로 상용화되었습니다.Unitree는 일반적으로 LINCS 및 NLTSS의 유산이라고 할 수 있는 HPSS(High Performance Storage System)로 대체되었습니다.예를 들어, LINCS와 NLTSS는 서드파티 전송 형식을 도입했습니다(NLTSS에서 파일을 파일로 복사하는 프로세스에서는 파일서버에 2개의 요구를 송신할 수 있습니다.하나는 파일서버를 읽고 파일서버끼리 데이터를 전송하도록 지시하는 요구입니다).이러한 요구는 Unitree와 HPSS에 수정 형식으로 전달됩니다.

구현 및 설계 문제

NLTSS의 제품 수명 기간 동안 가장 큰 타격을 입었던 것은 성능이었습니다.사용자에게 가장 큰 영향을 준 성능 문제 중 하나는 파일 액세스 지연이었습니다.이는 일반적으로 디스크 입출력(I/O)에는 큰 문제가 되지 않았지만 NLTSS가 실행한 시스템에서는 액세스 시간이 10마이크로초 미만인 매우 짧은 대기 시간 솔리드 스테이트 디스크도 상당 부분 지원되었습니다.NLTTS에서의 파일 조작의 초기 레이텐시는 솔리드 스테이트 디스크 액세스의 레이텐시와 비슷하며, 이러한 액세스의 LTTS 레이텐시보다 훨씬 더 높습니다.NLTTS에서 파일 액세스 지연을 개선하기 위해 가장 지연에 민감한 프로세스(특히 파일 서버)를 커널에 배치하도록 구현이 대폭 변경되었습니다.이 작업은 모든 NLTSS 서버가 멀티스레딩 모델에서 작동했기 때문에 처음에는 그다지 중요하지 않았습니다.이 변경은 파일 서버 서비스를 담당하는 스레드를 별도의 파일 서버 프로세스에서 커널 "프로세스"로 이동시키는 것이었습니다.사용자와의 통신은 변경되지 않았지만(아직 버퍼 테이블, LINCS 토큰 등을 통해), 파일 조작은 오래된 LTSS 및 경쟁사의 Cray Time Sharing System에 비해 지연 시간이 길어지는 주요 원인이었던 몇 가지 컨텍스트 변경을 피했습니다.이 변경으로 파일 I/O 작업의 지연 시간이 크게 향상되었지만(설계가 아닌 구현에 의해) 파일 서버가 커널의 신뢰할 수 있는 부분이 되었습니다.

데이터 실장 기능의 보안/통합성과 관련된 NLTSS의 두 번째 실장 문제.이 구현에서는 암호 기능 모델을 사용했습니다(예: [2]암호에 의한 제어 참조).이 모델을 사용하면 프로세스의 메모리 공간에 액세스할 수 있는 모든 사용자 또는 프로세스가 해당 메모리에서 발견된 데이터에 의해 나타나는 기능에 액세스할 수 있는 권한을 갖게 됩니다.일부 시스템 설계자(예: Andrew S) Amoeba distributed operating system의 설계자인 Tanenbaum은 기능에 대한 액세스를 암시하는 메모리에 대한 액세스의 속성이 본질적으로 문제가 아니라고 주장했습니다.NLTTS 환경에서는 분석을 위해 프로그램 메모리 덤프를 다른 사람에게 가져가는 경우가 종종 있었습니다.이러한 문제 및 기타 문제로 인해 이러한 비밀번호 기능은 NLTSS의 취약점으로 간주되었습니다.이 취약성에 대해 Control by Public Key Encryption[3] 메커니즘을 보호하기 위해 설계가 수행되었습니다.이 메커니즘은 상당한 성능 비용과 비밀번호 기능의 취약성을 사용자가 인식하지 못했기 때문에 NLTSS에서 운영 환경에 도입되지 않았습니다.암호학의 현대적 발전은 특히 인터넷/웹 기능(예[4]: YURL 또는 WideWORD [5]참조)에 대한 이러한 보호 기능을 실용화할 것입니다.

NLTSS의 설계상의 문제는 실가동 환경에서 제외된 지 몇 년이 지나서야 검토되었습니다.그것은 오픈 네트워크 아키텍처였습니다.NLTSS에서는 방화벽이나 기타 제한이 없는 네트워크에서는 프로세스가 가상 프로세서로 간주되었습니다.어떤 프로세스든 자유롭게 통신할 수 있습니다.즉, "벽방잉"과 같은 비밀 채널을 제한하는 것과 같은 직접적인 통신을 제한하는 의미에서도 구속을 할 수 없다는 것을 의미했다.이 문제를 해결하려면 NLTSS가 통신을 활성화하기 위한 기능을 필요로 합니다.「스트림 번호」등의 NLTTS의 개발은, 이러한 설비에 가까워지고 있었지만, 1988년에 액티브한 개발이 정지했을 무렵에는, NLTTS에서의 통신은 아직 확립되어 있지 않았다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Components of a Network Operating System". webstart.com.
  2. ^ "Managing Domains in a Network Operating System". webstart.com.
  3. ^ "Managing Domains in a Network Operating System". webstart.com.
  4. ^ "YURL". Waterken Inc.
  5. ^ "Home". wideword.net.

추가 정보

외부 링크