D-Bus: Anvelope pentru Linux
V-ați gândit deja la anvelope de iarnă sau la fracturi și dislocări? Du-te înapoi în lumea virtuală - Andrew Borovsky se referă la autobuzul pentru schimbul de date între aplicațiile desktop!
Ce este D-Bus? Cel mai simplu răspuns este un alt sistem de comunicare interproces (Interprocess Communication sau IPC). Cuvintele cheie aici sunt "încă o dată". Există multe sisteme IPC la nivel înalt pentru Unix / Linux. În plus față de sistemele de nivel înalt, Unix a dezvoltat IPC de nivel scăzut (prize, canale), care sunt utilizate cu succes de multe aplicații direct. Atunci de ce avem nevoie de D-Bus? Acest sistem a fost conceput ca un FreeDesktop.org grup mijloace IPC, nu în funcție de tipul de desktop conceput pentru a înlocui atât DCOP în KDE și CORBA / Bonobo în GNOME. Disloca nativ înseamnă IPC KDE și GNOME noul sistem nu a fost încă [adevărul, KDE 4 D-Bus va fi încă folosit în loc de DCOP, - aprox. Ed. ], dar în curs de dezvoltare D-Bus a găsit câteva caracteristici unice și utile. Caracteristicile importante ale D-Bus sunt sistemul de semnale și apelurile metodelor asincrone, precum și sistemul de control al execuției aplicațiilor. Deci, răspunsul la întrebare, de ce ați putea avea nevoie de programarea D-Bus, constă din două părți. În primul rând, multe aplicații importante și componente ale sistemului (de exemplu, Linux HAL și NetworkManager) utilizează D-Bus ca mijloc de comunicare cu lumea exterioară. În al doilea rând, D-Bus este un sistem IPC independent de platformă, care este prezent în aproape toate distribuțiile Linux și este instalat implicit în multe dintre ele. Prin urmare, dacă scrieți o aplicație care trebuie să furnizeze servicii IPC fără a fi parte a unui desktop, cu siguranță trebuie să acordați atenție D-Bus-ului. În acest caz, este necesar să se ia în considerare minusurile D-Bus. Sistemul încă nu realizează legătura dintre diferite mașini, deși lucrează în această direcție. D-Bus poate fi ușor ported către alte platforme Unix, însă versiunea sa pentru Windows este încă departe de a fi completată.
Printre tehnologiile concurente (în sensul că acestea pot fi adesea folosite în loc de D-Bus), trebuie notate CORBA, SOAP, XML-RPC, DCOM, DCOP, Bonobo. Cum este D-Bus diferit de ei? CORBA, ca și D-Bus, utilizează un protocol binar rapid. Spre deosebire de D-Bus, CORBA este conceput pentru a rezolva o gamă extrem de largă de sarcini și poate fi utilizat atât într-un sistem local cât și distribuit. În CORBA, nu există elemente D-Bus, cum ar fi un sistem de gestionare a aplicațiilor și un sistem de semnale. SOAP și XML-RPC sunt protocoale în care XML este folosit în mod activ la un nivel scăzut. Aceste comunicare tehnologii interprocese potrivite pentru Internet, dar schimbul de date între aplicațiile care rulează pe aceeași mașină, utilizarea mecanismelor XML conduce la o risipă de resurse (în acest caz, ar trebui remarcat, desigur, că aplicațiile care utilizează aceste protocoale, este extrem de ușor de scară). Tehnologia DCOM, DCOP și Bonobo au un dezavantaj similare - fiecare proiectat pentru o anumită platformă (Windows, KDE și GNOME, respectiv), precum și de a organiza o interacțiune între aplicații pe mai multe platforme cu ajutorul lor va fi foarte dificil.
Interfața client D-Bus Skype
Ați observat deja că, ca exemplu de aplicație care oferă servicii D-Bus, menționăm clientul Skype. Interfața exportată de clientul Skype este foarte simplă și în același timp demonstrează toate caracteristicile principale ale D-Bus. Obiectul / com / Skype suportă o singură metodă - Invoke. Permite unei aplicații externe să trimită comenzi către clientul Skype. Singurul argument pentru metoda Invoke este linia de comandă, iar valoarea returnată este șirul care conține răspunsul programului la comanda trecută. Cu toate acestea, clientul Skype nu poate executa numai comenzi de la aplicații de la terțe părți, ci le trimite și diverse informații, de exemplu, despre conectarea unui nou utilizator. Pentru a primi mesaje de la clientul Skype. aplicația trebuie să înregistreze clasa / com / Skype / Client. Atunci când un client Skype dorește să informeze aplicația despre ceva, el apelează metoda Notify a clasei / com / Skype / Client. trecând într-un singur parametru al acestei metode un mesaj de tip șir. Metoda de notificare nu returnează valori.
Puțin despre arhitectură
Baza structurii D-Bus este conceptul de autobuz (autobuz). Un autobuz este un mecanism prin care procesele schimbă date. Deși, în principiu, oricare două procese pot organiza un autobuz "privat" utilizând D-Bus și schimbă date între ele, autobuzele publice pe care suportă daemonul D-Bus sunt de interes. Fișierul daemon executabil este numit dbus-daemon. În mod normal, dacă trebuie să porniți manual daemonul D-Bus, utilizați comanda dbus-launch.
Daemonul D-Bus ne oferă două magistrale: o magistrală de sistem și o magistrală a utilizatorului (sesiune-bus). O magistrală de sistem poate fi utilizată pentru a transfera date pe o scară de sistem, în timp ce o magistrală de utilizator permite transferul datelor între procesele aparținând aceluiași utilizator. Trebuie remarcat faptul că D-Bus monitorizează drepturile utilizatorilor din sistem și nu vă va permite să încălcați politica de securitate Linux utilizând busul de sistem.
Toate procesele care utilizează D-Bus pentru schimbul de date acționează ca și clienți care se conectează la daemonul D-Bus și astfel obțin acces la unul dintre autobuze. Acest lucru ar trebui să fie amintit, printre altele, și pentru a nu deveni confuz în terminologie. Prin conectarea la magistrala, fiecare proces creează o conexiune (cu daemonul D-Bus). Fiecare conexiune are un nume (care, în literatura de specialitate originală, este desemnată de numele conexiunii de termeni și numele busului). Numele de conectare sunt similare cu numele site-urilor Internet întoarse. De exemplu, managerul HAL creează o conexiune cu numele org.freedesktop.Hal. și clientul Skype cu numele com.Skype.API. Deoarece toate aplicațiile care utilizează sistemul sau un autobuz utilizator D-Bus, sunt conectate la daemonul D-Bus, dar nu unul cu celălalt, este posibil să se utilizeze un compus D-Bus pentru comunicarea între diferite aplicații.
Dacă ajungem la un nivel de abstracție, vom vedea ce este asemănarea dintre obiectele D-Bus și obiectele OOP. Schimbul de mesaje din modelul de solicitare-răspuns poate fi privit ca un apel la metoda obiectului în care mesajul de solicitare trece parametrii metodei și mesajul de răspuns returnează valorile returnate. Este semantica invocării metodei care este utilizată atunci când se generează mesaje de interogare și se recepționează răspunsuri D-Bus.
Deoarece baza apelurilor către metodele obiectului D-Bus este schimbul de mesaje, există posibilitatea unui apel asincron. Apelând metoda obiectului D-Bus, programul poate efectua anumite operații fără a aștepta un răspuns. Puteți chiar să apelați o altă metodă a obiectului înainte ca rezultatul apelului anterior să fi fost primit. Mesajele-semnale sunt cel mai ușor de comparat cu semnale Qt.
Deși nu puteți lucra direct cu obiectele D-Bus, sistemul furnizează programatorilor o interfață asemănătoare obiectului, care este implementată folosind așa-numitele proxy-uri (obiecte proxy). Un proxy poate fi considerat un reprezentant al obiectului D-Bus în programul dvs. În ceea ce privește obiectul proxy este similar cu "real" - depinde de implementare. În Java și Python, lucrul cu proxy-urile este aproape la fel ca în cazul obiectelor de limbă "reale". Atunci când se utilizează interfețe GLib bibliotecă, un set special de funcții este utilizat pentru a lucra cu proxy-ul.
Când se referă la obiectele D-Bus ale unei aplicații, presupuneți că cel puțin o instanță a acestei aplicații rulează pe sistem. Și dacă nu este așa? Sa observat mai sus că sistemul D-Bus este capabil să controleze executarea aplicației. Daemonul D-Bus poate lansa aplicația în funcție de cerințele dvs. (pentru aceasta, desigur, această aplicație trebuie înregistrată într-un mod special pe sistem). Acest mecanism este cunoscut ca activarea D-Bus.
Implică-te!
Baza unui D-Bus API low-level este două obiecte - DBusConnection și DBusMessage. Primul obiect încapsulează toate aspectele legate de controlul D-Bus-ului, al doilea vă permite să gestionați mesajele. Încă o dată vă reamintesc că atunci când vorbim despre D-Bus obiecte API, nu este vorba despre obiecte, în sensul OOP, ci despre obiectele în stilul de GTK + API (D-Bus interfață de programare, în general, este foarte similar cu interfața de programare a aplicațiilor GTK +).
Următorul cod este un program minim care utilizează capabilitățile D-BUS.
După stabilirea conexiunii cu magistrala, numim metoda obiectului unei alte aplicații. Apelul pentru metode constă în patru pași: crearea unui mesaj de solicitare, crearea unei liste de argumente pentru metoda apelată, transmiterea mesajului și procesarea rezultatului apelului.
Un mesaj de solicitare pentru a apela o metodă este creat de funcția dbus_message_new_method_call (). Cele patru argumente sunt numele de conexiune ale aplicației la distanță, obiect, interfață și metoda apelată. Funcția returnează un pointer la obiectul DBusMessage pe care la creat. care conține informații despre un apel nou. Deoarece mesajul pe care îl creați are scopul de a apela o metodă, trebuie să generăm o listă a argumentelor sale. Aceasta se face folosind funcția dbus_message_append_args (). Primul argument pentru această funcție este un indicator pentru obiectul DBusMessage. Apoi vine un număr variabil de parametri care trec argumentele metodei chemate. Fiecare argument corespunde cu doi parametri ai funcției dbus_message_append_args (). În primul parametru, se trece o constantă, indicând tipul argumentului, în al doilea parametru - un indicator în zona de memorie în care este stocată valoarea sa. Lista de argumente se termină cu DBUS_TYPE_INVALID constantă. Deoarece metoda invoke pe care o numim are un parametru, treceți o listă cu trei argumente dbus_message_append_args (). Argumentul DBUS_TYPE_STRING specifică tipul parametrului Invoke. atunci există un pointer la valoare (în cazul nostru, un pointer la o variabilă de tip char *), apoi markerul final al listei DBUS_TYPE_INVALID. Rețineți că funcția dbus_message_append_args () nu este singura modalitate de a crea o listă de argumente. Interfața D-Bus de nivel inferior oferă alte funcții la dispoziția noastră, care pot genera liste dinamice de argumente la momentul executării.
Aceasta conchide programul nostru. Cu dbus_message_unref funcții () și dbus_connection_unref () spune sistemul pe care l-am creat obiecte de interfață D-Bus noi nu mai sunt necesare, și selectate de către memoria lor poate fi eliberată.
Cred că ați înțeles deja că lucrul cu D-Bus folosind un API de nivel scăzut nu este foarte convenabil. Normal, programatorii au creat numeroase legături API D-Bus la diferite limbi de programare și biblioteci. În prezent, D-Bus este sprijinit în GTK + / GLib (trebuie remarcat faptul că este - ancora cea mai proiectată), Qt 3 / Qt 4, Python, Java, Perl. Lucrez la legările D-Bus pentru wxWidgets.
Legăturile D-Bus rezolvă trei sarcini. Mai întâi, se realizează integrarea ciclului de procesare a mesajelor D-Bus și a platformei țintă. În al doilea rând, modelul obiect al API-ului D-Bus este mapat la modelul de obiect adoptat pe platforma țintă. În al treilea rând, sunt create metode pentru lucrul cu proxy-ul D-Bus, la fel ca în cazul obiectelor "native". Dar toate acestea sunt o poveste complet diferită. LXF
Articole similare
Trimiteți-le prietenilor: