RPC: Was ist daran so besonders?



  • Hi,

    ich lese immer wieder über RPC, benötigt habe ich es noch nie.
    Ich frage mich, was da genau die Besonderheiten/Vorteile sein sollen.

    Ich kann doch einfach ein simples Protokoll definieren, zB. sende ich ein Byte als "message ID", und der Server führt bei ID 1 die Funktion1() aus, bei ID 2 die Funktion2() usw..

    Klar, man hat das halt alles gekapselt, bekommt also auch eine Response als Rückgabewert. Aber das ist doch meist synchron und somit ziemlich eingeschränkt.

    Es ist doch nicht so schwierig, selbst ein Paket loszuschicken und am Server eine simple Logik zu haben. Die Response kann man dann auch asynchron verarbeiten.

    Oder ist das einfach für die faulen Leute? 😛



  • Ja schön, und wenn du nun Übergabe von Parametern, das Dispatching und den ganzen Kram implementiert hast, dann hast die 1.000.001ste RPC-Implementierung geschrieben, Glückwunsch.



  • Natürlich ist RPC nichts besonderes. Natürlich kannst Du Dein eigenes Protokoll definieren, um Daten zwischen Prozessen auf verschiedenen Rechnern auszutauschen. Wenn Dein Server so ein response-reply hat, dann ist das im prinzip RPC. Also wenn Du das so gemacht hast, dann hast Du RPC genutzt.

    Und wenn Du etwas rundes baust, was sich einfacher wälzen lässt, als ein Quadrat, dann kannst Du das auch "Rad" nennen. Ist eigenlich eine prima Idee.

    Und "faule Leute"? Ist es Faul, wenn ich zum Reifenhändler gehe und mir neue Kompletträder kaufe statt sie einfach selbst zu bauen.

    Im übrigen ist so ein Protokoll gar nicht unbedingt so trivial. Du musst Dir Gedanken machen, wie Du deine Daten sinnvoll serialisierst und wieder deserialisierst. Und wie Du beispielsweise mit Verbindungsabbrüchen umgehen willst.

    Ach ja: es gibt nicht "das RPC"-Protokoll. Es gibt viele RPC-Protokolle. Du kannst gerne noch eins erfinden.



  • RPC-Lösungen haben die Tendenz zu viel auf einmal zu machen, aber nichts davon optimal. Das Protokoll ist mit nichts anderem kompatibel und reicht höchstens für das Problem der ursprünglichen Autoren 100% aus. Einfachste Konzepte wie Discriminated Unions fehlen fast immer. Selbstverständlich ist keine existierende Netzwerkbibliothek gut genug, also muss eine weitere erfunden werden. Signed int ist gut genug für jedermann. Ist das hier im Zweierkomplement? Who knows.



  • Der Beitrag ist nicht hilfreich.



  • es geht eigentlich nicht um 'vorteile', sondern darum auf funktionalitaet auf dem server zuzugreifen. ein simples beispiel sind XHRs, die dir im browser erlauben funktionen auf dem HTTP server aufzurufen.
    dabei brauchst du weder alle daten zu transferieren, noch die ganze funktionalitaet, du musst client und server nichtmal in der selben sprache oder zur selben zeit implementieren. oft sind die server nur services (z.b. wetter abfrage, navigationsdaten, werbe netzwerke, sms-schicken, aktien kurse,...) und darauf wird dann von verschiedenen clients zugegriffen. kann html/js basierend sein, aber genau so gut von einer app oder einem desktop-program.

    insofern, vorteile gibt es nicht. RPC ist eigentlich nicht da um besser zu sein als propriaetere client-server-software. RPC ist eher eine moeglichkeit server und clients voneinander zu entkoppeln.

    da wir jetzt std::async haben, waere ein std::remote recht nett.


Anmelden zum Antworten