RPC's als Einbahnstrasse ?



  • Hallo,

    Ich habe jetzt (vor längerer Zeit in Angriff genommen). Eine kleine Client Server Anwendung geschrieben :

    Ausgangspunkt siehe
    Cleint Server mit COM

    Nun sind mir da mehrere Möglichkeiten das vernüftig zu realisieren über den Weg gelaufen:

    1.) COM-DLL die mittels zugehöriger EXE als Systemdienst geladen wird
    Siehe z.B.: http://www.codeproject.com/com/hellotutorial6.asp

    Vorteil: schneller Zugriffsmechanismus
    Nachteil: IMHO unhandlich zu implementieren, besonders in bestehende
    Anwendungen, die um eine DCOM - Schnittstelle erweitert werden sollen

    2.) Realisierung über zwei OCX/DLL's, die die Client - Server - Schnittstelle
    zur Verfügung stellen und von der jeweiligen Anwendung benutzt werden.

    Vorteil: mhh, naja - was soll man sagen 🙂
    Nachteil: Jede Anwendung muß mit dieser DLL oder OCX erstellt werden (wird mir
    bei dem oben genannten Projekt zu unübersichtlich -> Client OCX,
    Server OCX, Client App, Server App)

    3.) Direkte Erstellung eines RPC - Zugriffs.

    Vorteil: -Schnittstelle kann Problemlos geändert oder erweitert werden
    -keine zusätzlich zu entwickelnde Komponente wird benötigt
    Nachteil: bisher fällt mir keiner ein...

    Also habe ich mich für Variante 3 entschieden. Das funktioniert auch soweit ganz gut nach einem Beispiel aus einem Mircosoft Press Buch über DCOM. Aber täusche ich mich oder ist dort nur der Remote Procedure Aufruf des Clients auf dem Server möglich? Kann man dafür auch einen Mechanismus wie Connection - Points verwenden? Oder muß ich dem Client auch Server- Funktionalität verpassen und umgekehrt, um RPC's auf beiden Systemen auszuführen?

    Danke



  • Gut, gut, letzter Versuch:

    Das RPC - Beispiel ist aus "Inside Distributed COM" von Guy Eddon und Henry Eddon. Auf dem Server werden im IDL - File die Interfacefunktionen definiert und auf der Clientseite wird mittels RPC - Funktionen eine Bindung dazu erzeugt.
    Nun ist die frage nach Funktionsaufrufen in die "andere" Richtung (Server-Client).

    Wenn das hier Niemand weiss, ist das ganze vielleicht bei Rund um.. besser aufgehoben oder?



  • Wenn man weiss, was RPC ist, dann eruebrigt sich, glaub ich, auch die Frage 🙂
    Setz dich mal mit COM, besonders mit den Marshallern auseinander, dann solltest theorethisch zu dem Ergebnis kommen, das DCOM nur nen Überbau zu RPC ist ...

    Mit RPC selber kenn ich mich ned so aus ... aber soviel ich weiss, geht der Funktionsaufruf nur in eine Richtung. Auf dem Empfaenger brauchst ja auch den RPC daemon, (oder service, bei windoof). Connection-Points werden mit Sicherheit durch mehere RPC-Aufrufe realisiert, in beiden Richtungen.

    Du könntest auch pollen, und deine RPC's asynchron aufrufen .... viel SPass beim programmieren 🙂

    Ciao ...



  • Du könntest auch pollen, und deine RPC's asynchron aufrufen .... viel SPass beim programmieren 🙂

    Pollen wollte ich eben gerade vermeiden (Sonst hätte ich es gleich mit Sockets gemacht 🙂 ). Das DCOM im Prinzip auch nur auf RPC aufgesetztes COM ist kam mir auch schon in den Sinn, besonders nachdem selbst in dem oben genannten Buch bei mir bei dem Beispiel zu DCOM eigentlich nur RPC-Aufrufe zu finden wahren.

    Fazit:

    Ich werde also meinem Client als Rück-Kanal auch ein Serverinterface verpassen und umgekehrt. Wie ist eigentlich das Verhältnis von RPC hinsichtlich der Ausführungs- und Übertragungsgeschwindigkeit im Vergleich zu Sockets?

    Vielen Dank schonmal für die Anregung, Spass werde ich wohl reichlich haben....


Anmelden zum Antworten