나는 윈도우 시스템에 왜 서버가 있어야 하는지 전혀 이해하지 못했습니다. 데스크탑 환경, 디스플레이 관리자 및 창 관리자에 xorg-server가 필요한 이유는 무엇입니까? 그래픽 카드 위에 추상화 레이어만 있는 걸까요? 윈도우 시스템이 클라이언트-서버 모델을 사용하는 이유는 무엇입니까? 명명된 파이프를 통해 프로세스 간 통신을 수행하는 것이 더 간단하지 않습니까?
답변1
나는 당신이 일종의 "서버"가 필요하다는 것을 알아차렸다고 생각합니다. 각 클라이언트(데스크톱 환경, 창 관리자 또는 창 프로그램)는 다른 모든 클라이언트와 디스플레이를 공유해야 하며 하드웨어 세부 정보나 디스플레이를 사용하는 다른 사람을 알지 못해도 콘텐츠를 표시할 수 있어야 합니다. 따라서 X11 서버는 IPC 인터페이스를 제공하여 언급한 추상화 및 공유 계층을 제공합니다.
X11은 명명된 파이프에서 실행될 수 있지만 명명된 파이프가 수행할 수 없는 두 가지 큰 작업이 있습니다.
- 명명된 파이프는 한 방향으로만 통신합니다.
- 두 프로세스가 명명된 파이프의 "전송" 끝에 데이터를 넣기 시작하면 데이터가 함께 혼합됩니다.
실제로 대부분의 X 클라이언트는 UNIX 도메인 소켓이라는 "새롭고 향상된" 명명된 파이프를 사용하여 서버와 통신합니다. 이는 프로세스가 양방향으로 통신하고 누가 무엇을 말했는지 추적할 수 있다는 점을 제외하면 명명된 파이프와 매우 유사합니다. 이는 네트워킹이 수행해야 하는 모든 작업이므로 UNIX 도메인 소켓은 네트워크 통신을 제공하는 TCP/IP 소켓과 동일한 프로그래밍 인터페이스를 사용합니다.
하지만 여기서는 "클라이언트가 아닌 다른 호스트에서 서버를 실행하면 어떻게 되나요?"라고 말하기 쉽습니다. UNIX 소켓 대신 TCP 소켓을 사용하면 됩니다. 짜잔, 이것은 Windows RDP보다 몇 년이나 앞선 방법입니다. 원격 데스크톱 프로토콜. ssh4개의 서로 다른 원격 호스트에 연결하고 각 호스트에서 (그래픽 패키지 관리자)를 실행할 수 synaptic있으며 4개의 창이 모두 내 로컬 컴퓨터의 디스플레이에 표시됩니다.
답변2
윈도우 시스템에는 서버가 필요하지 않지만 클라이언트-서버 모델을 기반으로 윈도우 시스템을 구현하도록 결정할 수 있습니다. 이렇게 하면 여러 가지 이점이 있습니다. 클라이언트와 서버의 활동을 명확하게 분리할 수 있고 동일한 시스템에서 실행할 필요가 없으며 여러 클라이언트에 서비스를 제공하는 것이 더 쉽습니다. 이는 현재로서는 매우 편리하지만(예: ssh다른 컴퓨터에 들어갈 때) X를 개발할 때 이것이 필수 사항으로 간주된다는 점을 알아야 합니다. 로컬 컴퓨터가 클라이언트를 실행할 만큼 강력하지 않을 수 있습니다.
명명된 파이프는 TCP 구현처럼 네트워크에서 실행될 수 있다는 이점을 자동으로 제공하지 않습니다. 그러나 명명된 파이프는 DOS에서 사용할 수 없으며 DosExtender는 Desqview/X(1992)를 실행하고 AFAIK는 VMS에서도 사용할 수 없습니다. 이러한 구현에서는 Unix 관련 통신이 문제가 됩니다.
TCP는 Unix에만 국한되지 않으며 클라이언트가 VAX/VMS(X 개발은 1984년에 시작됨)에서 실행되고 기본 UNIX 기반 그래픽 워크스테이션에 출력을 제공할 수 있도록 해줍니다. "X 윈도우 시스템: Xlib, X 프로토콜, ICCCM, XLFD에 대한 완전한 참조" 1에서:
1986년 가을, Digital은 ULTRIX, VMS 및 MS-DOS에 대한 전체 데스크탑 워크스테이션 전략을 X에 기반을 두기로 결정했습니다. 이는 우리에게 위안이 되기도 하지만, 대화할 사람이 더 많아진다는 뜻이기도 합니다. 이로 인해 약간의 지연이 발생했지만 궁극적으로는 더 나은 디자인으로 이어졌습니다. Digital의 Ralph Swick은 이 기간 동안 Project Athena에 참여하여 버전 11 개발에 중요한 역할을 했습니다. 마지막 버전인 버전 10은 1986년 12월에 출시되었습니다.
"X 프로토콜 참조 매뉴얼"²에서:
책임의 분할
X 프로토콜을 설계할 때 우리는 요청, 응답 및 이벤트를 통해 어떤 정보가 앞뒤로 전달되어야 하는지를 결정하는 서버와 클라이언트 간의 기능 분할에 대해 많은 생각을 했습니다. 디자인 프로토콜의 특정 선택 뒤에 있는 이론적 근거에 대한 훌륭한 정보 소스는 Transaction on Graphics, Issue 5 Volume, Issue 10에 게재된 Robert W. Scheifler와 Jim Gettys의 "The X Window System" 기사입니다. 1986년 4월 2일에 내려진 최종 결정은 클라이언트 프로그램의 이식성, 클라이언트 프로그래밍의 용이성 및 성능을 기반으로 이루어졌습니다.
첫째, 서버는 클라이언트 응용 프로그램과의 기본 하드웨어 차이점을 최대한 숨기도록 설계되었습니다. ...
TOG에 관한 기사가 흥미로웠던 기억이 납니다. 그것은 X에 대한 나의 관심을 촉발시켰고(이것은 World Wide Web 이전이었습니다) O'Reilly가 X 시리즈 책을 출판하기 시작할 때까지 훨씬 더 많은 정보를 얻는 것이 어려웠습니다.
¹ X 버전 11, 4판, 2-X페이지, PDF 온라인 이용 가능여기
²이것은 내가 1990년에 구입한 O'Reilly에서 발행한 두 번째 판의 9페이지입니다. 최신 버전이 있지만 저는 굳이 이것을 구입한 적이 없으며, 제가 아는 한 이 버전은 하드 카피로만 구할 수 있습니다. 나는 그들이 책임 분담의 근거를 바꾸었다고 생각하지 않습니다.
답변3
윈도우 시스템은 여러 개의 독립적인 프로그램이 공통 리소스, 화면 및 입력 장치를 공유하는 것을 의미합니다. 리소스 공유는 다음 두 가지 방법으로만 안전하게 수행할 수 있습니다.
- 리소스는 커널에 의해 제어될 수 있으며 애플리케이션은 커널을 호출하여 리소스에 액세스할 수 있습니다.
- 리소스는 전용 프로세스(서버)에 의해 제어될 수 있으며, 애플리케이션은 리소스에 액세스하기 위해 서버에 접속합니다.
물론 실제 디스플레이 하드웨어에 대한 접근은 커널에 의해 제어되지만 윈도우 시스템에서는 이것만으로는 충분하지 않습니다.부분다른 프로세스가 디스플레이(창)를 방해하지 않을 것이라는 점은 합리적으로 확신할 수 있으며, 어떤 애플리케이션이 언제 리소스의 어떤 부분에 액세스할 수 있는지에 대해 어느 정도의 보호가 제공되어야 합니다.
이제 모든 것이 커널로 들어갈 수 있습니다. 제가 아는 한 Windows에서는 이러한 작업을 수행합니다. 이것의 장점은 더 빠르다는 것입니다(보통 커널을 호출하는 것이 다른 프로세스에 접속하는 것보다 훨씬 빠릅니다). 그러나 보안 허점을 열 수 있다는 단점이 있습니다(시스템의 모든 허점은 커널 수준 허점입니다). 한계는 이식성입니다(커널에 구현된 시스템은 커널과 강력하게 결합되어 있으므로 커널 코드에 액세스할 수 없으면 전혀 다른 운영 체제로 쉽게 이식할 수 없습니다).
커널에서 구현하고 싶지 않다면 이를 구현하는 유일한 다른 방법은 전용 프로세스, 즉 서버로 구현하는 것입니다. 명명된 파이프를 통해 연결된 서버는 여전히 서버입니다. 또한 동일한 시스템에서 실행될 때 X 서버와 클라이언트 간의 통신 대부분은 이제 공유 메모리를 통해 이루어지지만 디스플레이 서버가 서버라는 사실은 여전히 바뀌지 않습니다.
이제 서버에 연결하기 위해 명명된 파이프 대신 소켓을 사용하는 이유는 무엇입니까? 글쎄, 이 작업을 수행하기 위해 소켓을 사용하는 경우 모든 통신을 위해 전체 서버에 단일 소켓만 제공하면 됩니다. 통신에 파이프를 사용하는 경우 클라이언트당 두 개의 파이프가 필요합니다. 이러한 모든 파이프를 관리하는 번거로움 외에도 충분한 프로그램이 동시에 서버와 통신을 시도하는 경우 열려 있는 파이프 수에 대한 운영 체제 제한이 발생할 수도 있습니다.
물론, 파이프에 비해 소켓이 갖는 또 다른 장점은 소켓을 사용하면 여러 기계에 걸쳐 연결이 가능하다는 점입니다. 이는 전용 터미널에 앉아 있는 많은 사람들이 실제 컴퓨터를 공유하는 시대에 특히 중요했습니다. 하지만 오늘날의 네트워크 환경에서도 여전히 매우 유용합니다.
답변4
클라이언트-서버 모델은 서버와 클라이언트가 하나만 있는 경우에도 다양한 애플리케이션에 널리 사용되는 디자인입니다. 책임 영역 간에 명확하고 잘 정의된 인터페이스를 허용합니다.
X서버와 클라이언트는 다양한 방법으로 통신할 수 있지만 (다른 사람들이 언급한 이점에 관계없이) 선택한 사항은 중복되지 않습니다.할 수 있는다른 컴퓨터의 서버 에 연결 X하고 데스크탑(또는 다른 협업 데스크탑)에서 창을 엽니다. 이는 많은 대학과 기업이 Unix 서버와 통신할 수 있는 많은 "X 터미널"을 보유하고 있던 X 개발 시대에 매우 일반적이었습니다.인터넷에 준비된 통신 프로토콜을 사용함으로써 X는 호스트 내에서 또는 호스트 간에 원활하게 사용될 수 있습니다.
X는 단일 컴퓨터의 단일 사용자 운영 체제가 아닌 다중 사용자 환경으로서의 UNIX의 역사와 일치하여 다른 컴퓨터의 창을 투명하게 표시할 수 있는 최초의 GUI 환경이었습니다. 컴퓨터와 물리적으로 또는 원격으로 상호 작용할 수 있는 유일한 사람이라면 많은 UNIX 기능이 과도해 보일 수 있습니다.