3. DAS RPC-MODELL

Das ONC-RPC-Protokoll basiert auf dem Remote Procedure Callmodell, das dem lokalen Verfahrensanrufmodell ähnlich ist. Im lokalen Fall legt der Anrufer Argumente zu einem Verfahren in etwas gut spezifizierte Position (wie ein Registerfenster). Es bringt dann Steuerung auf das Verfahren und gewinnt schließlich Steuerung wieder. An diesem Punkt werden die Resultate des Verfahrens von der gut spezifizierten Position extrahiert, und der Anrufer setzt Durchführung fort. Das Remote Procedure Callmodell ist ähnlich.

Ein Gewinde der Steuerlogisch Winde durch zwei Prozesse: der Prozeß des Anrufers und Prozeß eines Bedieners. Der Anruferprozeß zuerst schickt eine Anrufanzeige zum Bedienerprozeß und wartet (Blöcke) auf eine Antwortanzeige. Die Anrufanzeige umfaßt die Parameter des Verfahrens, und die Antwortanzeige umfaßt die Resultate des Verfahrens. Einmal wird die Antwortanzeige empfangen, werden die Resultate des Verfahrens extrahiert, und Durchführung des Anrufers wird wieder aufgenommen.

Auf der Bedienerseite ist ein Prozeß schlafend, die Ankunft einer Anrufanzeige erwartend. Wenn man ankommt, extrahiert der Bedienerprozeß die Parameter des Verfahrens, berechnet die Resultate, sendet eine Antwortanzeige und erwartet dann die folgende Anrufanzeige. In diesem Modell ist nur eins der zwei Prozesse zu jeder möglicher gegebenen Zeit aktiv. Jedoch wird dieses Modell nur als Beispiel gegeben. Das ONC-RPC-Protokoll bildet keine Beschränkungen auf dem eingeführten Parallelitätsmodell, und andere sind möglich.

Z.B. kann eine Implementierung beschließen, RPC-Anrufe asynchron sein zu lassen, damit der Klient nützliche Arbeit bei der Aufwartung der Antwort vom Bediener erledigen kann. Eine andere Möglichkeit soll den Bediener eine unterschiedliche Aufgabe verursachen lassen, einen eingehenden Anruf zu verarbeiten, damit der ursprüngliche Bediener frei sein kann, andere Anträge zu empfangen. Es gibt einige wichtige Weisen, in denen Remoteverfahrensanrufe von den lokalen Verfahrensanrufen sich unterscheiden:

1. Fehlerbehandlung: Ausfälle des Remotebedieners oder des Netzes müssen angefaßt werden, wenn man Remoteverfahren verwendet, benennt.

2. Globale Variablen und Nebenwirkungen: da der Bediener nicht Zugang zum Adressbereich des Klienten hat, können versteckte Argumente nicht als globale Variablen geführt werden oder als Nebenwirkungen zurückgebracht werden.

3. Leistung: Remoteverfahren lassen normalerweise ein oder mehr Aufträge der Größe langsam laufen, als lokales Verfahren benennt.

4. Authentisierung: da Remoteverfahrensanrufe über ungesicherte Netze transportiert werden können, kann Authentisierung notwendig sein. Authentisierung verhindert, daß ein Wesen als irgendein anderes Wesen masquerading.

Die Zusammenfassung ist daß, obwohl es die Werkzeuge zum automatisch Erzeugen der Klienten- und Bedienerbibliotheken für einen gegebenen Service gibt, Protokolle muß noch sorgfältig entworfen werden.

4. TRANSPORTE UND SEMANTIK

Das RPC-Protokoll können auf einigen unterschiedlichen Transportprotokollen eingeführt werden. Das RPC-Protokoll interessiert, wie sich eine Anzeige von einem Prozeß zu anderen geführt wird, aber nicht nur mit Spezifikation und Deutung der Anzeigen. Jedoch kann die Anwendung möchte Informationen über (und möglicherweise Steuerung über) die Transportschicht durch eine Schnittstelle erreichen, die nicht in diesem Dokument spezifiziert wird.

Z.B. kann das Transportprotokoll eine Beschränkung der maximalen Größe der RPC-Anzeigen auferlegen, oder es kann wie TCP ohne Größenbegrenzung stream-oriented sein. Der Klient und der Bediener müssen über ihre Transportprotokollwahlen einigSEIN. Es ist wichtig, zu unterstreichen, daß RPC versucht, keine Art Zuverlässigkeit einzuführen und daß die Anwendung die Art des Transportprotokolls unter RPC berücksichtigen müssen kann. Wenn es weiß, läuft es auf einen zuverlässigen Transport wie TCP [ 6 ], dann die meisten der Arbeit wird getan bereits für es. Andererseits wenn es auf einen unzuverlässigen Transport wie UDP [ 7 ] läuft, muß es seinen eigenen Time-out, nochmalige Übertragung und doppelte Abfragungspolitik einführen, da das RPC-Protokoll nicht diese Dienstleistungen liefert. Wegen der Transportunabhängigkeit bringt das RPC-Protokoll spezifische Semantik nicht zu den Remoteverfahren oder zu ihren Durchführungsanforderungen an. Semantik kann, aus (aber sollte ausdrücklich vorbei spezifiziert werden), dem zugrundeliegenden Transportprotokoll geschlossen werden.

Z.B. betrachten Sie RPC, das auf einen unzuverlässigen Transport wie UDP läuft. Wenn eine Anwendung RPC-Anrufanzeigen nach Zeitheraus nochmal überträgt und nicht eine Antwort empfängt, kann sie nicht nichts über die Zahl Zeiten schließen, die das Verfahren durchgeführt wurde. Wenn sie eine Antwort empfängt, dann kann sie schließen, daß das Verfahren mindestens einmal durchgeführt wurde. Ein Bediener kann möchte sich an vorher bewilligte Anträge von einem Klienten erinnern und nicht regrant sie, um irgendeinen Grad von zu versichern durchführen-an-am meisten-sobald Semantik. Ein Bediener kann dies tun, indem er Nutzen aus der Verhandlung Identifikation zieht, die mit jeder RPC-Anzeige verpackt wird. Der Hauptgebrauch von dieser Verhandlung Identifikation ist durch das Klienten-RPC-Wesen in zusammenpassenden Antworten auf Anrufe.

Jedoch kann eine Klientenanwendung beschließen, seine vorhergehende Verhandlung Identifikation wiederzuverwenden, wenn sie einen Anruf nochmal überträgt. nach der Durchführung eines Anrufs, der Bediener kann beschließen, sich an diese Identifikation zu erinnern und Anrufe mit der gleichen Identifikation nicht, durchzuführen, um irgendeinen Grad von zu erzielen durchführen-an-am meisten-sobald Semantik. Der Bediener wird nicht diese Identifikation in irgendeiner anderen Weise ausgenommen als Test für Gleichheit überprüfen gelassen. Andererseits wenn, einen "zuverlässigen" Transport wie TCP verwendend, die Anwendung aus einer Antwortanzeige schließen kann, daß das Verfahren genau einmal durchgeführt wurde, aber wenn es keine Antwortanzeige empfängt, er nicht annehmen kann, daß das Remoteverfahren nicht durchgeführt wurde. Merken Sie, daß, selbst wenn ein connection-oriented Protokoll wie TCP verwendet wird, eine Anwendung noch Abschaltungen und Umschaltung benötigt, Bedienerabbrüche anzufassen.

Es gibt andere Möglichkeiten für Transporte außer Datengramm oder connection-oriented Protokollen. Z.B. verlangen-antworten Sie Protokoll wie VMTP [ 2 ] ist möglicherweise ein natürlicher Transport für Gebrauch TCP- RPC. ONC RPC und UDP-Transportprotokolle. Abschnitt 10 (SATZ MARKIERUNGSCStandard) beschreibt die Einheit, die von ONC RPC eingesetzt wird, um einen connection-oriented, stream-oriented Transport wie TCP zu verwenden.