컴퓨터 세상에는 다양한 개발자들이 개발한 수 많은 앱들이 있다. 안드로이드를 예로 들어보자. 우리는 유투브로 마음에 드는 영상을 "공유" 버튼을 클릭해서 카카오톡으로 친구에게 공유한다. 친구가 공유받은 영상을 보던 중에 스카이프 영상통화가 오면, 영상통화를 하는 중에 유투브는 자동으로 정지된다. 유투브와 카카오톡, 스카이프는 모두 서로 다른 개발자가 만들었다. 이처럼 서드파티가 개발한 앱들이 자연스럽게 소통을 주고 받는 일이, 기존 리눅스 IPC만을 이용해서 가능할까? 기술적으로는 가능하겠지만, 현실적으로는 불가능할 것이다. 그렇다면 왜 현실적으로 기존 리눅스 IPC로 서드파티 앱들간 소통이 어려울까?
대략 다음과 같은 이유들이 있을 수 있다.
- 통신 방식이 서로 제각각이다. (e.g. 유닉스 도메인 소켓, 메시지큐 등)
- 자료구조가 통일되지 못했다.
- IPC에 사용되는 채널이 제각각 다르다. (유닉스 도메인 소켓이라면, 어떤 소켓 파일을 사용하는지 각각 다르다.)
- 결정적으로 상대방이 어떤 통신 방식을 사용하고, 어떤 자료구조를 사용하며, 어떤 채널을 사용하는지 알 수 없다.
이러한 문제를 해결하기 위해서 안드로이드는 바인더라는 IPC 시스템을 개발하여 앱들간 통신에 사용하고 있다.
안드로이드와 마찬가지로 리눅스 세상에서도 이와 비슷한 문제가 있었다. 따라서 리눅스 커뮤니티에서도 기존 IPC의 한계를 극복하기 위해서 여러 IPC 시스템을 개발했었다. 대표적으로 Cobra, Dcop 등이 있었다. 이들은 어느정도 기존 IPC의 한계를 극복하며, 리눅스 생태계에 정착되었다. 하지만 여전히 큰 문제가 남아 있었다. 바로 "여러 IPC 시스템"을 개발했기 때문에, IPC 시스템 간 파편화가 발생한 것이다. 결국 리눅스 커뮤니티들은 의견을 모아서 통일된 IPC 시스템을 개발하였고, 이것이 지금 다루려고 하는 D-Bus이다.
D-Bus는 모던 방식의 IPC 시스템이다. 오래된 리눅스 IPC와 비교하여 D-Bus는 아래와 같은 특징을 가지고 있다. (리눅스 기존 IPC에서도 일부 항목은 해당되기도 한다.)
- 주소 기반 메시지 시스템
- 서비스 데몬이 메시지 관리 (프로세스가 종료되어도 메시지 상태 유지)
- 비동기 동작 (Notification 기능)
- 광역 브로드캐스팅기능 제공
- 데이터 인터페이스, 타입 공유
- 객체지향적인 API 설계(GDbus 한정)
그러면 D-Bus가 이러한 특징을 제공하기 위해서 어떤 구조를 가지고 있는지 살펴보자.
참고사이트
'Programming > Communication' 카테고리의 다른 글
| ttySx, ttyUSBx, ttyACMx (0) | 2023.08.15 |
|---|---|
| gRPC-web 사용하기 (0) | 2022.12.08 |
| Apache Thrift (0) | 2022.12.05 |
| MQTT (Message Queue Telemetry Transport): mosquitto (0) | 2022.12.05 |
