통신

D-bus 튜토리얼

desafinado 2024. 1. 26. 11:08
728x90

 

 

D-Bus란 무엇인가?

D-Bus 애플리케이션

 

개념

  • 네이티브 객체 및 객체 경로
  • 메소드와 신호
  • 인터페이스
  • 프록시
  • 버스 이름
  • 주소
  • 큰 개념적 그림
  • 메시지 - 뒤에서 일어나는 일
  • 메소드 호출 - 뒤에서 일어나는 일
  • 신호 방출 - 뒤에서 일어나는 일
  • 인트로스펙션

    GLib API
    파이썬 API
    Qt API

 

 

 

 

Tutorial Work In Progress

이 튜토리얼은 완성되지 않았습니다; 아마도 유용한 정보를 담고 있겠지만, 여러 부분에서 빈틈이 있습니다. 현재로서는, D-Bus 명세, Doxygen 참조 문서를 참조하고, 다른 앱들이 D-Bus를 어떻게 사용하는지 몇 가지 예제를 봐야 할 것입니다.

이 튜토리얼을 개선하는 것은 분명히 권장됩니다 - 패치나 제안을 메일링 리스트로 보내주세요. 만약 D-Bus 바인딩을 만들었다면, 귀하의 바인딩에 대한 섹션을 튜토리얼에 추가해주세요, 비록 짧은 섹션이라도 몇 가지 예제와 함께 말이죠.

 

 

 

What is D-Bus?

D-Bus는 프로세스 간 통신(IPC)을 위한 시스템입니다. 구조적으로 여러 계층이 있습니다:

  • 두 애플리케이션이 서로 연결되어 메시지를 교환할 수 있게 하는 라이브러리, libdbus.
  • libdbus를 기반으로 하는 메시지 버스 데몬 실행 파일로, 여러 애플리케이션이 연결될 수 있습니다. 데몬은 한 애플리케이션으로부터 온 메시지를 다른 애플리케이션으로 라우팅할 수 있습니다.
  • 특정 애플리케이션 프레임워크를 기반으로 하는 래퍼 라이브러리나 바인딩들. 예를 들어, libdbus-glib 및 libdbus-qt가 있습니다. 또한 Python과 같은 언어로 바인딩도 있습니다. 이러한 래퍼 라이브러리는 대부분의 사람들이 사용해야 할 API입니다. 왜냐하면 이들은 D-Bus 프로그래밍의 세부 사항을 단순화하기 때문입니다. libdbus는 더 높은 수준의 바인딩을 위한 저수준 백엔드로 의도되었습니다. libdbus API의 많은 부분은 바인딩 구현을 위해 유용합니다.
  • libdbus는 원시 네트워크 소켓과 마찬가지로 일대일 연결만 지원합니다. 그러나 연결을 통해 바이트 스트림을 보내는 대신 메시지를 보냅니다. 메시지에는 메시지 종류를 식별하는 헤더와 데이터 페이로드를 포함하는 본문이 있습니다. libdbus는 또한 사용되는 정확한 전송(소켓 대 기타)을 추상화하고 인증과 같은 세부 사항을 처리합니다.
  • 메시지 버스 데몬은 바퀴의 중심을 형성합니다. 바퀴의 각 스포크는 libdbus를 사용하는 애플리케이션과의 일대일 연결입니다. 애플리케이션은 자신의 스포크를 통해 데몬에 메시지를 보내고, 데몬은 다른 연결된 애플리케이션에 적절하게 메시지를 전달합니다. 데몬을 라우터로 생각하면 됩니다.
  • 일반적인 컴퓨터에서 메시지 버스 데몬은 여러 인스턴스를 가집니다. 첫 번째 인스턴스는 시스템 데몬으로, sendmail이나 Apache와 같은 기계 전역 싱글톤입니다. 이 인스턴스는 어떤 메시지를 수락할지에 대해 엄격한 보안 제한을 가지고 있으며, 시스템 전체의 통신에 사용됩니다. 다른 인스턴스들은 사용자 로그인 세션당 하나씩 생성됩니다. 이 인스턴스들은 사용자의 세션 내 애플리케이션들이 서로 통신할 수 있게 합니다.
  • 시스템 전체와 사용자당 데몬은 별개입니다. 일반적인 세션 내 IPC는 시스템 전체 메시지 버스 프로세스와 관련이 없으며 그 반대도 마찬가지입니다.

 

 

D-Bus applications

D-Bus 애플리케이션

세계에는 "프로세스 간 통신" 또는 "네트워킹"을 목적으로 하는 수많은 기술들이 있습니다: CORBA, DCE, DCOM, DCOP, XML-RPC, SOAP, MBUS, 인터넷 커뮤니케이션 엔진(ICE) 등이 있으며, 아마도 수백 개가 더 있을 것입니다. 이들 각각은 특정한 종류의 애플리케이션을 위해 맞춤화되어 있습니다. D-Bus는 두 가지 구체적인 경우를 위해 설계되었습니다:

  1. 동일한 데스크톱 세션 내의 데스크톱 애플리케이션 간의 통신; 데스크톱 세션 전체의 통합을 가능하게 하고, 프로세스 생명주기(데스크톱 구성요소가 언제 시작하고 중지되는지)의 문제를 해결하기 위해.
  2. 데스크톱 세션과 운영 체제 간의 통신; 여기서 운영 체제는 일반적으로 커널과 모든 시스템 데몬 또는 프로세스를 포함합니다.

데스크톱 세션 내 사용 사례의 경우, GNOME과 KDE 데스크톱은 CORBA 및 DCOP와 같은 다양한 IPC 솔루션에 대한 상당한 경험이 있습니다. D-Bus는 그 경험을 바탕으로 하여 특히 이러한 데스크톱 프로젝트의 요구를 충족시키기 위해 신중하게 맞춤화되었습니다. D-Bus는 다른 애플리케이션에 적합할 수도, 그렇지 않을 수도 있으며, FAQ에는 다른 IPC 시스템과의 비교가 있습니다.

시스템 전체 또는 운영 체제와의 통신 사례가 해결하는 문제는 Linux Hotplug 프로젝트의 다음 텍스트에 잘 설명되어 있습니다:

현재 리눅스 지원에서 부족한 부분은 어떤 종류의 동적 "사용자와 상호 작용" 구성 요소가 현재 지원되지 않는다는 것입니다. 예를 들어, 네트워크 어댑터나 프린터가 처음 연결될 때, 또는 디스크 드라이브를 마운트할 적절한 장소를 결정할 때 종종 필요합니다. 이러한 작업은 책임 있는 인간을 식별할 수 있는 경우에 지원될 수 있을 것 같습니다: 단일 사용자 워크스테이션 또는 원격으로 관리되는 어떤 시스템이든.

이것은 전형적인 "원격 시스템 관리자" 문제입니다. 여기서는 이 경우 핫플러그가 한 보안 도메인(이 경우 운영 체제 커널)에서 다른 도메인(로그인한 사용자의 데스크톱 또는 원격 시스템 관리자)으로 이벤트를 전달해야 합니다. 효과적인 응답은 반대 방향으로 이루어져야 합니다: 원격 도메인이 커널이 원하는 장치 기능을 노출할 수 있도록 어떤 행동을 취합니다. (행동은 종종 비동기적으로 취해질 수 있으며, 예를 들어 회의가 끝날 때까지 새 하드웨어를 유휴 상태로 두는 것과 같습니다.) 이 글을 쓰는 시점에, 리눅스는 이러한 문제에 대한 널리 채택된 해결책을 가지고 있지 않습니다. 그러나 새로운 D-Bus 작업은 이 문제를 해결하기 시작할 수 있습니다.

D-Bus는 설계된 목적 외에도 다른 용도로 유용할 수 있습니다. 다른 IPC 형식과 구별되는 일반적인 특성은 다음과 같습니다:

  • 비동기적으로 사용하기 위해 설계된 이진 프로토콜(영감을 받은 것은 X 윈도우 시스템 프로토콜과 유사).
  • 시간이 지남에 따라 지속적으로 유지되는 상태 있는, 신뢰할 수 있는 연결.
  • 메시지 버스는 "떼"나 분산 아키텍처가 아닌 데몬입니다.
  • 많은 구현 및 배포 문제가 모호하거나 구성 가능/플러그인 가능하게 남겨지는 대신 명시되어 있습니다.
  • 기존 DCOP 시스템과 유사한 의미론, 이로 인해 KDE가 더 쉽게 채택할 수 있습니다.
  • 메시지 버스의 시스템 전체 모드를 지원하는 보안 기능.

 

개념 D-Bus 애플리케이션을 작성할 때 사용하는 애플리케이션 프레임워크에 상관없이 몇 가지 기본 개념이 적용됩니다. 하지만 GLib, Qt, Python 애플리케이션에 대한 실제 작성하는 코드는 다를 것입니다.

다음에 설명될 개념들을 시각화하는 데 도움이 될 수 있는 다이어그램(png 또는 svg)이 여기에 있습니다.

(위에 첨부한 다이어 그램)

 

 

 

 

Native Objects and Object Paths

네이티브 객체 및 객체 경로

 

프로그래밍 프레임워크는 대체로 "객체"가 어떤 것인지 정의합니다; 보통은 기본 클래스를 통해 정의합니다. 예를 들어, java.lang.Object, GObject, QObject, 파이썬의 기본 Object, 또는 그와 유사한 것들입니다. 이를 네이티브 객체라고 부릅시다.

저수준 D-Bus 프로토콜 및 해당하는 libdbus API는 네이티브 객체에 대해서는 신경 쓰지 않습니다. 그러나 객체 경로라는 개념을 제공합니다. 객체 경로의 아이디어는 상위 레벨 바인딩이 네이티브 객체 인스턴스에 이름을 붙일 수 있게 하고, 원격 애플리케이션들이 그것들을 참조할 수 있게 하는 것입니다.

객체 경로는 파일 시스템 경로와 유사하게 보이는데, 예를 들어 객체는 /org/kde/kspread/sheets/3/cells/4/5 처럼 명명될 수 있습니다. 사람이 읽을 수 있는 경로는 좋지만, /com/mycompany/c5yo817y0c1y1c5b와 같은 객체를 만드는 것이 애플리케이션에 맞다면 자유롭게 생성할 수 있습니다.

객체 경로에 네임스페이스를 지정하는 것이 현명합니다. 소유한 도메인 이름의 구성 요소로 시작함으로써 (/org/kde와 같이), 같은 프로세스 내의 다른 코드 모듈들이 서로의 발목을 잡지 않도록 할 수 있습니다.

 

Methods and Signals

메소드와 신호

 

각 객체는 멤버를 가지고 있으며, 멤버의 두 가지 종류는 메소드와 신호입니다. 메소드는 객체에 대해 수행될 수 있는 작업으로, 선택적 입력(인수 또는 "입력 파라미터"라고 함)과 출력(반환 값 또는 "출력 파라미터"라고 함)을 포함할 수 있습니다. 신호는 객체로부터 관심을 가진 관찰자들에게 보내는 방송으로, 신호에는 데이터 페이로드가 포함될 수 있습니다.

메소드와 신호는 모두 이름으로 참조되며, 예를 들어 "Frobate" 또는 "OnClicked"와 같습니다.

Interfaces

인터페이스

 

각 객체는 하나 이상의 인터페이스를 지원합니다. 인터페이스를 GLib, Qt, Java와 같이 메소드와 신호의 명명된 그룹으로 생각하십시오. 인터페이스는 객체 인스턴스의 유형을 정의합니다.

DBus는 org.freedesktop.Introspectable 같은 단순한 네임스페이스 문자열로 인터페이스를 식별합니다. 대부분의 바인딩은 이러한 인터페이스 이름을 해당 프로그래밍 언어 구조로 직접 매핑할 것입니다. 예를 들어 Java 인터페이스나 C++ 순수 가상 클래스로 매핑됩니다.

 

 

Proxies

프록시

프록시 객체는 다른 프로세스의 원격 객체를 나타내기 위해 생성된 편리한 네이티브 객체입니다. 저수준 DBus API는 수동으로 메소드 호출 메시지를 생성하고, 보내고, 그 다음 메소드 응답 메시지를 수동으로 받고 처리하는 것을 포함합니다. 더 높은 수준의 바인딩은 대신 프록시를 제공합니다. 프록시는 일반 네이티브 객체처럼 보이지만, 프록시 객체에 메소드를 호출하면 바인딩이 이를 DBus 메소드 호출 메시지로 변환하고, 응답 메시지를 기다렸다가 반환 값을 풀고, 네이티브 메소드에서 이를 반환합니다.

가상 코드로, 프록시 없이 프로그래밍하는 것은 다음과 같이 보일 수 있습니다:

Message message = new Message("/remote/object/path", "MethodName", arg1, arg2);
Connection connection = getBusConnection();
connection.send(message);
Message reply = connection.waitForReply(message);
if (reply.isError()) {
  
} else {
  Object returnValue = reply.getReturnValue();
}

프록시를 사용하여 프로그래밍하는 것은 다음과 같이 보일 수 있습니다:

Proxy proxy = new Proxy(getBusConnection(), "/remote/object/path");
Object returnValue = proxy.MethodName(arg1, arg2);

 

 

Bus Names

버스 이름

각 애플리케이션이 버스 데몬에 연결할 때, 데몬은 즉시 고유 연결 이름이라는 이름을 할당합니다. 고유 이름은 ':'(콜론) 문자로 시작합니다. 이러한 이름들은 버스 데몬의 수명 동안 절대 재사용되지 않습니다 - 즉, 주어진 이름이 항상 동일한 애플리케이션을 참조한다는 것을 알 수 있습니다. 고유 이름의 예로는 :34-907이 있습니다. 콜론 뒤의 숫자는 고유성 외에는 의미가 없습니다.

이름이 특정 애플리케이션의 연결과 매핑되면, 해당 애플리케이션은 그 이름을 소유하고 있다고 합니다.

애플리케이션은 추가적인 잘 알려진 이름을 소유하도록 요청할 수 있습니다. 예를 들어, com.mycompany.TextEditor라는 이름을 정의하는 명세를 작성할 수 있습니다. 귀하의 정의에 따르면, 이 이름을 소유하기 위해 애플리케이션은 /com/mycompany/TextFileManager 경로에 객체를 두고 org.freedesktop.FileHandler 인터페이스를 지원해야 합니다.

그런 다음 애플리케이션들은 이 버스 이름, 객체, 및 인터페이스에 메시지를 보내 메소드 호출을 실행할 수 있습니다.

고유 이름을 IP 주소로, 잘 알려진 이름을 도메인 이름으로 생각할 수 있습니다. 따라서 com.mycompany.TextEditor는 mycompany.com이 192.168.0.5와 같은 것에 매핑되는 것처럼 :34-907에 매핑될 수 있습니다.

메시지 라우팅 외에도 이름은 또 다른 중요한 용도가 있습니다. 그것은 생명주기 추적입니다. 애플리케이션이 종료되거나 충돌할 경우, 운영 체제 커널에 의해 메시지 버스에 대한 연결이 닫힙니다. 그런 다음 메시지 버스는 남은 애플리케이션들에게 애플리케이션의 이름이 소유자를 잃었다는 알림 메시지를 보냅니다. 이러한 알림을 추적함으로써, 귀하의 애플리케이션은 다른 애플리케이션의 수명을 신뢰성 있게 모니터링할 수 있습니다.

버스 이름은 또한 단일 인스턴스 애플리케이션을 조율하는 데에도 사용될 수 있습니다. 예를 들어, 한 번에 하나의 com.mycompany.TextEditor 애플리케이션이 실행되도록 하려면, 버스 이름에 이미 소유자가 있는 경우 텍스트 편집기 애플리케이션을 종료하게 하십시오.

 

 

Addresses

주소

D-Bus를 사용하는 애플리케이션은 서버 또는 클라이언트입니다. 서버는 들어오는 연결을 기다리며, 클라이언트는 서버에 연결합니다. 연결이 설정되면, 메시지의 대칭적인 흐름이 있으며, 클라이언트-서버 구분은 연결을 설정할 때만 중요합니다.

버스 데몬을 사용하는 경우, 귀하의 애플리케이션은 버스 데몬의 클라이언트가 될 것입니다. 즉, 버스 데몬은 연결을 기다리고 귀하의 애플리케이션은 버스 데몬에 연결을 시작합니다.

D-Bus 주소는 서버가 어디에서 듣고 클라이언트가 어디에 연결할지를 지정합니다. 예를 들어, unix:path=/tmp/abcdef 주소는 서버가 /tmp/abcdef 경로의 UNIX 도메인 소켓에서 듣고 클라이언트가 해당 소켓에 연결할 것임을 지정합니다. 주소는 TCP/IP 소켓이나 D-Bus 사양의 향후 반복에서 정의된 다른 전송을 지정할 수도 있습니다.

메시지 버스 데몬과 함께 D-Bus를 사용할 때, libdbus는 환경 변수를 읽어 세션별 버스 데몬의 주소를 자동으로 발견합니다. 시스템 전체 버스 데몬은 잘 알려진 UNIX 도메인 소켓 경로를 확인하여 발견합니다(환경 변수로 이 주소를 재정의할 수 있습니다).

버스 데몬 없이 D-Bus를 사용하는 경우, 어떤 애플리케이션이 서버가 될지, 어떤 것이 클라이언트가 될지를 정의하고, 서버의 주소에 동의하기 위한 메커니즘을 지정하는 것은 귀하에게 달려 있습니다. 이는 드문 경우입니다.

 

 

Big Conceptual Picture

큰 개념적 그림

이러한 모든 개념을 종합해보면, 특정 객체 인스턴스에서 특정 메소드 호출을 지정하기 위해 여러 중첩된 구성 요소들이 명명되어야 합니다:

 

주소 -> [버스 이름] -> 경로 -> 인터페이스 -> 메소드

 

버스 이름은 대괄호 안에 있어 선택 사항임을 나타냅니다 -- 버스 데몬을 사용할 때 메소드 호출을 올바른 애플리케이션으로 라우팅하기 위해 이름을 제공하는 경우에만 필요합니다. 다른 애플리케이션과 직접 연결된 경우에는 버스 이름이 사용되지 않습니다; 버스 데몬이 없기 때문입니다.

인터페이스도 선택 사항이며, 주로 역사적인 이유 때문입니다; DCOP는 인터페이스를 지정할 필요가 없으며, 대신 동일한 객체 인스턴스에서 메소드 이름의 중복을 금지합니다. 따라서 D-Bus는 인터페이스를 생략할 수 있도록 하지만, 메소드 이름이 모호한 경우 어떤 메소드가 호출될지는 정의되어 있지 않습니다.

 

Messages - Behind the Scenes

메시지 - 뒤에서 일어나는 일

D-Bus는 프로세스 간에 메시지를 보내는 방식으로 작동합니다. 충분히 고급 바인딩을 사용하는 경우, 직접 메시지를 다룰 필요가 없을 수도 있습니다.

4가지 유형의 메시지가 있습니다:

  • 메소드 호출 메시지는 객체에서 메소드를 호출하도록 요청합니다.
  • 메소드 반환 메시지는 메소드 호출의 결과를 반환합니다.
  • 에러 메시지는 메소드를 호출하는 과정에서 발생한 예외를 반환합니다.
  • 신호 메시지는 주어진 신호가 방출되었다는 것(어떤 이벤트가 발생했다는 것)을 알리는 알림입니다. 이를 "이벤트" 메시지로 생각할 수도 있습니다.

메소드 호출은 메시지에 매우 간단하게 매핑됩니다: 메소드 호출 메시지를 보내고, 응답으로 메소드 반환 메시지 또는 에러 메시지를 받습니다.

각 메시지에는 필드를 포함하는 헤더와, 인자를 포함하는 본문이 있습니다. 헤더를 메시지의 라우팅 정보로, 본문을 페이로드로 생각할 수 있습니다. 헤더 필드에는 보내는 버스 이름, 목적지 버스 이름, 메소드 또는 신호 이름 등이 포함될 수 있습니다. 헤더 필드 중 하나는 본문에 있는 값들을 설명하는 타입 시그니처입니다. 예를 들어, "i" 문자는 "32비트 정수"를 의미하므로, 시그니처 "ii"는 페이로드에 두 개의 32비트 정수가 있다는 것을 의미합니다.

 

 

Calling a Method - Behind the Scenes

메소드 호출 - 뒤에서 일어나는 일

 

DBus에서의 메소드 호출은 두 개의 메시지로 구성됩니다; 프로세스 A에서 프로세스 B로 보내진 메소드 호출 메시지와, 프로세스 B에서 프로세스 A로 보내진 매칭 메소드 응답 메시지입니다. 호출과 응답 메시지 모두 버스 데몬을 통해 라우팅됩니다. 호출자는 각 호출 메시지에 다른 일련 번호를 포함하고, 응답 메시지는 이 번호를 포함하여 호출자가 호출에 대한 응답을 매칭할 수 있도록 합니다.

호출 메시지에는 메소드에 대한 인자가 포함됩니다. 응답 메시지는 오류를 나타낼 수도 있고, 메소드에 의해 반환된 데이터를 포함할 수도 있습니다.

DBus에서 메소드 호출은 다음과 같이 이루어집니다:

  • 언어 바인딩은 프록시를 제공하여 프로세스 내 객체에서 메소드를 호출하면 다른 프로세스의 원격 객체에서 메소드가 호출되도록 할 수 있습니다. 이 경우, 애플리케이션은 프록시에서 메소드를 호출하고, 프록시는 원격 프로세스로 보낼 메소드 호출 메시지를 구성합니다.
  • 보다 저수준 API를 사용하는 경우, 애플리케이션은 프록시를 사용하지 않고 직접 메소드 호출 메시지를 구성할 수 있습니다.
  • 어느 경우에든 메소드 호출 메시지에는 원격 프로세스에 속하는 버스 이름, 메소드 이름, 메소드 인자, 원격 프로세스 내의 객체 경로, 그리고 선택적으로 메소드를 지정하는 인터페이스 이름이 포함됩니다.
  • 메소드 호출 메시지는 버스 데몬으로 전송됩니다.
  • 버스 데몬은 목적지 버스 이름을 확인합니다. 그 이름을 소유한 프로세스가 있으면, 버스 데몬은 해당 프로세스로 메소드 호출을 전달합니다. 그렇지 않으면, 버스 데몬은 오류 메시지를 생성하고 메소드 호출 메시지에 대한 응답으로 이를 보냅니다.
  • 수신 프로세스는 메소드 호출 메시지를 분석합니다. 단순한 저수준 API 상황에서는 즉시 메소드를 실행하고 버스 데몬에 메소드 응답 메시지를 보낼 수 있습니다. 고급 바인딩 API를 사용하는 경우, 바인딩은 객체 경로, 인터페이스, 메소드 이름을 검토하고 메소드 호출 메시지를 네이티브 객체(GObject, java.lang.Object, QObject 등)의 메소드 호출로 변환한 다음, 네이티브 메소드의 반환 값을 메소드 응답 메시지로 변환할 수 있습니다.
  • 버스 데몬은 메소드 응답 메시지를 받고 이를 메소드 호출을 한 프로세스에 보냅니다.
  • 메소드 호출을 한 프로세스는 메소드 응답을 확인하고 응답에 포함된 반환 값을 사용합니다. 응답은 오류가 발생했음을 나타낼 수도 있습니다. 바인딩을 사용하는 경우, 메소드 응답 메시지는 프록시 메소드의 반환 값이나 예외로 변환될 수 있습니다.
  • 버스 데몬은 메시지의 순서를 변경하지 않습니다. 즉, 동일한 수신자에게 두 개의 메소드 호출 메시지를 보내면, 보낸 순서대로 수신됩니다. 수신자는 호출에 대한 응답을 순서대로 처리할 필요는 없습니다. 예를 들어, 각 메소드 호출을 별도의 스레드에서 처리하고 스레드 완료 시점에 따라 응답 메시지를 정의되지 않은 순서로 반환할 수 있습니다. 메소드 호출에는 메소드 호출자가 응답 메시지를 호출 메시지와 매치하기 위해 사용하는 고유 일련 번호가 있습니다.

 

 

Emitting a Signal - Behind the Scenes

신호 방출 - 뒤에서 일어나는 일

 

DBus에서의 신호는 하나의 메시지로 구성되며, 하나의 프로세스에서 다른 프로세스들에게 보내집니다. 즉, 신호는 단방향 방송입니다. 신호는 인자(데이터 페이로드)를 포함할 수 있지만, 방송이기 때문에 "반환 값"이 없습니다. 이는 메소드 호출과 대조됩니다(“메소드 호출 - 뒤에서 일어나는 일” 섹션 참조) 메소드 호출 메시지에는 매칭되는 메소드 응답 메시지가 있습니다.

신호 발신자(또는 송신자)는 신호 수신자에 대해 알지 못합니다. 수신자는 "매치 규칙"을 기반으로 버스 데몬에 신호 수신을 등록합니다 - 이러한 규칙은 일반적으로 송신자와 신호 이름을 포함합니다. 버스 데몬은 관심을 표한 수신자에게만 각 신호를 보냅니다.

DBus에서 신호는 다음과 같이 이루어집니다:

  • 신호 메시지가 생성되어 버스 데몬에 전송됩니다. 저수준 API를 사용하는 경우 이 작업은 수동으로 수행될 수 있으며, 특정 바인딩을 사용하는 경우 네이티브 객체가 네이티브 신호 또는 이벤트를 발생시킬 때 바인딩에 의해 자동으로 수행될 수 있습니다.
  • 신호 메시지에는 신호를 지정하는 인터페이스의 이름, 신호의 이름, 신호를 보내는 프로세스의 버스 이름, 그리고 모든 인자가 포함됩니다.
  • 메시지 버스의 모든 프로세스는 관심 있는 신호를 나타내는 "매치 규칙"을 등록할 수 있습니다. 버스에는 등록된 매치 규칙의 목록이 있습니다.
  • 버스 데몬은 신호를 검사하고 그것에 관심 있는 프로세스를 결정합니다. 그런 다음 이러한 프로세스에 신호 메시지를 보냅니다.
  • 신호를 받는 각 프로세스는 이에 대해 무엇을 할지 결정합니다. 바인딩을 사용하는 경우, 바인딩은 프록시 객체에서 네이티브 신호를 발생시킬 수도 있습니다. 저수준 API를 사용하는 경우, 프로세스는 신호 송신자와 이름을 보고 그에 기반하여 무엇을 할지 결정할 수 있습니다.

Introspection

인트로스펙션

 

D-Bus 객체는 org.freedesktop.DBus.Introspectable 인터페이스를 지원할 수 있습니다. 이 인터페이스에는 인자를 취하지 않고 XML 문자열을 반환하는 Introspect라는 하나의 메소드가 있습니다. XML 문자열은 객체의 인터페이스, 메소드 및 신호를 설명합니다. 이 인트로스펙션 형식에 대한 자세한 내용은 D-Bus 사양을 참조하십시오.

 

 

 

GLib APIs

GLib API

 

D-Bus에 권장되는 GLib API는 GLib 버전 2.26부터 배포된 GDBus입니다. 여기에서는 문서화되어 있지 않습니다. GDBus 사용 방법에 대한 자세한 내용은 GLib 문서를 참조하십시오.

더 오래된 API인 dbus-glib도 존재합니다. 이것은 더 이상 사용되지 않으며 새 코드에서는 사용되어서는 안 됩니다. 가능한 경우 기존 코드를 dbus-glib에서 GDBus로 포팅하는 것도 권장됩니다.

https://developer.gnome.org/gio/stable/gdbus-convenience.html

 

Gio-2.0

Reference for Gio-2.0

docs.gtk.org

 

Python API

파이썬 API

파이썬 API인 dbus-python은 이제 dbus-python 튜토리얼(또한 dbus-python 소스 배포판에서 python-docutils로 빌드된 경우 doc/tutorial.txt 및 doc/tutorial.html에서도 사용 가능)에서 별도로 문서화되어 있습니다.

http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html

 

Qt API

Qt API

libdbus를 위한 Qt 바인딩인 QtDBus는 Qt 버전 4.2부터 Qt와 함께 배포되었습니다. 여기에서는 문서화되어 있지 않습니다. QtDBus 사용 방법에 대한 자세한 내용은 Qt 문서를 참조하십시오.

http://qt-project.org/doc/qt-5/qtdbus-index.html

 

출처)https://dbus.freedesktop.org/doc/dbus-tutorial.html

 

D-Bus Tutorial

Tutorial Work In Progress This tutorial is not complete; it probably contains some useful information, but also has plenty of gaps. Right now, you'll also need to refer to the D-Bus specification, Doxygen reference documentation, and look at some examples

dbus.freedesktop.org

 

 

 

728x90
저작자표시 (새창열림)