
나는 윈도우 시스템에 왜 서버가 있어야 하는지 전혀 이해하지 못했습니다. 데스크탑 환경, 디스플레이 관리자 및 창 관리자에 xorg-server가 필요한 이유는 무엇입니까? 그래픽 카드 위에 추상화 레이어만 두는 것일까요? 윈도우 시스템이 클라이언트-서버 모델을 사용하는 이유는 무엇입니까? 명명된 파이프를 통한 프로세스 간 통신이 더 간단하지 않나요?
답변1
나는 당신이 이미 일종의 "서버"가 필요하다는 것을 알아차렸다고 생각합니다. 각 클라이언트(데스크톱 환경, 창 관리자 또는 창 프로그램)는 다른 모든 클라이언트와 디스플레이를 공유해야 하며, 하드웨어의 세부 정보나 디스플레이를 사용하는 다른 사람을 알지 못해도 사물을 표시할 수 있어야 합니다. 따라서 X11 서버는 IPC 인터페이스를 제공함으로써 귀하가 언급한 추상화 및 공유 계층을 제공합니다.
X11은 아마도 명명된 파이프 위에서 실행되도록 만들어질 수 있지만 명명된 파이프가 할 수 없는 두 가지 큰 일이 있습니다.
- 명명된 파이프는 한 방향으로만 통신합니다.
- 두 프로세스가 명명된 파이프의 "전송" 끝에 데이터를 넣기 시작하면 데이터가 혼합됩니다.
실제로 대부분의 X 클라이언트는 UNIX 도메인 소켓이라는 "새롭고 향상된" 명명된 파이프를 사용하여 서버와 통신합니다. 프로세스가 양방향으로 통신할 수 있다는 점과 누가 무엇을 말했는지 추적한다는 점을 제외하면 명명된 파이프와 매우 유사합니다. 이는 네트워크가 수행해야 하는 것과 동일한 종류의 작업이므로 UNIX 도메인 소켓은 네트워크 통신을 제공하는 TCP/IP 소켓과 동일한 프로그래밍 인터페이스를 사용합니다.
하지만 여기서는 "클라이언트가 아닌 다른 호스트에서 서버를 실행하면 어떻게 되나요?"라고 말하기는 정말 쉽습니다. UNIX 소켓 대신 TCP 소켓을 사용하면 됩니다. Windows RDP보다 수십 년 앞서는 원격 데스크톱 프로토콜입니다. ssh
4개의 서로 다른 원격 호스트에 대해 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 프로토콜을 설계하는 과정에서 서버와 클라이언트 간의 기능 분할에 대해 많은 생각을 했습니다. 이는 요청, 응답 및 이벤트를 통해 어떤 정보를 주고 받아야 하는지 결정하기 때문입니다. 프로토콜 설계 시 특정 선택의 근거에 대한 정보의 훌륭한 소스는 컴퓨팅 기계 협회(Association of Computing Machinery) 저널 Transaction on Graphics, Vol 5, No.에 게재된 Robert W. Scheifler 및 Jim Gettys의 The X Window System 기사입니다. 1986년 4월 2일 최종적으로 내려진 결정은 클라이언트 프로그램의 이식성, 클라이언트 프로그래밍의 용이성 및 성능을 기반으로 이루어졌습니다.
첫째, 서버는 클라이언트 애플리케이션과 기본 하드웨어의 차이점을 최대한 숨기도록 설계되었습니다. ...
TOG의 기사를 흥미롭게 읽었던 것으로 기억합니다. 그것은 확실히 X에 대한 나의 관심을 촉발시켰고, O'Reilly가 X 시리즈 책을 출판하기 시작할 때까지 우리가 더 많은 정보를 손에 얹는 데 어려움을 겪었습니다.
¹ X 버전 11, 릴리스 4, 2-X페이지, 온라인에서 PDF 사용 가능여기
² 이것은 내가 1990년에 구입한 O'Reilly에서 출판한 2판 9페이지에 있는 것입니다. 최신판이 있지만 나는 이것을 구입하려고 애쓰지 않았으며 AFAIK는 종이로만 구할 수 있습니다. 나는 그들이 책임 분담의 근거를 바꾸었다고 생각하지 않습니다.
답변3
윈도우 시스템은 여러 개의 독립적인 프로그램이 공통 리소스, 화면 및 입력 장치를 공유하는 것을 의미합니다. 공유 리소스는 다음 두 가지 방법으로만 안전하게 구현할 수 있습니다.
- 리소스는 커널에 의해 제어될 수 있으며 응용 프로그램은 리소스에 액세스하기 위해 커널을 호출합니다.
- 리소스는 전용 프로세스(서버)에 의해 제어될 수 있으며 애플리케이션은 리소스에 액세스하기 위해 서버에 접속합니다.
물론 실제 디스플레이 하드웨어에 대한 액세스는 커널에 의해 제어되지만 윈도우 시스템에는 충분하지 않습니다. 프로세스에 특정 디스플레이를 할당할 수 있는 방법이 있어야 합니다.부분다른 프로세스가 방해하지 않는다고 합리적으로 확신할 수 있는 디스플레이(창)의 경우, 어떤 응용 프로그램이 언제 리소스의 어느 부분에 액세스할 수 있는지에 대한 특정 수준의 보호가 있어야 합니다.
이제 모든 것이 Windows가 수행하는 AFAIK인 커널에 들어갈 수 있습니다. 이는 속도가 더 빠르다는 장점이 있지만(일반적으로 커널을 호출하는 것이 다른 프로세스에 접속하는 것보다 훨씬 빠릅니다), 보안 허점이 생길 수 있다는 단점이 있습니다(시스템의 모든 악용은 커널 수준에서의 악용입니다). 시간은 이식성을 제한합니다(커널에 구현된 시스템은 커널과 강력하게 연결되어 있으므로 다른 운영 체제로 쉽게 이식할 수 없으며 커널 코드에 액세스할 수 없으면 완전히 이식할 수 없습니다).
커널에서 구현하고 싶지 않은 경우 구현하는 유일한 다른 방법은 전용 프로세스, 즉 서버로 구현하는 것입니다. 명명된 파이프를 통해 연결되는 서버는 여전히 서버입니다. 또한, 동일한 시스템에서 실행될 때 요즘에는 X 서버와 클라이언트 간의 많은 통신이 공유 메모리를 통해 이루어집니다. 그래도 디스플레이 서버가 서버라는 사실은 바뀌지 않습니다.
이제 명명된 파이프를 사용하지 않고 소켓을 사용하여 서버에 연결하는 이유는 무엇입니까? 글쎄, 소켓을 사용하여 수행하는 경우 모든 통신을 수행할 수 있는 전체 서버에 대해 하나의 소켓만 있으면 됩니다. 파이프로 통신하는 경우 클라이언트당 두 개의 파이프가 필요합니다. 모든 파이프를 관리하는 것이 매우 번거롭다는 사실 외에도, 충분히 많은 프로그램이 동시에 서버와 통신을 시도하는 경우 열려 있는 파이프 수에 대한 일부 운영 체제 제한에 도달할 수도 있습니다.
물론 파이프에 비해 소켓이 갖는 또 다른 장점은 소켓을 사용하면 여러 기계를 연결할 수 있다는 점입니다. 이는 전용 터미널에 앉아 있는 많은 사람들이 실제 컴퓨터를 공유하는 시대에 특히 중요했습니다. 따라서 컴퓨터의 프로그램은 서로 통신해야 했습니다. 하지만 오늘날에도 네트워크 환경에서 여전히 매우 유용합니다.
답변4
클라이언트-서버 모델은 서버와 클라이언트가 하나만 있는 경우에도 모든 종류의 애플리케이션에 널리 사용되는 디자인입니다. 책임 영역 간에 명확하고 잘 정의된 인터페이스를 허용합니다.
서버와 클라이언트가 통신할 수 있는 방법은 많지만 X
(다른 사람이 언급한 장점에 관계없이) 선택하는 방법은 불필요하지 않습니다.~할 수 있다다른 컴퓨터의 서버 에 연결 X
하고 데스크톱(또는 다른 협력 데스크톱)에서 창을 엽니다. 이것은 X가 개발되던 시절, 많은 대학과 기업이 Unix 서버와 이와 통신하는 많은 "X 터미널"을 보유하고 있던 시절에 매우 일반적이었습니다.인터넷에 준비된 통신 프로토콜을 사용함으로써 X는 호스트 내에서 또는 호스트 간에 원활하게 사용될 수 있습니다.
X는 단일 컴퓨터의 단일 사용자를 위한 OS가 아닌 다중 사용자 환경으로서의 UNIX의 역사와 일치하여 다른 컴퓨터의 창을 투명하게 표시할 수 있는 최초의 GUI 환경이었습니다. 컴퓨터와 (물리적으로 또는 원격으로) 상호 작용할 수 있는 유일한 사람이라면 많은 UNIX 기능이 과잉처럼 보입니다.