Qt D-Bus 개요

D-Bus는 원래 리눅스를 위해 개발된 프로세스 간 통신(IPC) 및 원격 프로시저 호출(RPC) 메커니즘으로, 기존 및 경쟁적인 IPC 솔루션들을 하나의 통합된 프로토콜로 대체하기 위해 고안되었습니다. 또한 시스템 수준 프로세스(예: 프린터 및 하드웨어 드라이버 서비스)와 일반 사용자 프로세스 간의 통신을 가능하게 하도록 설계되었습니다.

D-Bus는 빠른 이진 메시지 전달 프로토콜을 사용하며, 낮은 지연 시간과 적은 오버헤드로 인해 동일 시스템 내 통신에 적합합니다. 현재 이 프로토콜의 사양은 freedesktop.org 프로젝트에서 정의하고 있으며, 모든 사용자에게 공개되어 있습니다.

일반적으로 통신은 “버스(bus)”라고 불리는 중앙 서버 애플리케이션을 통해 이루어지지만(이름의 유래), 애플리케이션 간 직접 통신도 가능합니다. 버스를 통해 통신할 때, 애플리케이션은 사용 가능한 다른 애플리케이션 및 서비스를 조회할 수 있을 뿐만 아니라 필요에 따라 이를 활성화할 수도 있습니다.

버스

D-Bus 버스는 다대다(many-to-many) 통신이 필요한 경우에 사용됩니다. 이를 위해, 어떤 애플리케이션도 버스에 연결하기 전에 중앙 서버가 먼저 시작됩니다. 이 서버는 연결된 애플리케이션을 추적하고, 메시지를 발신지에서 목적지까지 올바르게 라우팅하는 역할을 담당합니다.

또한, D-Bus는 시스템 버스(system bus)와 세션 버스(session bus)라고 불리는 두 가지 잘 알려진 버스를 정의합니다. 이 버스들은 명확하게 정의된 의미론을 가지고 있다는 점에서 특별합니다. 즉, 일부 서비스는 이 두 버스 중 하나 또는 둘 모두에서 찾을 수 있도록 정의되어 있습니다.

예를 들어, 컴퓨터에 연결된 하드웨어 장치 목록을 조회하려는 애플리케이션은 시스템 버스에서 제공되는 서비스와 통신할 가능성이 높으며, 사용자의 웹 브라우저를 실행하는 서비스는 세션 버스에서 찾을 수 있을 것입니다.

시스템 버스에서는 각 애플리케이션이 제공할 수 있는 서비스에 대한 제한 사항도 있을 것으로 예상할 수 있습니다. 따라서 특정 서비스가 존재한다면, 그 서비스는 신뢰할 수 있는 애플리케이션에 의해 제공되고 있다고 합리적으로 확신할 수 있습니다.

개념

메시지

저수준에서 애플리케이션은 서로 메시지를 주고받으며 D-Bus를 통해 통신합니다. 메시지는 원격 프로시저 호출(RPC)은 물론, 이와 관련된 응답 및 오류도 전달하는 데 사용됩니다. 버스를 통해 사용될 때 메시지에는 수신처가 지정되어 있으므로, 관심 있는 당사자에게만 라우팅되어 “스워밍(swarming)”이나 브로드캐스팅으로 인한 혼잡을 피할 수 있습니다.

그러나 “신호 메시지”(Qt의 신호 및 슬롯 ( Signals and Slots ) 메커니즘에 기반한 개념)라고 불리는 특수한 종류의 메시지는 미리 정의된 수신지가 없습니다. 이 메시지의 목적은 일대다(one-to-many) 컨텍스트에서 사용되는 것이므로, 신호 메시지는 “옵트인(opt-in)” 메커니즘을 통해 작동하도록 설계되었습니다.

Qt D-Bus 모듈은 메시지의 저수준 개념을 Qt 개발자에게 친숙한, 더 단순한 객체 지향적 접근 방식으로 완전히 캡슐화합니다. 대부분의 경우 개발자는 메시지 송수신에 대해 걱정할 필요가 없습니다.

서비스 이름

버스를 통해 통신할 때, 애플리케이션은 “서비스 이름”이라고 불리는 것을 얻습니다. 이는 해당 애플리케이션이 동일한 버스에 있는 다른 애플리케이션들에게 어떻게 인식되기를 원하는지를 나타내는 것입니다. 서비스 이름은 D-Bus 버스 데몬에 의해 중개되며, 한 애플리케이션에서 다른 애플리케이션으로 메시지를 라우팅하는 데 사용됩니다. 서비스 이름과 유사한 개념으로는 IP 주소와 호스트 이름이 있습니다. 컴퓨터는 일반적으로 하나의 IP 주소를 가지며, 네트워크에 제공하는 서비스에 따라 하나 이상의 호스트 이름이 연결될 수 있습니다.

반면, 버스를 사용하지 않는다면 서비스 이름도 사용되지 않습니다. 이를 다시 컴퓨터 네트워크에 비유하자면, 이는 지점 간(point-to-point) 네트워크에 해당합니다. 상대방이 이미 알려져 있으므로, 상대방을 찾거나 그 IP 주소를 확인하기 위해 호스트 이름을 사용할 필요가 없습니다.

D-Bus 서비스 이름의 형식은 사실 호스트 이름과 매우 유사합니다. 즉, 점(.)으로 구분된 문자와 숫자의 조합입니다. 일반적인 관행으로는 해당 서비스를 정의한 조직의 도메인 이름에 따라 서비스 이름을 짓기도 합니다.

예를 들어, freedesktop.org 에서 정의한 D-Bus 서비스는 버스에서 다음 서비스 이름으로 찾을 수 있습니다:

org.freedesktop.DBus

객체 경로

네트워크 호스트와 마찬가지로, 애플리케이션은 객체를 노출함으로써 다른 애플리케이션에 특정 서비스를 제공합니다. 이러한 객체들은 QObject 에서 파생된 클래스들이 가지는 부모-자식 관계와 매우 유사하게 계층적으로 구성됩니다. 그러나 한 가지 차이점은 모든 객체가 최상위 부모로 갖는 “루트 객체”라는 개념이 존재한다는 것입니다.

웹 서비스와의 비유를 이어가자면, 객체 경로는 URL의 경로 부분과 동일합니다:

이와 마찬가지로, D-Bus의 객체 경로는 파일 시스템의 경로 이름과 유사하게 구성됩니다. 즉, 슬래시(/)로 구분된 레이블로 이루어지며, 각 레이블은 영문자, 숫자 및 밑줄 문자("_")로 구성됩니다. 객체 경로는 반드시 슬래시로 시작해야 하며, 슬래시로 끝나서는 안 됩니다.

인터페이스

인터페이스는 C++의 추상 클래스나 Java의 interface 키워드와 유사하며, 호출자와 피호출자 사이에 수립되는 “계약”을 선언합니다. 즉, 인터페이스는 사용 가능한 메서드, 시그널 및 속성의 이름을 정의할 뿐만 아니라, 통신이 수립되었을 때 양측에서 기대되는 동작도 규정합니다.

Qt는 플러그인 시스템에서 매우 유사한 메커니즘을 사용합니다. C++의 기본 클래스는 Q_DECLARE_INTERFACE() 매크로를 통해 고유 식별자와 연결됩니다.

사실 Qt D-Bus 인터페이스 이름은 Qt 플러그인 시스템에서 제안하는 방식과 유사하게 명명됩니다. 즉, 해당 인터페이스를 정의한 엔티티의 도메인 이름을 기반으로 식별자가 구성되는 경우가 일반적입니다.

참고 자료

명명 형식과 그 용도를 쉽게 기억할 수 있도록 다음 표를 참고할 수 있습니다:

디버깅

D-Bus를 사용하는 애플리케이션을 개발할 때, 각 애플리케이션이 버스를 통해 주고받는 메시지에 대한 정보를 확인할 수 있다면 유용할 때가 있습니다.

이 기능은 각 애플리케이션을 실행하기 전에 ` QDBUS_DEBUG ` 환경 변수를 설정하여 애플리케이션별로 활성화할 수 있습니다. 예를 들어, D-Bus 원격 제어 자동차 예제에서 자동차에 대해서만 디버깅을 활성화하려면 다음과 같은 방식으로 컨트롤러와 자동차를 실행하면 됩니다.

examples/dbus/remotecontrolledcar/controller/controller &
QDBUS_DEBUG=1 examples/dbus/remotecontrolledcar/car/car &

메시지에 대한 정보는 해당 애플리케이션이 실행된 콘솔에 출력됩니다.