DCOP


... [ Seminar Linux und Apache ] ... [ Thema Komponentenmodell von KDE 2 ] ... [ Applikationen ] ...

Übersicht: DCOP (Desktop COmmunication Protocol)


IPC (Inter-Prozess-Kommunikation) unter Unix

Nachdem wir im vorherigen Kapitel die Kommunikation zwischen Applikationen und in ihnen eingebetteten Komponenten betrachtet haben, beschreibt dieses Kapitel die Kommunikation auf dem gesamten Desktop.
Hier soll noch einmal deutlich drauf hingewiesen werden, daß KParts keine Aufrufe über Prozessgrenzen hinweg durchführen kann. Die Kommunikation, die vom KParts-Framework bereitgestellt wird, dient nur der Kommunikation von Applikation und Komponente in einem Prozess.

Nachfolgend wird der Informationsaustausch zwischen 2 Applikationen (verschiedenen Prozessen), oder einer Applikation und dem Linux-System betrachtet.
In den Anfängen von UNIX wurde das geniale Konzept der Pipes entwickelt.
Es ermöglicht die Kombination von vielen kleinen Tools, um somit eine komplexe Aufgabe zu bearbeiten. Jeder der mit einem Linux-System arbeitet, hat sicherlich schon Shell-Statements wie z.B. diese verwendet:

Linux-Shell bei Benutzung des Pipe-Operators
   1 
   2 ]~> find . -name "*.cc" | xargs wc -l
   3 ]~> cat /etc/passwd | awk -F: 'print $4' > /tmp/users-realnames
   4 ]~> echo "What a happy world!" | mail -s "Oh yeah!" buddy@paradise.org
   5 

Es ist sehr einfach, diese Art der IPC (Inter-Prozess-Kommunikation) selbst zu implementieren.
Ein Prozess öffnet erst eine Pipeline durch Aufruf von pipe(2) und spaltet sich danach durch fork(2).
Einer der Prozesse benutzt nun das eine Ende der Pipeline als Standardeingabe, der andere Prozess das andere Ende als Standardausgabe. Damit steht mit einfachsten Mitteln ein Kommunikationskanal zum einseitigen Datenaustausch zwischen den Prozessen zur Verfügung.

Kommunikation auf dem Desktop

Leider eignet sich diese Art der Kommunikation nicht für die Dynamik eines Desktops. Die Forderung, immer nur mit abgespaltenen Prozessen kommunizieren zu können, ist viel zu einschränkend.
Auf dem Desktop kommen und gehen Anwendungen während einer Sitzung, d.h. man kann garnicht im voraus wissen, mit wem sie kommunizieren werden. Üblicherweise will man manchmal sogar vielen Anwendungen parallel Nachrichten schicken, sogenannte Broadcasts.
Typische Anwendungsbeispiele für IPC auf dem Desktop sind: Bis Oktober 1999 hat das KDE Team daran gearbeitet, CORBA (Common Object Request Broker Architecture) für diese Art von Aufgaben einzusetzen, mit zweifelhaftem Erfolg.
Weitere Informationen zur Struktur von CORBA sind im Seminarvortrag: Das Komponentenmodell von Gnome von Torsten Frost enthalten.
In diesem Seminar wird nicht weiter auf die Struktur CORBA eingegangen.

Es sollen nur kurz die Gründe für die Abkehr von CORBA erläutert werden.
Ein vollständiges CORBA-System schien einerseits viel zu komplex für die anvisierten Aufgaben. Auf der anderen Seite wirkte es wiederum zu statisch für einen dynamischen Desktop und zu einschränkend, was die Datentypen angeht. C++ Programmierer empfinden CORBAs Programmierschnittstelle allgemein als zu unelegant.
Ferner schien der Nutzen von CORBA nicht dessen Resourcenverbrauch zu rechtfertigen, weder betreffend Speicherverbrauch noch Rechenzeit. Die KDE Sicherheitsexperten kritisierten zudem das völlige Fehlen der Abfrage einer Zugriffsberechtigung bei der Benutzung des CORBA-Protokols IIOP (Internet Inter-Orb Protocol). Ein unter CORBA laufender Desktop wäre damit leichtes Ziel böswilliger Angreifer geworden.
Da man Programmierer in einem Open-Source Projekt zu nichts zwingen kann, was sie nicht selber wollen (glücklicherweise!), blieben viele Entwickler weiterhin versucht, anstelle ordentlicher Inter-Prozess-Kommunikation ihre beliebten Hacks einzusetzen.
Dies konnte auf keinen Fall im Sinne des Projektes sein.
Es mußte also eine geeignete, gemeinsam benutzte Middleware gefunden werden, die dem Desktop mehr funktionelle Tiefe verleiht, um ihn auch mit beliebigen Skriptsprachen (wie z.B. Perl) komfortabel steuern und konfigurieren zu können. (siehe: KSycoca)

DCOP Architektur und Funktionsweise

Die Suche nach der gemeinsam genutzten Middleware wurde auf der KDE II Konferenz im Oktober 1999 beendet, als der Umstieg auf ein eigenes Protokoll namens DCOP (Desktop COmmunication Protocol) entschieden wurde. DCOP ist eine ressourcensparende Middleware zur Kommunikation von Applikationen, die auf der X11-Standardbibliothek libICE aufsetzt. Vorgestellt wurde DCOP von Matthias Ettrich (KDE-Gründer) und Preston Brown.


Eine typische, standard-konforme X11-Anwendung ist über zwei Bibliotheken an jeweils einen Server-Prozess gebunden, über libX11 an den X-Server und über libSM an den Session-Management-Server. libSM widerum ist nur eine verhältnismäßig kleine Protokollimplementierung auf der Grundlage von libICE, einer allgemeinen Kommunikationsbibliothek, deren Design das Multiplexing verschiedener Protokolle über eine Verbindung ermöglicht.

Applikation
    - libX11 <-----------------> XServer

    - libSM <----------> SMServer
    - libICE


DCOP macht sich nun zu nutze, daß jegliche Anwendung bereits über libICE verfügt und damit die Bibliothek bereits im Arbeitsspeicher vorhanden ist. Über libDCOP wird ein weiteres Protokol, eben DCOP, auf ICE aufgesetzt. Mit diesem greift die Anwendung auf einen dritten Server, den DCOP-Server, zu.

Applikation
    - libX11 <-----------------> XServer

    - libDCOP <--------> DCOPServer
    - libSM <----------> SMServer
    - libICE


Der DCOP-Server ist ein Prozess der ständig auf dem Desktop läuft, jeder Client muß sich einmalig bei ihm anmeldet und kann dann mit jedem anderen Client auf dem Desktop kommunizieren. Bei der Anmeldung erhält jeder Client einen eineindeutigen Namen, über den er jederzeit identifiziert werden kann.

Client/Server Architektur von DCOP

Der DCOP-Server steht wie ein Verkehrspolizist in der Mitte der Kreuzung und regelt die Kommunikation zwischen den Clients. Diese Eigenschaft brachte ihm (neben dem offensichtlichem Grund: Desktop COmmunication Protocol) seinen Namen, er wurde in Anlehnung an den Traffic-COP, als Desktop-COP bezeichnet.

Das Design mit einem DCOP-Server in der Mitte hat 3 entscheidende Vorteile:
  1. Man bekommt einen Naming-Service umsonst mit dazu. Es wird einfach, laufenden Anwendungen zu lokalisieren.
  2. Es werden wenig Verbindungen gebraucht (n Verbindungen für n Anwendungen), für Anfragen müssen nicht extra neue Verbindungen geöffnet werden. Dadurch ergibt sich eine sehr kurze Latenzzeit auch für den jeweils ersten Aufruf.
  3. Ermöglicht sehr schnelle Massensendungen (broadcasts).

Es werden 2 Arten der Kommunikation zwischen Clients unterstützt: Bei Fire and Forget sendet Client A eine Nachricht an Client B. Es handelt sich um eine einseitige Kommunikation, wobei Client B auch mehrere Applikationen seien können (broadcasts).
Client A hat bei dieser Art der Kommunikation keine Möglichkeit zu überprüfen, ob die Nachricht bei allen Clients angekommen ist, es interessiert Client A auch nicht.

Call and Listen behebt diesen Nachteil. Hierbei erwartet Client A eine Reaktion von Client B. A ist also im Stande zu überprüfen, ob seine versendete Nachricht alle Empfänger erreicht hat und kann gegebenenfalls auf die Antwort reagieren; es handelt sich um eine zwei-, bzw mehrseitige Kommunikation.

Die synchronen Aufrufe sind dafür leider langsamer als das asynchrone Senden. Der Entwickler hat im konkreten Fall die Entscheidung zu treffen, was ihm wichtiger ist. Ein sicheres Ankommen mit einer Antwortmöglichkeit einerseits, oder das schnellere (nicht abgesicherte) Versenden einer Nachricht andererseits.
Beide Methoden haben ihre Berechtigung für die Kommunikation auf dem Desktop.

Abschließend ein gekürztes, nicht vollständiges Code-Beispiel
   1 
   2 File myapp.cpp
   3 -------------------------------
   4   #include <kapp.h>
   5   #include <dcopclient.h>
   6 
   7   int main(int nargs, char** argv) {
   8     KApplication* a = new KApplication(nargs, argv, "myapp");
   9     a->setMainWidget(new ASmartWidget("smart"));
  10     QByteArray  data, reply_data;    // a byte array for the data and for the reply
  11     QCString reply_type; // will contain the type of the reply
  12 
  13     client = a.dcopClient();
  14     client.attach();
  15     client.registerAs("myapp");
  16 
  17   if (!client->call("otherClientId", // identify the recipient
  18                     "anObject/aChildOject", // designate the targeted object
  19                     "readAnIntAndAnswer(int)", // method to handle data and answer
  20                     data,                      // sent data
  21                     reply_type,  // type of data contained in the answer
  22                     reply_data);         // the answer
  23     kdDebug << "Calling over DCOP failed!" << endl;
  24   else {
  25     if (reply_type == "Qstring") {
  26       this->doSomething(answer(reply_data, IO_ReadOnly));
  27     } else
  28       kdDebug << "Calling over DCOP succeeded,\
  29              but the answer had wrong type!" << endl;
  30   }
  31 
  

Nachdem sich für die neue Applikation a (Zeile8) ein Client besorgt worden ist (Z.13), wird eine Verbindung zum DCOP-Server erstellt (Z.14). Es folgt die Anmeldung am Server unter dem Namen "myapp" (Z.15).
Die call-Methode(Z.17) entspricht in Verbindung mit answer (Z.26) dem "Call and Listen"-Prinzip.
Die call-Methode liefert die Antwortdaten reply-data (Z.22), sowie den Antworttyp reply-type (Z.21), die Daten können weiterverarbeitet werdem (Z.26), nachdem noch auf den richtigen Antworttyp überprüft worden ist (Z.25).

Konklusion

DCOP ist ein kleines aber feines System. Es ermöglicht Desktop-Anwendungen, miteinander zu kommunizieren, ohne die Lernkurve für die Programmierer unnötig steiler zu machen oder das Entwickeln von Anwendungen zäher und komplizierter.
Die Möglichkeit, eigene C++ Datentypen ohne aufwendige Konvertierungen direkt für entfernte Funktionsaufrufe verwenden zu können, macht das System besonders interesant für die GUI-Entwicklung, wo man es üblicherweise mit vielen Werte-basierten GUI-Datentypen zu tun hat. Der geringe Speicherverbrauch, erreicht durch die Verwendung bereits im Speicher befindlicher Komponenten, erlaubt es, DCOP für wirklich alle Desktop-Anwendungen einzusetzen.
... [ Seminar Linux und Apache] ... [ Thema Komponentenmodell von KDE 2 ] ... [ nach oben ] ... [ Applikationen ] ...