상위 질문
타임라인
채팅
관점
X 윈도 시스템 프로토콜 및 아키텍처
위키백과, 무료 백과사전
Remove ads
컴퓨팅에서 X 윈도 시스템(일반적으로 X11 또는 X)은 비트맵 디스플레이를 위한 네트워크 투명 윈도 시스템이다. 이 문서는 X11의 프로토콜 및 기술 구조를 자세히 설명한다.
클라이언트-서버 모델 및 네트워크 투명성
X는 클라이언트-서버 모델을 사용한다. X 서버 프로그램은 그래픽 디스플레이가 있는 컴퓨터에서 실행되며 다양한 클라이언트 프로그램과 통신한다. X 서버는 사용자와 클라이언트 프로그램 간의 중개자 역할을 하며, 클라이언트 프로그램으로부터 그래픽 출력(창)에 대한 TCP 포트 6000과 디스플레이 번호[1]에 대한 요청을 받아 사용자에게 표시하고(디스플레이), 사용자 입력(키보드, 마우스)을 수신하여 클라이언트 프로그램에 전송한다.
X에서 서버는 사용자 컴퓨터에서 실행되는 반면, 클라이언트는 원격 컴퓨터에서 실행될 수 있다. 이 용어는 클라이언트가 일반적으로 사용자 로컬 컴퓨터에서 실행되고 서버가 원격 컴퓨터에서 실행되는 클라이언트-서버 시스템의 일반적인 개념을 뒤집는다. X 윈도 용어는 X 윈도 프로그램이 모든 활동의 중심에 있다는 관점을 취한다. 즉, X 윈도 프로그램은 애플리케이션과 사용자의 마우스 및 키보드 입력으로부터 요청을 수락하고 응답한다. 따라서 (원격 컴퓨터의) 애플리케이션은 X 윈도 서버 프로그램의 클라이언트로 간주된다.
서버와 클라이언트 간의 통신 프로토콜은 네트워크 투명하게 실행된다. 클라이언트와 서버는 동일한 컴퓨터에서 실행될 수도 있고 다른 컴퓨터에서 실행될 수도 있으며, 경우에 따라 다른 컴퓨터 구조와 운영체제를 가질 수도 있다. 클라이언트와 서버는 암호화된 연결을 통해 연결을 터널링하여 인터넷을 통해 안전하게 통신할 수 있다.[2]
Remove ads
설계 원칙
밥 샤이플러와 짐 게티스는 X의 초기 원칙을 다음과 같이 제시했다 (Scheifler/Gettys 1996에 나열됨):
- 구현자가 실제 애플리케이션을 완성할 수 없다면 새로운 기능을 추가하지 마라.
- 시스템이 무엇이 아닌지를 결정하는 것이 무엇인지를 결정하는 것만큼 중요하다. 세상의 모든 요구를 충족시키려 하지 마라. 대신 시스템을 확장 가능하게 만들어 추가적인 요구를 상위 호환 방식으로 충족시킬 수 있도록 하라.
- 하나의 예시로부터 일반화하는 것보다 더 나쁜 것은 예시가 전혀 없는 상태에서 일반화하는 것이다.
- 문제가 완전히 이해되지 않았다면, 해결책을 전혀 제공하지 않는 것이 아마도 최선일 것이다.
- 작업량의 10%로 원하는 효과의 90%를 얻을 수 있다면, 더 간단한 해결책을 사용하라. (또한 Worse is better 참조.)
- 복잡성을 가능한 한 많이 격리하라.
- 정책보다는 메커니즘을 제공하라. 특히 사용자 인터페이스 정책은 클라이언트의 손에 맡겨라.
첫 번째 원칙은 X11 설계 과정에서 "실제 애플리케이션에서 필요로 하는 새로운 기능이 아니면 추가하지 마라"로 수정되었다.
X는 이후로 이러한 원칙을 대체로 지켜왔다. X.Org 재단은 구현의 확장 및 개선을 목표로 참조 구현을 개발하며, 1987년 원본 프로토콜과 거의 완벽하게 호환되도록 유지한다.
Remove ads
코어 프로토콜
요약
관점
이 부분의 본문은 X 윈도 시스템 코어 프로토콜입니다.서버와 클라이언트 간의 통신은 네트워크 채널을 통해 패킷을 교환함으로써 이루어진다. 클라이언트가 연결을 설정하고 첫 번째 패킷을 보낸다. 서버는 연결 수락 또는 거부를 알리거나 추가 인증 요청을 포함한 패킷을 다시 보내 응답한다. 연결이 수락되면 수락 패킷에는 클라이언트가 서버와의 후속 상호 작용에 사용할 데이터가 포함된다.
연결이 설정된 후, 클라이언트와 서버는 채널을 통해 다음 네 가지 유형의 패킷을 교환한다:
- 요청: 클라이언트가 서버로부터 정보를 요청하거나 특정 작업을 수행하도록 요청한다.
- 응답: 서버가 요청에 응답한다. 모든 요청이 응답을 생성하는 것은 아니다.
- 이벤트: 서버가 클라이언트에게 이벤트를 보낸다. 예를 들어 키보드 또는 마우스 입력, 창 이동, 크기 조정 또는 노출 등이 있다.
- 오류: 요청이 유효하지 않으면 서버가 오류 패킷을 보낸다. 요청은 대기열에 들어가므로, 요청에 의해 생성된 오류 패킷이 즉시 전송되지 않을 수 있다.
X 서버는 기본 서비스 세트를 제공한다. 클라이언트 프로그램은 서버와 상호 작용하여 더 복잡한 기능을 구현한다.
창
다른 그래픽 사용자 인터페이스에서 일반적으로 창이라고 부르는 것은 X 윈도 시스템에서는 최상위 창이다. 창이라는 용어는 다른 창 안에 있는 창, 즉 부모 창의 하위 창에도 사용된다. 버튼, 메뉴, 아이콘 등과 같은 그래픽 요소는 모두 창을 사용하여 구현된다.
창은 부모 창의 하위 창으로만 생성될 수 있다. 이로 인해 창은 계층적으로 트리 형태로 배열된다. X 서버는 자동으로 트리의 루트인 루트 창을 생성한다. 최상위 창은 루트 창의 직접적인 하위 창이다. 시각적으로 루트 창은 화면만큼 크며, 다른 모든 창 뒤에 위치한다.
식별자
X 서버는 창, 글꼴 등 모든 데이터에 대한 정보를 저장한다. 클라이언트는 이러한 객체의 식별자(서버와 상호 작용할 때 객체의 이름으로 사용할 수 있는 정수)를 알고 있다. 예를 들어, 클라이언트가 창을 생성하기를 원하면 서버에 창 생성을 요청하고 (성공할 경우) 새로 생성된 창과 연결된 식별자를 반환받는다. 이 식별자는 나중에 클라이언트가 예를 들어 창에 문자열을 그리도록 요청하는 데 사용될 수 있다.
식별자는 클라이언트에 대해서뿐만 아니라 서버에 대해서도 고유하다. 예를 들어, 두 개의 다른 클라이언트가 생성했더라도 두 개의 창이 동일한 식별자를 가질 수 없다. 클라이언트는 객체를 다른 클라이언트가 생성했더라도 식별자가 주어지면 어떤 객체에도 접근할 수 있다.
속성 및 특성
모든 창에는 미리 정의된 속성 집합과 특성 집합이 있으며, 이들은 모두 X 서버에 저장되고 적절한 요청을 통해 클라이언트가 접근할 수 있다. 속성은 창의 크기, 위치, 배경색 등 창에 대한 데이터이다. 특성은 창에 첨부된 데이터 조각이다. 속성과 달리 특성은 X 윈도 코어 프로토콜 수준에서 의미가 없다. 클라이언트는 창의 특성에 임의의 데이터를 저장할 수 있다.
특성은 이름, 유형 및 값으로 특징지어진다. 특성은 명령형 프로그래밍 언어의 변수와 유사하며, 애플리케이션은 주어진 이름과 유형을 가진 새 특성을 생성하고 그 안에 값을 저장할 수 있다. 특성은 창과 연결된다. 동일한 이름을 가진 두 개의 특성이 두 개의 다른 창에 존재할 수 있으며, 다른 유형과 값을 가질 수 있다.
특성은 주로 클라이언트 간 통신에 사용된다. 예를 들어, WM_NAME이라는 특성은 창의 이름을 저장하며, 창 관리자는 일반적으로 이 특성을 읽고 창의 이름을 창 상단에 표시한다.
xprop 프로그램은 창의 특성을 표시할 수 있다. 특히, xprop -root는 X 리소스(프로그램의 매개변수)를 포함한 루트 창의 특성을 보여준다.
이벤트
이벤트는 클라이언트에게 관심 있는 일이 발생했음을 알리기 위해 서버가 클라이언트에게 보내는 패킷이다. 클라이언트는 서버에게 다른 클라이언트에게 이벤트를 보내도록 요청할 수 있으며, 이는 클라이언트 간 통신에 사용된다. 예를 들어, 클라이언트가 현재 선택된 텍스트를 요청할 때, 선택을 처리하고 있는 창을 담당하는 클라이언트에게 이벤트가 전송된다.
창의 내용은 특정 조건(예: 창이 가려진 경우)에서 "파괴"될 수 있다. 파괴된 내용의 영역이 보이는 상태가 될 때마다 서버는 Expose 이벤트를 생성하여 창의 일부를 그려야 한다는 것을 클라이언트에게 알린다.
다른 이벤트는 키보드 또는 마우스 입력, 새 창 생성 등을 클라이언트에게 알리는 데 사용될 수 있다.
일부 종류의 이벤트는 항상 클라이언트에게 전송되지만, 대부분의 종류의 이벤트는 클라이언트가 이전에 관심이 있다고 명시한 경우에만 전송된다. 이는 클라이언트가 특정 종류의 이벤트에만 관심이 있을 수 있기 때문이다. 예를 들어, 클라이언트는 키보드 관련 이벤트에는 관심이 있지만 마우스 관련 이벤트에는 관심이 없을 수 있다.
색상 모드
X 윈도 시스템이 색상을 처리하는 방식은 때때로 사용자에게 혼란을 줄 수 있으며, 역사적으로 여러 가지 다른 모드가 지원되었다. 대부분의 최신 애플리케이션은 트루컬러 (24비트 색상, 빨강, 녹색, 파랑 각 8비트)를 사용하지만, 오래되거나 특수 애플리케이션은 다른 색상 모드를 요구할 수 있다. 많은 상업용 특수 애플리케이션은 PseudoColor를 사용한다.
X11 프로토콜은 실제로 대부분의 그래픽 작업에서 단일 색상을 나타내기 위해 픽셀 값이라고 불리는 단일 32비트 부호 없는 정수를 사용한다. 원색의 강도를 전송할 때는 각 색상 구성 요소에 16비트 정수가 사용된다. 다음 색상 표현이 존재하며, 특정 장치에서 모두 지원되지 않을 수 있다.
- DirectColor: 픽셀 값은 별도의 빨강, 녹색, 파랑 하위 필드로 분해된다. 각 하위 필드는 별도의 색상표를 인덱싱한다. 모든 색상표의 항목은 변경될 수 있다.
- TrueColor: DirectColor와 동일하지만, 색상표 항목이 하드웨어에 의해 미리 정의되어 변경할 수 없다. 일반적으로 빨강, 녹색, 파랑 색상표는 각각 (거의) 선형적인 강도 변화를 제공한다.
- GrayScale: 픽셀 값은 단색 강도를 포함하는 단일 색상표를 인덱싱한다. 색상표 항목은 변경될 수 있다.
- StaticGray: GrayScale과 동일하지만, 색상표 항목이 하드웨어에 의해 미리 정의되어 변경할 수 없다.
- PseudoColor (Chunky): 픽셀 값은 색상 강도를 포함하는 단일 색상표를 인덱싱한다. 색상표 항목은 변경될 수 있다.
- StaticColor: PseudoColor와 동일하지만, 색상표 항목이 하드웨어에 의해 미리 정의되어 변경할 수 없다.
Remove ads
Xlib 및 기타 클라이언트 라이브러리
대부분의 클라이언트 프로그램은 Xlib 클라이언트 라이브러리를 통해 서버와 통신한다. Xlib 외에 XCB 라이브러리는 X 프로토콜에 더 가깝게 작동한다. 특히, 대부분의 클라이언트는 Xaw, 모티프, GTK+ 또는 Qt와 같은 라이브러리를 사용하며, 이들은 다시 Xlib를 사용하여 서버와 상호 작용한다. Qt는 5.0 릴리스에서 Xlib에서 XCB로 전환했지만, 클라이언트 프로그램은 이 변경의 영향을 거의 받지 않았다.
클라이언트 간 통신
요약
관점
X 윈도 코어 프로토콜은 클라이언트 간 통신을 위한 메커니즘을 제공한다. 특히 창 속성 및 이벤트, 그리고 클라이언트-클라이언트 메시지 이벤트가 있다. 그러나 이러한 상호 작용을 위한 프로토콜은 지정하지 않는다. 대신, 별도의 클라이언트 간 통신 규칙 세트가 이러한 프로토콜을 관장한다.
Inter-Client Communication Conventions Manual은 선택을 통한 데이터 교환 및 애플리케이션과 창 관리자 간의 상호 작용을 위한 프로토콜을 지정한다. 일부 사람들은 이 사양이 어렵고 혼란스럽다고 생각했다.[3][4] 애플리케이션의 룩 앤드 필 및 통신의 일관성은 일반적으로 특정 데스크톱 환경에 프로그래밍함으로써 다루어진다.
ICE(Inter-Client Exchange protocol)는 클라이언트 간 상호 작용을 위한 프로토콜 구축을 위한 프레임워크를 지정하여, 프로그래머가 그 위에 특정 프로토콜을 구축할 수 있도록 한다. 특히, XSMP(X Session Management protocol)는 ICE를 기반으로 하는 프로토콜로, 애플리케이션과 세션 관리자 간의 상호 작용을 관장한다. 세션 관리자는 대화형 세션이 끝날 때 데스크톱 상태를 저장하고 동일한 사용자로 다른 세션이 다시 시작될 때 이를 복구하는 프로그램이다.
freedesktop 사양에는 새로운 규칙이 포함되어 있다. 여기에는 드래그 앤 드롭 규칙 Xdnd (데이터를 선택하고 다른 창으로 드래그하여 전송하는 데 사용됨)와 내장 애플리케이션 규칙 Xembed (애플리케이션이 다른 애플리케이션의 하위 창에서 실행되는 방식을 자세히 설명함)가 포함된다.
선택, 잘라내기 버퍼, 드래그 앤 드롭
이 부분의 본문은 X 윈도 선택입니다.X 윈도 시스템의 선택, 잘라내기 버퍼 및 드래그 앤 드롭 메커니즘을 통해 사용자는 한 창에서 다른 창으로 데이터를 전송할 수 있다. 선택 및 잘라내기 버퍼는 (일반적으로) 사용자가 창에서 텍스트 또는 다른 데이터를 선택하고 다른 창에 붙여넣을 때 사용된다. 드래그 앤 드롭은 사용자가 창에서 무언가를 선택한 다음, 선택 항목을 클릭하고 다른 창으로 끌어다 놓을 때 사용된다.
두 개의 다른 애플리케이션이 두 창을 처리할 수 있으므로, 데이터 전송에는 동일한 X 서버에 연결된 다른 클라이언트들이 상호 작용해야 한다. X 윈도 코어 프로토콜에는 선택 교환에 특정한 일부 유형의 요청 및 이벤트가 포함되어 있지만, 전송은 주로 일반 클라이언트-클라이언트 이벤트 전송 및 창 속성을 사용하여 이루어지며, 이는 선택 전송에 특정하지 않다.
사용자는 클라이언트 간에 다양한 유형의 데이터를 전송할 수 있다. 일반적으로 텍스트이지만 픽스맵, 숫자, 객체 목록 등도 될 수 있다.
선택 및 드래그 앤 드롭은 능동적인 메커니즘이다. 사용자가 창에서 데이터를 선택하면 해당 창을 처리하는 클라이언트는 해당 데이터를 요청하는 애플리케이션으로 전송하기 위한 프로토콜을 적극적으로 지원해야 한다. 이와 대조적으로 잘라내기 버퍼는 수동적인 메커니즘을 제공한다. 사용자가 일부 텍스트를 선택하면 해당 내용이 잘라내기 버퍼로 전송되며, 창을 처리하는 애플리케이션이 종료되고 창이 파괴되더라도 그곳에 남아 있다.
창 관리자
창 관리자는 창과 그래픽 사용자 인터페이스의 다른 그래픽 요소의 일반적인 모양을 제어하는 프로그램이다. X 윈도 시스템의 다른 설치에서 모양의 차이는 주로 다른 창 관리자의 사용 또는 창 관리자의 다른 구성에서 비롯된다.
창 관리자는 창의 위치를 결정하고, 창 주위에 장식 테두리를 배치하고, 아이콘을 처리하고, 창 외부(배경)에서 마우스 클릭을 처리하고, 특정 키 스트로크를 처리하는 등의 작업을 담당한다.
X 서버의 관점에서 창 관리자는 다른 클라이언트와 마찬가지로 클라이언트로 작동한다. 창의 초기 위치와 창 주위의 장식 테두리는 다음 요청을 사용하여 창 관리자가 처리한다.
- 애플리케이션은 서버에 특정 창의 하위 창을 매핑(표시)하는 요청을 만족시키지 않고 대신 이벤트를 보내도록 요청할 수 있다.
- 애플리케이션은 창의 부모를 변경하도록 요청할 수 있다.
창 관리자는 첫 번째 요청을 사용하여 최상위 창(루트 창의 자식)을 매핑하는 모든 요청을 가로챈다. 다른 애플리케이션이 최상위 창의 매핑을 요청할 때마다 서버는 이를 수행하지 않고 창 관리자에게 이벤트를 보낸다. 대부분의 창 관리자는 창을 재부모화한다. 즉, 더 큰 최상위 창(프레임 창이라고 함)을 만들고 원래 창을 그 하위로 재부모화한다. 그래픽적으로 이는 원래 창을 프레임 창 안에 배치하는 것에 해당한다. 원래 창이 차지하지 않는 프레임 창의 공간은 창 주위의 장식 프레임("테두리" 및 "제목 표시줄")에 사용된다.
창 관리자는 프레임 창에서 마우스 클릭을 처리한다. 이를 통해 사용자는 예를 들어 테두리나 제목 표시줄을 클릭하고 드래그하여 창을 이동하거나 크기를 조정할 수 있다.
창 관리자는 아이콘 및 그래픽 사용자 인터페이스의 관련 시각적 요소도 처리한다. 아이콘은 X 윈도 코어 프로토콜 수준에 존재하지 않는다. 이는 창 관리자에 의해 구현된다. 예를 들어, 창이 "아이콘화"되어야 할 때, FVWM 창 관리자는 창의 매핑을 해제하고 아이콘 이름을 위한 창을 만들고, 가능하면 아이콘 이미지를 위한 다른 창을 만든다. 따라서 아이콘의 의미와 처리는 전적으로 창 관리자에 의해 결정된다. wm2와 같은 일부 창 관리자는 아이콘을 전혀 구현하지 않는다.
세션 관리자
이 부분의 본문은 X 세션 관리자입니다.대략적으로 세션의 상태는 특정 시점의 "데스크톱 상태"이다. 즉, 현재 콘텐츠가 있는 창 세트이다. 더 정확하게 말하면, 이러한 창을 관리하는 애플리케이션 세트와 이러한 애플리케이션이 필요한 경우 관리되는 창의 상태를 복원할 수 있도록 하는 정보이다. X 세션 관리자라고 알려진 프로그램이 세션의 상태를 저장하고 복원한다.
가장 두드러진 점은 세션 관리자를 사용하면 사용자가 대화형 세션에서 로그아웃한 후에도 다시 로그인할 때 정확히 동일한 창을 동일한 상태로 찾을 수 있다는 것이다. 이를 위해 세션 관리자 프로그램은 로그아웃 시 실행 중인 애플리케이션의 이름을 저장하고 로그인 시 다시 시작한다. 애플리케이션의 상태도 복원되려면 (창의 콘텐츠를 복원하는 데 필요하다) 애플리케이션은 세션 관리자의 요청에 따라 실행 상태를 저장하고 다시 시작할 때 다시 로드할 수 있어야 한다.
X 윈도 시스템에는 xsm이라는 기본 세션 관리자가 포함되어 있다. 개발자들은 특정 데스크톱 시스템을 위해 다른 세션 관리자를 작성했다. 주요 예시로는 KDE의 ksmserver, Xfce의 xfce4-session, GNOME의 gnome-session이 있다.
Remove ads
X 디스플레이 관리자
이 부분의 본문은 X 디스플레이 관리자입니다.X 디스플레이 관리자라고 알려진 프로그램은 X 윈도 시스템에서 그래픽 로그인 프롬프트를 표시한다. 더 일반적으로, 디스플레이 관리자는 로컬 컴퓨터에서 하나 이상의 X 서버를 실행하거나 원격 컴퓨터에서 실행 중인 X 서버로부터 들어오는 연결을 수락한다. 로컬 서버는 디스플레이 관리자에 의해 시작되며, 디스플레이 관리자는 이 서버에 연결하여 사용자에게 로그인 화면을 제시한다. 원격 서버는 디스플레이 관리자와 독립적으로 시작되어 디스플레이 관리자에 연결한다. 이 상황에서 디스플레이 관리자는 그래픽 텔넷 서버처럼 작동한다. X 서버는 디스플레이 관리자에 연결하여 세션을 시작할 수 있으며, 이 세션을 사용하는 애플리케이션은 디스플레이 관리자와 동일한 컴퓨터에서 실행되지만 (사용자 앞의 컴퓨터 또는 원격 컴퓨터일 수 있는) X 서버가 실행되는 컴퓨터에서 입출력을 한다.
X 윈도 시스템은 기본 제공되는 디스플레이 관리자로 XDM을 포함한다. 다른 디스플레이 관리자로는 GDM (그놈), KDM/SDDM (KDE), WDM (윈도 메이커에서 사용되는 WINGs 위젯 세트 사용) 및 entrance (Enlightenment v.17에서 사용되는 아키텍처 사용)가 있다.
Remove ads
사용자 인터페이스 요소
초기 X용 위젯 툴킷에는 Xaw (아테나 위젯 세트, 1983), OLIT (OPEN LOOK 인트린식스 툴킷, 1988), XView (1988), 모티프 (1980년대) 및 Tk가 포함되었다. OLIT과 XView는 썬의 레거시 OpenWindows 데스크톱 환경의 기본 툴킷으로 기능한다.
모티프는 공통 데스크톱 환경(CDE)을 위한 기본 툴킷을 제공한다. CDE는 솔라리스, AIX 및 HP-UX와 같은 상업용 유닉스 시스템에서 사용되는 데스크톱 환경이다. (솔라리스 10에는 CDE와 그놈이 모두 포함되어 있으며, 후자가 2010 년 기준[update] 선호되는 데스크톱 환경이다.)
최근에 개발된 툴킷에는 Qt (1991-, KDE에서 사용), GTK+ (1997-, 그놈에서 사용), WxWidgets (1992-), FLTK (1998-), FOX (1997-) 및 fpGUI (2005-현재)가 포함된다.
Remove ads
확장
요약
관점
샤이플러와 게티스는 X 서버를 간단하지만 확장 가능하게 설계했다. 따라서 현재 많은 기능이 프로토콜 확장 내에 존재한다.
프로토콜 수준에서 각 확장에는 새로운 요청/이벤트/오류 패킷 유형이 할당될 수 있다. 확장 기능은 클라이언트 애플리케이션이 확장 라이브러리를 통해 접근한다. 현재 X 서버 구현에 확장을 추가하는 것은 서버 설계의 모듈성 부족으로 인해 어려운 것으로 알려져 있다.[5] XCB 프로젝트의 장기 목표는 XML 프로토콜 설명에서 확장의 클라이언트 및 서버 측을 모두 자동 생성하는 것이다.
다음 표는 개발된 확장 중 일부를 도입 시기에 따라 대략적으로 정렬한 것이다.
더 이상 사용되지 않는 확장
Remove ads
같이 보기
각주
참고 자료
추가 자료
외부 링크
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads