Zusammenfassung

  • Der Zielkonflikt war betrieblich spürbar: Ein Dienst konnte einen freien Port wählen, doch der Client konnte ihn nicht erraten. Ein fester Port für jedes Programm hätte die Koordination in den gemeinsam genutzten, begrenzten Portbereich verlagert.
  • RFC 1057 bot mit dem Portmapper eine feste lokale Auskunftsstelle für den wechselnden Zielport. Sie bestätigte eine Registrierung auf diesem Rechner, aber weder Erreichbarkeit noch Identität des antwortenden Dienstes.

Der Dienstport änderte sich; die Auskunftsstelle blieb

Ein hypothetischer Neustart zeigt das Betriebsrisiko direkt: Der Dateidienst läuft weiter, bindet aber einen anderen freien Port, während ein Client noch den alten anspricht. Wenn die Auskunftsstelle diese Änderung nicht meldet, gehen die Aufrufe ins Leere; für den Client wirkt der Dienst nicht erreichbar, obwohl sein Prozess noch läuft. Rechner und RPC-Programm sind unverändert, nur das Ziel hat sich bewegt. Ein weltweit fester Port für jedes Programm würde die Abstimmung in den gemeinsam genutzten, begrenzten Portbereich zurückverlagern.

Die Architekturfrage bleibt unabhängig von einer behaupteten historischen Wirkung lesbar: Wer veröffentlicht ein bewegliches Ziel, und was muss der Client danach selbst noch prüfen?

RFC 1057, im Juni 1988 von Sun Microsystems veröffentlicht, beschrieb eine andere Aufteilung. Programmnummer und Version sagen, was der Client aufrufen will; TCP oder UDP bezeichnet den Transport. Ein lokaler Portmapper am bekannten Port 111 ordnet diese Kennungen dem vom Server gewählten Port zu. Der Client fragt zuerst den Mapper und kontaktiert anschließend den Dienst. RPC-Aufruf und Auflösung des Dienstziels sind getrennte Schritte.

PMAPPROC_SET registriert den Dienst. Der Server übermittelt Programmnummer, Version, Transportprotokoll und Listener-Port an den Mapper auf demselben Rechner. Eine zweite Registrierung derselben Kombination aus Programm, Version und Protokoll lehnt der Mapper ab. Wird der Dienst beendet, entfernt PMAPPROC_UNSET den Eintrag. Der Client fragt mit PMAPPROC_GETPORT nach; der Wert null bedeutet, dass keine Zuordnung für diese Kombination registriert ist.

Die Aufgabenverteilung war knapp: Der Dienst wählte seinen Listener, der Mapper machte diese Wahl an einem vorhersehbaren Treffpunkt sichtbar, und der Client verwendete den zurückgegebenen Port. Der Dienstendpunkt durfte wechseln, während die Auskunftskonvention stabil blieb.

Was die Antwort nicht belegte

Die Mapper-Antwort spiegelte den lokalen Registrierungseintrag wider. RFC 1057 machte GETPORT weder zu einer Ende-zu-Ende-Gesundheitsprüfung noch zum Nachweis eines offenen Netzwerkpfads oder zu einer kryptografischen Aussage darüber, welches Programm am Port lauschte. Der Client musste weiterhin verbinden, den RPC-Aufruf ausführen und dessen Ergebnis bewerten. War der Dienst beendet, aber der Eintrag noch vorhanden, konnte die Abfrage gelingen und die Verbindung scheitern. Fehlte der Eintrag, scheiterte die Dienstbindung schon bei der Suche.

„Gefunden“ klingt umfassender als „registriert“. Die Portnummer sagt, wo der Dienst zum Lauschen eingetragen war. Sie sagt nicht, ob Pakete ankommen, der Dienst diesen Client akzeptiert oder die angeforderte Prozedur abgeschlossen wird. RFC 1057 behandelt Authentisierung und Transportsemantik getrennt; der Portmapper ersetzt sie nicht.

Die Tabelle war auch kein globales Register aller RPC-Programme. Sie lag auf dem Rechner, auf dem der Dienst lief. Der Client brauchte die Hostadresse aus einer anderen Quelle und fragte dann den dortigen Mapper nach dem Transport-Port. Die Namensauflösung verteilte sich also auf Schichten: Name oder Konfiguration lieferten den Host, Programmnummer und Version wählten die Schnittstelle, der Portmapper lieferte den Transportendpunkt.

RFC 1057 beschrieb auch PMAPPROC_DUMP zum Auflisten der Einträge und PMAPPROC_CALLIT für Broadcast-Aufrufe. Der Client sendete an den Mapper-Port an der Broadcast-Adresse. Jeder Mapper, der die Nachricht empfing, konnte den lokal registrierten Dienst aufrufen. Laut RFC antwortete er nur bei erfolgreicher Ausführung; andernfalls blieb er still. So ließ sich ein Dienst trotz unterschiedlicher Ports auf mehreren Rechnern ansprechen, ohne eine Zustellgarantie oder ein vollständiges Verzeichnis der Empfänger zu schaffen.

Auch die Programmnummern erhielten einen Koordinationsrahmen: RFC 1057 teilte sie in Bereiche für Sun, Nutzer, temporäre Nutzung und Reservierungen. Die logische Programmkennung musste damit nicht dem dynamischen Transport-Port entsprechen. Eine Nummer bezeichnete das RPC-Programm, ein lokal aufgelöster Wert den Listener der aktuellen Instanz.

Von TCP/UDP-Ports zu universellen Adressen

Der ursprüngliche Portmapper arbeitete direkt mit TCP- und UDP-Ports. RFC 1833 beschrieb 1995 Version 2 des Port Mappers sowie RPCBIND in den Versionen 3 und 4. Das Grundproblem blieb: Ein Server konnte seine Transportadresse dynamisch wählen, während der Client an der Serveradresse einen bekannten Auskunftspunkt benötigte. RPCBIND stellte Transportadressen als universelle Adresszeichenfolgen dar und nahm eine Netzwerkkennung auf. Damit ging die Bindung über die ursprünglichen TCP/UDP-Ports hinaus.

Das spätere Dokument macht die Reichweite des Entwurfs von 1988 deutlicher. RFC 1057 band ein RPC-Programm nicht an einen einzelnen Transport-Port. Es definierte einen Treffpunkt, der Programm und Version einem transportbezogenen Listener zuordnete. RFC 5531 beschreibt RPC-Nachrichtenprotokoll und Bindungs- beziehungsweise Rendezvousmechanismen später ausdrücklich als voneinander unabhängig.

Der Nutzen war begrenzt, aber klar: Wenn Client und Server dieselbe Abfragekonvention nutzten, musste der Client den Dienst-Port nicht vorab kennen. Das sparte feste Ports und ließ jede Instanz lokal wählen. Dafür kam vor dem Aufruf eine zusätzliche Anfrage hinzu, und ein Zustandsverzeichnis musste Start, Registrierung, Abschaltung und Entfernung des Dienstes nachführen.

Die RFCs dokumentieren den Mechanismus, nicht die historische Verbreitung oder gemessene Zuverlässigkeit. Sie zeigen weder, wie oft veraltete Einträge vorkamen, noch wie schnell bestimmte Systeme sie bereinigten. Die belastbare Aussage ist architektonisch: Der Portmapper machte einen RPC-Endpunkt über einen stabilen lokalen Treffpunkt auffindbar; Erreichbarkeit, Authentisierung und erfolgreiche Ausführung blieben nachfolgende Prüfungen.

Primärdokumente: RFC 1057 — RPC Version 2; RFC 1833 — ONC-RPC-Bindungsprotokolle; RFC 5531 — ONC RPC Version 2.