SCTP: Was den gemeinsamen Socket verlässt, braucht ein eigenes Ende

Zusammenfassung

• sctp_peeloff gliedert eine bereits bestehende SCTP-Assoziation aus einem One-to-many-Socket in einen eigenen One-to-one-Socket aus. Es baut keine Ersatzassoziation auf.
• Sämtliche späteren Daten- und Steuerungsoperationen verwenden den neuen Deskriptor. Das Schließen des ursprünglichen Sockets beendet die ausgegliederte Assoziation nicht.

Die Aussage „der gemeinsame Socket ist geschlossen“ kann korrekt sein und trotzdem ein unvollständiges Bild vom Zustand eines Dienstes vermitteln. SCTP erlaubt es einer Anwendung, einzelne Assoziationen vorher aus diesem Socket herauszulösen. Wer beim Herunterfahren weiterhin mit der alten Gruppierung arbeitet, erreicht diese ausgelagerten Teile nicht mehr.

Das ist keine unerwartete Lücke im Protokoll. RFC 6458 beschreibt genau diese Grenze für sctp_peeloff. Eine bestehende Assoziation erhält einen eigenen Socket; ihr bisheriger Socket verliert seine Rolle als Schnittstelle für die nachfolgenden Operationen auf dieser Assoziation.

Die organisatorische Folgerung liegt nahe, ist aber nicht automatisch umgesetzt: Wer Arbeit aus einem gemeinsamen Verwaltungsbereich löst, muss ihre weitere Zuständigkeit festhalten. Eine Entscheidung zur Isolation umfasst sonst nur den Entlastungseffekt und nicht die Pflicht, das isolierte Stück Arbeit zu einem beabsichtigten Ende zu führen.

Nicht blockierend heißt nicht unabhängig

Ein One-to-many-Socket erlaubt es, mehrere SCTP-Assoziationen über einen Deskriptor zu bearbeiten. Soweit eine Operation eine Auswahl benötigt, bezeichnet eine Assoziationskennung das Ziel. Diese Bündelung vereinfacht den Zugriff, beweist jedoch keine Trennung der darunterliegenden Ressourcen.

Abschnitt 3.3 untersucht eine Implementierung, die ihre Ausgangspufferzuteilung unter mehreren Assoziationen teilt. Kommt eine davon nicht mehr voran, können ihre wartenden Daten die gemeinsame Kapazität füllen und weitere Sendungen anderer Assoziationen verhindern. Auch ein nicht blockierender Socket beseitigt diese Kopplung nicht. Ein Aufruf muss nicht warten, um an einer erschöpften gemeinsamen Ressource zu scheitern.

Der Text nennt verschiedene Ansatzpunkte: Reservierung von Pufferraum je Assoziation, Begrenzung ungelesener Daten durch das Anwendungsprotokoll, individuelle Sockets von Beginn an oder Ausgliederung vor einem großen Austausch, der ins Stocken geraten könnte. Damit wird die Begrenzung jeweils an einer anderen Stelle eingeführt.

Aus dieser Aufzählung folgt kein allgemeines Leistungsversprechen. Die Ausgangsbedingung hängt von der tatsächlichen Ressourcenzuteilung der Implementierung ab. Die betrachteten Passagen belegen weder das Kopieren bestehender Warteschlangen noch einen kopierfreien Übergang, konkrete Speicherwerte oder eine bestimmte Durchsatzsteigerung. Sie zeigen eine Gestaltungsoption, deren Wirkung auf einer Plattform gesondert nachzuweisen wäre.

Der neue Deskriptor ist die neue Steuerungsadresse

Beim Aufruf übergibt die Anwendung den ursprünglichen Socket und die Kennung einer bereits etablierten Assoziation. Ein Erfolg liefert einen nicht negativen neuen Deskriptor; ein Fehler wird mit minus eins und einer Fehlerangabe gemeldet. Das ist nicht die gewöhnliche Annahme einer neu eintreffenden Verbindung.

Abschnitt 9.2 legt fest, dass alle späteren Daten- und Steuerungsoperationen für diese Assoziation den neuen Socket verwenden. Das Schließen des ursprünglichen Sockets beendet sie nicht. Die Ausgliederung ist damit keine bloße interne Verkehrsoptimierung, die für die weitere Verwaltung unsichtbar bleiben dürfte.

Als Gedankenbeispiel kann ein Dienst viele Assoziationen gemeinsam bearbeiten und einen besonders großen Austausch ausgliedern. Schließt er später seinen gemeinsamen Eingang, ist der ausgelagerte Austausch nicht mehr Teil dieses Schließbereichs. Dass er dort einmal aufgenommen wurde, ändert daran nichts. Der neue Deskriptor muss im Bestand der weiterhin zu verwaltenden Arbeit bleiben. Dies ist ein Beispiel für die Schnittstellenlogik, kein Bericht über einen beobachteten Betrieb.

Das Weiterlaufen kann beabsichtigt sein. Vielleicht soll eine Wartung den großen Austausch gerade nicht unterbrechen. Entscheidend ist deshalb, ob seine Fortsetzung eine verantwortete Entscheidung ist oder lediglich aus dem Verschwinden aus einer alten Liste folgt.

Einstellungen gelten in einem bestimmten Bereich

Socket- und IP-Optionen haben laut RFC einen Socket-bezogenen Geltungsbereich. Bei One-to-many betrifft dies die zugehörigen Assoziationen, bei One-to-one die dort repräsentierte Assoziation. Die Pufferabschnitte weisen zudem auf Implementierungsunterschiede im gemeinsamen Modell hin.

Besonders aufschlussreich ist SCTP_AUTOCLOSE. Abschnitt 8.1.8 dokumentiert die Option nur für One-to-many-Sockets. Sie bezieht sich auf Inaktivität beim Austausch von Nutzdaten. Der Standardwert null deaktiviert sie; ein anderer Wert bezeichnet Sekunden. Will die Anwendung über solche Beendigungen informiert werden, benötigt sie die Benachrichtigungen über Assoziationsänderungen.

Daraus lässt sich nicht ableiten, wie ein bereits laufender Zeitgeber beim Peel-off behandelt wird. Automatisches Löschen, Neustarten oder Vererben wäre eine zusätzliche Behauptung, die durch die ausgewählten Stellen nicht gedeckt ist. Zu prüfen ist die gewünschte Lebensdauerregel für den neuen Socket in der eingesetzten Implementierung, statt den früheren Wert als fortbestehende Zusicherung zu behandeln.

Auch das Ende ist zu differenzieren. Ein gewöhnliches close auf einem individuellen Socket leitet den geordneten SCTP-Abbau ein und macht den Deskriptor für spätere Operationen unbrauchbar. Ist SO_LINGER eingeschaltet und die Wartezeit null, führt close dagegen zum Abbruch. Eine positive Wartezeit begrenzt das Warten des Aufrufs; der Protokollabbau kann nach dessen Rückkehr weiterlaufen.

Die beschriebene shutdown-Schnittstelle kann den Deskriptor für Benachrichtigungen während der Beendigung erhalten. SHUT_WR leitet dabei einen vollständigen SCTP-Protokollabbau ein, keine TCP-artige Halb-Schließung. Keines dieser Transportereignisse bestätigt für sich genommen den Abschluss einer geschäftlichen Transaktion.

Eine belastbare Aussage bleibt begrenzt

Der Eintrag des RFC Editor ordnet den Text als Informational vom Dezember 2011 ein. Er ist keine aktuelle Bestandsaufnahme aller Betriebssysteme. In der eingesehenen Errata-Liste finden sich verifizierte Korrekturen anderer Stellen, aber keine direkte Korrektur von Abschnitt 9.2. Zur späteren Aktualisierung zurückgestellte und abgelehnte Einträge sind nicht mit akzeptierten Änderungen gleichzusetzen.

Die Governance-Deutung setzt auf dieser Grundlage auf. Lu Heng fragt in seinem Beitrag zum Prinzipal-Agent-Problem, wie Entscheidungsrechte und die Last ihrer Folgen zusammenpassen. Hier lautet die konkrete Frage, ob mit der Freigabe der Isolation auch die Zuständigkeit für das Ende benannt wird. Über die Motive von Entwicklern sagt das nichts aus.

Sein Beitrag zum Zweck von BTW Media stellt beobachtbare Wirklichkeit über Interessenvertretung. Für den Betrieb bedeutet das, die tatsächlich noch steuernden Deskriptoren zu betrachten und nicht allein die Erzählung vom geschlossenen Eingang.

Peel-off macht eine technische Grenze nutzbar. Die Verwaltung muss vermeiden, dass ihre Verantwortungsgrenze an der alten Stelle stehen bleibt.