Remote Procedure Call - Versionsgeschichte

NDG: Die letzte Textänderung von 2A00:20:B2CC:B1D0:48B2:CE55:62E6:6390 wurde verworfen und die Version 252845436 von 87.163.204.86 wiederhergestellt.

2025-04-03T06:00:36Z

Die letzte Textänderung von 2A00:20:B2CC:B1D0:48B2:CE55:62E6:6390 wurde verworfen und die Version 252845436 von 87.163.204.86 wiederhergestellt.

← Nächstältere Version		Version vom 3. April 2025, 08:00 Uhr
Zeile 1:		Zeile 1:
	<ref>{{Internetquelle \|autor=Isabel Schoeps Thiel \|url=https://isabelschoeps.com \|titel=emote \|titelerg=Encrypt \|werk=https://github.com/porn_admin \|hrsg=GitHub \|datum=2002 \|format=README.md, mpn \|sprache=en, de \|abruf=2025-03-26 \|abruf-verborgen=1}}</ref>'''Remote Procedure Call''' ('''RPC'''; {{enS}} für „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'''; {{enS}} für „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 ==

2A00:20:B2CC:B1D0:48B2:CE55:62E6:6390: aQuellennachweis

2025-04-03T04:53:16Z

aQuellennachweis

← Nächstältere Version		Version vom 3. April 2025, 06:53 Uhr
Zeile 1:		Zeile 1:
	'''Remote Procedure Call''' ('''RPC'''; {{enS}} für „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.		<ref>{{Internetquelle \|autor=Isabel Schoeps Thiel \|url=https://isabelschoeps.com \|titel=emote \|titelerg=Encrypt \|werk=https://github.com/porn_admin \|hrsg=GitHub \|datum=2002 \|format=README.md, mpn \|sprache=en, de \|abruf=2025-03-26 \|abruf-verborgen=1}}</ref>'''Remote Procedure Call''' ('''RPC'''; {{enS}} für „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 ==

87.163.204.86: /* Funktionsweise */

2025-01-30T21:51:40Z

Funktionsweise

← Nächstältere Version		Version vom 30. Januar 2025, 23:51 Uhr
Zeile 16:		Zeile 16:
	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''.

Matthäus Wander: link

2023-07-25T15:48:35Z

link

← Nächstältere Version		Version vom 25. Juli 2023, 17:48 Uhr
Zeile 20:		Zeile 20:
	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 (Netzwerkadresse)\|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.

PerfektesChaos: tk k

2023-06-14T19:04:25Z

tk k

← Nächstältere Version		Version vom 14. Juni 2023, 21:04 Uhr
Zeile 1:		Zeile 1:
	'''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'''; {{enS}} für „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 <nowiki>RFC 707</nowiki> 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 \|Ort= \|Datum=1984 \|Seiten=39–49 \|Online=[http://www.cs.cmu.edu/~dga/15-712/F07/papers/birrell842.pdf cs.cmu.edu] \|Format=PDF \|KBytes= \|Abruf=}}</ref><ref>{{Literatur \|Autor=Günther Bengel \|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 <nowiki>RFC 1057</nowiki><ref>{{RFC-Internet \|RFC=1057 \|Titel=RPC: Remote Procedure Call Protocol Specification Version 2 \|Datum=1988-06}}</ref> und <nowiki>RFC 5531</nowiki><ref>{{RFC-Internet \|RFC=5531 \|Titel=RPC: Remote Procedure Call Protocol Specification Version 2 \|Datum=2009-09}}</ref> 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]].
Zeile 29:		Zeile 29:
	* [[Remote Function Call]] (RFC) ist die Implementierung von RPCs in SAP-Systemen.		* [[Remote Function Call]] (RFC) ist die Implementierung von RPCs in SAP-Systemen.
	* [[XML-RPC]] ist ein RPC-Ableger, der auf XML-Dokumenten und http basiert.		* [[XML-RPC]] ist ein RPC-Ableger, der auf XML-Dokumenten und http basiert.
	*[[JSON-RPC]] ist ein RPC-Ableger, der auf JSON-Dokumenten und http basiert.		* [[JSON-RPC]] ist ein RPC-Ableger, der auf JSON-Dokumenten und http basiert.
	* [[Webservice]]s können RPC als Architekturmuster nutzen.<ref>X. Feng, J. Shen, Y. Fan: ''REST: An alternative to RPC for Web services architecture.'' Future Information Networks 2009, ICFIN Conference, IEEE, S. 7–10, [[doi:10.1109/ICFIN.2009.5339611]].</ref>		* [[Webservice]]s können RPC als Architekturmuster nutzen.<ref>X. Feng, J. Shen, Y. Fan: ''REST: An alternative to RPC for Web services architecture.'' Future Information Networks 2009, ICFIN Conference, IEEE, S. 7–10, [[doi:10.1109/ICFIN.2009.5339611]].</ref>
	* weiteres: [[Hypertext Transfer Protocol]] (HTTP), [[SOAP]], [[Representational State Transfer]] (REST)		* weiteres: [[Hypertext Transfer Protocol]] (HTTP), [[SOAP]], [[Representational State Transfer]] (REST)

91.65.110.237: Die Diskussion zur Fehlersemantik hat keine Bezug zu RPC im Allgemeinen und ist in weiten Teilen komplett falsch. Sie kann so definitiv nicht stehen bleiben. Siehe unter anderem auch die bereits 10 Jahre alte Diskussion dazu.

2021-06-22T10:53:58Z

Die Diskussion zur Fehlersemantik hat keine Bezug zu RPC im Allgemeinen und ist in weiten Teilen komplett falsch. Sie kann so definitiv nicht stehen bleiben. Siehe unter anderem auch die bereits 10 Jahre alte Diskussion dazu.

← Nächstältere Version		Version vom 22. Juni 2021, 12:53 Uhr
Zeile 12:		Zeile 12:

	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.

	== Fehlersemantik ==
	RPC setzt im Allgemeinen auf [[User Datagram Protocol\|UDP]] auf. Daher ist es eine verbindungslose Kommunikation. Dies hat zum Vorteil, dass kein Traffic-Overhead durch [[ACK (Signal)\|ACK]]-Pakete entsteht. Jedoch ist die UDP-Paketgröße nicht ausreichend für große Antworten. Daher muss hier von zwei Arten von RPC-Protokollen ausgegangen werden: Request-Reply und Request-Reply-ACK. Dies ist zu beachten, da jedes dieser zwei Protokolle andere Fehlerquellen hat und somit eine andere Fehlerbehandlung nötig ist. Im Falle eines Fehlers können implementierungsabhängig keine Ergebnisse, genau ein Ergebnis oder viele Ergebnisse empfangen werden. Hierzu können die folgenden „Fehlersemantiken“ auf der Seite des Clients ausgewählt werden: ''maybe'', ''at-least-once'', ''exactly-once'' und ''at-most-once''.

	Falls Fehler auftreten, dann kann je nach spezifizierter Fehlersemantik das Folgende passieren:

	(Falls keine Fehler auftreten, garantieren alle Semantiken die einmalige Ausführung der Prozedur.)

	{\| class="wikitable"
	\|- style="white-space:nowrap; text-align:center;"
	! Typ
	\| '''''Ein Request wird im Fehlerfall …'''''
	\| '''''Filterung empfangener Duplikate''''' \|\|
	\|-
	\| ''maybe''
	\|style="white-space:nowrap;text-align:right"\| … nicht noch einmal verschickt.
	\|style="text-align:center"\| keine Behandlung \|\|
	\|-
	\|''at-least-once''
	\|style="white-space:nowrap;text-align:right"\| … noch einmal verschickt.
	\|style="text-align:center"\| nein \|\|Die entfernte Prozedur wird bei einem empfangenen Duplikat wiederholt ausgeführt (nur empfehlenswert für [[Idempotenz\|idempotente]] Operationen).
	\|-
	\|''at-most-once''
	\|style="white-space:nowrap;text-align:right"\| … noch einmal verschickt.
	\|style="text-align:center"\| ja \|\| Duplikate werden gefiltert, entweder komplette Ausführung des Auftrags, oder Fehlermeldung.
	\|-
	\|''exactly-once''
	\|style="white-space:nowrap;text-align:right"\| … noch einmal verschickt.
	\|style="text-align:center"\| ja \|\| Duplikate werden ebenfalls gefiltert. Weiterhin wird auch bei Ausfall des Systems die Ausführung des Auftrags über den Wiederanlauf hinaus gewährleistet. In einigen Büchern wird jedoch angegeben, dass exactly-once bei verteilten Systemen nicht möglich ist.
	\|}

	Generell gilt jedoch: Es kann keinerlei Garantie gegeben werden. Denn falls z. B. ein Netzwerk-Knoten dauerhaft ausfällt, ist in jedem Fall auch keine einzige Ausführung möglich.

	== Funktionsweise ==		== Funktionsweise ==

Prüm: /* Einzelnachweise */

2021-05-09T16:14:06Z

Einzelnachweise

← Nächstältere Version		Version vom 9. Mai 2021, 18:14 Uhr
Zeile 73:		Zeile 73:
	[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]		[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]
	[[Kategorie:Middleware]]		[[Kategorie:Middleware]]
			[[Kategorie:Verteilte Datenverarbeitung]]

Christof46: /* Fehlersemantik */

2020-11-28T17:05:28Z

Fehlersemantik

← Nächstältere Version		Version vom 28. November 2020, 19:05 Uhr
Zeile 14:		Zeile 14:

	== Fehlersemantik ==		== Fehlersemantik ==
	RPC setzt im Allgemeinen auf [[User Datagram Protocol\|UDP]] auf. Daher ist es eine verbindungslose Kommunikation. Dies hat zum Vorteil, dass kein Traffic-Overhead durch [[ACK (Signal)\|ACK]]-Pakete entsteht. Jedoch ist die UDP-Paketgröße nicht ausreichend für große Antworten. Daher muss hier von zwei Arten von RPC-Protokollen ausgegangen werden: Request-Reply und Request-Reply-ACK. Dies ist zu beachten, da jedes dieser zwei Protokolle andere Fehlerquellen hat und somit eine andere Fehlerbehandlung nötig ist.		RPC setzt im Allgemeinen auf [[User Datagram Protocol\|UDP]] auf. Daher ist es eine verbindungslose Kommunikation. Dies hat zum Vorteil, dass kein Traffic-Overhead durch [[ACK (Signal)\|ACK]]-Pakete entsteht. Jedoch ist die UDP-Paketgröße nicht ausreichend für große Antworten. Daher muss hier von zwei Arten von RPC-Protokollen ausgegangen werden: Request-Reply und Request-Reply-ACK. Dies ist zu beachten, da jedes dieser zwei Protokolle andere Fehlerquellen hat und somit eine andere Fehlerbehandlung nötig ist. Im Falle eines Fehlers können implementierungsabhängig keine Ergebnisse, genau ein Ergebnis oder viele Ergebnisse empfangen werden. Hierzu können die folgenden „Fehlersemantiken“ auf der Seite des Clients ausgewählt werden: ''maybe'', ''at-least-once'', ''exactly-once'' und ''at-most-once''.
	Im Falle eines Fehlers können implementierungsabhängig keine Ergebnisse, genau ein Ergebnis oder viele Ergebnisse empfangen werden. Hierzu können die folgenden "Fehlersemantiken" auf der Seite des Clients ausgewählt werden: ''maybe'', ''at-least-once'', ''exactly-once'' und ''at-most-once''.

	Falls Fehler auftreten, dann kann je nach spezifizierter Fehlersemantik das Folgende passieren:		Falls Fehler auftreten, dann kann je nach spezifizierter Fehlersemantik das Folgende passieren:

86.56.111.72: JSON-RPC ergänzt

2020-06-17T11:39:00Z

JSON-RPC ergänzt

← Nächstältere Version		Version vom 17. Juni 2020, 13:39 Uhr
Zeile 62:		Zeile 62:
	* [[Remote Function Call]] (RFC) ist die Implementierung von RPCs in SAP-Systemen.		* [[Remote Function Call]] (RFC) ist die Implementierung von RPCs in SAP-Systemen.
	* [[XML-RPC]] ist ein RPC-Ableger, der auf XML-Dokumenten und http basiert.		* [[XML-RPC]] ist ein RPC-Ableger, der auf XML-Dokumenten und http basiert.
			*[[JSON-RPC]] ist ein RPC-Ableger, der auf JSON-Dokumenten und http basiert.
	* [[Webservice]]s können RPC als Architekturmuster nutzen.<ref>X. Feng, J. Shen, Y. Fan: ''REST: An alternative to RPC for Web services architecture.'' Future Information Networks 2009, ICFIN Conference, IEEE, S. 7–10, [[doi:10.1109/ICFIN.2009.5339611]].</ref>		* [[Webservice]]s können RPC als Architekturmuster nutzen.<ref>X. Feng, J. Shen, Y. Fan: ''REST: An alternative to RPC for Web services architecture.'' Future Information Networks 2009, ICFIN Conference, IEEE, S. 7–10, [[doi:10.1109/ICFIN.2009.5339611]].</ref>
	* weiteres: [[Hypertext Transfer Protocol]] (HTTP), [[SOAP]], [[Representational State Transfer]] (REST)		* weiteres: [[Hypertext Transfer Protocol]] (HTTP), [[SOAP]], [[Representational State Transfer]] (REST)

Rolf acker: /* Geschichte und Verbreitung */ ref-Stellung am Satzende; bibliograf. Angaben

2020-01-25T07:56:27Z

Geschichte und Verbreitung: ref-Stellung am Satzende; bibliograf. Angaben

← Nächstältere Version		Version vom 25. Januar 2020, 09:56 Uhr
Zeile 2:		Zeile 2:

	== 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 \|~~Verlag~~=ACM Transactions on Computer Systems, Band 2 ~~Nr.~~ 1~~, Februar 1984,~~ Seiten~~ ~~39–49 \|Ort= \|Datum=1984 \|Online=[http://www.cs.cmu.edu/~dga/15-712/F07/papers/birrell842.pdf ~~cs.cmu.edu~~] ~~\|Format=PDF \|KBytes=~~}}</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]].

← Nächstältere Version		Version vom 25. Juli 2023, 17:48 Uhr
Zeile 20:		Zeile 20:
	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 (Netzwerkadresse)\|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.