Remote Procedure Call: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“ |
||
| (18 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
'''topic''' | '''topic''' - Kurzbeschreibung | ||
== Beschreibung == | == Beschreibung == | ||
'''Remote Procedure Call''' ('''RPC'''; [[Englische Sprache|engl.]] „Aufruf einer fernen Prozedur“) ist eine Technik zur Realisierung von [[Interprozesskommunikation]]. | |||
* Sie ermöglicht den Aufruf von [[Funktion (Programmierung)|Funktionen]] in anderen [[Adressraum#Adressraum in der Informationstechnologie|Adressräumen]]. | |||
* Im Normalfall werden die aufgerufenen Funktionen auf einem anderen [[Computer]] als das aufrufende Programm ausgeführt. | |||
* Es existieren viele Implementierungen dieser Technik, die in der Regel untereinander nicht kompatibel sind. | |||
'''Remote Procedure Call''' ('''RPC'''; [[Englische Sprache|engl.]] „Aufruf einer fernen Prozedur“) ist eine Technik zur Realisierung von [[Interprozesskommunikation]]. Sie ermöglicht den Aufruf von [[Funktion (Programmierung)|Funktionen]] in anderen [[Adressraum#Adressraum in der Informationstechnologie|Adressräumen]]. Im Normalfall werden die aufgerufenen Funktionen auf einem anderen [[Computer]] als das aufrufende Programm ausgeführt. Es existieren viele Implementierungen dieser Technik, die in der Regel untereinander nicht kompatibel sind. | |||
== Geschichte und Verbreitung == | == Geschichte und Verbreitung == | ||
Der Grundgedanke von RPC wurde erstmals 1976 von James E. White im RFC 707 publiziert.<ref>{{RFC-Internet |Autor=James E. White |RFC=707 |Titel=A High-Level Framework for Network-Based Resource Sharing |Datum=1976-01-14 |Kommentar=''Proceedings of the 1976 National Computer Conference''}}</ref> Eine der ersten Implementierungen ist ''Xerox Courier'', das ein Teil des ''Xerox Network Systems (XNS)'' ist und auch in [[NetWare|Novells Netware]] benutzt wird.<ref>{{Literatur |Autor=Andrew D. Birrell, Bruce Jay Nelson |Hrsg=Xerox Palo Alto Research Center |Titel=Implementing Remote Procedure Calls |Sammelwerk=ACM Transactions on Computer Systems |Band=2 |Nummer=1 |Seiten=39–49 |Ort= |Datum=1984 |Online=[http://www.cs.cmu.edu/~dga/15-712/F07/papers/birrell842.pdf PDF]}}</ref><ref>{{Literatur |Autor=Günther Bengel |Hrsg= |Titel=Grundkurs verteilte Systeme |Verlag=Vieweg und Teubner Verlag |Ort= |Datum=2005 |ISBN=3-528-25738-5}}</ref> Die Entwickler [[Andrew Birrell]] und [[Bruce Nelson]] erhielten dafür 1994 den [[ACM Software System Award]]. Der genaue Aufbau von RPC ist in RFC 1057 und RFC 5531 beschrieben. | Der Grundgedanke von RPC wurde erstmals 1976 von James E. White im RFC 707 publiziert.<ref>{{RFC-Internet |Autor=James E. White |RFC=707 |Titel=A High-Level Framework for Network-Based Resource Sharing |Datum=1976-01-14 |Kommentar=''Proceedings of the 1976 National Computer Conference''}}</ref> | ||
* Eine der ersten Implementierungen ist ''Xerox Courier'', das ein Teil des ''Xerox Network Systems (XNS)'' ist und auch in [[NetWare|Novells Netware]] benutzt wird.<ref>{{Literatur |Autor=Andrew D. Birrell, Bruce Jay Nelson |Hrsg=Xerox Palo Alto Research Center |Titel=Implementing Remote Procedure Calls |Sammelwerk=ACM Transactions on Computer Systems |Band=2 |Nummer=1 |Seiten=39–49 |Ort= |Datum=1984 |Online=[http://www.cs.cmu.edu/~dga/15-712/F07/papers/birrell842.pdf PDF]}}</ref><ref>{{Literatur |Autor=Günther Bengel |Hrsg= |Titel=Grundkurs verteilte Systeme |Verlag=Vieweg und Teubner Verlag |Ort= |Datum=2005 |ISBN=3-528-25738-5}}</ref> | |||
* Die Entwickler [[Andrew Birrell]] und [[Bruce Nelson]] erhielten dafür 1994 den [[ACM Software System Award]]. | |||
* Der genaue Aufbau von RPC ist in RFC 1057 und RFC 5531 beschrieben. | |||
Die am weitesten verbreitete Variante ist das ''ONC RPC ([[Open Network Computing]] Remote Procedure Call)'', das vielfach auch als Sun RPC bezeichnet wird. ONC RPC wurde ursprünglich durch [[Sun Microsystems]] für das ''[[Network File System]] (NFS)'' entwickelt. Für diese RPC-Variante findet sich unter anderem auch eine [[Implementierung]] in [[Linux]]. | Die am weitesten verbreitete Variante ist das ''ONC RPC ([[Open Network Computing]] Remote Procedure Call)'', das vielfach auch als Sun RPC bezeichnet wird. | ||
* ONC RPC wurde ursprünglich durch [[Sun Microsystems]] für das ''[[Network File System]] (NFS)'' entwickelt. | |||
* Für diese RPC-Variante findet sich unter anderem auch eine [[Implementierung]] in [[Linux]]. | |||
Die Implementierung [[Distributed Computing Environment|Distributed Computing Environment Remote Procedure Call]] (DCE RPC) ist ebenfalls weit verbreitet. Microsoft leitete Microsoft RPC (MSRPC) von der DCE RPC 1.1 Referenzimplementation ab. Auf dieser Grundlage wurde später [[Distributed Component Object Model|DCOM]] implementiert. Die Erfahrungen aus DCOM flossen in [[.NET Remoting]] ein. | Die Implementierung [[Distributed Computing Environment|Distributed Computing Environment Remote Procedure Call]] (DCE RPC) ist ebenfalls weit verbreitet. | ||
* Microsoft leitete Microsoft RPC (MSRPC) von der DCE RPC 1.1 Referenzimplementation ab. | |||
* Auf dieser Grundlage wurde später [[Distributed Component Object Model|DCOM]] implementiert. | |||
* Die Erfahrungen aus DCOM flossen in [[.NET Remoting]] ein. | |||
== Ablauf == | == Ablauf == | ||
RPC ist eine Möglichkeit, ein [[Client-Server-Modell]] zu implementieren. Die Kommunikation beginnt, indem der Client eine Anfrage an einen bekannten Server schickt und auf die Antwort wartet. In der Anfrage gibt der Client an, welche Funktion mit welchen Parametern ausgeführt werden soll. Der Server bearbeitet die Anfrage und schickt die Antwort an den Client zurück. Nach Empfang der Nachricht kann der Client seine Verarbeitung fortführen. | RPC ist eine Möglichkeit, ein [[Client-Server-Modell]] zu implementieren. | ||
* Die Kommunikation beginnt, indem der Client eine Anfrage an einen bekannten Server schickt und auf die Antwort wartet. | |||
* In der Anfrage gibt der Client an, welche Funktion mit welchen Parametern ausgeführt werden soll. | |||
* Der Server bearbeitet die Anfrage und schickt die Antwort an den Client zurück. | |||
* Nach Empfang der Nachricht kann der Client seine Verarbeitung fortführen. | |||
Beim Einsatz von RPC können durch Kommunikationsfehler unterschiedliche Fehlerkonstellationen auftreten, die beachtet und bearbeitet werden müssen. | Beim Einsatz von RPC können durch Kommunikationsfehler unterschiedliche Fehlerkonstellationen auftreten, die beachtet und bearbeitet werden müssen. | ||
== Funktionsweise == | == Funktionsweise == | ||
Um eine fremde Prozedur aufzurufen, muss eine Nachricht vom Client-Prozess zum Server-Prozess versendet werden. In dieser müssen der Name der Prozedur (oder eine ID) und die zugehörigen Parameterwerte enthalten sein. Die Nachricht sollte letztlich bei einem Server-Prozess ankommen, der genau diese Prozedur implementiert (hierzu erforderlich beim Server: ''register'' (Bekanntmachung, Sicherstellen des öffentlichen Zugangs); hierzu erforderlich beim Client: ''lookup'' und ''binding''). | Um eine fremde Prozedur aufzurufen, muss eine Nachricht vom Client-Prozess zum Server-Prozess versendet werden. | ||
* In dieser müssen der Name der Prozedur (oder eine ID) und die zugehörigen Parameterwerte enthalten sein. | |||
* Die Nachricht sollte letztlich bei einem Server-Prozess ankommen, der genau diese Prozedur implementiert (hierzu erforderlich beim Server: ''register'' (Bekanntmachung, Sicherstellen des öffentlichen Zugangs); hierzu erforderlich beim Client: ''lookup'' und ''binding''). | |||
Die Suche nach einem entsprechenden Server kann durch [[Broadcast]] (in einem lokalen Netz) realisiert werden oder durch Inanspruchnahme eines [[Verzeichnisdienst]]es. (Der Verzeichnisdienst hält ein global verfügbares Objekt, genauer ein Verzeichnis von Servern und den von ihnen implementierten Prozeduren bereit.) | Die Suche nach einem entsprechenden Server kann durch [[Broadcast]] (in einem lokalen Netz) realisiert werden oder durch Inanspruchnahme eines [[Verzeichnisdienst]]es. (Der Verzeichnisdienst hält ein global verfügbares Objekt, genauer ein Verzeichnis von Servern und den von ihnen implementierten Prozeduren bereit.) | ||
Die Suche und die Codierung, aber auch z. B. notwendige [[Rollback|Recovery-Maßnahmen]] (''error recoveries'') erledigt auf der Seite des Clients der ''client stub''. | Die Suche und die Codierung, aber auch z. B. notwendige [[Rollback|Recovery-Maßnahmen]] (''error recoveries'') erledigt auf der Seite des Clients der ''client stub''. | ||
Die wichtigste Komponente auf der Serverseite ist der ''[[Portmapper]]''-[[Daemon]], der bei ONC RPC auf dem [[User Datagram Protocol|UDP]]- und [[Transmission Control Protocol|TCP]]-[[Port (Protokoll)|Port]] 111 lauscht; bei DCE RPC übernimmt diese Funktion der ''Endpointmapper'', welcher auf dem UDP- und TCP-Port 135 lauscht. ''Portmapper'' resp. ''Endpointmapper'' übernehmen die Koordination der durch den Client gewünschten Funktionsaufrufe. Jedes Programm, das auf dem Server RPC-Dienste zur Verfügung stellen will, muss ihm daher bekannt sein. | Die wichtigste Komponente auf der Serverseite ist der ''[[Portmapper]]''-[[Daemon]], der bei ONC RPC auf dem [[User Datagram Protocol|UDP]]- und [[Transmission Control Protocol|TCP]]-[[Port (Protokoll)|Port]] 111 lauscht; bei DCE RPC übernimmt diese Funktion der ''Endpointmapper'', welcher auf dem UDP- und TCP-Port 135 lauscht. ''Portmapper'' resp. ''Endpointmapper'' übernehmen die Koordination der durch den Client gewünschten Funktionsaufrufe. | ||
* Jedes Programm, das auf dem Server RPC-Dienste zur Verfügung stellen will, muss ihm daher bekannt sein. | |||
Wenn der Rechner, auf dem der Server-Prozess läuft, die Anfrage empfängt, so wird mit Hilfe des Portmappers entweder erst der Prozess erschaffen, der die Prozedur ausführt, oder alternativ kann ein Prozess auch nur aktiviert werden (in diesem Fall wird eine vordefinierte Anzahl von Prozessen bereitgehalten). Oder aber es wird ein neuer [[Thread (Informatik)|Thread]] erzeugt. | Wenn der Rechner, auf dem der Server-Prozess läuft, die Anfrage empfängt, so wird mit Hilfe des Portmappers entweder erst der Prozess erschaffen, der die Prozedur ausführt, oder alternativ kann ein Prozess auch nur aktiviert werden (in diesem Fall wird eine vordefinierte Anzahl von Prozessen bereitgehalten). | ||
* Oder aber es wird ein neuer [[Thread (Informatik)|Thread]] erzeugt. | |||
== Installation == | |||
== Anwendungen == | |||
=== Problembehebung === | |||
== Aufruf == | |||
=== Optionen === | |||
=== Parameter === | |||
=== Umgebung === | |||
=== Rückgabewert === | |||
== Konfiguration == | |||
=== Dateien === | |||
== Sicherheit == | |||
== Dokumentation == | |||
=== RFC === | |||
=== Man-Page === | |||
=== Info-Pages === | |||
== Siehe auch == | == Siehe auch == | ||
== Weblinks == | == Links == | ||
=== Projekt-Homepage === | |||
=== Weblinks === | |||
# Kapitel 9: [https://msdn.microsoft.com/de-de/library/dn151205.aspx ''Remote Procedure Call – RPC''.] microsoft.com Netzwerk-Know-how, tecCHANNEL COMPACT (deutsch) | |||
[[Kategorie: | [[Kategorie:OSI/5 Session]] | ||
Aktuelle Version vom 12. November 2024, 18:36 Uhr
topic - Kurzbeschreibung
Beschreibung
Remote Procedure Call (RPC; engl. „Aufruf einer fernen Prozedur“) ist eine Technik zur Realisierung von Interprozesskommunikation.
- Sie ermöglicht den Aufruf von Funktionen in anderen Adressräumen.
- Im Normalfall werden die aufgerufenen Funktionen auf einem anderen Computer als das aufrufende Programm ausgeführt.
- Es existieren viele Implementierungen dieser Technik, die in der Regel untereinander nicht kompatibel sind.
Geschichte und Verbreitung
Der Grundgedanke von RPC wurde erstmals 1976 von James E. White im RFC 707 publiziert.[1]
- Eine der ersten Implementierungen ist Xerox Courier, das ein Teil des Xerox Network Systems (XNS) ist und auch in Novells Netware benutzt wird.[2][3]
- Die Entwickler Andrew Birrell und Bruce Nelson erhielten dafür 1994 den ACM Software System Award.
- Der genaue Aufbau von RPC ist in RFC 1057 und RFC 5531 beschrieben.
Die am weitesten verbreitete Variante ist das ONC RPC (Open Network Computing Remote Procedure Call), das vielfach auch als Sun RPC bezeichnet wird.
- ONC RPC wurde ursprünglich durch Sun Microsystems für das Network File System (NFS) entwickelt.
- Für diese RPC-Variante findet sich unter anderem auch eine Implementierung in Linux.
Die Implementierung Distributed Computing Environment Remote Procedure Call (DCE RPC) ist ebenfalls weit verbreitet.
- Microsoft leitete Microsoft RPC (MSRPC) von der DCE RPC 1.1 Referenzimplementation ab.
- Auf dieser Grundlage wurde später DCOM implementiert.
- Die Erfahrungen aus DCOM flossen in .NET Remoting ein.
Ablauf
RPC ist eine Möglichkeit, ein Client-Server-Modell zu implementieren.
- Die Kommunikation beginnt, indem der Client eine Anfrage an einen bekannten Server schickt und auf die Antwort wartet.
- In der Anfrage gibt der Client an, welche Funktion mit welchen Parametern ausgeführt werden soll.
- Der Server bearbeitet die Anfrage und schickt die Antwort an den Client zurück.
- Nach Empfang der Nachricht kann der Client seine Verarbeitung fortführen.
Beim Einsatz von RPC können durch Kommunikationsfehler unterschiedliche Fehlerkonstellationen auftreten, die beachtet und bearbeitet werden müssen.
Funktionsweise
Um eine fremde Prozedur aufzurufen, muss eine Nachricht vom Client-Prozess zum Server-Prozess versendet werden.
- In dieser müssen der Name der Prozedur (oder eine ID) und die zugehörigen Parameterwerte enthalten sein.
- Die Nachricht sollte letztlich bei einem Server-Prozess ankommen, der genau diese Prozedur implementiert (hierzu erforderlich beim Server: register (Bekanntmachung, Sicherstellen des öffentlichen Zugangs); hierzu erforderlich beim Client: lookup und binding).
Die Suche nach einem entsprechenden Server kann durch Broadcast (in einem lokalen Netz) realisiert werden oder durch Inanspruchnahme eines Verzeichnisdienstes. (Der Verzeichnisdienst hält ein global verfügbares Objekt, genauer ein Verzeichnis von Servern und den von ihnen implementierten Prozeduren bereit.)
Die Suche und die Codierung, aber auch z. B. notwendige Recovery-Maßnahmen (error recoveries) erledigt auf der Seite des Clients der client stub.
Die wichtigste Komponente auf der Serverseite ist der Portmapper-Daemon, der bei ONC RPC auf dem UDP- und TCP-Port 111 lauscht; bei DCE RPC übernimmt diese Funktion der Endpointmapper, welcher auf dem UDP- und TCP-Port 135 lauscht. Portmapper resp. Endpointmapper übernehmen die Koordination der durch den Client gewünschten Funktionsaufrufe.
- Jedes Programm, das auf dem Server RPC-Dienste zur Verfügung stellen will, muss ihm daher bekannt sein.
Wenn der Rechner, auf dem der Server-Prozess läuft, die Anfrage empfängt, so wird mit Hilfe des Portmappers entweder erst der Prozess erschaffen, der die Prozedur ausführt, oder alternativ kann ein Prozess auch nur aktiviert werden (in diesem Fall wird eine vordefinierte Anzahl von Prozessen bereitgehalten).
- Oder aber es wird ein neuer Thread erzeugt.
Installation
Anwendungen
Problembehebung
Aufruf
Optionen
Parameter
Umgebung
Rückgabewert
Konfiguration
Dateien
Sicherheit
Dokumentation
RFC
Man-Page
Info-Pages
Siehe auch
Links
Projekt-Homepage
Weblinks
- Kapitel 9: Remote Procedure Call – RPC. microsoft.com Netzwerk-Know-how, tecCHANNEL COMPACT (deutsch)