STREAMS

컴퓨터 망에서 STREAMS는 유닉스 시스템 V에서 문자 장치 드라이버, 네트워크 프로토콜, 프로세스 간 통신을 구현하기 위한 기본 프레임워크이다. 이 프레임워크에서 스트림은 프로그램과 장치 드라이버 사이(또는 프로그램 쌍 사이)에서 메시지 전달을 수행하는 코루틴의 체인이다. STREAMS는 리서치 유닉스 버전 8에서 스트림(Streams, 대문자 아님)으로 처음 시작되었다.

STREAMS의 설계는 커널과 장치 드라이버 사이에서 전이중 입출력을 구현하기 위한 모듈식 아키텍처이다. 가장 빈번하게 사용된 분야는 터미널 입출력(라인 디시플린) 및 네트워킹 서브시스템 개발이다. 시스템 V 릴리스 4에서는 전체 터미널 인터페이스가 STREAMS를 사용하여 재구현되었다. STREAMS의 중요한 개념은 드라이버 – 네트워크 인터페이스나 다른 장치의 기능을 수정할 수 있는 사용자 정의 코드 모듈 – 을 푸시(push)하여 함께 스택을 형성하는 기능이다. 이러한 드라이버 중 다수를 순서대로 연결할 수 있다.

역사

STREAMS는 데니스 리치가 8판 리서치 유닉스(V8)에서 도입한 스트림 입출력 서브시스템을 기반으로 하며, 터미널 입출력 서브시스템과 인터넷 프로토콜 스위트를 위해 사용되었다. 아직 대문자 STREAMS라고 불리지 않았던 이 버전은 기존의 장치 입출력 시스템 호출(open, close, read, write, ioctl) 하에서 새로운 기능을 맞추었으며, 그 응용 범위는 터미널 입출력과 파이프 형태의 입출력 의미론을 제공하는 프로토콜로 제한되었다.

이 입출력 시스템은 TCP, ISO 클래스 4 전송, SNA LU 6.2, AT&T NPACK 프로토콜(RFS에서 사용)을 포함한 다양한 전송 프로토콜을 지원하기 위한 더 넓은 프레임워크의 일환으로 로버트 이스라엘, 길 맥그래스, 데이브 올랜더, 허다우 체, 모리 바흐에 의해 시스템 V 릴리스 3로 포팅되었다. 이는 유닉스 시스템 V 릴리스 3의 네트워크 지원 유틸리티(NSU) 패키지와 함께 처음 출시되었다. 이 포팅을 통해 putmsg, getmsg, poll 시스템 호출이 추가되었으며, 이는 버클리 소켓의 send, recv, select 호출과 목적상 거의 동일하다. putmsg와 getmsg 시스템 호출은 원래 send와 recv라고 불렸으나, 네임스페이스 충돌을 피하기 위해 이름이 변경되었다. 시스템 V 릴리스 4에서 STREAMS는 터미널 입출력 프레임워크와 파이프를 위해 확장되어, 양방향 파이프 및 파일 서술자 전달과 같은 유용한 새 기능을 제공하였다. UNICOS를 위한 포팅도 이루어졌다. 에릭 레이먼드는 데니스 리치가 자신의 V8 스트림과 비교하여 시스템 V STREAMS의 복잡성에 대해 "스트림은 소리 질러 말할 때 다른 의미를 갖는다(Streams means something different when shouted)"라고 언급한 것을 인용하였다.

시스템 V 릴리스 3 포팅과 동시에, AT&T는 OSI 모형(2~4계층)의 링크 계층, 네트워크 계층, 그리고 전송 계층에 대한 프로토콜 독립적인 STREAMS 메시지 전달 가이드라인을 개발하였다. 특정 프로토콜 스택 내에서 네트워크 프로토콜과 전송 프로토콜의 긴밀한 구현 결합과, 커널 외부에서 5~7계층을 구현하는 일반적인 관행 때문에, X/Open은 나중에 링크 계층 및 전송 계층 STREAMS 서비스 인터페이스만을 표준화하였다. 전송 메시지 전달 모델과 함께, 응용 프로그램 개발을 위한 전송 프로토콜 독립적 API를 제공하기 위해 전송 계층 인터페이스(나중에 X/Open 전송 인터페이스로 채택됨)가 정의되었다. 또한, 세션 계층, 표현 계층, 응용 계층을 지원하는 라이브러리가 정의되었고 나중에 오픈 그룹에 의해 표준화되었다.

STREAMS는 단일 유닉스 규격 버전 1(UNIX 95) 및 2(UNIX 98) 준수에 필요했으나, BSD 및 리눅스 개발자들이 STREAMS 제공을 거부함에 따라 버전 3(UNIX 03)에서는 오스틴 그룹에 의해 POSIX 준수를 위한 선택 사항으로 표시되었다. TC1이 포함된 POSIX.1-2008(IEEE Std 1003.1, 2013년판)은 STREAMS를 '폐기 예정(marked obsolescent)'으로 지정했으며, 이는 해당 기능이 향후 규격 버전에서 제거될 수 있음을 의미한다. 그러나 사용된 '폐기 예정'의 구체적인 정의는 또한 엄격하게 POSIX를 준수하는 응용 프로그램은 '폐기 예정 기능을 사용해서는 안 된다'고 명시하고 있다.

기술적 개요

(Ritchie 1984)를 따라 원격 명령 실행을 구현하기 위해 스트림을 사용하는 예시

버전 7 유닉스에서 명령은 라인 디시플린(line discipline)이라는 메커니즘을 통해 터미널(키보드와 화면, 또는 전신타자기)에 연결되었으며, 이는 입력을 처리하기 위해 프로그램에 보내기 전에 사용자가 Return 키를 누를 때까지 기다리는, 즉 한 줄의 입력을 버퍼링하는 방식이었다. 이는 간단한 오류 수정을 가능하게 했다. 스트림은 이를 인접한 모듈 간의 양방향 통신을 허용하는 선형 체인으로 조직된 처리 모듈 세트로 대체하였다. 프로그램은 터미널이나 다른 문자 장치의 동작을 변경하기 위해 체인의 한쪽 끝에 새로운 모듈을 "푸시(push)"할 수 있었다. 리치는 네트워크를 통한 원격 로그인을 달성하기 위해 터미널 모듈을 데이터킷 네트워크 모듈과 연결한 체인 예시를 제시하였다. 프로그램에서 장치로, 또는 그 반대로 이동하는 문자(바이트) 외에도 스트림은 "끊기(hangup)"(연결 끊기) 및 Ioctl 메시지와 같은 제어 메시지를 전달할 수 있었다.

스트림은 또한 프로세스 간 통신을 위해 두 프로세스를 의사 터미널에 연결하는 데 사용될 수 있었다. 이 기능은 여러 단말 에뮬레이터 창을 표시할 수 있는 Blit 그래픽 터미널용 mpx 윈도우 시스템에서 구현되었다. 각 창은 라인 디시플린 드라이버가 설치된 의사 터미널을 통해 윈도우 시스템과 통신하는 프로세스였으며, 입력한 문자를 보내고 표시할 텍스트(및 그래픽)를 수신하였다. 제어 신호는 창 간 전환 또는 창 닫기에 대한 사용자의 의도를 지정하였다.: 348–350 

실제 스트림 모듈은 유닉스의 사용자 공간 및 커널 공간에 존재하며, ioctl 시스템 호출에 의해 설치(푸시)되거나 제거(팝)된다. 예를 들어, 터미널 장치를 참조하는 파일 서술자 fd에 앞서 언급한 라인 디시플린을 설치하려면 C 언어로 다음과 같이 작성한다:: 347 

ioctl(fd, PUSH, TTYLD);

스트림에서 입출력을 수행하려면 일반 파일 서술자와 마찬가지로 read 및 write 시스템 호출을 사용하거나, 제어 메시지를 보내기 위한 일련의 STREAMS 전용 함수를 사용한다.

리치는 프로세스 대신 커널 내에 스트림을 구현해야 했던 것을 후회한다고 인정했지만, 효율성 이유로 그렇게 할 수밖에 없었다고 느꼈다. 이후의 플랜 9 구현에서는 모듈을 사용자 수준 프로세스로 구현하였다.

구현

STREAMS는 주로 시스템 V 유닉스 환경에서 사용되었으나, 다른 구현도 존재한다:

리눅스 커널은 타사 추가 기능 없이는 STREAMS 기능을 포함하지 않는다. 칼데라는 자사의 리눅스용 넷웨어를 지원하기 위해 1998년경 STREAMS를 리눅스에 포함시키려 "푸시"했으나, 기술적 근거(주로 성능)로 인해 리눅스 커널 개발자들에 의해 단호히 거부되었다. 다른 운영체제용 리눅스 호환성 계층은 STREAMS 작업을 가능한 한 빨리 소켓으로 변환한다. 칼데라가 사용한 구현은 GCOM이라는 회사의 "LiS"였으며, 이는 나중에 칼데라의 후계자인 SCO 그룹이 리눅스를 상대로 벌인 법적 분쟁에서 핵심이 되었고, SCO는 STREAMS가 포함된 리눅스가 자신들의 유닉스 시스템 V 저작권을 침해했다고 주장하였다.

내용주

  1. ↑ (Goodheart 1994, 51–53, 403–527쪽)
  2. ↑ (Goodheart 1994, 52–53쪽)
  3. 1 2 (Goodheart 1994, 17쪽)
  4. ↑ (Goodheart 1994, 51쪽)
  5. 1 2 3 (Ritchie 1984)
  6. ↑ (Goodheart 1994)
  7. ↑ Eric S. Raymond (2003). 〈Chapter 7. Multiprogramming〉. 《The Art of Unix Programming》. Addison-Wesley.
  8. 1 2 3 (DLPI & 2.0.0)
  9. ↑ (NPI & 2.0.0)
  10. ↑ (TPI & 1.5)
  11. ↑ (TPI & 2.0.0)
  12. ↑ (APLI 1990)
  13. ↑ (XAP 1993)
  14. ↑ “Base Specifications, Issue 7, 2013 Edition, Section B.2.6 STREAMS”. The Open Group. 2015년 3월 9일에 확인함.
  15. ↑ “The Austin Common Standards Revision Group”. The Open Group. 2015년 3월 9일에 확인함.
  16. ↑ “The Open Group Base Specifications Issue 7, Codes”. The Open Group. 2015년 3월 9일에 확인함.
  17. ↑ Pike, Rob (1984). “The Blit: A Multiplexed Graphics Terminal”. 《AT&T Bell Laboratories Technical Journal》 63 (8): 1607–1631. doi:10.1002/j.1538-7305.1984.tb00056.x. S2CID 34062559.
  18. 1 2 Bach, Maurice J. (1986). 《The Design of the UNIX Operating System》. Prentice Hall. Bibcode:1986duos.book.....B. ISBN 9780132017992.
  19. ↑ 참조: putmsg, 및 getmsg.
  20. 1 2 Presotto, David L. (1990). 《Multiprocessor streams for Plan 9》. Proc. UKUUG Summer Conf. CiteSeerX 10.1.1.42.1172.
  21. ↑ Newton, Mark. “FreeBSD SysVR4 Emulation”. 《Mark Newton's FreeBSD pages》.
  22. ↑ (Barr 2001)
  23. ↑ (Valentine 2001)
  24. ↑ “Alpha Micro Phun Machine: Primer to AMOS”. 2022년 3월 5일에 확인함.
  25. 1 2 “STREAMS, LiS, and Caldera's Netware for Linux - Updated”. 《Groklaw》. 2006년 7월 3일. 2010년 5월 5일에 원본 문서에서 보존된 문서. 2022년 7월 14일에 확인함.
  26. ↑ Alan Cox, Streams and Linux, Linux Kernel Mailing List, 28 June 1998

참고 문헌

각주

외부 링크