Entfernter Verfahren-Anruf

In der Informatik ist ein entfernter Verfahren-Anruf (RPC) eine Zwischenprozess-Kommunikation, die einem Computerprogramm erlaubt, ein Unterprogramm oder Verfahren zu veranlassen, in einem anderen Adressraum (allgemein auf einem anderen Computer in einem geteilten Netz) ohne den Programmierer durchzuführen, der ausführlich die Details für diese entfernte Wechselwirkung codiert.

D. h. der Programmierer schreibt im Wesentlichen denselben Code, ob das Unterprogramm zum Durchführungsprogramm lokal oder entfernt ist. Wenn die Software in der Frage objektorientierte Grundsätze verwendet, wird RPC entfernte Beschwörung oder entfernte Methode-Beschwörung genannt.

Viele verschieden (häufig unvereinbar) Technologien können verwendet werden, um das Konzept durchzuführen.

Geschichte und Ursprünge

Die Idee, Netzoperationen als entfernte Verfahren-Anrufe zu behandeln, geht mindestens zu den 1980er Jahren in frühen ARPANET Dokumenten zurück.

Bruce Jay Nelson wird allgemein das Münzen des Begriffes zugeschrieben.

Einer des ersten Geschäftsgebrauches von RPC war durch Xerox unter dem Namen "Bote" 1981. Die erste populäre Durchführung von RPC auf Unix war der RPC der Sonne (jetzt hat ONC RPC genannt), verwendet als die Basis für das Netzdateisystem.

Nachrichtenübergang

Ein RPC wird vom Kunden begonnen, der eine Bitte-Nachricht an einen bekannten entfernten Server sendet, um ein angegebenes Verfahren mit gelieferten Rahmen durchzuführen. Der entfernte Server sendet eine Antwort dem Kunden, und die Anwendung setzt seinen Prozess fort. Es gibt viele Schwankungen und Subtilität in verschiedenen Durchführungen, auf eine Vielfalt von verschiedenen (unvereinbaren) RPC Protokollen hinauslaufend. Während der Server den Anruf bearbeitet, wird der Kunde blockiert (es wartet, bis der Server beendet hat, vor der die Tätigkeit wieder aufnehmenden Ausführung in einer Prozession zu gehen), wenn der Kunde keine asynchrone Bitte an den Server wie ein XHTTP-Anruf sendet.

Ein wichtiger Unterschied zwischen entfernten Verfahren-Anrufen und Ortsgesprächen ist, dass entfernte Anrufe wegen unvorhersehbarer Netzprobleme scheitern können. Außerdem müssen sich Anrufer allgemein mit solchen Misserfolgen befassen ohne zu wissen, ob das entfernte Verfahren wirklich angerufen wurde. Verfahren von Idempotent (diejenigen, die keine zusätzlichen Effekten, wenn genannt, mehr haben als einmal) werden leicht behandelt, aber genug Schwierigkeiten bleiben, die codieren, um zu rufen, entfernte Verfahren wird häufig auf sorgfältig geschriebene auf niedriger Stufe Subsysteme beschränkt.

Folge von Ereignissen während eines RPC

  1. Der Kunde nennt den Kundenstummel. Der Anruf ist ein lokaler Verfahren-Anruf, mit Rahmen ist zum Stapel auf die normale Weise vorangegangen.
  2. Der Kundenstummel packt die Rahmen in eine Nachricht ein und macht einen Systemanruf, die Nachricht zu senden. Verpackung der Rahmen wird genannt aufstellend.
  3. Das lokale Betriebssystem des Kunden sendet die Nachricht von der Kundenmaschine bis die Server-Maschine.
  4. Das lokale Betriebssystem auf der Server-Maschine passiert die eingehenden Pakete zum Server-Stummel.
  5. Schließlich nennt der Server-Stummel das Server-Verfahren. Die Antwort verfolgt dieselben Schritte in der Rückwartsrichtung.

Standardkontakt-Mechanismen

Um verschiedene Kundenzugriffsserver zu lassen, sind mehrere standardisierte RPC Systeme geschaffen worden. Die meisten von diesen verwenden eine Schnittstelle-Beschreibungssprache (IDL), um verschiedene Plattformen den RPC nennen zu lassen. Die IDL Dateien können dann verwendet werden, um Code zu erzeugen, um zwischen dem Kunden und Server zu verbinden. Das allgemeinste dafür verwendete Werkzeug ist RPCGEN.

Andere RPC Entsprechungen

RPC Entsprechungen gefunden anderswohin:

  • Javas Java Entfernte Methode-Beschwörung (Java RMI) API stellt ähnliche Funktionalität dem Standard Unix RPC Methoden zur Verfügung.
  • Die Netzgegenstände von Modula-3, die die Basis für Javas RMI waren
  • XML-RPC ist ein RPC Protokoll, das XML verwendet, um seine Anrufe und HTTP als ein Transportmechanismus zu verschlüsseln.
  • JSON-RPC ist ein RPC Protokoll, das JSON-verschlüsselte Nachrichten verwendet
  • JSON-WSP ist ein RPC Protokoll, das JSON-verschlüsselte Nachrichten verwendet
  • SEIFE ist ein Nachfolger von XML-RPC und verwendet auch XML, um seine HTTP-basierten Anrufe zu verschlüsseln.
  • Microsoft.NET Remoting bietet RPC Möglichkeiten für verteilte auf der Windows-Plattform durchgeführte Systeme an. Es ist durch WCF ersetzt worden.
  • RPyC führt RPC Mechanismen in der Pythonschlange mit der Unterstützung für asynchrone Anrufe durch.
  • Pyro objektorientierte Form von RPC für die Pythonschlange.
  • Der Internetkommunikationsmotor von ZeroC (Eis) hat Rechenplattform verteilt.
  • Ätzen Sie (Protokoll) Fachwerk, um Netzdienste zu bauen.
  • Das Sparsamkeitsprotokoll und Fachwerk von Facebook.
  • CORBA stellt entfernte Verfahren-Beschwörung durch eine Zwischenschicht genannt den Gegenstand-Bitte-Makler zur Verfügung.
  • Verteilte Ruby (DRb) erlaubt Programmen von Ruby, mit einander auf derselben Maschine oder über ein Netz zu kommunizieren. DRb verwendet entfernte Methode-Beschwörung (RMI), um Befehle und Daten zwischen Prozessen zu passieren.
  • Action Message Format (AMF) erlaubt Anwendungen von Adobe Flex, mit Zurückenden oder anderen Anwendungen dieser Unterstützung AMF mitzuteilen.
  • Libevent stellt ein Fachwerk zur Verfügung, um RPC Server und Kunden zu schaffen.
  • Windows-Nachrichtenfundament ist eine Anwendung, Schnittstelle im.NET Fachwerk programmierend, um verbundene, dienstorientierte Anwendungen zu bauen.
  • Google Protokoll-Puffer (protobufs) Paket schließen eine für seine RPC Protokolle verwendete Schnittstelle-Definitionssprache ein.
  • Google Web Toolkit verwendet einen asynchronen RPC, um den Server-Dienst mitzuteilen.

Web

Siehe auch

  • Lokaler Verfahren-Anruf
  • SEIFE
  • HTTP
  • ODBC
  • Entfernter Funktionsanruf
  • Außendatendarstellung
  • ROA (Quellenorientierte Architektur)
:

Weiterführende Literatur

Außenverbindungen


Register-Übertragungssprache / Russisches Unterseeboot K-141 Kursk
Impressum & Datenschutz