Linux-тағы D Bus орталық бағдарламасы

Кіріспе

Linux аралық бағдарламалық қамтамасыз ету

D-Bus (Desktop Bus деп қысқартылған) – бір машинада бір уақытта іске қосылған бірнеше процестер арасында байланыс орнатуға мүмкіндік беретін хабарға бағытталған аралық бағдарламалық қамтамасыз ету механизмі. D-Bus, GNOME әзірлеушісі Havoc Pennington бастамасымен құрылған freedesktop.org жобасының бір бөлігі ретінде әзірленді, мақсаты GNOME және KDE сияқты Linux десктоп орталары ұсынатын қызметтерді стандарттау болды. freedesktop.org жобасы сонымен қатар спецификацияның анықталған нұсқасы ретінде libdbus деп аталатын тегін және ашық кодты бағдарламалық кітапхананы да әзірледі. Бұл кітапхананы D-Bus-пен шатастыруға болмайды, себебі D-Bus спецификациясының басқа да іске асырылымдары бар, мысалы GDBus (GNOME), QtDBus (Qt/KDE), dbus-java және sd-bus (systemd құрамында).

Автобус үлгісі

Автобуспен әрбір байланыс D Bus контекстінде автобус атауы деп аталады. Автобус атауы әріптердің, сандардың, дефистердің және астын сызулардың нүктелермен бөлінген екі немесе одан көп тізбегінен тұрады. Жарамды автобус атауының мысалы:
Процесс автобуспен байланыс орнатқанда, автобус сол байланысқа бірегей байланыс атауы деп аталатын арнайы автобус атауын тағайындайды. Осы типтегі автобус атаулары өзгермейді—байланыс бар болғанша олар өзгермейді және, ең бастысы, автобустың қызмет ету мерзімі ішінде оларды қайта пайдалануға болмайды. Яғни, егер сол процесс автобусқа қосылысты жабып, жаңасын ашса да, басқа ешқандай қосылысқа мұндай бірегей байланыс атауы тағайындалмайды. Бірегей байланыс атауларын тану оңай, себебі олар әдетте тыйым салынған қос нүктеден басталады. Бірегей байланыс атауының мысалы: (қос нүктеден кейінгі таңбалардың ерекше мағынасы жоқ). Процесс өзінің байланысы үшін қосымша автобус атауларын сұрауы мүмкін, егер сұралған атау басқа қосылыспен пайдаланылмайтын болса. D Bus терминологиясында, автобус атауы қосылысқа тағайындалғанда, қосылыс автобус атауына ие деп айтылады. Осыған орай, бір автобус атауы бір уақытта екі қосылысқа тиесілі бола алмайды, бірақ бірегей байланыс атауларынан айырмашылығы, егер бос болса, осы атауларды қайта пайдалануға болады: процесс басқа процесс босатып алған автобус атауын (қасақана немесе қателікпен) қайтарып алуы мүмкін. Осы қосымша автобус атауларының мақсаты, көбінесе «жақсы белгілі атаулар» деп аталады, – алдын ала келісілген автобус атауын пайдаланып қызметке сілтеме жасау мүмкіндігін ұсыну. Мысалы, жүйелік автобустағы ағымдағы уақыт пен күнді хабарлайтын қызмет, ол қай процесс болса да, автобус атауына ие болатын процесс ішінде орналасқан. Автобус атауларын қарапайым тәсіл ретінде бір инстанциялық қолданбаларды жүзеге асыру үшін пайдалануға болады (екінші инстанциялар автобус атауы қолданылып жүргенін анықтайды). Сондай-ақ, қызмет процесінің өмірлік циклын қадағалау үшін де пайдалануға болады, себебі процесс аяқталғанда автобус автобус атауын босатып, хабарлама жібереді.

Every connection to a bus is identified in the context of D Bus by what is called a bus name. A bus name consists of two or more dot separated strings of letters, digits, dashes, and underscores. An example of a valid bus name is
When a process sets up a connection to a bus, the bus assigns to the connection a special bus name called unique connection name. Bus names of this type are immutable—it is guaranteed they will not change as long as the connection exists—and, more importantly, they cannot be reused during the bus lifetime. This means that no other connection to that bus will ever have assigned such unique connection name, even if the same process closes down the connection to the bus and creates a new one. Unique connection names are easily recognizable because they start with the otherwise forbidden colon character. An example of a unique connection name is (the characters after the colon have no particular meaning). A process can ask for additional bus names for its connection, provided that any requested name is not already being used by another connection to the bus. In D Bus parlance, when a bus name is assigned to a connection, it is said the connection owns the bus name. In that sense, a bus name cannot be owned by two connections at the same time, but, unlike unique connection names, these names can be reused if they are available: a process may reclaim a bus name released—purposely or not—by another process. The idea behind these additional bus names, commonly called well known names, is to provide a way to refer to a service using a prearranged bus name. For instance, the service that reports the current time and date in the system bus lies in the process whose connection owns the bus name, regardless of which process it is. Bus names can be used as a simple way to implement single instance applications (second instances detect that the bus name is already taken). It can also be used to track a service process lifecycle, since the bus sends a notification when a bus name is released due to a process termination.

Нысанның үлгісі

Бірнеше компоненттік бағытталған байланыс жүйелерін алмастыру ретінде бастапқы тұжырымдамасының нәтижесінде, D-Bus өзінің алдыңғыларымен клиенттер мен қызметтер арасындағы байланыстың семантикасын білдіретін объектілік модельді бөліседі. D-Bus нысандық моделінде қолданылатын терминдер кейбір нысанға бағытталған бағдарламалау тілдерінде қолданылатын терминдерді еліктейді. Бұл D-Bus-тың ҰОБ тілдерімен шектеледі дегенді білдірмейді, шын мәнінде, ең көп қолданылатын іске асыру C тілінде, процедуралық бағдарламалау тілінде жазылған. D-Bus-та процесс өзінің қызметтерін нысандарды ашу арқылы ұсынады. Бұл нысандар шақырылатын әдістерге және нысан шығаратын сигналдарға ие. Әдістер мен сигналдар бірлесіп нысанның мүшелері деп аталады. Автобусқа қосылған кез келген клиент нысанмен оның әдістерін пайдалану арқылы, сұрау салулар жасау арқылы немесе нысанға әрекеттерді орындауға бұйрық беру арқылы өзара әрекеттесе алады. Мысалы, уақыт қызметін көрсететін нысанды клиент ағымдағы күн мен уақытты қайтаратын әдісті пайдалану арқылы сұрауы мүмкін. Клиент сондай-ақ белгілі бір оқиғаларға байланысты, әдетте, негізгі қызметпен байланысты, нысанның күйі өзгергенде шығаратын сигналдарды тыңдай алады. Мысал ретінде, USB немесе желілік драйверлер сияқты аппараттық құрылғыларды басқаратын қызмет «жаңа аппараттық құрылғы қосылды» оқиғасын белгілейді. Клиенттер басқа белгілі бір нысаннан белгілі бір сигналдарды қабылдауға қызығушылық танытатынын көрсетуі керек, өйткені D-Bus басы тек қана оларға тіркелген қызығушылық бар процестерге сигналдарды жібереді. D-Bus шинасына қосылған процесс одан қанша D-Bus нысанын экспорттауды сұрауы мүмкін. Әрбір нысан нысанның жолымен, сандар, әріптер және сызықтар тізбектерімен анықталады, олар слэш таңбасымен бөлінген және префикстелген, Unix файлдық жүйесінің жолдарына ұқсастығы үшін осылай аталады. Нысан жолы сұрату процесінде таңдалады және ол осы автобус байланысы аясында бірегей болуы тиіс. Дұрыс нысан жолының мысалы: Алайда, нысан жолдары ішінде иерархия құруға мәжбүр емес, бірақ одан бас тартпайды. Қызметтің нысандарына арналған атаудың ерекше конвенциясы мұндай қызметтің әзірлеушілеріне байланысты, бірақ көптеген әзірлеушілер оларды жобаның резервтелген домендік атын префикс ретінде (мысалы) қолдана отырып, атау кеңістігін таңдайды. Әрбір нысан экспортталған нақты автобус байланысымен ажырамас байланыста болады және D-Bus тұрғысынан алғанда, тек осындай байланыс аясында ғана өмір сүреді. Сондықтан, белгілі бір қызметті пайдалану үшін клиент тек қажетті қызметті ұсынатын нысан жолын ғана емес, сонымен қатар қызмет процесі автобусқа қосылған автобус атауын көрсетуі тиіс. Бұл өз кезегінде шинаға қосылған бірнеше процестердің бірдей нысан жолдары бар әртүрлі нысандарды біркелкі экспорттауына мүмкіндік береді. Интерфейс нысанмен қолдануға болатын мүшелерді - әдістер мен сигналдарды анықтайды. Бұл Java тілінің интерфейс белгісіне ұқсас нүктеден бөлінген атаумен анықталған әдістердің (оның өту және қайтару параметрлерін қоса алғанда) және сигналдардың (оның параметрлерін қоса алғанда) декларацияларының жиынтығы. Интерфейс атауларының ұқсастығына қарамастан, интерфейс атаулары мен шина атауларын шатастыруға болмайды. D-Bus нысаны бірнеше интерфейсті іске асыра алады, бірақ кем дегенде біреуін іске асырып, ол анықтаған әрбір әдіс пен сигналға қолдау көрсетуі керек. Нысанның барлық интерфейстерінің комбинациясы нысанның түрі деп аталады. Нысанды пайдаланған кезде клиенттік процеске мүше атауынан басқа мүше интерфейсінің атауын беру жақсы тәжірибе, бірақ бұл нысанмен іске асырылған әртүрлі интерфейстерден қол жетімді мүше атауларының қайталануы салдарынан екіжақтылық туындаған кезде ғана міндетті, әйтпесе таңдалған мүше анықталмаған немесе қате. Ал эмиссияланатын сигнал әрқашан өзінің қандай интерфейске жататынын көрсетуі тиіс. D-Bus спецификациясы сонымен қатар бірнеше стандартты интерфейстерді анықтайды, оларды нысан өзінің интерфейстерінен басқа да іске асыруы мүмкін. Техникалық тұрғыдан ерікті болса да, D-Bus қызметтерін әзірлеушілердің көпшілігі оларды экспортталған нысандарда қолдауға шешім қабылдайды, өйткені олар D-Bus клиенттеріне маңызды қосымша мүмкіндіктер ұсынады, мысалы, интроспекция. Бұл стандартты интерфейстер: D-Bus қосылысының белсенді екенін тексерудің жолын ұсынады. : клиенттік процеске орындау кезінде нысан іске асыратын интерфейстердің, әдістер мен сигналдардың сипаттамасын (XML форматында) алуға мүмкіндік беретін интроспекция механизмін ұсынады. : D-Bus нысанына негізгі нысан қасиеттерін немесе атрибуттарын көрсетуге немесе олар болмаған жағдайда оларды имитациялауға мүмкіндік береді. : D-Bus қызметі нысандарын иерархиялық түрде ұйымдастырғанда, бұл интерфейс нысанға оның жолының астындағы барлық қосалқы нысандар, сондай-ақ олардың интерфейстері мен қасиеттері туралы ақпаратты алуға мүмкіндік береді, бұл тек бір әдіс шақыру арқылы жасалады. D-Bus спецификациясы басқарушылық автобус операцияларын ( «автобус қызметтері» деп аталатын) анықтайды, оларды нысаны арқылы орындауға болады, ол автобус атауында орналасқан. Әрбір автобус бұл арнайы автобус атауын өзі үшін резервтейді және осы автобус атауы мен нысан жолына жасалған кез келген сұрауды басқарады. Автобуспен ұсынылатын басқарушылық операциялар нысан интерфейсімен анықталады. Бұл операциялар мысалы, автобустың күйі туралы ақпарат беру үшін немесе қосымша белгілі автобус атауларын басқару және босату үшін қолданылады.

Because of its original conception as a replacement for several component oriented communications systems, D Bus shares with its predecessors an object model in which to express the semantics of the communications between clients and services. The terms used in the D Bus object model mimic those used by some object oriented programming languages. That does not mean that D Bus is somehow limited to OOP languages—in fact, the most used implementation is written in C, a procedural programming language. In D Bus, a process offers its services by exposing objects. These objects have methods that can be invoked, and signals that the object can emit. Methods and signals are collectively referred to as the members of the object. Any client connected to the bus can interact with an object by using its methods, making requests or commanding the object to perform actions. For instance, an object representing a time service can be queried by a client using a method that returns the current date and time. A client can also listen to signals that an object emits when its state changes due to certain events, usually related to the underlying service. An example would be when a service that manages hardware devices—such as USB or network drivers—signals a "new hardware device added" event. Clients should instruct the bus that they are interested in receiving certain signals from a particular object, since a D Bus bus only passes signals to those processes with a registered interest in them. A process connected to a D Bus bus can request it to export as many D Bus objects as it wants. Each object is identified by an object path, a string of numbers, letters and underscores separated and prefixed by the slash character, called that because of their resemblance to Unix filesystem paths. The object path is selected by the requesting process, and must be unique in the context of that bus connection. An example of a valid object path is However, it is not enforced—but also not discouraged—to form hierarchies within object paths. The particular naming convention for the objects of a service is entirely up to the developers of such service, but many developers choose to namespace them using the reserved domain name of the project as a prefix (e. g. ). Every object is inextricably associated to the particular bus connection where it was exported, and, from the D Bus point of view, only lives in the context of such connection. Therefore, in order to be able to use a certain service, a client must indicate not only the object path providing the desired service, but also the bus name under which the service process is connected to the bus. This in turn allows that several processes connected to the bus can export different objects with identical object paths unambiguously. An interface specifies members—methods and signals—that can be used with an object. It is a set of declarations of methods (including its passing and returning parameters) and signals (including its parameters) identified by a dot separated name resembling the Java language interfaces notation. An example of a valid interface name is Despite their similarity, interface names and bus names should not be mistaken. A D Bus object can implement several interfaces, but at least must implement one, providing support for every method and signal defined by it. The combination of all interfaces implemented by an object is called the object type. When using an object, it is a good practice for the client process to provide the member's interface name besides the member's name, but is only mandatory when there is an ambiguity caused by duplicated member names available from different interfaces implemented by the object—otherwise, the selected member is undefined or erroneous. An emitted signal, on the other hand, must always indicate to which interface it belongs. The D Bus specification also defines several standard interfaces that objects may want to implement in addition to its own interfaces. Although technically optional, most D Bus service developers choose to support them in their exported objects since they offer important additional features to D Bus clients, such as introspection. These standard interfaces are:
: provides a way to test if a D Bus connection is alive. : provides an introspection mechanism by which a client process can, at run time, get a description (in XML format) of the interfaces, methods and signals that the object implements. : allows a D Bus object to expose the underlying native object properties or attributes, or simulate them if it does not exist. : when a D Bus service arranges its objects hierarchically, this interface provides a way to query an object about all sub objects under its path, as well as their interfaces and properties, using a single method call. The D Bus specification defines a number of administrative bus operations (called "bus services") to be performed using the object that resides in the bus name. Each bus reserves this special bus name for itself, and manages any requests made specifically to this combination of bus name and object path. The administrative operations provided by the bus are those defined by the object's interface These operations are used for example to provide information about the status of the bus, or to manage the request and release of additional well known bus names.

Ішкі істер

Қазіргі D Bus жүйелерінің көпшілігі анықтамалық нұсқаулықтың архитектурасын қолданады. Бұл архитектура екі негізгі компоненттен тұрады:

екі процесс арасында хабар алмасу үшін D Bus сымдық протоколын іске асыратын, нүктеден нүктеге байланыс кітапханасы. Басқа жүйелерде бұл кітапхана жоғары деңгейдегі басқа кітапханамен, тілдік байланыспен немесе бірдей мақсатқа қызмет ететін басқа дербес жүйемен ауыстырылуы мүмкін. Бұл кітапхана екі процесс арасындағы бір-бірден байланысты ғана қолдайды. D Bus нүктеден нүктеге байланыс кітапханасын пайдалана отырып, автобустық рөлді атқаратын және қалған процестер қосылатын арнайы демондық процесс. Бұл процесс хабарлар шинасы деп те аталады, себебі ол шинаға қосылған кез келген процестен басқа процеске хабарларды бағыттауға жауапты. Анықтамалық нұсқаулықта бұл рөлді , өзі D Bus-тің үстіне салынған , атқарады. Басқа бір нұсқаулық – бұл хабарлар шинасы , ол D Bus-тің үстіне салынған. Кітапхана (немесе оған баламасы) D Bus қосылысының екі шетіндегі екі процесс арасында қажетті D Bus хабарларын тасымалдау үшін төменгі деңгейдегі IPC механизмін ішкі түрде пайдаланады. D Bus спецификациясы қолданылуға тиіс нақты IPC тасымалдау механизмдерін міндеттейді деп айтуға болмайды, себебі байланыс кітапханасы қандай тасымалдау әдістерін қолдайтынын шешеді. Мысалы, Linux сияқты Unix жүйелерінде әдетте Unix домендік сокеттерін негізгі тасымалдау әдісі ретінде пайдаланады, бірақ TCP сокеттерін де қолдайды. Екі процестің байланыс кітапханалары таңдалған тасымалдау әдісі және олардың байланысы үшін қолданылатын арна туралы келісуі керек. Бұл ақпарат D Bus адресі деп аталады. Unix домендік сокеттері файлдық жүйе объектілері болып табылады, сондықтан оларды файл атауымен анықтауға болады, сондықтан жарамды мекенжай unix:path=/tmp/. жасырын сокет болады. Екі процесс те D Bus қосылысын орнату үшін тиісті байланыс кітапханаларына бірдей адресті беруі керек. Адрес сонымен қатар байланыс кітапханасына кілт-мәнді жұптар түрінде қосымша деректерді беруге мүмкіндік береді. Осылайша, мысалы, ол оны қолдайтын белгілі бір қосылыс түріне аутентификациялық ақпаратты ұсынуы мүмкін. D Bus шинасын іске асыру үшін хабарлар шинасы демоны пайдаланылғанда, шинаға қосылуды көздейтін барлық процестер шина адресін білуі керек, яғни процесс орталық хабарлар шинасы процесіне D Bus қосылысын орната алатын адресті білуі керек. Бұл жағдайда хабарлар шинасы демоны шина адресін таңдайды және қалған процестер осы мәнді тиісті немесе баламалы кітапханаларға беруі керек. әрбір шина нұсқасы үшін әртүрлі шина адресін анықтайды. Бұл мекенжайлар демонның конфигурациялық файлдарында анықталған. Екі процесс тікелей бір-бірімен хабар алмасу үшін D Bus қосылысын пайдалана алады, бірақ бұл D Bus-ты пайдаланудың қалыпты тәсілі емес. Көбінесе әрбір процесс өзінің нүктеден нүктеге D Bus қосылысын орнатуы тиіс байланыс орталық нүктесі ретінде хабарлар шинасын (яғни ) пайдалану қажет. Процесс – клиент немесе қызмет – D Bus хабарын жібергенде, хабарлар шинасы процесі оны бірінші кезекте қабылдайды және тиісті алушыға жеткізеді. Хабарлар шинасы демонын әрбір хабарды D Bus қосылысы арқылы алушы процеске қайталау арқылы оның мақсатына жеткізуді басқаратын хаб немесе маршрутизатор ретінде қарастыруға болады. Алушы процесс хабарламаның бас бөлігіндегі мақсатты шина атауымен немесе сигнал тарату хабарламалары жағдайында хабарлар шинасы демонымен сақталатын сигналдарға жазылу ақпаратымен анықталады. Хабарлар шинасы демоны белгілі бір жағдайларға жауап ретінде өзінің хабарларын шығара алады, мысалы, жоқ шина атауына хабар жіберген процесске қате туралы хабарлама. D Bus өзі ұсынған мүмкіндіктер жиынтығын қосымша функционалдықпен жақсартады. Мысалы, қызметті белсендіру қажет болған кезде қызметтерді автоматты түрде іске қосуға мүмкіндік береді, осындай қызметтің кез келген шина атауына алғашқы сұрау хабарлар шинасы демонына келгенде. Осылайша, қызмет процестерін жүйелік немесе пайдаланушы инициализациясы кезінде іске қосудың қажеті жоқ, сондай-ақ олар пайдаланылмаған кезде жадты немесе басқа ресурстарды тұтынудың қажеті жоқ. Бұл мүмкіндік бастапқыда setuid көмекшілерін пайдалану арқылы іске асырылды, бірақ қазіргі уақытта оны systemd-тің қызметті белсендіру шеңберінен де қамтамасыз етуге болады. Қызметті белсендіру – қызметтердің өмірлік циклін басқаруды жеңілдететін маңызды мүмкіндік (мысалы, десктоп компоненті қашан іске қосылуы немесе тоқтатылуы керек).

a point to point communications library that implements the D Bus wire protocol in order to exchange messages between two processes. In the reference implementation this library is In other implementations may be wrapped by another higher level library, language binding, or entirely replaced by a different standalone implementation that serves the same purpose. This library only supports one to one communications between two processes. a special daemon process that plays the bus role and to which the rest of the processes connect using any D Bus point to point communications library. This process is also known as the message bus daemon, since it is responsible for routing messages from any process connected to the bus to another. In the reference implementation this role is performed by , which itself is built on top of Another implementation of the message bus daemon is , which is built on top of
The library (or its equivalent) internally uses a native lower level IPC mechanism to transport the required D Bus messages between the two processes in both ends of the D Bus connection. D Bus specification does not mandate which particular IPC transport mechanisms should be available to use, as it is the communications library that decides what transport methods it supports. For instance, in Unix like operating systems such as Linux typically uses Unix domain sockets as the underlying transport method, but it also supports TCP sockets. The communications libraries of both processes must agree on the selected transport method and also on the particular channel used for their communication. This information is defined by what D Bus calls an address. Unix domain sockets are filesystem objects, and therefore they can be identified by a filename, so a valid address would be unix:path=/tmp/. hiddensocket. Both processes must pass the same address to their respective communications libraries to establish the D Bus connection between them. An address can also provide additional data to the communications library in the form of comma separated key=value pairs. This way, for example, it can provide authentication information to a specific type of connection that supports it. When a message bus daemon like is used to implement a D Bus bus, all processes that want to connect to the bus must know the bus address, the address by which a process can establish a D Bus connection to the central message bus process. In this scenario, the message bus daemon selects the bus address and the remainder processes must pass that value to their corresponding or equivalent libraries. defines a different bus address for every bus instance it provides. These addresses are defined in the daemon's configuration files. Two processes can use a D Bus connection to exchange messages directly between them, but this is not the way in which D Bus is normally intended to be used. The usual way is to always use a message bus daemon (i. e. ) as a communications central point to which each process should establish its point to point D Bus connection. When a process—client or service—sends a D Bus message, the message bus process receives it in the first instance and delivers it to the appropriate recipient. The message bus daemon may be seen as a hub or router in charge of getting each message to its destination by repeating it through the D Bus connection to the recipient process. The recipient process is determined by the destination bus name in the message's header field, or by the subscription information to signals maintained by the message bus daemon in the case of signal propagation messages. The message bus daemon can also produce its own messages as a response to certain conditions, such as an error message to a process that sent a message to a nonexistent bus name. improves the feature set already provided by D Bus itself with additional functionality. For example, service activation allows automatic starting of services when needed—when the first request to any bus name of such service arrives at the message bus daemon. This way, service processes neither need to be launched during the system initialization or user initialization stage nor need they consume memory or other resources when not being used. This feature was originally implemented using setuid helpers, but nowadays it can also be provided by systemd's service activation framework. Service activation is an important feature that facilitates the management of the process lifecycle of services (for example when a desktop component should start or stop).

Тарих және қабылдау

D Bus 2002 жылы Havoc Pennington, Alex Larsson (Red Hat) және Anders Carlsson бастады. 1.0 нұсқасы – API тұрақты деп есептелді – 2006 жылдың қараша айында жарияланды. KDE 2 және 3 нұсқаларында қолданылған DCOP жүйесінің үлкен ықпалымен, D Bus KDE 4 нұсқасында DCOP-ты толығымен алмастырды. D Bus-тің іске асырылуы көптеген POSIX операциялық жүйелерін қолдайды, сондай-ақ Windows үшін де портталған. Оны Qt 4 және одан кейін GNOME қолданады. GNOME-да ол бұрынғы Bonobo механизмінің көп бөлігін біртіндеп алмастырды. Xfce да оны пайдаланады. Алғашқы пайдаланушылардың бірі (қазір қолданыстан шығарылған) Аппараттық абстракция қабаты болды. HAL D Bus-ті компьютерге қосылған немесе алынып тасталған аппараттық құралдар туралы ақпаратты экспорттау үшін пайдаланды. D Bus-тің қолданылуы үстелдік орталардың бастапқы саласынан асып, жүйелік қызметтердің көлемін кеңейтуде. Мысалы, NetworkManager желілік демоны, BlueZ Bluetooth стегі және PulseAudio дыбыс сервері өз қызметтерінің бір бөлігін немесе толығымен беру үшін D Bus-ті пайдаланады. systemd және systemd арасындағы байланыс үшін D Bus сымдық протоколын қолданады, сондай-ақ дәстүрлі жүйелік демондарды, мысалы logind-ті, D Bus қызметтеріне айналдыруға көмектеседі. D Bus-тің тағы бір белсенді пайдаланушысы – Polkit, оның саясатты басқару демоны жүйелік шинаға қосылған қызмет ретінде іске асырылған.

libdbus (жазбаша)

D Bus-тың бірнеше іске асырылуы болғанымен, ең көп қолданылатыны – freedesktop.org жобасымен әзірленген эталондық іске асырылым libdbus. Дегенмен, libdbus – төменгі деңгейдегі іске асырылым, ол қолданба жасаушылар үшін тікелей пайдалану үшін емес, D Bus-тың басқа да қайта іске асырылымдары үшін (мысалы, десктоп орталарының стандартты кітапханаларында немесе бағдарламалау тілі байланыстарында кездесетіндер) анықтамалық ретінде қарастырылған. freedesktop.org жобасының өзі қолданба авторларына "жоғары деңгейдегі байланыстардың немесе іске асырылымдардың бірін пайдалануды" ұсынады. libdbus-тың ең көп қолданылатын D Bus іске асырылымы болуы "D Bus" және "libdbus" терминдерінің жиі алмастырылып қолданылуына, соның салдарынан шатасуға әкеп соқты.

GDBus

GDBus – GTK+ және GNOME үшін арналған, GLib құрамына кіретін GIO ағындары негізінде құрылған D-Bus-тің іске асырылуы. GDBus libdbus-тың қаптамасы емес, D-Bus спецификациясы мен протоколының толыққанды және тәуелсіз қайта іске асырылуы болып табылады. GTK+ 3-ке негізделген MATE Desktop және Xfce (4.14 нұсқасы) да GDBus-ты пайдаланады.

sd-көлік

2013 жылы systemd жобасы кодты жеңілдету мақсатында libdbus-ты қайта жазды, бірақ бұл D Bus жүйесінің жалпы өнімділігін күрт арттыруға әкелді. Алдын ала сынақтар нәтижесінде BMW компаниясы systemd-нің D Bus кітапханасы өнімділікті 360%-ға дейін арттыратынын анықтады. Systemd нұсқасы 221-ге жеткен кезде sd шинасының API тұрақты деп жарияланды.

kdbus

kdbus - ядро арқылы басқарылатын, өзара байланыс механизмі ретінде D-Bus-ті қайта іске асыруды мақсат еткен жоба. Оның өнімділігін арттырудан басқа, kdbus Linux ядросының атау кеңістіктері және аудит сияқты басқа мүмкіндіктерінен де артықшылықтарға ие болар еді, мысалы, ядроның араласуы арқылы қауіпсіздік, жарыс жағдайларын болдырмау, сондай-ақ D-Bus-ті жүйелік жүктеу және өшіру кезінде пайдалану мүмкіндігі (systemd-ге қажет болған жағдайларда). Linux ядросына kdbus-ты қосу мәселелі болды және процестер аралық байланыс құралы ретінде BUS1 пайдасына тоқтатылды.

Тілдік байланыстар

D Bus үшін Java, C#, Ruby, Rust және Perl сияқты бірнеше бағдарламалау тілдеріне арналған байланыстар әзірленді.