X Window System이 서버를 사용하는 이유는 무엇입니까?

나는 왜 윈도우 시스템에 서버가 있어야하는지 이해하지 못했습니다. 데스크탑 환경, 디스플레이 관리자 및 창 관리자에 xorg-server가 필요한 이유는 무엇입니까? 그래픽 카드 위에 추상화 레이어 만있는 것입니까? 윈도우 시스템이 클라이언트-서버 모델을 사용하는 이유는 무엇입니까? 명명 된 파이프를 통한 프로세스 간 통신이 더 간단하지 않습니까?

"서버"가 필요하다는 것을 이미 알고 계신 것 같습니다. 각 클라이언트 (데스크톱 환경, 창 관리자 또는 창 프로그램)는 다른 모든 장치와 디스플레이를 공유해야하며 하드웨어의 세부 사항을 알지 못하거나 다른 사용자가 디스플레이를 사용 중인지 알 필요없이 항목을 표시 할 수 있어야합니다. 따라서 X11 서버는 IPC 인터페이스를 제공하여 언급 한 추상화 및 공유 계층을 제공합니다.

X11은 명명 된 파이프를 통해 실행되도록 만들 수 있지만 명명 된 파이프로는 할 수없는 두 가지 큰 일이 있습니다.

• 명명 된 파이프는 한 방향으로 만 통신합니다.
• 두 프로세스가 명명 된 파이프의 "송신"끝에 데이터를 넣기 시작하면 데이터가 혼합됩니다.

실제로 대부분의 X 클라이언트는 UNIX 도메인 소켓이라는 "새롭고 개선 된"파이프를 사용하여 서버와 통신합니다. 프로세스가 양방향으로 대화하고 누가 무엇을 말했는지 추적한다는 점을 제외하면 명명 된 파이프와 매우 비슷합니다. 이것들은 네트워크와 같은 종류의 작업이므로 UNIX 도메인 소켓은 네트워크 통신을 제공하는 TCP / IP 소켓과 동일한 프로그래밍 인터페이스를 사용합니다.

그러나 거기에서 "클라이언트가 아닌 다른 호스트에서 서버를 실행하면 어떻게됩니까?"라고 말하기가 정말 쉽습니다. UNIX 소켓 대신 TCP 소켓과 voila : Windows RDP보다 수십 년 전의 원격 데스크톱 프로토콜 만 사용하십시오. 내가 할 수있는 ssh네 가지 원격 호스트 및 실행하려면 synaptic그들 각각에 (그래픽 패키지 관리자) 및 네 개의 창 내 로컬 컴퓨터의 디스플레이에 나타납니다.

윈도우 시스템에는 서버가 필요하지 않지만 클라이언트 서버 모델을 기반으로 윈도우 시스템을 구현하도록 결정할 수 있습니다. 이렇게하면 클라이언트와 서버의 활동을 명확하게 분리 할 수 ​​있으므로 몇 가지 장점이 있으며 동일한 시스템에서 실행할 필요가 없으며 여러 클라이언트를보다 쉽게 ​​서비스 할 수 있습니다. 그것은 여전히 ​​매우 편리하지만 (예를 ssh들어 다른 컴퓨터에 넣을 때 ) X가 개발 될 때 필요하다고 여겨지는 로컬 컴퓨터가 클라이언트를 실행하기에 충분히 강력하지 않을 수 있음을 알아야합니다.

명명 된 파이프는 TCP 구현처럼 네트워크를 통해 실행할 수 있다는 자동 이점을 제공하지 않습니다. 그러나 DosExtender가 Desqview / X (1992)를 실행하는 DOS에서는 명명 된 파이프를 사용할 수 없었으며 AFAIK도 VMS에는 없습니다. 이러한 구현에서 유닉스 고유의 통신은 문제가 될 것입니다.

TCP는 Unix 전용이 아니며 VAX / VMS에서 클라이언트를 실행하고 (1984 년 X 개발 시작) 로컬 UNIX 기반 그래픽 워크 스테이션에 출력을 제공 할 수 있습니다. "X Window 시스템 : Xlib, X 프로토콜, ICCCM, XLFD에 대한 완전한 참조"¹에서 :

1986 년 가을, Digital은 ULTRIX, VMS 및 MS-DOS에 대한 전체 데스크톱 워크 스테이션 전략을 X에 기반으로 결정했습니다. 이로 인해 약간의 지연이 발생했지만 결국에는 더 나은 디자인으로 이어졌습니다. Ralph Swick of Digital은이 기간 동안 Project Athena에 합류했으며 버전 11의 개발은 아니지만 중요한 역할을 수행했습니다. 마지막 버전 10 릴리스는 1986 년 12 월에 제공되었습니다.

"X 프로토콜 참조 매뉴얼"²에서 :

책임 분담

X 프로토콜을 설계하는 과정에서 서버와 클라이언트 간의 기능 분할에 대한 많은 생각이 있었으며, 이는 요청, 응답 및 이벤트를 통해 어떤 정보를 앞뒤로 전달해야하는지 결정합니다. 프로토콜 설계에서 선택한 특정 선택의 근거에 대한 훌륭한 정보 소스는 Robert W. Scheifler와 Jim Gettys의 The X Window System 기사, Association of Computing Machinery 저널, Transaction on Graphics, Vol 5, No. 1986 년 4 월 2 일 궁극적으로 도달 한 결정은 클라이언트 프로그램의 이식성, 클라이언트 프로그래밍의 용이성 및 성능에 따라 결정되었습니다.

첫째, 서버는 클라이언트 응용 프로그램에서 기본 하드웨어의 차이점을 숨기도록 가능한 한 많이 설계되었습니다. ...

나는 TOG의 기사가 흥미로운 기사임을 기억합니다. 그것은 X에 대한 관심을 불러 일으켰으며 (이것은 WorldWideWeb 이전이었습니다) O'Reilly가 X 시리즈 책을 출판하기 시작할 때까지 더 많은 정보를 얻는 데 어려움을 겪었습니다.

¹ _{X 버전 11, 릴리스 4, 2-X, PDF ( 여기에서 온라인으로 제공)}
² _{이 문서는 1990 년에 구입 한 O'Reilly가 발행 한 2 판 9 페이지에서 발췌 한 것입니다. 이것들과 AFAIK는 종이로만 제공됩니다. 나는 그들이 책임 분담의 근거를 바꾸지 않았다고 생각합니다.}

윈도우 시스템은 여러 개의 독립적 인 프로그램이 공통 자원, 화면 및 입력 장치를 공유 함을 의미합니다. 공유 리소스는 다음 두 가지 방법으로 만 안전하게 구현할 수 있습니다.

• 리소스는 커널에 의해 제어 될 수 있으며 응용 프로그램은 커널 호출을 통해 액세스합니다.
• 리소스는 전용 프로세스 (서버)에 의해 제어 될 수 있으며 응용 프로그램은 서버에 접속하여 액세스합니다.

물론 실제 디스플레이 하드웨어에 대한 액세스는 커널에 의해 제어되지만 윈도우 시스템에는 충분하지 않습니다. 프로세스가 디스플레이 의 특정 부분 (윈도우)을 합리적으로 할당 할 수있는 방법이 있어야합니다. 다른 프로세스가 방해하지 않도록하고, 어떤 애플리케이션이 어떤 시점에 리소스의 어느 부분에 액세스 할 수 있는지에 대한 특정 수준의 보호가 있어야합니다.

이제 모든 것이 커널에 들어갈 수 있었는데, 이는 Windows가하는 AFAIK입니다. 이것은 더 빠르다는 장점이 있지만 (보통 커널을 호출하는 것이 다른 프로세스에 접촉하는 것보다 훨씬 빠르지 만) 보안 허점을 열 수 있다는 단점이 있습니다 (시스템의 악용은 커널 수준에서의 악용 임). 시간은 이식성을 제한합니다 (커널에 구현 된 시스템은 커널에 강력하게 연결되어 있으므로 다른 운영 체제로 쉽게 이식 할 수 없으며 커널 코드에 액세스 할 수없는 경우 완전히 수행 할 수 없습니다).

커널에서 커널을 구현하지 않으려는 경우이를 구현하는 유일한 다른 방법은 전용 프로세스, 즉 서버입니다. 명명 된 파이프를 통해 연결된 서버는 여전히 서버입니다. 또한 같은 컴퓨터에서 실행될 때 요즘 X 서버와 클라이언트 간의 많은 통신은 공유 메모리를 통해 이루어집니다. 여전히 디스플레이 서버가 서버라는 사실을 변경하지는 않습니다.

이제 서버가 소켓을 사용하여 연결되고 명명 된 파이프를 사용하지 않는 이유는 무엇입니까? 소켓을 사용하여 전체 서버에 대해 하나의 소켓 만 있으면 모든 통신을 수행 할 수 있습니다. 파이프와 통신하는 경우 클라이언트 당 두 개의 파이프가 필요합니다. 이러한 모든 파이프를 관리하는 것이 상당히 번거 롭다는 사실 외에도, 충분한 수의 프로그램이 동시에 서버와 통신하려고 시도하는 경우 열린 파이프 수에 대한 일부 운영 체제 제한에 도달 할 수 있습니다.

물론 파이프보다 소켓의 또 다른 장점은 소켓을 사용하여 여러 기계를 연결할 수 있다는 것인데, 이는 전용 터미널에 앉아 많은 사람들이 실제 컴퓨터를 공유 할 때 특히 중요했기 때문에 컴퓨터의 프로그램이 통신해야했습니다. 다른 터미널에도 적용되지만 오늘날에도 네트워크 환경에서 매우 유용합니다.

X는 원래 MIT에서 개발하고 유지 관리했으며 오픈 소스 MIT 라이센스가 있었지만 실제로는 중요하지 않습니다.

언약적인 것으로 여겨지지만 잠시 생각해보십시오. 소프트웨어에서 클라이언트-서버 패러다임을 사용하는 선택을 어떻게 설명 할 것인가? 그리고 아마도 나는 CEO에게 말해야한다 ..

대학에서의 선택에 감사하는 방법을 소개합니다. 클라이언트 - 서버, 서버는 자원을 관리하고, 특히 , 어떤 자원이 있어야 할 공유 . 따라서 X 서버는 클라이언트 앱, 키보드, 마우스 및 프레임 버퍼 (또는 시스템의 화면에 쓰는)에 제공하는 프로세스입니다 .

실제로 정확하지는 않지만 창 관리자는 종종 다음과 같이 설명됩니다. 간단하게, 그 일, 핸들 및 기타 장식을 앱의 프레임과 창, 대화 상자 등에 넣는 것입니다.

클라이언트 서버 모델은 하나의 서버와 하나의 클라이언트 만있는 경우에도 모든 종류의 응용 프로그램에 널리 사용되는 디자인입니다. 책임 영역간에 깨끗하고 명확한 인터페이스를 제공합니다.

서버와 클라이언트가 통신 할 수있는 많은 방법이 있지만, 선택은에 의해 X(에 관계없이 다른 사람에 의해 언급 한 장점이) 불필요한되지 않습니다 : 당신은 할 수 에 연결하는 X또 다른 협력을 바탕 화면에 다른 시스템과 열려있는 창에 서버 (또는에 데스크톱). 이것은 X가 개발 된 시절, 많은 대학과 기업이 Unix 서버와 많은 "X 터미널"을 가지고있을 때 매우 흔했습니다. 인터넷 지원 통신 프로토콜을 사용하면 X를 호스트 내에서 또는 호스트간에 원활하게 사용할 수 있습니다.

X는 단일 컴퓨터의 단일 사용자 용 OS가 아닌 다중 사용자 환경으로서의 UNIX 기록과 일치하여 다른 컴퓨터의 창을 투명하게 표시 할 수있는 최초의 GUI 환경이었습니다. 컴퓨터와 (물리적 또는 원격으로) 상호 작용할 수있는 유일한 사람이라면 많은 UNIX 기능이 과도하게 보입니다.

처음에는 컴퓨팅 리소스가 부족하고 메인 프레임이 대부분의 작업을 수행했기 때문에 x 서버는 클라이언트 서버 아키텍처로 설계되었다고 생각합니다. X- 터미널은 x- 서버에 연결되어 사용자에게 표시해야하는 모든 것을 표시하는 씬 클라이언트입니다.

X의 통신 프로토콜은 현재 매우 무겁지만 많은 이점이 있습니다. 특히 여러 클라이언트에서 동일한 디스플레이를 표시 할 수 있으며 X에서 여러 사용자와 화면을 공유하는 것이 쉽습니다.