Lxf99 d-busz
D-Bus: A gumiabroncsok a Linux számára
Már gondolkozott a téli gumiabroncsokról, törésekről és diszlokációkról? Menj vissza a virtuális világba - Andrew Borovsky utal az autóbuszra az asztali alkalmazások közötti adatcserére!
Mi az a D-Bus? A legegyszerűbb válasz egy másik interprocess kommunikációs rendszer (Interprocess Communication vagy IPC). A kulcsszavak itt "még egy". Számos magas szintű IPC rendszer van a Unix / Linux számára. A magas szintű rendszerek mellett a Unix alacsony szintű IPC-t (aljzatokat, csatornákat) fejlesztett ki, amelyeket számos alkalmazás közvetlenül használ. Akkor miért van szükség D-Busra? Ezt a rendszert a FreeDesktop.org csoport fogalmazta meg IPC eszközként, függetlenül az asztali típusától, melynek célja a DCOP KDE és CORBA / Bonobo helyettesítése a GNOME-ban. Az IPC KDE és a GNOME natív eszközeinek eltávolításához az új rendszer még nem volt lehetséges [bár a KDE 4-ben a D-Bus továbbra is a DCOP helyett használható - jegyzet. Ed. ], de a fejlesztés során a D-Bus számos egyedi és hasznos tulajdonságot talált. A D-Bus fontos funkciói a jel- és aszinkron módú hívások, valamint az alkalmazás-végrehajtás vezérlőrendszere. Tehát a D-Bus programozáshoz szükséges kérdésre adott válasz két részből áll. Először is, sok fontos alkalmazás és rendszerelem (pl. Linux HAL és NetworkManager) a D-busz használatát használja a külvilággal való kommunikáció eszközeként. Másodszor, a D-Bus egy platformtól független IPC rendszer, amely szinte minden Linux disztribúcióban jelen van, és alapértelmezés szerint sok esetben telepítve van. Ezért, ha olyan alkalmazást írsz, amelynek IPC-szolgáltatásokat kell biztosítania anélkül, hogy bármelyik asztal része lenne, akkor biztosan figyelnie kell a D-Busra. Ebben az esetben figyelembe kell venni a D-Bus mínuszokat. A rendszer még mindig nem veszi észre a különböző gépek közötti kapcsolatot, bár ez a munka folyamatban van. A D-Bus könnyen átvihető más Unix platformokra, de a Windows verziója még mindig messze nem teljes.
A versengő technológiák (abban az értelemben, hogy gyakran használhatók a D-Bus helyett), meg kell jegyezni a CORBA, a SOAP, az XML-RPC, a DCOM, a DCOP, a Bonobo. Miben különbözik a D-Bus? A CORBA, mint például a D-Bus, gyors bináris protokollt használ. A D-Busrel ellentétben a CORBA rendkívül széleskörű feladatok megoldására készült, és mind helyi, mind elosztott rendszerben használható. A CORBA-ban nincsenek D-Bus elemek, például alkalmazáskezelő rendszer és jelrendszer. A SOAP és az XML-RPC olyan protokollok, amelyekben az XML-t aktívan használják alacsony szinten. Ezek a technológiák közötti kommunikációt alkalmas az internet, de a különböző rendszerek közötti adatcsere futó alkalmazások ugyanazon a gépen, az XML mechanizmusok vezet az erőforrások pazarlását (ebben az esetben meg kell állapítani, persze, hogy az alkalmazások, amelyek ezeket a protokollokat, hogy rendkívül könnyű méretarányosan). Technology DCOM DCOP és Bonobo hasonló hátránya - amelyek mindegyike egy adott platformon (Windows, KDE és a GNOME esetében), és szervezni közötti kölcsönhatás alkalmazások több platformon ezek segítségével nagyon nehéz lesz.
D-Bus kliens felület Skype
Már észrevette, hogy a D-Bus szolgáltatásokat nyújtó alkalmazás példájaként megemlítjük a Skype klienst. A Skype kliens által exportált felület nagyon egyszerű, ugyanakkor bemutatja a D-Bus minden főbb jellemzőjét. A / com / Skype objektum egyetlen módszert támogat - Invoke. Lehetővé teszi egy külső alkalmazás számára, hogy parancsokat küldjön a Skype ügyfélnek. Az Invoke módszer egyetlen argumentuma a parancssor, és a visszatérési érték az a parancssor, amely tartalmazza a program válaszát a leadott parancsra. A Skype kliens azonban nem csak parancsokat képes végrehajtani harmadik féltől származó alkalmazásokból, hanem különféle információkat is küldhet, például egy új felhasználó csatlakoztatásáról. Az üzenetek fogadása a Skype ügyféltől. az alkalmazásnak regisztrálnia kell az osztályt / com / Skype / Client alkalmazást. Ha egy Skype ügyfél szeretné tájékoztatni valamit az alkalmazásról, felhívja az osztály / com / Skype / Client Értesítési módját. a módszer egyetlen paraméterében átadja a karakterláncot. Az Értesítési módszer nem adja vissza az értékeket.
Egy kicsit az építészetről
A D-Bus struktúra alapja a busz (busz) fogalma. A busz olyan mechanizmus, amellyel a folyamatok adatcserét folytatnak. Bár elvben minden két folyamat egy "privát" buszot szervezhet a D-busz használatával, és egymás között cserélheti az adatokat, a D-Bus démon által támogatott nyilvános buszok érdekesek. A futtatható démon fájl neve dbus-daemon. Általában ha a D-Bus démont manuálisan kell elindítani, használja a dbus-launch parancsot.
A D-Bus démon két buszot biztosít: egy rendszerbusz és egy felhasználói busz (session-bus). Rendszerbusz segítségével adatokat lehet átvinni a rendszer méretarányára, míg a felhasználói busz lehetővé teszi az adatok továbbítását az ugyanazon felhasználóhoz tartozó folyamatok között. Meg kell jegyezni, hogy a D-Bus figyeli a felhasználók jogát a rendszerben, és nem teszi lehetővé, hogy a rendszerbusz használatával megsértse a Linux biztonsági szabályait.
A D-busz adatcserét használó folyamatok olyan ügyfelek, amelyek a D-Bus démonhoz csatlakoznak, és így hozzáférhetnek az egyik buszhoz. Ezt többek között meg kell említeni, és annak érdekében, hogy ne keveredjen a terminológiába. A buszra való csatlakozással minden folyamat létrehoz egy kapcsolatot (a D-busz démonnal). Minden kapcsolatnak van egy neve (amely az eredeti szakirodalomban a kapcsolat név és a busz nevét jelöli). A kapcsolat nevek hasonlítanak az interneten elhelyezett webhelyek nevéhez. Például a HAL menedzser kapcsolatot hoz létre az org.freedesktop.Hal névvel. és a Skype kliens a com.Skype.API néven. Mivel minden használó alkalmazások a rendszer vagy a felhasználó busz D-Bus, csatlakozik a D-Bus démon, de nem egymással, akkor lehetséges, hogy egy vegyület D-Bus kommunikáció különböző alkalmazásokhoz.
Ha felmegyünk egy absztrakciós szintre, meglátjuk, mi a hasonlóság a D-Bus objektumok és az OOP objektumok között. A kérés-válasz modellben az üzenetváltás úgy tekinthető, mint egy hívás az objektummódszerre, amelyben a kérés üzenet átadja a metódus paramétereket, és a válaszüzenet visszaadja a visszaküldött értékeket. Ez a módszerhívás semantikája, amelyet lekérdező üzenetek generálásakor és D-Bus válaszok fogadásakor használnak.
Mivel a D-Bus objektum metódusokra történő hívások alapja az üzenetváltás, lehetőség van aszinkron hívásra. A D-Bus objektum metódusának meghívása esetén a program elvégezheti a műveleteket, anélkül, hogy várakozást várna. Még az objektum egy másik módját is hívhatjuk, mielőtt az előző hívás eredményét megkapnánk. Az üzenetek jelzései a legkönnyebben összehasonlíthatók a Qt jelekkel.
Noha nem tud közvetlenül együttműködni a D-Bus objektumokkal, a rendszer objektumszerű felületet biztosít a programozók számára, amelyet úgynevezett proxyk (proxy objektumok) segítségével hajtanak végre. A proxy a D-Bus objektum képviselőjének tekinthető a programban. Ami a proxy objektum hasonló a "valós" - attól függ, hogy a végrehajtás. A Java és a Python esetében a proxikokkal való munka majdnem ugyanaz, mint a "valódi" nyelvi objektumoknál. A GLib könyvtár interfészek használatakor speciális funkciókészlet használható a proxy használatához.
Amikor egy alkalmazás D-Bus objektumára hivatkozik, azt feltételezi, hogy ezen alkalmazás legalább egy példánya fut a rendszeren. És mi van, ha nem így van? Megjegyeztük, hogy a D-Bus rendszer alkalmas az alkalmazás végrehajtására. A D-Bus démon az Ön igényeinek megfelelően indíthatja el az alkalmazást (ehhez természetesen ezt az alkalmazást speciálisan regisztrálni kell a rendszeren). Ezt a mechanizmust D-Bus aktiválásnak nevezzük.
Vegyen részt!
Az alacsony szintű D-Bus API alapja két objektum - a DBusConnection és a DBusMessage. Az első objektum a D-busz vezérlésével kapcsolatos összes funkciót foglalja össze, a második pedig az üzenetek kezelését teszi lehetővé. Ismét emlékeztetni, hogy amikor arról beszélünk, D-Bus API tárgyak, nem a tárgyak a OOP értelemben, hanem a tárgyak a stílus GTK + API (D-Bus interfész programozás általában nagyon hasonlít a GTK + alkalmazás programozási felület).
A következő kód egy minimális program a D-BUS képességek használatával.
Miután létrejött a kapcsolat a buszral, egy másik alkalmazás objektumát hívjuk. A módszerhívás négy lépésből áll: egy kérésüzenet létrehozása, egy argumentumlista létrehozása a hívott eljáráshoz, az üzenet átadása és a hívás eredményének feldolgozása.
A dbus_message_new_method_call () függvény létrehoz egy kérés üzenetet a módszer hívására. Ennek négy argumentuma a távoli alkalmazás, objektum, interfész és hívott módszer kapcsolati neve. A függvény egy mutatót visz vissza a létrehozott DBusMessage objektumhoz. amely egy új hívással kapcsolatos információkat tartalmaz. Mivel az üzenetet, amelyet létrehozni szándékozik hívni egy módszert, meg kell adnunk egy listát annak érveiről. Ez a dbus_message_append_args () függvény használatával történik. A függvény első argumentuma egy mutató a DBusMessage objektumhoz. Ezután változó számú paraméter érkezik, amely átadja a hívott módszer argumentumait. Minden argumentum a dbus_message_append_args () függvény két paraméterének felel meg. Az első paraméterben az argumentum típusát jelző állandó, a második paraméterben - egy mutató a memóriaterületre, amelyben az értéke tárolódik. Az argumentumlista az állandó DBUS_TYPE_INVALID értékkel ér véget. Mivel a hívási eljárásnak van egy paramétere, egy dbus_message_append_args () három argumentum listáját adjuk át. A DBUS_TYPE_STRING argumentum határozza meg az Invoke paraméter típusát. akkor van egy mutató az értékre (esetünkben egy mutató a char * változóhoz), majd a DBUS_TYPE_INVALID lista végjelzője. Vegye figyelembe, hogy a dbus_message_append_args () függvény nem csak az argumentumlista létrehozása. Az alacsony szintű D-Bus interfész olyan egyéb funkciókat kínál, amelyek rendelkezésre állnak, és dinamikus argumentumlistákat generálhatnak futási idő alatt.
Ez zárja programunk munkáját. A funkciók dbus_message_unref () és dbus_connection_unref () azt a rendszert, amely az általunk létrehozott objektumok Interface D-Bus vagyunk már nincs szükség, és a kiválasztott által memóriát lehet szabadítani.
Azt hiszem, már tudta, hogy a D-Bus alacsony szintű API használatával nem elég kényelmes. Nem meglepő, hogy a programozók számos D-Bus API kötést hoztak létre a különböző programozási nyelvek és könyvtárak számára. Jelenleg a D-Bus támogatja a GTK + / GLib (megjegyezzük, hogy ezek a leginkább kidolgozott kötések), Qt 3 / Qt 4, Python, Java, Perl. Én magam dolgozom D-Bus kötések wxWidgets.
A D-Bus kötések három feladatot oldanak meg. Először a D-Bus üzenetfeldolgozási ciklus és a célplatform integrálása kerül végrehajtásra. Másodszor, a D-Bus API objektummodelljét a célplatformon elfogadott objektummodellhez kell leképezni. Harmadszor, a D-Bus proxyval való együttműködéshez olyan módszerek jönnek létre, mint a "natív" objektumokkal. De mindez teljesen más történet. LXF