[linux-l] SUN-RPC

Peter Ross Peter.Ross at alumni.tu-berlin.de
Di Dez 16 03:12:04 CET 2003


On Mon, 15 Dec 2003, Jan-Benedict Glaw wrote:

> Widerspruch #3:
>
> RPC ist ein *Konzept*, kein Protokoll. Es ist bedauernswert, daß einige
> Protokolle das Kürzel "RPC" im Namen haben.
>
> Auch HTTP (im Einsatz als Webserver) ist im Prinzip RPC:
>
> 	Input:		URL
> 			If-Modified-Since
> 			...
>
> 	Output:		Return-Wert (200, 404, ...)
> 			HTML-Code
>
> Wow, das ist ja sogar RPC mit varargs!

Auch auf die Gefahr, jetzt als stoerrisch zu gelten: Nein.

1.RPC ist der Name fuer zwei Protokolle, die deshalb einen Vorsatz
brauchen, um unterscheidbar zu sein.

2. HTTP ist ein Datentransferprotokoll, aehnlich wie FTP. Auch dort
bekomme ich bei "mget *" Daten und Return-Werte und doch ist es kein RPC.

RPC ist designt, um auf einem fremden Rechner Prozeduren aufzurufen, HTTP
und FTP nicht.

Dass das de facto HTTP anderswo Code ausfuehrt und das Resultat
zurueckschickt, liegt daran, dass die Daten nicht statisch sind und so
erst dynamisch generiert werden.

Wenn ich im FTP "get daten_von_heute" mache und der FTP-Server bemerken
wuerde, dass die zu generieren sind, um dann das Generieren anzuwerfen und
das Resultat zu uebertragen, waere das ein erweiterter FTP-Server, der das
Protokoll nicht veraendert. Es ist nach wie vor ein
Datenuebertragungsprotokoll.

DCE-RPC kenne ich, wie schon gesagt nicht, aber in Sun-RPC gibt es einen
zentralen Server (portmapper oder rpcbind), der Dienste registriert, die
bereit sind, Prozeduren auszufuehren, die von einem Client remote
ausgefuehrt werden duerfen.

Ein Webbrowser z.B. weiss von den Prozeduren hinter dem Server gar nichts.
Alles, was er haben will, sind Daten.

Ein RPC-Client will dagegen, dass remote Prozeduren ausgefuehrt werden.
das ist Teil des Konzepts. Ob er die findet, kann er beim Portmapper
erfragen.

Wie ich schon sagte, dass man etwas aufbohren kann, um damit alles
Moegliche anzustellen, aendert nichts daran, dass sie nicht dafuer gedacht
sind.

Daran krankt nicht zuletzt das Web. Guck Dir doch den ganzen Schrott an,
der nur da ist, weil alle einen Webbrowser haben. Frueher haette man
dafuer eine Client-Server-Applikation geschrieben, und die waere oft
wesentlich besser designt als der ganze Webschrott, der auf einem
zustandslosen und so schon von Anfang an sehr fragwuerdigem Protokoll
beruht (Deswegen gibt es die Kekse und Session-IDs in der URL nun, alles
nur, um diesem Problem abzuhelfen.. klassisch kranker Workaround)

Ja, der Nachteil der Client-Server-Geschichte ist die
Plattformabhaengigkeit. Deshalb gab es mal eine vernuenftige Idee namens
Java - einmal laden und ausfuehren, egal wo. Vorraussetzung: eine VM.

Und das geht auf Performance-Kosten. Tja, man kann nicht alles haben..
wobei ich mich langsam frag', was der Anwender noch an GHz braucht, wenn
der Bottleneck doch zumeist in Wirklichkeit der des Annwenders ist,
welcher kaum in der Lage ist, schnell genug zu denken.

Aber Gott sei Dank gibt es ja weltweit warten, damit das nicht weiter
auffaellt.

Gruss
Peter





Mehr Informationen über die Mailingliste linux-l