D-BUS – koncept

Koncepce komunikace mezi programy pomocí D-BUS spočívá v nabízení a využívání služeb. Některé aplikace a systém služby nabízí, jiné jich využívají. Podívejme se na to z pohledu aplikace, která chce nějakou existující službu využít.

Spojení, služby a objekty

Nejprve je nutno navázat spojení s D-BUS daemonem. Je potřeba si vybrat, jestli chceme komunikovat se systémovým, nebo uživatelským. Dále je potřeba uvést, s kterou službou (aplikací) chceme komunikovat. Aplikace nekomunikují přímo, ale skrze objekty, přitom aplikace jich může nabízet ke komunikaci víc.

Například HAL nabízí objekt správce zařízení, pomocí kterého se můžeme spojit s nějakým zařízením. Každé zařízení přitom představuje vlastní objekt.

Funguje to tak, že si od vzdálené aplikace vyžádáme objekt. Vzdálená aplikace nám přes D-BUS pošle jeho instanci. Abychom jej mohli ovládat, připojíme k němu rozhraní a pak už můžeme v naší aplikaci volat jeho metody. To co v naší aplikaci zavoláme, to se ve vzdálené aplikaci provede.

Metody [METODA]

Tyto metody mohou dělat cokoliv, třeba jen vrátit nějakou informaci, nebo ale také na dálku ovládat textový editor či klidně vypnout skrze vzdálenou službu počítač. Je to klasický mechanizmus RPC (vzdálené volaní procedur).

Signály [SIGNAL]

Kromě metod může objekt nabízet i signály (eventy, události). Fungují jako opak metod. V naší aplikaci si můžeme zaregistrovat signál, to jest definujeme, která funkce nebo metoda naší aplikace se má zavolat v případě vzniku signálu. Když pak ve vzdálené aplikaci takový signál vznikne, v naší aplikaci se spustí příslušná fukce a můžeme tak na událost, která signál vyvolala zareagovat.

Obrázek může napovědět, jak komunikace může probíhat.

Abychom to všechno mohli provést, tak k tomu potřebujeme znát:

• Název služby
• Název objektu
• Název rozhraní

Protože služby může programovat kdokoli, je potřeba do toho vnést nějaký řád, aby to bylo jednotné, srozumitelné a zároveň nedocházelo ke konfliktům v názvech.

Název služby

Jako jednoznačný identifikátor se používá webová adresa projektu služby pozpátku. Tedy něco jako cz.mojefirma.nazevsluzby nebo například D-BUS samotný nabízí nějaké služby (třeba získání seznamu všech registrovaných služeb) a služba má název org.freedesktop.DBus a já bych u svých služeb používal cz.iglu.wraith.nazevsluzby.

Název objektu [OBJEKT]

Úplně stejně se pojmenovávají objekty, akorát místo teček se používají lomítka, takže to vypadá jako zápis cesty a také se to tak někdy nazývá (PATH). Tedy objekt správce zařízení (device manager) služby org.freedesktop.Hal se jmenuje /org/freedesktop/Hal/Manager. Je možno mít hierarchickou skupinu objektů a tak cesta může mít klidně další položky, je-li to potřeba, třeba /org/kde/kspread/sheets/3/cells/4/5 je název objeku buňky KSpreadu z KOffice.

Název rozhraní [ROZHRANI]

A abychom nemuseli bádat, jaký je název rozhraní pro jaký objekt, tak ten je úplně stejný jako název objektu, akorát se lomítka nahradí tečkou. Tedy taková je konvence u jedinečných objektů. Je-li nějaký objekt generický, jako například ona buňka v KSpreadu, tak by bylo nesmyslné a nemožné, aby každá buňka měla svůj název rozhraní, když všechny buňky mají to rozhraní stejné. Na rozhraní se jde dívat jako na pojmenovaný seznam metod a signálů, které objekt zpřístupňuje. Rozhraní definuje typ objektu.

Je to celé trochu složitější

Teď už bych mohl skončt s tím, že víte všechno důležité. Ale pro zájemce jsou zde ještě další informace, které pohled na D-BUS trochu komplikují. Dosud jsme si povídali o typickém použití, kdy aplikace spolu komunikují přes BUS daemona.

Adresa [ADRESA]

V takovém případe je BUS daemon server a všechny ostatní aplikace k němu připojení klienti. Když se klient připojuje k k serveru, musí znát jeho adresu. Ta se, v případě kdy server je BUS daemon, nalezne sama. Komunikují-li ale spolu dvě aplikace skrz D-BUS přímo, pak jedna z nich je server a čeká na připojení té druhé a ta druhá musí znát adresu té první.

Adresa může mít tvar například unix:path=/tmp/abcde, v případě, kdy aplikace spolu budou komunikovat přes UNIX domain socket. Lze použít i klasický TCP/IP socket.

ID spojení s BUS daemonem [BUSID]

Je další skrytý název, který se používá pouze v případě komunikace přes dbusd. Název spojení je jedinečný název po dobu životnosti příslušné instance BUS daemona. Pokaždé když se nějaké aplikace připojí, dostane toto spojení jedinečný název, který začíná znakem ':', třeba :34-907. Může se to hodit třeba pro zjištění, že vzdálená aplikace se odpojila a připojila.

Název spojení se ale používá především pro interní účely směřování zpráv, takže se jím nemusíme moc zabývat. V podstatě se používá místo názvu služby. Tedy třeba org.freedesktop.Hal se může namapovat na :34-907 podobně jako se název počítače mapuje na IP adresu, která také s každým spojením (třeba u dhpc nebo dial-upu) může být jiná.

Výsledek této koncepce

ADRESA -> [BUSID -> ] OBJEKT -> ROZHRANI -> METODA

Tady je přehledně vidět, jak se směrují zprávy v rámci systému D-BUS. BUSID se neuplatňuje v případě přímého spojení, proto je uzavřeno v [].

Zprávy

Zprávy mají hlavičku a tělo. V těle jsou samotná data, v hlavičce směrování, pois dat a podobné provozní údaje.

D-BUS implementuje tyto 4 typy zráv:

• volací zpráva (call message)
• návratová zpráva (return message)
• chybová zpráva (error mesage)
• signálová zpráva (signal/event message)