Diskussion:Remote Procedure Call

RPC arbeitet meiner Meinung nach nicht explizit auf der 7. Schicht des ISO/OSI Modells. Ich hätte es eher auf Schicht fünf angesiedelt (vgl: [1]). Wie ist eure Meinung dazu? --Deki 11:26, 26. Jan 2005 (CET)

RPC wird häufig auf Schicht 5 oder 6 eingeordnet, je nachdem ob der Schwerpunkt auf der Kommunikationssteuerung oder der plattformunabhängigen Darstellung von RPC liegt. Auf Schicht 7 habe ich es allerdings noch nie gesehen. --Ernst 26. April 2005

Genau so sehe ich das auch. Die 7 Schicht ist schliesslich die Applikationsschicht. Die Erklrung mit Schicht 5 und 6 war ja bis vor Kurzem auch vorhanden. Ich habe es korrigiert. --Joachim 11:36, 16. Mai 2005 (CEST)

RPC ist auch ein häufig verwendeter Name für das grundlegende Konzept. Sun-RPC ist spezieller, und damit können Protokoll, OS-spezifische Schnittstellen oder eine Implementierung von diesen gemeint sein. Diese Begriffe (RPC als Konzept und als Umsetzung) sollten daher getrennt dargestellt werden. Mopskatze 21:14, 12. Jul. 2007 (CEST)

Entwickler von RPC

So weit ich informiert bin wurde RPC ursprünglich nicht von Sun, sondern am XEROX PARC (1981) entwickelt.

Das kann ich bestätigen. Leider habe ich keine genauen Informationen zu Quellen, aber laut der Vorlesung Verteilte Systeme an der Uni Mainz muss die erste Beschreibung von einem Herrn Nelson stammen, der das als Dissertation am XEROX Palo Alto Research Center 1981 veröffentlicht hat. --Paschelino 20:27, 16. Jul. 2008 (CEST)

Lemma

Wenn hier schon mit den Teilübersetzungen rumexperimentiert wird, schlag ich mal "Fernprozeduraufruf" vor. Das entspricht der englischen Begriffsbildungsfolge und weist höchstens einen Nachteil auf, dass nämlich die Prozedur eine Lehnübersetzung aus dem Englischen ist - also ein Fast-Fremdwort. --SonniWPDisk. 20:06, 17. Sep. 2007 (CEST)

Künstliche Übersetzungen, die zudem nicht dem allgemeinen Sprachgebrauch entsprechen, können aber auch verwirren. --Paschelino 20:28, 16. Jul. 2008 (CEST)

Üblich ist "Entfernter Prozeduraufruf" oder ähnliches. Fernprozeduraufruf habe ich noch nie gehört. --Homac 23:45, 10. Mai 2011 (CEST)

RPC Parameterübergabe

Remote Procedure Calls können auch mit Parametern erfolgen. Aufgrund der möglichen Heterogenität von Client und Server (z.B. unterschiedliche Prozessorarchitektur mit Little- und Big-Endian oder unterschiedliche Zeichenkodierungen) gibt es besondere Erfordernisse hierfür. Stichwort: Netzdatendarstellung, z.B. External Data Representation -- Paschelino 20:57, 16. Jul. 2008 (CEST)

DBus

DBus gehört strenggenommen auch dazu und ist weit verbreitet... (nicht signierter Beitrag von 80.132.221.104 (Diskussion | Beiträge) 16:51, 25. Aug. 2009 (CEST))

Fehlersemantik

• Gibt es zur "Fehlersemantik" maybe eine Quelle? In RPC DCE ist sie eine Untergruppe der Ausführungssemantik idempotent, die at-least-once entspricht - somit kann das nicht die Quelle dafür sein. Homac 14:46, 9. Jan. 2012 (CET)
• "RPC setzt im Allgemeinen auf UDP auf" ist falsch. Siehe RFC 5531, MS RPCE und DCE RPC --Homac 00:00, 11. Mai 2011 (CEST)
• Der Begriff "Fehlersemantik" sollte definiert werden.

Das sollte vermutlich eine Übersetzung von "Execution Semantics" aus dem DCE RPC sein (siehe Remote Procedure Call Model (DCE)) --Homac 00:00, 11. Mai 2011 (CEST)

• "Hierzu können die folgenden "Fehlersemantiken" auf der Seite des Clients ausgewählt werden" - Wer wählt aus, und wann?
  • Der Client - irgendwann vor dem Aufruf. Homac 14:46, 9. Jan. 2012 (CET)
• "Generell gilt jedoch: Es kann keinerlei Garantie gegeben werden" Garantie wofür? (nicht signierter Beitrag von 87.78.201.145 (Diskussion | Beiträge) 16:52, 10. Mai 2010 (CEST))
  • Der Satz ist irreführend. Die Ausführungssemantik beschreibt das Verhalten für den Fall, dass ein Fehler aufgetreten ist, der Client-seitig nicht festgestellt wird. D.h., die Funktion, die am Client-Stub aufgerufen wird, gibt keinen Fehlercode zurück! Wenn also die Ausführung dieser Funktion erfolgreich war, dann ist die Funktion auf Server-Seite mindestens einmal, maximal einmal oder genau einmal ausgeführt worden. Tritt jedoch ein Zustand ein, in dem es nicht mehr möglich ist, dass die vorgegebene Ausführungssemantik eingehalten wird, dann muss dieser Umstand als Fehler gemeldet werden! Mit anderen Worten: Die Middleware muss an dieser Stelle garantieren, dass die Ausführungssemantik eingehalten wird und andernfalls einen Fehler melden. Homac 14:08, 9. Jan. 2012 (CET)

Fremdzugriffe

Könnte das mal jemand sichten, der sich damit auskennt? Da wurde vor kurzem ein ganzer Abschnitt über mögliche Angriffe entfernt. Bin darauf aufmerksam geworden, weil es so wie es jetzt da steht keinerlei Sinn ergibt. Die Überschrift steht in keinem Zusammenhang zum (Mini-)Absatz, der Satz selbst ergibt keinen Sinn und was die Kommandozeilen in den Klammern sollen ist auch nicht klar. Ich nehme mal an es geht um den entsprechenden Windows-Service und welche Einfallstore für Hacker der bietet. -- 77.185.206.5 14:33, 4. Mär. 2012 (CET)

Vermutlich wurden die Zeilen deshalb entfernt :D / Spass beiseite, mir ist der Absatz ebenfalls aufgefallen und ich denke, dass er ganz weg kann, weil er sich auf eine bestimmte Implementierung bezieht und daher nichts in diesem Artikel, der sich mit dem grundlegenden Konzept auseinandersetzt, zu suchen hat. 82.82.138.197 20:13, 4. Jan. 2015 (CET)

Habe mir den Absatz in der Historie noch einmal angesehen und er ergibt keinen ersehbaren Sinn im engeren Bezug auf den Artikel. Ein von dem Verfasser angemahnter unerlaubter Zugriff durch das Unternehmen welches das Betriebssystem und die Middleware entwickelt und/oder dritte, die mit dem Unternehmen zusammenarbeiten, ist/sind in keinster Weise auf RPC angewiesen. Darüberhinaus gilt insbesonder was ich oben schon angemerkt habe. 82.82.138.197 20:45, 4. Jan. 2015 (CET)

Funktionsweise

Ist das die Funktionsweise von RPC unter Windows? Sollte verdeutlicht werden, da es auf jeden Fall nicht die generelle Funktionsweise beschreibt. -- 195.243.27.84 16:06, 9. Mai 2012 (CEST)