D-Bus는 2002년 Havoc Pennington, Alex Larsson, Anders Carlsson에 의해 시작된 프로세스 간 통신(IPC) 시스템이다. KDE 2, 3에서 사용된 DCOP를 대체하며, 대부분의 POSIX 운영 체제와 윈도우를 지원한다. 데스크톱 환경뿐만 아니라 NetworkManager, BlueZ, PulseAudio, systemd, Polkit 등 시스템 서비스에서도 사용된다. D-Bus는 시스템 버스와 세션 버스를 통해 정보 공유, 모듈성, 권한 격리를 제공하며, 일대일 요청-응답 및 발행/구독 통신 방식을 지원한다. libdbus가 널리 사용되며, GDBus, sd-bus, kdbus 등의 구현체와 다양한 언어 바인딩이 존재한다.
더 읽어볼만한 페이지
Freedesktop.org - 메사 (컴퓨터 그래픽스) 메사는 다양한 운영체제에서 3D 그래픽 하드웨어 가속을 지원하는 자유-오픈 소스 그래픽 라이브러리로, OpenGL, Vulkan, OpenCL 등 다양한 그래픽 API를 지원하며 소프트웨어 렌더링 기능도 제공한다.
Freedesktop.org - HAL (소프트웨어) HAL(Hardware Abstraction Layer)은 D-Bus IPC 메커니즘을 통해 하드웨어 검색, 열거 및 접근을 중재하는 데몬이었으나, 복잡성 및 유지보수 문제로 인해 리눅스 배포판과 프로젝트에서 사용이 중단되고 기능이 DeviceKit이나 udev 등으로 이전되었다.
원격 프로시저 호출 - DCE/RPC DCE/RPC는 분산 컴퓨팅 환경에서 원격 프로시저 호출을 가능하게 하는 프로토콜로, 오픈 소프트웨어 재단에서 개발되었으며, 다양한 운영체제와 환경에서 사용된다.
원격 프로시저 호출 - SOAP SOAP는 분산 환경에서 정보 교환을 위해 XML 기반 메시지를 사용하는 프로토콜로, 확장성, 중립성, 독립성을 특징으로 가지나 복잡성, 오버헤드, 성능 문제로 REST 아키텍처가 대안으로 제시되기도 한다.
프로세스 간 통신 - Ajax Ajax는 웹 페이지 전체를 새로고침하지 않고 비동기적으로 서버와 통신하여 웹 애플리케이션의 일부를 업데이트하는 웹 개발 기술로, XMLHttpRequest 객체의 등장으로 가능해졌으며 HTML, CSS, DOM, JavaScript, JSON 등의 기술을 통합하여 동적인 사용자 인터페이스를 구현한다.
프로세스 간 통신 - 공유 메모리 공유 메모리는 다중 CPU 시스템에서 여러 프로세서가 접근 가능한 메모리 영역으로, 프로세스 간 통신에 활용되며, 다양한 하드웨어 구조 및 운영체제에서 지원되고 GPU 내에서도 사용되어 성능 향상에 기여한다.
D-Bus는 원래 그놈 및 KDE 리눅스 데스크톱 환경 (각각 CORBA, DCOP)에서 사용되는 소프트웨어 컴포넌트 통신 시스템을 대체하기 위해 설계된 프로세스 간 통신 (IPC) 메커니즘이다.[5] 이러한 데스크톱 환경의 구성 요소는 일반적으로 여러 프로세스에 분산되어 있으며 각 프로세스는 몇 가지(보통 하나)의 서비스만 제공한다. 이러한 서비스는 일반적인 클라이언트 응용 프로그램 또는 데스크톱 환경의 다른 구성 요소에서 작업을 수행하는 데 사용될 수 있다.
협업하는 대규모 프로세스 그룹은 개별 통신 채널(일대일 IPC 방식 사용)의 조밀한 메쉬가 필요하다. D-Bus는 단일 공유 채널로 IPC 요구 사항을 단순화한다.
D-Bus는 단일 공유 가상 채널을 통해 프로세스 그룹 간의 모든 통신을 수집하는 소프트웨어 버스 추상화를 제공한다.[6] 버스에 연결된 프로세스는 내부적으로 어떻게 구현되는지 알 수 없지만, D-Bus 사양은 버스에 연결된 모든 프로세스가 이를 통해 서로 통신할 수 있도록 보장한다.
D-Bus는 2002년 Havoc Pennington, Alex Larsson (레드햇)과 Anders Carlsson에 의해 시작되었다. API가 안정적인 것으로 간주되는 버전 1.0은 2006년 11월에 출시되었다.
KDE 버전 2와 3에서 사용된 DCOP 시스템의 영향을 크게 받은 D-Bus는 KDE 4 릴리스에서 DCOP를 대체했다. D-Bus의 구현은 대부분의 POSIX 운영 체제를 지원하며, 윈도우용 포트도 존재한다. Qt 4 이상과 GNOME에서 사용된다. GNOME에서는 이전 Bonobo 메커니즘의 대부분을 점차 대체했다. Xfce에서도 사용된다.
초창기 채택자 중 하나는 (현재는 사용 중단된) 하드웨어 추상화 계층이었다. HAL은 D-Bus를 사용하여 컴퓨터에 추가되거나 제거된 하드웨어에 대한 정보를 내보냈다.
D-Bus의 사용은 데스크톱 환경의 초기 범위를 넘어 점차 확장되어 시스템 서비스의 양이 증가하고 있다. 예를 들어, NetworkManager 네트워크 데몬, BlueZ 블루투스 스택, PulseAudio 사운드 서버는 D-Bus를 사용하여 서비스의 일부 또는 전체를 제공한다. systemd는 systemctl과 systemd 간의 통신에 D-Bus 와이어 프로토콜을 사용하며, logind와 같은 전통적인 시스템 데몬을 D-Bus 서비스로 홍보하고 있다. D-Bus의 또 다른 주요 사용자는 Polkit이며, 정책 권한 데몬은 시스템 버스에 연결된 서비스로 구현된다.
3. D-Bus 사양
D-Bus는 원래 그놈 및 KDE 리눅스 데스크톱 환경에서 사용되는 소프트웨어 컴포넌트 통신 시스템(CORBA, DCOP 각각)을 대체하기 위해 설계된 프로세스 간 통신 (IPC) 메커니즘이다.[1] 이러한 데스크톱 환경의 구성 요소는 일반적으로 여러 프로세스에 분산되어 있으며 각 프로세스는 몇 가지(보통 하나)의 서비스를 제공한다. 이러한 서비스는 일반적인 클라이언트 응용 프로그램 또는 데스크톱 환경의 다른 구성 요소에서 작업을 수행하는 데 사용될 수 있다.[5]
D-Bus는 단일 공유 가상 채널을 통해 프로세스 그룹 간의 모든 통신을 수집하는 소프트웨어 버스 추상화를 제공한다.[2] 버스에 연결된 프로세스는 내부적으로 어떻게 구현되는지 알 수 없지만, D-Bus 사양은 버스에 연결된 모든 프로세스가 이를 통해 서로 통신할 수 있도록 보장한다.
리눅스 데스크톱 환경은 다음과 같은 여러 버스를 인스턴스화하여 D-Bus 기능을 활용한다.[3][2][1]
모든 사용자와 시스템의 프로세스에서 사용할 수 있는 단일 '''시스템 버스''', 시스템 서비스(즉, 운영 체제에서 제공하는 서비스와 모든 시스템 데몬)에 대한 액세스를 제공한다.
각 사용자 로그인 세션에 대한 '''세션 버스''', 동일한 데스크톱 세션의 사용자 응용 프로그램에 데스크톱 서비스를 제공하고 데스크톱 세션을 전체적으로 통합할 수 있도록 한다.
프로세스는 해당 버스에 대한 액세스 권한이 부여된 경우 원하는 만큼의 버스에 연결할 수 있다. 이는 모든 사용자 프로세스가 시스템 버스와 현재 세션 버스에 연결할 수 있지만, 다른 사용자의 세션 버스 또는 동일한 사용자가 소유한 다른 세션 버스에는 연결할 수 없음을 의미한다. 모든 사용자 세션이 단일 사용자 버스로 결합될 경우 이 제한은 변경될 수 있다.[4]
D-Bus는 정보 공유, 모듈성 및 권한 분리를 포함하여 응용 프로그램에 추가적인 기능이나 기존 기능을 단순화한다. 예를 들어, 블루투스 또는 스카이프를 통해 수신된 음성 통화 정보는 현재 실행 중인 음악 플레이어에 의해 전파 및 해석될 수 있으며, 음소거하거나 통화가 종료될 때까지 재생을 일시 중지하는 방식으로 반응할 수 있다.[5]
D-Bus는 사용자 응용 프로그램의 서로 다른 구성 요소를 통합하는 프레임워크로도 사용할 수 있다. 예를 들어, 오피스 스위트는 세션 버스를 통해 워드 프로세서와 스프레드시트 간에 데이터를 공유할 수 있다.
3. 1. 버스 모델
D-Bus는 그놈 및 KDE 리눅스 데스크톱 환경에서 사용되는 소프트웨어 구성 요소 통신 시스템을 대체하기 위해 설계된 IPC 메커니즘이다.[1] 이 데스크톱 환경의 구성 요소들은 일반적으로 여러 프로세스에 분산되어 있으며, 각기 몇몇의 서비스(보통은 하나의 서비스)를 제공한다. 이러한 서비스들은 일반적인 클라이언트 애플리케이션이나 데스크톱 환경의 다른 구성 요소들에 의해 사용될 수 있다.
D-Bus는 하나의 단일 공유 채널에서 IPC 요건을 단순하게 만들어 준다.
많은 수의 프로세스들이 관련되어 있기 때문에, 이들 간의 1대1 IPC 통신은 비효율적이고 불안정한 접근 방식이 된다. 대신, D-Bus는 소프트웨어 버스 추상화를 제공하여 단일 공유 가상 채널을 통해 일련의 프로세스들 간의 모든 통신을 수집한다.[2] 버스에 연결된 프로세스들은 내부 구현 방식을 알지 못하지만, D-Bus 사양은 버스에 연결된 모든 프로세스들이 이를 통해 서로 통신할 수 있음을 보장한다.
리눅스 데스크톱 환경은 하나의 버스뿐 아니라 여러 버스들을 열거함으로써 D-Bus 기능을 활용한다.[3][2][1]
하나의 단일 '''시스템 버스''': 시스템의 모든 사용자와 프로세스에 이용이 가능하며, 시스템 서비스에 대한 접근 권한을 제공한다. (예: 운영 체제와 데몬이 제공하는 서비스들)
각 사용자 로그인 세션별 '''세션 버스''': 데스크톱 서비스를 동일 데스크톱 세션의 사용자 애플리케이션에 제공하고 하나의 단위로 데스크톱 세션을 허용한다.
프로세스는 여러 버스들에 대한 접근 권한이 있다면 여러 버스들에 연결할 수 있다. 즉, 어떤 사용자 프로세스라도 시스템 버스와 현재 소속된 세션 버스에 연결할 수 있지만, 다른 사용자의 세션 버스나 심지어 동일 사용자가 소유한 다른 세션 버스에는 연결할 수 없다. 후자의 제한은 나중에 모든 사용자 세션이 하나의 사용자 버스로 병합되는 경우에는 변경될 수 있다.[4]
D-Bus는 정보 공유, 모듈성, 권한 격리 등 애플리케이션에 대한 기존 기능을 추가하거나 단순화한다. 예를 들어, 블루투스나 스카이프를 통해 들어온 음성 통화 정보는 현재 실행 중인 음악 플레이어에 의해 전파되고 해석될 수 있으며, 통화가 끝날 때까지 음소거하거나 재생을 일시 중지시킴으로써 반응할 수 있다.[5]
또한, D-Bus는 각기 다른 사용자 애플리케이션의 구성 요소 연동을 위한 프레임워크로서 사용될 수 있다. 예를 들어, 오피스 제품군은 워드 프로세서와 스프레드시트 간 데이터 공유를 위해 세션 버스를 통해 통신할 수 있다.
버스에 대한 모든 연결은 D-Bus의 맥락에서 "버스 이름"이라고 불리는 것으로 식별된다. 버스 이름은 점으로 구분된 두 개 이상의 문자열, 숫자, 대시, 밑줄로 구성되며, 이는 역 도메인 이름이다. 유효한 버스 이름의 예시는 `org.freedesktop.NetworkManager`이다.
프로세스가 버스에 대한 연결을 설정하면, 버스는 해당 연결에 "고유 연결 이름"이라고 불리는 특별한 버스 이름을 할당한다. 이러한 유형의 버스 이름은 변경 불가능하며—연결이 존재하는 한 변경되지 않음이 보장된다—더욱 중요한 것은 버스 수명 동안 재사용될 수 없다는 것이다. 즉, 동일한 프로세스가 버스에 대한 연결을 종료하고 새로운 연결을 생성하더라도, 해당 버스에 대한 다른 연결은 이러한 고유 연결 이름을 절대 할당받지 못한다. 고유 연결 이름은 금지된 콜론 문자로 시작하기 때문에 쉽게 알아볼 수 있다. 고유 연결 이름의 예시는 `:1.1553`이다 (콜론 뒤의 문자는 특별한 의미가 없다).
프로세스는 연결에 대한 추가 버스 이름을 요청할 수 있으며, 요청된 이름이 버스에 대한 다른 연결에서 이미 사용 중이 아닌 경우에만 가능하다. D-Bus 용어로, 버스 이름이 연결에 할당되면, 해당 연결이 버스 이름을 "소유"한다고 말한다. 그런 의미에서, 버스 이름은 동시에 두 개의 연결이 소유할 수 없지만, 고유 연결 이름과 달리, 이러한 이름은 사용 가능하다면 재사용될 수 있다. 즉, 프로세스는 다른 프로세스에 의해—의도적으로든 그렇지 않든—해제된 버스 이름을 되찾을 수 있다.
이러한 추가 버스 이름 (일반적으로 "잘 알려진 이름"이라고 불림)의 아이디어는 미리 정해진 버스 이름을 사용하여 서비스에 참조할 수 있는 방법을 제공하는 것이다. 예를 들어, 시스템 버스에서 현재 시간과 날짜를 보고하는 서비스는, 어떤 프로세스인지에 관계없이, `org.freedesktop.timedate1` 버스 이름을 소유한 연결을 가진 프로세스에 있다.
버스 이름은 단일 인스턴스 애플리케이션을 구현하는 간단한 방법으로 사용될 수 있다 (두 번째 인스턴스는 버스 이름이 이미 사용 중임을 감지한다). 또한 버스는 프로세스 종료로 인해 버스 이름이 해제될 때 알림을 보내기 때문에, 서비스 프로세스 수명 주기를 추적하는 데 사용될 수 있다.
3. 2. 객체 모델
D-Bus는 여러 컴포넌트 기반 통신 시스템을 대체하기 위해 처음 구상되었기 때문에, 이전 시스템들과 마찬가지로 클라이언트와 서비스 간의 통신 의미를 표현하는 객체 모델을 공유한다. D-Bus 객체 모델에서 사용되는 용어는 일부 객체 지향 프로그래밍 언어에서 사용되는 용어를 모방한다. 그렇다고 D-Bus가 OOP 언어에만 제한된다는 의미는 아니다. 실제로 가장 많이 사용되는 구현(libdbus)은 C로 작성되었는데, 이는 절차적 프로그래밍 언어이다.[13]
D-Feet를 사용하여 D-Bus 버스에서 기존 버스 이름, 객체, 인터페이스, 메서드 및 시그널을 탐색하는 모습
D-Bus에서 프로세스는 '객체'를 노출하여 서비스를 제공한다. 이러한 객체는 호출할 수 있는 '메서드'와 객체가 발생시킬 수 있는 '시그널'을 가지고 있다. 메서드와 시그널은 함께 객체의 '멤버'라고 한다. 버스에 연결된 모든 클라이언트는 객체의 메서드를 사용하여 객체와 상호 작용하고, 요청을 보내거나 객체에게 작업을 수행하도록 명령할 수 있다. 예를 들어, 시간 서비스를 나타내는 객체는 현재 날짜와 시간을 반환하는 메서드를 사용하여 클라이언트가 쿼리할 수 있다. 또한 클라이언트는 특정 이벤트(일반적으로 기본 서비스와 관련됨)로 인해 상태가 변경될 때 객체가 발생시키는 시그널을 수신할 수 있다. 예를 들어 USB 또는 네트워크 드라이버와 같은 하드웨어 장치를 관리하는 서비스가 "새 하드웨어 장치 추가" 이벤트를 시그널하는 경우가 있다. 클라이언트는 D-Bus 버스가 특정 객체에서 특정 시그널을 수신하는 데 관심이 있는 프로세스에만 시그널을 전달하므로, 특정 객체에서 특정 시그널을 수신하는 데 관심이 있음을 버스에 알려야 한다.
D-Bus 버스에 연결된 프로세스는 원하는 만큼 많은 D-Bus 객체를 'export'하도록 요청할 수 있다. 각 객체는 '객체 경로'로 식별되며, 이 객체 경로는 슬래시 문자로 구분되고 접두사가 붙은 숫자, 문자 및 밑줄의 문자열로, 유닉스 파일 시스템 경로와 유사하기 때문에 그렇게 불린다. 객체 경로는 요청하는 프로세스에서 선택하며, 해당 버스 연결의 컨텍스트 내에서 고유해야 한다. 유효한 객체 경로의 예는 `/org/kde/kspread/sheets/3/cells/4/5` 이다. 그러나 객체 경로 내에서 계층 구조를 형성하는 것이 강제되지는 않지만, 권장되지도 않는다. 서비스의 객체에 대한 특정 명명 규칙은 해당 서비스 개발자에게 전적으로 달려 있지만, 많은 개발자는 프로젝트의 예약된 도메인 이름을 접두사로 사용하여 네임스페이스를 지정한다(예: `/org/kde`).
모든 객체는 export된 특정 버스 연결과 밀접하게 연관되어 있으며, D-Bus 관점에서 해당 연결의 컨텍스트 내에서만 존재한다. 따라서 특정 서비스를 사용하려면 클라이언트는 원하는 서비스를 제공하는 객체 경로뿐만 아니라 서비스 프로세스가 버스에 연결된 버스 이름도 표시해야 한다. 이는 버스에 연결된 여러 프로세스가 동일한 객체 경로를 가진 다른 객체를 명확하게 export할 수 있도록 한다.
'인터페이스'는 객체와 함께 사용할 수 있는 멤버(메서드 및 시그널)를 지정한다. 인터페이스는 자바 언어 인터페이스 표기법과 유사한 점으로 구분된 이름으로 식별되는 메서드(매개변수 전달 및 반환 포함)와 시그널(매개변수 포함)의 선언 집합이다. 유효한 인터페이스 이름의 예는 `org.freedesktop.Introspectable`이다. 유사성에도 불구하고 인터페이스 이름과 버스 이름을 혼동해서는 안 된다. D-Bus 객체는 여러 인터페이스를 '구현'할 수 있지만, 적어도 하나는 구현해야 하며, 해당 인터페이스에 정의된 모든 메서드 및 시그널을 지원해야 한다. 객체가 구현하는 모든 인터페이스의 조합을 객체 '타입'이라고 한다.
객체를 사용할 때, 클라이언트 프로세스는 멤버의 이름 외에 멤버의 인터페이스 이름을 제공하는 것이 좋지만, 객체가 구현한 다른 인터페이스에서 사용 가능한 중복 멤버 이름으로 인해 모호성이 발생하는 경우에만 필수이다. 그렇지 않으면 선택된 멤버가 정의되지 않거나 오류가 발생한다. 반면에 발생된 시그널은 항상 어떤 인터페이스에 속하는지 표시해야 한다.
D-Bus 사양은 또한 객체가 자체 인터페이스 외에도 구현할 수 있는 여러 표준 인터페이스를 정의한다. 기술적으로 선택 사항이지만, 대부분의 D-Bus 서비스 개발자는 내관찰(Introspection)과 같은 중요한 추가 기능을 D-Bus 클라이언트에 제공하므로, export된 객체에서 이러한 인터페이스를 지원하도록 선택한다. 이러한 표준 인터페이스는 다음과 같다.
`org.freedesktop.DBus.Peer`: D-Bus 연결이 활성 상태인지 테스트하는 방법을 제공한다.
`org.freedesktop.DBus.Introspectable`: 클라이언트 프로세스가 런타임에 객체가 구현하는 인터페이스, 메서드 및 시그널에 대한 설명( XML 형식)을 얻을 수 있는 내관찰(introspection) 메커니즘을 제공한다.
`org.freedesktop.DBus.Properties`: D-Bus 객체가 기본 네이티브 객체 속성 또는 속성을 노출하거나, 존재하지 않는 경우 시뮬레이션할 수 있도록 한다.
`org.freedesktop.DBus.ObjectManager`: D-Bus 서비스가 객체를 계층적으로 배열하는 경우, 이 인터페이스는 단일 메서드 호출을 사용하여 객체에게 해당 경로 아래의 모든 하위 객체와 해당 인터페이스 및 속성에 대해 쿼리할 수 있는 방법을 제공한다.
D-Bus 사양은 `org.freedesktop.DBus` 버스 이름에 있는 `/org/freedesktop/DBus` 객체를 사용하여 수행할 여러 관리 버스 작업("버스 서비스"라고 함)을 정의한다. 각 버스는 이 특수 버스 이름을 자체적으로 예약하고, 버스 이름과 객체 경로의 이 조합에 특정하게 수행된 모든 요청을 관리한다. 버스에서 제공하는 관리 작업은 객체의 인터페이스 `org.freedesktop.DBus`에 의해 정의된 작업이다. 이러한 작업은 예를 들어 버스의 상태에 대한 정보를 제공하거나, 추가 "잘 알려진" 버스 이름의 요청 및 해제를 관리하는 데 사용된다.
3. 3. 통신 모델
D-Bus는 그놈과 KDE 리눅스 데스크톱 환경에서 사용되던 소프트웨어 구성 요소 통신 시스템 (CORBA, DCOP)을 대체하기 위해 설계된 IPC 메커니즘이다.[1] 이 데스크톱 환경의 구성 요소들은 여러 프로세스에 분산되어 각각 몇 가지 서비스를 제공한다. 이러한 서비스는 클라이언트 애플리케이션이나 데스크톱 환경의 다른 구성 요소들이 자신의 작업을 수행하는 데 사용될 수 있다.
D-Bus는 하나의 단일 공유 채널에서 IPC 요건을 단순하게 만들어 준다.
프로세스 수가 많으면 1대1 IPC 통신은 비효율적이다. D-Bus는 소프트웨어 버스 추상화를 제공하여 단일 공유 가상 채널을 통해 프로세스 간 통신을 수집한다.[2] 버스에 연결된 프로세스들은 내부 구현 방식을 알지 못하지만, D-Bus 사양은 버스에 연결된 모든 프로세스가 서로 통신할 수 있음을 보장한다.
리눅스 데스크톱 환경은 여러 버스를 열거하여 D-Bus 기능을 활용한다.[3][2][1]
시스템 버스: 시스템의 모든 사용자와 프로세스에 사용 가능하며, 시스템 서비스(예: 운영 체제와 데몬 서비스)에 대한 접근 권한을 제공한다.
세션 버스: 각 사용자 로그인 세션별로 존재하며, 데스크톱 서비스를 동일 데스크톱 세션의 사용자 애플리케이션에 제공하고 데스크톱 세션을 하나로 통합한다.
프로세스는 여러 버스에 연결할 수 있지만, 사용자 프로세스는 시스템 버스와 현재 소속된 세션 버스에만 연결할 수 있다. 다른 사용자의 세션 버스나 동일 사용자의 다른 세션 버스에는 연결할 수 없다.
D-Bus는 정보 공유, 모듈성, 권한 격리 등 애플리케이션 기능을 추가하거나 단순화한다. 예를 들어, 블루투스나 스카이프를 통한 음성 통화 정보는 음악 플레이어에 의해 음소거되거나 재생이 일시 중지될 수 있다.[4]
D-Bus는 프레임워크로서 사용자 애플리케이션 간 연동을 지원한다. 예를 들어, 오피스 제품군은 워드 프로세서와 스프레드시트 간 데이터 공유를 위해 세션 버스를 통해 통신할 수 있다.
D-Bus는 고수준의 프로세스 간 통신 시스템으로 설계되었으며, "raw 바이트" 대신 ''메시지'' 교환을 기반으로 한다. D-Bus 메시지는 버스를 통해 연결된 다른 프로세스로 보낼 수 있는 고수준 항목이다. 메시지는 잘 정의된 구조를 가지며, 버스는 메시지 유효성을 검사하고 잘못된 형식의 메시지를 거부할 수 있다.
일대일 요청-응답: 클라이언트가 객체의 메서드를 호출하는 방식이다. 클라이언트는 서비스 프로세스로 메시지를 보내고, 서비스는 클라이언트로 응답 메시지를 보낸다. 클라이언트 메시지는 객체 경로, 메서드 이름, 입력 매개변수 값을 포함해야 한다. 응답 메시지는 출력 매개변수 값 또는 오류 발생 시 ''예외'' 정보를 포함한다.
발행/구독: 객체가 신호 발생을 알리는 방식이다. 서비스 프로세스는 버스가 구독하는 클라이언트에게만 전달하는 메시지를 브로드캐스트한다. 메시지는 객체 경로, 신호 이름, 인터페이스, 매개변수 값을 전달한다. 통신은 단방향이며, 응답 메시지가 없다.
모든 D-Bus 메시지는 헤더와 본문으로 구성된다. 헤더는 메시지 유형, 발신자, 수신자 정보(대상 버스 이름, 객체 경로, 메서드/신호 이름, 인터페이스 이름 등)를 포함한다. 본문에는 입력/출력 인수 등 데이터 페이로드가 포함되며, 직렬화를 지원하는 이진 형식으로 인코딩된다.
D-Bus 사양은 와이어 프로토콜을 정의하여 D-Bus 메시지 구축 방법을 정의하지만, 기본 전송 방법은 정의하지 않는다.
D-Bus는 세 개의 레이어로 구성된 아키텍처이다.[13]
# '''libdbus''' : 두 애플리케이션을 연결하고 메시지 교환을 가능하게 하는 라이브러리
# '''dbus-daemon''' : `libdbus` 위에 만들어진 실행 파일 형식의 메시지 버스 데몬. 여러 애플리케이션이 접속하여 메시지를 배포하고 게시-구독 모델을 구현한다.
D-Bus의 대부분의 기존 구현은 참조 구현의 아키텍처를 따른다. 이 아키텍처는 두 가지 주요 구성 요소로 구성된다.
두 프로세스 간에 메시지를 교환하기 위해 D-Bus 와이어 프로토콜을 구현하는 지점 간 통신 라이브러리 (컴퓨팅). 참조 구현에서 이 라이브러리는 `libdbus`이다. 다른 구현에서는 `libdbus`가 다른 상위 수준 라이브러리, 언어 바인딩으로 래핑되거나 동일한 목적을 수행하는 다른 독립형 구현으로 완전히 대체될 수 있다.[4] 이 라이브러리는 두 프로세스 간의 일대일 통신만 지원한다.[5]
D-Bus 메시지 버스 데몬 역할을 하는 `dbus-daemon` 프로세스. 버스에 연결된 모든 프로세스는 버스와 하나의 D-Bus 연결을 유지한다. 버스 역할을 수행하고 나머지 프로세스가 모든 D-Bus 지점 간 통신 라이브러리를 사용하여 연결하는 특수 데몬 데몬 프로세스. 이 프로세스는 다른 프로세스로부터 버스에 연결된 메시지를 라우팅하는 역할을 담당하기 때문에 '메시지 버스 데몬'이라고도 한다.[8] 참조 구현에서 이 역할은 `dbus-daemon`에 의해 수행되며, 자체적으로 `libdbus`를 기반으로 구축된다. 메시지 버스 데몬의 또 다른 구현은 `dbus-broker`이며, `sd-bus`를 기반으로 구축되었다.
`libdbus` 라이브러리(또는 이에 상응하는 라이브러리)는 내부적으로 기본 하위 수준 IPC 메커니즘을 사용하여 D-Bus 연결의 양쪽 끝에서 두 프로세스 간에 필요한 D-Bus 메시지를 전송한다. D-Bus 사양은 어떤 특정 IPC 전송 메커니즘을 사용할 수 있는지 규정하지 않으며, 지원하는 전송 방법을 결정하는 것은 통신 라이브러리이다. 예를 들어, 리눅스와 같은 유닉스 계열 운영 체제에서 `libdbus`는 일반적으로 기본 전송 방법으로 유닉스 도메인 소켓을 사용하지만, TCP 소켓도 지원한다.[3][5]
두 프로세스의 통신 라이브러리는 선택한 전송 방법과 통신에 사용되는 특정 채널에 대해 동의해야 한다. 이 정보는 D-Bus가 "주소"라고 부르는 것으로 정의된다.[10][5]유닉스 도메인 소켓은 파일 시스템 객체이므로 파일 이름으로 식별할 수 있으며, 따라서 유효한 주소는 `unix:path=/tmp/.hiddensocket`이다.[3][11] 두 프로세스는 D-Bus 연결을 설정하기 위해 해당 통신 라이브러리에 동일한 주소를 전달해야 한다. 주소는 또한 쉼표로 구분된 `key=value` 쌍 형태로 통신 라이브러리에 추가 데이터를 제공할 수 있다.[10][11] 예를 들어, 이를 통해 지원하는 특정 유형의 연결에 인증 정보를 제공할 수 있다.
`dbus-daemon`과 같은 메시지 버스 데몬을 사용하여 D-Bus 버스를 구현하는 경우, 버스에 연결하려는 모든 프로세스는 '버스 주소'를 알아야 한다. 즉, 프로세스가 중앙 메시지 버스 프로세스에 D-Bus 연결을 설정할 수 있는 주소이다.[3][5] 이 시나리오에서 메시지 버스 데몬은 버스 주소를 선택하고 나머지 프로세스는 해당 값을 해당 `libdbus` 또는 이에 상응하는 라이브러리에 전달해야 한다. `dbus-daemon`은 제공하는 모든 버스 인스턴스에 대해 다른 버스 주소를 정의한다. 이러한 주소는 데몬의 구성 파일에 정의되어 있다.
두 프로세스는 D-Bus 연결을 사용하여 직접 메시지를 교환할 수 있지만,[4] 이것이 D-Bus가 일반적으로 사용하도록 의도된 방식은 아니다. 일반적인 방법은 각 프로세스가 지점 간 D-Bus 연결을 설정해야 하는 통신 중심 지점으로 항상 메시지 버스 데몬(예: `dbus-daemon`)을 사용하는 것이다. 프로세스(클라이언트 또는 서비스)가 D-Bus 메시지를 보내면 메시지 버스 프로세스가 먼저 메시지를 수신하여 해당 수신자에게 전달한다. 메시지 버스 데몬은 각 메시지를 해당 대상에 도달하도록 담당하는 허브 또는 라우터로 볼 수 있다. 메시지 버스 데몬은 메시지를 수신 프로세스에 대한 D-Bus 연결을 통해 반복한다.[5] 수신 프로세스는 메시지 헤더 필드의 대상 버스 이름에 의해 결정되거나[11] 신호 전파 메시지의 경우 메시지 버스 데몬이 유지 관리하는 신호에 대한 구독 정보에 의해 결정된다.[10] 메시지 버스 데몬은 존재하지 않는 버스 이름으로 메시지를 보낸 프로세스에 대한 오류 메시지와 같은 특정 조건에 대한 응답으로 자체 메시지를 생성할 수도 있다.[5]
`dbus-daemon`은 D-Bus 자체가 이미 제공하는 기능 세트를 추가 기능으로 향상시킨다. 예를 들어, '서비스 활성화'는 필요한 경우—해당 서비스의 버스 이름에 대한 첫 번째 요청이 메시지 버스 데몬에 도착할 때—서비스를 자동으로 시작할 수 있다.[3] 이렇게 하면 서비스 프로세스가 시스템 초기화 또는 사용자 초기화 단계에서 시작될 필요가 없으며 사용하지 않을 때 메모리 또는 다른 리소스를 소비할 필요가 없다. 이 기능은 원래 setuid 도우미를 사용하여 구현되었지만,[12] 요즘에는 systemd의 서비스 활성화 프레임워크에서도 제공할 수 있다. 서비스 활성화는 데스크톱 구성 요소의 시작 또는 중단과 같은 서비스의 프로세스 수명 주기를 관리하는 데 도움이 되는 중요한 기능이다.[5]
5. 구현체
D-Bus의 여러 구현체가 있지만, 가장 널리 사용되는 것은 freedesktop.org 프로젝트에서 개발한 레퍼런스 구현인 ''libdbus''이다. 그러나 libdbus는 응용 프로그램 개발자가 직접 사용하도록 설계되지 않았으며, D-Bus의 다른 재구현(데스크톱 환경의 표준 라이브러리 또는 프로그래밍 언어 바인딩에 포함된 것과 같은)에 대한 참조 가이드 역할을 한다. freedesktop.org 프로젝트 자체는 응용 프로그램 작성자에게 대신 "더 높은 수준의 바인딩 또는 구현 중 하나를 사용"할 것을 권장한다. libdbus가 가장 많이 사용되는 D-Bus 구현으로 우세해지면서 "D-Bus"와 "libdbus"라는 용어가 종종 같은 의미로 사용되어 혼란을 야기했다.
GDBus는 GLib에 포함된 GIO 스트림을 기반으로 하는 D-Bus의 구현체로, GTK+ 및 GNOME에서 사용될 수 있도록 설계되었다. GDBus는 libdbus의 래퍼가 아니라 D-Bus 명세 및 프로토콜의 완전하고 독립적인 재구현이다. MATE 데스크톱[7]과 Xfce (버전 4.14) 역시 GTK+ 3를 기반으로 하며 GDBus를 사용한다.
2013년, systemd 프로젝트는 코드를 단순화하기 위해 libdbus를 다시 작성했으며, 이는 전체 D-Bus 성능의 상당한 증가로 이어졌다. 초기 벤치마크에서 BMW는 systemd의 D-Bus 라이브러리가 성능을 360% 향상시켰다는 것을 발견했다. 2015년에 출시된 systemd 버전 221에서 sd-bus API는 안정적인 것으로 선언되었다.
''kdbus''는 D-Bus를 커널을 매개로 하는 프로세스 간 통신 메커니즘으로 재구현하는 것을 목표로 하는 프로젝트였다. kdbus는 성능 향상 외에도 리눅스 커널의 네임스페이스 및 감사 기능과 같은 다른 기능으로부터의 이점, 커널 중재로 인한 보안, 경합 조건 종료, 부팅 및 종료 시 D-Bus 사용 허용(systemd에서 필요)과 같은 이점을 제공했을 것이다. 리눅스 커널에 kdbus를 포함시키는 것은 논란이 있었고, 더 일반적인 프로세스 간 통신인 [https://github.com/bus1 BUS1]을 선호하여 중단되었다.[10]
6. 언어 바인딩
D-Bus를 위한 여러 프로그래밍 언어 바인딩이 개발되었으며, 자바, C#, 루비, 러스트, 펄 등이 그 예이다.
7. D-Bus를 이용하는 소프트웨어
D-Bus 데몬(dbus-daemon)은 메시지를 관리한다. 운영체제(OS) 부팅 중에 상시 실행되는 '''시스템 관리용 데몬'''과 해당 로그인 세션이 유효한 기간 동안 실행되는 '''로그인 세션 관리 데몬''' 두 가지가 있다. 시스템 관리용 데몬은 프린터 큐 추가, 장치 추가/삭제 등을 알린다. 세션별 데몬은 데스크톱 애플리케이션 간의 통신에 사용된다.
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
