Zusammenfassung

  • TCPMUX nahm auf TCP-Port 1 einen Dienstnamen entgegen. Nach einer positiven Antwort begann das ausgewählte Protokoll auf derselben Verbindung; mehrere gleichzeitige Anwendungsströme waren damit nicht definiert.
  • Private Protokolle benötigten für diesen Zugang keinen eigenen offiziell zugeteilten TCP-Port. Bestehende Dienstnamen und bereits zugeteilte Ports behielten jedoch ihre Bedeutung.
  • inetd konnte die positive Antwort stellvertretend für ein Programm senden. Die Annahme einer Auswahl belegte daher weder erfolgreiche Authentifizierung noch Betriebsbereitschaft oder abgeschlossene Arbeit.

Die alte Tür durfte nicht verschwinden

Die auffälligste Einschränkung einer neuen gemeinsamen Eingangstür betraf die alten Türen. Dienste mit einer eigenen zugeteilten Portnummer mussten dort weiterhin erreichbar bleiben. TCPMUX durfte einen zusätzlichen Zugang anbieten, aber nicht stillschweigend den bisherigen ersetzen. Wer die neue Auswahl verstand, konnte sie nutzen; andere Clients sollten ihre vertraute Verbindung behalten.

Diese Regel steht in RFC 1078, dem im November 1988 veröffentlichten Vorschlag von M. Lottor für den TCP Port Service Multiplexer. Sie macht deutlich, dass eine kleine Protokollerweiterung nicht automatisch kleine Folgen für bestehende Software hat. Ein Client kann auf die erste Begrüßung des Servers warten, während der neue Eingang zunächst einen Dienstnamen erwartet.

Der Austausch war knapp festgelegt. Der Client verband sich mit TCP-Port 1 und schickte den Namen, abgeschlossen durch Wagenrücklauf und Zeilenvorschub. Groß- und Kleinschreibung waren für den Namen nicht bedeutungsunterscheidend. Der Server antwortete mit einem positiven oder negativen Vorzeichen, gegebenenfalls einer Erklärung und demselben Zeilenabschluss. Nach Zustimmung begann das gewünschte Protokoll, nach Ablehnung endete die Verbindung.

Ein neuer Zielport wurde dabei nicht ausgehandelt. Ebenso wenig musste der Client eine zweite Verbindung aufbauen. Der bereits bestehende TCP-Bytestrom ging in das Gespräch mit dem ausgewählten Dienst über. Die Vorstufe entschied also, wer die Verbindung übernahm, nicht wohin anschließend neu gewählt werden sollte.

Viele Möglichkeiten am Eingang, nur eine pro Verbindung

Der Begriff Multiplexer kann Erwartungen wecken, die diese Spezifikation nicht erfüllt. TCPMUX enthielt keine Kennungen für mehrere parallele Anwendungsströme innerhalb einer Verbindung und keine Regeln, ihre Nachrichten ineinander zu verschachteln. Mehrere Dienste teilten sich einen Kontaktpunkt; eine einzelne Verbindung wählte einen davon.

Das war eine bewusste Begrenzung der gemeinsamen Aufgabe. Die Vorstufe musste einen Namen und eine Antwort verstehen. Danach galten die Regeln des ausgewählten Protokolls. Die Einfachheit bestand darin, nicht auch dessen Datenmodell, Berechtigungen und Arbeitsabläufe in den Verteiler aufzunehmen.

Für einen unvorbereiteten Client blieb diese Vorstufe dennoch eine echte Änderung. Nur die Zielnummer auszutauschen reichte nicht. Beide Seiten mussten wissen, wer zuerst sprach und wo die Auswahlantwort endete. Ein gemeinsamer Eingang sparte keine Verständigung über den tatsächlichen Gesprächsbeginn.

Welche Arbeit eine Portzuteilung erledigte

Bekannte Portnummern ermöglichten unabhängigen Implementierungen einen gemeinsamen Treffpunkt. Ein Client musste nicht für jeden Server separat erfragen, wo ein bekannter Dienst normalerweise wartete. Die öffentliche Nummerntabelle koordinierte diese Erwartung und verminderte zufällige Bedeutungsüberschneidungen.

RFC 1010, die Ausgabe von Assigned Numbers vom Mai 1987, wurde von RFC 1078 ausdrücklich herangezogen. Sie dokumentierte Zuteilungen und nannte eine Kontaktperson für neue Nummern. Das ist ein Beleg für Koordination, nicht für den Betrieb eines konkreten Programms auf einem konkreten Rechner.

RFC 1078 bezeichnete damals den Bereich von 0 bis 255 als Bereich der bekannten Ports. Daraus folgt weder, dass TCP insgesamt nur 256 Werte darstellen konnte, noch dass dieser Bereich heute unverändert gilt. Die administrative Einteilung und die Größe des Portfeldes sind verschiedene Sachverhalte. Eine historische Darstellung muss beide auseinanderhalten.

Für ein privates Protokoll konnte eine neue offizielle Nummer unnötig sein, wenn die beteiligten Clients bereits einen Namen vereinbaren konnten. TCPMUX nutzte den gemeinsamen Port und ließ die Zuordnung dieses Namens zum Programm im Host erfolgen. Eine neue lokale Möglichkeit musste nicht für jeden Fall eine neue globale Zuteilung auslösen.

Damit wurde Koordination verkleinert, nicht abgeschafft. Der Treffpunkt und seine Grammatik blieben gemeinsam. Der Betreiber entschied über angebotene Programme und deren Rechte. Der Client musste das nachfolgende Protokoll beherrschen. Kein Name öffnete von selbst einen Netzfilter, wies eine Identität nach oder verpflichtete einen anderen Betreiber zur Teilnahme.

Namen waren Vereinbarungen, keine Ausweise

Die bereits in Assigned Numbers aufgeführten Namen behielten ihre definierten Bedeutungen. Für private Dienste empfahl die Spezifikation möglichst unverwechselbare Namen, etwa mit einem Organisationsnamen als Präfix. Versionszusätze waren ebenfalls möglich. Das senkte das Risiko zufälliger Kollisionen, ohne eine Zertifizierungsstelle für Organisationen zu schaffen.

Ein vertraut wirkender Präfix bewies folglich nicht, wer den Host kontrollierte. Auch eine Versionsangabe half nur, wenn beide Seiten ihre Bedeutung kannten. Lesbarkeit ist eine Eigenschaft des Namens; Berechtigung und Kompatibilität sind Eigenschaften der tatsächlichen Beteiligten und ihrer Programme.

Der reservierte Name HELP lieferte eine Liste unterstützter Dienste, jeweils einen Namen pro Zeile, und schloss danach die Verbindung. Diese Liste war ein lokales Menü. Sie suchte keine Server im gesamten Internet, prüfte keine Nutzerrechte und bestätigte nicht, dass jedes aufgeführte Programm eine kommende Aufgabe erfüllen konnte.

Gerade solche kleinen Verzeichnisse können zu viel Autorität erhalten. Ein korrekt erzeugtes Menü kann die Auswahlmöglichkeiten genau wiedergeben und trotzdem nichts über den Erfolg eines späteren Aufrufs sagen. Die Information wird nicht besser, wenn man ihren Geltungsbereich still erweitert.

Die Antwort des Vermittlers

Das NetBSD-Handbuch zu inetd beschreibt die Namenssuche in der durch /etc/inetd.conf bereitgestellten Diensttabelle. Bei tcpmux/ soll der aufgerufene Server die positive Antwort selbst senden. Bei tcpmux/+ übernimmt der Multiplexer diese Antwort für ihn. So lassen sich ältere Programme verwenden, die lediglich mit Standardeingabe und Standardausgabe arbeiten.

Diese Anpassung ist praktisch, verändert aber die Aussagekraft einer Paketaufzeichnung. Ein Pluszeichen kann die Auswahlentscheidung des Vermittlers ausdrücken, bevor die Anwendung eine sinnvolle Anfrage verarbeitet hat. Es ist kein unabhängiger Nachweis ihrer Gesundheit. Und selbst eine von der Anwendung gesendete Zustimmung bestätigt noch keinen abgeschlossenen Auftrag.

Die Zuständigkeit muss genau einmal vergeben sein. Wenn beide Komponenten die Auswahl quittieren, können zusätzliche Bytes in den Anwendungsdialog geraten. Wenn beide die andere Seite dafür zuständig halten, wartet der Client möglicherweise vergeblich. Das sind aus der Übergabe abgeleitete Fehlermöglichkeiten, keine hier behaupteten historischen Vorfälle.

Die Quelldatei des FreeBSD-Handbuchs zu inetd fordert außerdem, den Multiplexer selbst neben den einzelnen Diensten zu aktivieren. Ein Eintrag für das Programm bedeutet noch nicht, dass der gemeinsame Eingang Anfragen annimmt. Das Handbuch beschreibt auch die Übergabe der Verbindung über die Ein- und Ausgabedeskriptoren des Programms.

Die Dokumente belegen einen implementierten Weg, nicht seine Verbreitung. Sie zeigen aber klar, wo der operative Hebel liegt: in der lokalen Zuordnung von Name, ausführbarer Datei und Ausführungsidentität. Das öffentliche Register startet dort keinen Prozess und entscheidet nicht über dessen Befugnisse.

Was spätere Quellen sagen — und was nicht

RFC 6335 beschrieb 2011 die Bereiche System Ports 0–1023, User Ports 1024–49151 und Dynamic Ports 49152–65535. Dienstnamen können auch ohne festen Port registriert werden. Name und Nummer sind somit keine untrennbare Verwaltungseinheit.

RFC 7605 behandelte 2015 den sparsamen Umgang mit Portzuteilungen und die Unterscheidung von Versionen oder Gesprächen anhand protokollinterner Informationen. Das ordnet TCPMUX in eine länger bestehende Gestaltungsfrage ein. Es belegt nicht, dass die späteren Empfehlungen unmittelbar aus diesem Vorschlag entstanden.

Im heutigen IANA-Register für Dienstnamen und Portnummern steht tcpmux weiterhin bei Port 1. Dort erscheinen TCP- und UDP-Zeilen. RFC 1078 definiert jedoch den TCP-Austausch; eine parallele Registerzeile liefert keine fehlenden Regeln für ein UDP-Gespräch.

Auch die fortbestehende Zuteilung ist keine Nutzungsstatistik. Spezifikation, Handbuch, aktivierte Konfiguration und beobachteter Verkehr belegen unterschiedliche Dinge. Die Quellen reichen für eine präzise Geschichte des Mechanismus, nicht für Aussagen über Marktanteile oder einen eindeutigen Grund seines Erfolgs oder Misserfolgs.

TCPMUX braucht eine solche Erfolgserzählung nicht, um aufschlussreich zu sein. Es trennte einen gemeinsamen Treffpunkt von der lokalen Entscheidung über ein Programm und bewahrte dabei alte Zugänge. Die Grenze war klein genug, um sie auf dem Draht zu sehen: erst auswählen, dann sprechen, erst danach feststellen, ob die Arbeit tatsächlich gelungen ist.