6. DSO-Sitzungslebenszyklus und Timer

6.1. Initiierung einer DSO-Sitzung

Eine DSO-Sitzung beginnt wie in Abschnitt 5.1 beschrieben.

Sobald eine DSO-Sitzung erstellt wurde, können Client oder Server beliebig viele DNS-Operationen über die DSO-Sitzung initiieren.

Wenn ein Initiator mehrere Nachrichten zu senden hat, SOLLTE er NICHT auf jede Antwort warten, bevor er die nächste Nachricht sendet.

Ein Responder MUSS Nachrichten in der Reihenfolge bearbeiten, in der sie empfangen werden, und SOLLTE Antworten auf Anforderungsnachrichten zurückgeben, sobald sie verfügbar sind. Ein Responder SOLLTE das Senden von Antworten NICHT verzögern, um Antworten in derselben Reihenfolge zu liefern, in der die entsprechenden Anforderungen empfangen wurden.

Abschnitt 6.2.1.1 der DNS-over-TCP-Spezifikation [RFC7766] spezifiziert dies detaillierter.

6.2. DSO-Sitzungs-Timeouts

Zwei Timeout-Werte sind mit einer DSO-Sitzung verbunden: der Inaktivitäts-Timeout und das Keepalive-Intervall. Beide Werte werden im selben TLV, dem Keepalive-TLV (Abschnitt 7.1), übermittelt.

Der erste Timeout-Wert, der Inaktivitäts-Timeout, ist die maximale Zeit, für die ein Client eine inaktive DSO-Sitzung spekulativ offen halten kann, in der Erwartung, dass er zukünftige Anforderungen an diesen Server senden muss.

Der zweite Timeout-Wert, das Keepalive-Intervall, ist das maximal zulässige Intervall zwischen Nachrichten, wenn der Client die DSO-Sitzung am Leben erhalten möchte.

Die beiden Timeout-Werte sind unabhängig voneinander. Der Inaktivitäts-Timeout kann kürzer, gleich oder länger als das Keepalive-Intervall sein, obwohl in den meisten Fällen erwartet wird, dass der Inaktivitäts-Timeout kürzer ist als das Keepalive-Intervall.

Ein kürzerer Inaktivitäts-Timeout mit einem längeren Keepalive-Intervall signalisiert dem Client, dass er eine inaktive DSO-Sitzung nicht ohne Grund sehr lange spekulativ offen halten sollte, aber wenn er einen aktiven Grund hat, eine DSO-Sitzung offen zu halten, muss er kein aggressives Niveau an DSO-Keepalive-Verkehr senden, um diese Sitzung aufrechtzuerhalten. Ein Beispiel hierfür wäre ein Client, der DNS-Push-Benachrichtigungen abonniert hat. In diesem Fall sendet der Client keinen Verkehr an den Server, aber die Sitzung ist nicht inaktiv, da eine aktive Anforderung an den Server besteht, Push-Benachrichtigungen zu empfangen.

Ein längerer Inaktivitäts-Timeout mit einem kürzeren Keepalive-Intervall signalisiert dem Client, dass er eine inaktive DSO-Sitzung spekulativ lange offen halten kann, aber um diese inaktive DSO-Sitzung aufrechtzuerhalten, sollte er viel DSO-Keepalive-Verkehr senden. Diese Konfiguration wird voraussichtlich weniger häufig sein.

Im üblichen Fall, in dem der Inaktivitäts-Timeout kürzer ist als das Keepalive-Intervall, kommt das Keepalive-Intervall nur dann ins Spiel, wenn ein Client eine langlebige Operation mit geringem Verkehrsaufkommen hat, um sicherzustellen, dass eine ausreichende Restmenge an Verkehr generiert wird, um den NAT- und Firewall-Status aufrechtzuerhalten und dem Client und Server zu versichern, dass sie immer noch miteinander verbunden sind.

Bei einer neuen DSO-Sitzung beträgt der Standardwert für beide Timeouts 15 Sekunden, wenn kein expliziter DSO-Keepalive-Nachrichtenaustausch stattgefunden hat.

Bei beiden Timeouts führen niedrigere Timeout-Werte zu höherem Netzwerkverkehr und einer höheren CPU-Last auf dem Server.

6.3. Inaktive DSO-Sitzungen

Sowohl bei Servern als auch bei Clients setzt die Generierung oder der Empfang einer vollständigen DNS-Nachricht (einschließlich DNS-Anforderungen, Antworten, Aktualisierungen, DSO-Nachrichten usw.) beide Timer für diese DSO-Sitzung zurück, mit der einzigen Ausnahme, dass eine DSO-Keepalive-Nachricht nur den Keepalive-Timer und nicht den Inaktivitäts-Timeout-Timer zurücksetzt.

Darüber hinaus bleibt der Inaktivitäts-Timer gelöscht, solange der Client eine ausstehende Operation in Bearbeitung hat, und es kann kein Inaktivitäts-Timeout auftreten.

Für kurzlebige DNS-Operationen wie traditionelle Abfragen und Aktualisierungen gilt eine Operation für die Zeit zwischen Anforderung und Antwort als "in Bearbeitung", typischerweise ein Zeitraum von höchstens einigen hundert Millisekunden. Beim Client wird der Inaktivitäts-Timer beim Senden einer Anforderung gelöscht und bleibt bis zum Empfang der entsprechenden Antwort gelöscht. Beim Server wird der Inaktivitäts-Timer beim Empfang einer Anforderung gelöscht und bleibt bis zum Senden der entsprechenden Antwort gelöscht.

Für langlebige zustandsbehaftete DNS-Operationen (wie ein Push-Benachrichtigungsabonnement [Push] oder ein Discovery-Relay-Schnittstellenabonnement [Relay]) gilt eine Operation als "in Bearbeitung", solange die Operation aktiv ist, d. h. bis sie abgebrochen wird. Dies bedeutet, dass eine DSO-Sitzung mit aktiven Operationen existieren kann, ohne dass Nachrichten in eine der beiden Richtungen fließen, und zwar weitaus länger als der Inaktivitäts-Timeout. Dies ist kein Fehler. Aus diesem Grund gibt es zwei separate Timer: den Inaktivitäts-Timeout und das Keepalive-Intervall. Nur weil eine DSO-Sitzung über einen längeren Zeitraum keinen Verkehr hat, wird diese DSO-Sitzung nicht automatisch "inaktiv", wenn sie eine aktive Operation hat, die auf Ereignisse wartet.

6.4. Der Inaktivitäts-Timeout

Der Zweck des Inaktivitäts-Timeouts besteht darin, dass der Server einen Ausgleich zwischen den Kosten für das Einrichten neuer DSO-Sitzungen und den Kosten für die Aufrechterhaltung inaktiver DSO-Sitzungen schafft. Ein Server mit reichlich DSO-Sitzungskapazität kann einen hohen Inaktivitäts-Timeout anbieten, um Clients zu ermöglichen, eine spekulative DSO-Sitzung lange offen zu halten und die Kosten für das Einrichten einer neuen DSO-Sitzung für zukünftige Kommunikationen mit diesem Server zu sparen. Ein Server mit knappen Speicherressourcen kann einen niedrigen Inaktivitäts-Timeout anbieten, um Clients zu veranlassen, DSO-Sitzungen umgehend zu schließen, wenn sie keine ausstehenden Operationen mit diesem Server haben, und dann später bei Bedarf eine neue DSO-Sitzung zu erstellen.

6.4.1. Schließen inaktiver DSO-Sitzungen

Wenn der Inaktivitäts-Timeout einer Verbindung erreicht ist, MUSS der Client beginnen, die untätige Verbindung zu schließen, aber ein Client ist nicht verpflichtet, eine untätige Verbindung offen zu halten, bis der Inaktivitäts-Timeout erreicht ist. Ein Client KANN eine DSO-Sitzung jederzeit nach eigenem Ermessen schließen. Wenn ein Client feststellt, dass er keinen aktuellen oder vernünftigerweise vorhersehbaren zukünftigen Bedarf an einer derzeit inaktiven DSO-Sitzung hat, SOLLTE der Client diese Verbindung ordnungsgemäß schließen.

Wenn zu irgendeinem Zeitpunkt während der Lebensdauer der DSO-Sitzung der Inaktivitäts-Timeout-Wert (d. h. standardmäßig 15 Sekunden) verstreicht, ohne dass eine Operation auf der DSO-Sitzung aktiv ist, MUSS der Client die Verbindung ordnungsgemäß schließen.

Wenn zu irgendeinem Zeitpunkt während der Lebensdauer der DSO-Sitzung zu viel Zeit verstreicht, ohne dass eine Operation auf der DSO-Sitzung aktiv ist, MUSS der Server den Client als säumig betrachten und die DSO-Sitzung zwangsweise abbrechen. Was in diesem Zusammenhang als "zu viel Zeit" gilt, sind fünf Sekunden oder das Doppelte des aktuellen Inaktivitäts-Timeout-Werts, je nachdem, welcher Wert größer ist. Wenn der Inaktivitäts-Timeout seinen Standardwert von 15 Sekunden hat, bedeutet dies, dass ein Client als säumig betrachtet und getrennt wird, wenn er seine Verbindung nach 30 Sekunden Inaktivität nicht geschlossen hat.

In diesem Zusammenhang umfasst eine aktive Operation auf einer DSO-Sitzung eine Abfrage, die auf eine Antwort wartet, eine Aktualisierung, die auf eine Antwort wartet, oder eine aktive langlebige Operation, aber nicht einen DSO-Keepalive-Nachrichtenaustausch selbst. Ein DSO-Keepalive-Nachrichtenaustausch setzt nur den Keepalive-Intervall-Timer zurück, nicht den Inaktivitäts-Timeout-Timer.

Wenn der Client eine inaktive DSO-Sitzung länger als die Standarddauer offen halten möchte, verwendet er die DSO-Keepalive-Nachricht, um längere Timeout-Werte anzufordern, wie in Abschnitt 7.1 beschrieben.

6.4.2. Werte für den Inaktivitäts-Timeout

Für den Inaktivitäts-Timeout-Wert führen niedrigere Werte zu häufigerem Abbau und Neuaufbau von DSO-Sitzungen. Höhere Werte führen zu geringerem Verkehr und einer geringeren CPU-Last auf dem Server, aber zu einer höheren Speicherbelastung, um den Status für inaktive DSO-Sitzungen aufrechtzuerhalten.

Ein Server kann jeden beliebigen Wert für den Inaktivitäts-Timeout diktieren (entweder in einer Antwort auf eine vom Client initiierte Anforderung oder in einer vom Server initiierten Nachricht), einschließlich Werten unter einer Sekunde oder sogar Null.

Ein Inaktivitäts-Timeout von Null informiert den Client, dass er untätige Verbindungen überhaupt nicht spekulativ aufrechterhalten sollte, und sobald der Client die Operation oder Operationen in Bezug auf diesen Server abgeschlossen hat, sollte der Client sofort beginnen, diese Sitzung zu schließen.

Ein Server bricht eine untätige Client-Sitzung nach fünf Sekunden oder dem Doppelten des Inaktivitäts-Timeout-Werts zwangsweise ab, je nachdem, welcher Wert größer ist. Im Fall eines Inaktivitäts-Timeout-Werts von Null bedeutet dies, dass der Server die untätige Sitzung nach fünf Sekunden zwangsweise abbricht, wenn ein Client eine untätige Client-Sitzung nicht schließt.

Ein Inaktivitäts-Timeout von 0xFFFFFFFF steht für "unendlich" und informiert den Client, dass er eine untätige Verbindung so lange offen halten kann, wie er möchte. Beachten Sie, dass der Server nach Gewährung eines unbegrenzten Inaktivitäts-Timeouts auf diese Weise diesen Inaktivitäts-Timeout jederzeit ändern kann, indem er eine neue DSO-Keepalive-Nachricht sendet, die dem Client neue Sitzungs-Timeout-Werte diktiert.

Der größte endliche Inaktivitäts-Timeout, der vom aktuellen Keepalive-TLV unterstützt wird, ist 0xFFFFFFFE (2^32-2 Millisekunden, ca. 49,7 Tage).

6.5. Das Keepalive-Intervall

Der Zweck des Keepalive-Intervalls besteht darin, die Generierung ausreichender Nachrichten zu verwalten, um den Status in Middleboxen (wie NAT-Gateways oder Firewalls) aufrechtzuerhalten, und damit Client und Server regelmäßig überprüfen können, ob sie noch miteinander verbunden sind. Dies ermöglicht es ihnen, den Status zu bereinigen, wenn die Verbindung verloren geht, und gegebenenfalls eine neue Sitzung aufzubauen.

6.5.1. Ablauf des Keepalive-Intervalls

Wenn zu irgendeinem Zeitpunkt während der Lebensdauer der DSO-Sitzung der Keepalive-Intervallwert (d. h. standardmäßig 15 Sekunden) verstreicht, ohne dass DNS-Nachrichten auf einer DSO-Sitzung gesendet oder empfangen wurden, MUSS der Client Maßnahmen ergreifen, um die DSO-Sitzung am Leben zu erhalten, indem er eine DSO-Keepalive-Nachricht sendet (Abschnitt 7.1). Ein DSO-Keepalive-Nachrichtenaustausch setzt nur den Keepalive-Timer zurück, nicht den Inaktivitäts-Timer.

Wenn ein Client abrupt die Verbindung zum Netzwerk trennt, ohne seine DSO-Sitzung sauber zu schließen, und vielleicht eine langlebige Operation nicht abgebrochen lässt, erfährt der Server davon, nachdem er den erforderlichen DSO-Keepalive-Verkehr von diesem Client nicht empfangen hat. Wenn zu irgendeinem Zeitpunkt während der Lebensdauer der DSO-Sitzung das Doppelte des Keepalive-Intervallwerts (d. h. standardmäßig 30 Sekunden) verstreicht, ohne dass DNS-Nachrichten auf einer DSO-Sitzung gesendet oder empfangen wurden, SOLLTE der Server den Client als säumig betrachten und die DSO-Sitzung zwangsweise abbrechen.

6.5.2. Werte für das Keepalive-Intervall

Für den Keepalive-Intervallwert führen niedrigere Werte zu einem höheren Volumen an DSO-Keepalive-Verkehr. Höhere Werte des Keepalive-Intervalls reduzieren den Verkehr und die CPU-Last, haben jedoch nur minimale Auswirkungen auf die Speicherbelastung des Servers, da Clients eine DSO-Sitzung unabhängig vom erforderlichen DSO-Keepalive-Verkehrsniveau für die gleiche Zeitdauer (bestimmt durch den Inaktivitäts-Timeout) offen halten.

Es kann für Clients und Server angemessen sein, je nach Art des Netzwerks, in dem sie sich befinden, unterschiedliche Keepalive-Intervalle auszuwählen.

Ein Unternehmens-DNS-Server, der weiß, dass er nur Clients im internen Netzwerk bedient, ohne dazwischenliegende NAT-Gateways oder Firewalls, kann ein längeres Keepalive-Intervall vorschreiben, da kein häufiger DSO-Keepalive-Verkehr erforderlich ist.

Ein öffentlicher DNS-Server, der hauptsächlich private Verbraucher-Clients bedient, bei denen wahrscheinlich ein NAT-Gateway auf dem Pfad vorhanden ist, kann ein kürzeres Keepalive-Intervall vorschreiben, um häufigeren DSO-Keepalive-Verkehr zu generieren.

Ein intelligenter Client kann sich an seine Umgebung anpassen. Ein Client, der eine private IPv4-Adresse [RFC1918] verwendet, um mit einem DNS-Server an einer Adresse außerhalb dieses privaten IPv4-Adressblocks zu kommunizieren, kann zu dem Schluss kommen, dass wahrscheinlich ein NAT-Gateway auf dem Pfad vorhanden ist, und dementsprechend ein kürzeres Keepalive-Intervall anfordern.

Standardmäßig wird EMPFOHLEN, dass Clients ein Keepalive-Intervall von 60 Minuten anfordern und Server dieses gewähren. Dieses Keepalive-Intervall bietet eine einigermaßen zeitnahe Erkennung, wenn ein Client abrupt die Verbindung trennt, ohne die Sitzung sauber zu schließen. Außerdem reicht es aus, den Status in Firewalls und NAT-Gateways aufrechtzuerhalten, die der von der IETF empfohlenen aktuellen bewährten Methode folgen, dass der von Middleboxen verwendete "Leerlauf-Timeout für hergestellte Verbindungen" mindestens 2 Stunden und 4 Minuten beträgt [RFC5382] [RFC7857].

Beachten Sie, dass die Last auf Client und Server umso höher ist, je kürzer der Keepalive-Intervallwert ist. Darüber hinaus würde bei einem Keepalive-Wert, der kürzer ist als die Zeit, die der Transport für eine erneute Übertragung benötigt, der Verlust eines einzelnen Pakets dazu führen, dass ein Server die Verbindung übereifrig abbricht. Beispielsweise würde ein (hypothetischer und unrealistischer) Keepalive-Intervallwert von 100 ms zu einem kontinuierlichen Strom von zehn Nachrichten pro Sekunde oder mehr (falls durch das aktuelle Überlastungskontrollfenster zulässig) in beide Richtungen führen, um die DSO-Sitzung am Leben zu erhalten. Und in diesem extremen Beispiel würde eine einzelne erneute Übertragung über einen Pfad mit beispielsweise 100 ms RTT eine vorübergehende Pause im Nachrichtenstrom verursachen, die lang genug ist, um den Server zum Abbruch der Verbindung zu veranlassen.

Aufgrund dieser Bedenken DARF der Server KEINE DSO-Keepalive-Nachricht (entweder eine DSO-Antwort auf eine vom Client initiierte DSO-Anforderung oder eine vom Server initiierte DSO-Nachricht) mit einem Keepalive-Intervallwert von weniger als zehn Sekunden senden. Wenn ein Client eine DSO-Keepalive-Nachricht empfängt, die einen Keepalive-Intervallwert von weniger als zehn Sekunden angibt, ist dies ein fataler Fehler und der Client MUSS die Verbindung sofort zwangsweise abbrechen.

Ein Keepalive-Intervallwert von 0xFFFFFFFF steht für "unendlich" und informiert den Client, dass er keinen DSO-Keepalive-Verkehr generieren soll. Beachten Sie, dass der Server, nachdem er signalisiert hat, dass der Client auf diese Weise keinen DSO-Keepalive-Verkehr generieren soll, diese DSO-Keepalive-Verkehrsanforderung jederzeit ändern kann, indem er eine neue DSO-Keepalive-Nachricht sendet, die dem Client neue Sitzungs-Timeout-Werte diktiert.

Das größte endliche Keepalive-Intervall, das vom aktuellen Keepalive-TLV unterstützt wird, ist 0xFFFFFFFE (2^32-2 Millisekunden, ca. 49,7 Tage).

6.6. Server-initiierte Beendigung der DSO-Sitzung

Zusätzlich zum selektiven Abbrechen einzelner langlebiger Operationen (Abschnitt 5.6) gibt es auch Gelegenheiten, bei denen ein Server eine oder mehrere gesamte DSO-Sitzungen beenden muss. Eine gesamte DSO-Sitzung muss möglicherweise beendet werden, wenn der Client in irgendeiner Weise defekt ist oder das Netzwerk verlässt, ohne seine DSO-Sitzung zu schließen. DSO-Sitzungen müssen möglicherweise auch beendet werden, wenn der Server überlastet ist oder neu konfiguriert wird und nicht die Möglichkeit hat, selektiv auszuwählen, welche Operationen abgebrochen werden müssen.

Dieser Abschnitt erörtert verschiedene Gründe, warum eine DSO-Sitzung beendet werden kann, und die Mechanismen dafür.

Im normalen Betrieb liegt das Schließen einer DSO-Sitzung in der Verantwortung des Clients. Der Client bestimmt, wann eine DSO-Sitzung geschlossen werden soll, basierend auf einer Bewertung sowohl seiner eigenen Bedürfnisse als auch des vom Server diktierten Inaktivitäts-Timeout-Werts. Ein Server veranlasst die Beendigung einer DSO-Sitzung nur unter den unten beschriebenen außergewöhnlichen Umständen. Einige der außergewöhnlichen Situationen, in denen ein Server eine DSO-Sitzung beenden kann, sind:

• Die Serveranwendungssoftware oder das zugrunde liegende Betriebssystem wird heruntergefahren oder neu gestartet.

• Die Serveranwendungssoftware wird unerwartet beendet (vielleicht aufgrund eines Fehlers, der sie zum Absturz bringt, was dazu führt, dass das zugrunde liegende Betriebssystem ein TCP RST sendet).

• Der Server unterzieht sich einem Neukonfigurations- oder Wartungsverfahren, das aufgrund der Art und Weise, wie die Serversoftware implementiert ist, eine Trennung der Clients erfordert. Beispielsweise ist manche Software so implementiert, dass sie beim Start eine Konfigurationsdatei liest, und das Ändern der Serverkonfiguration erfordert das Ändern der Konfigurationsdatei und das anschließende Beenden und Neustarten der Serversoftware, was im Allgemeinen einen Verlust von Netzwerkverbindungen mit sich bringt.

• Der Client kommt seiner Verpflichtung nicht nach, den erforderlichen DSO-Keepalive-Verkehr zu generieren oder eine inaktive Sitzung innerhalb der vorgeschriebenen Zeit (fünf Sekunden oder das Doppelte des vom Server diktierten Zeitintervalls, je nachdem, welcher Wert größer ist, wie in Abschnitt 6.2 beschrieben) zu schließen.

• Der Client sendet eine grob ungültige oder falsch formatierte Anforderung, die auf eine ernsthaft defekte Client-Implementierung hinweist.

• Der Server ist überlastet und muss Last abwerfen.

6.6.1. Server-initiierte Wiederholungsverzögerungsnachricht (Retry Delay Message)

In den oben beschriebenen Fällen, in denen ein Server beschließt, eine DSO-Sitzung zu beenden, könnte er dies einfach durch zwangsweises Abbrechen der Verbindung tun. Wenn er dies jedoch täte, würde das wahrscheinliche Verhalten des Clients darin bestehen, dies einfach als Netzwerkfehler zu behandeln und sofort wieder eine Verbindung herzustellen, was den Server stärker belasten würde.

Um diese Wiederverbindungsexplosion zu vermeiden, SOLLTE ein Server daher stattdessen wählen, die Client-Last abzuwerfen, indem er eine Wiederholungsverzögerungsnachricht mit einem geeigneten RCODE-Wert sendet, der den Client über den Grund informiert, warum die DSO-Sitzung beendet werden muss. Das Format des DSO-Retry-Delay-TLV und die Interpretationen der verschiedenen RCODE-Werte werden in Abschnitt 7.2 beschrieben. Nach dem Senden einer DSO-Wiederholungsverzögerungsnachricht DARF der Server KEINE weiteren Nachrichten über diese DSO-Sitzung senden.

Der Server KANN Wiederholungsverzögerungen in Situationen randomisieren, in denen viele Wiederholungsverzögerungen in schneller Folge gesendet werden, um zu vermeiden, dass alle Clients gleichzeitig versuchen, die Verbindung wiederherzustellen. Im Allgemeinen sollten Implementierungen die Verwendung der DSO-Wiederholungsverzögerungsnachricht auf eine Weise vermeiden, die dazu führen würde, dass viele Clients zur gleichen Zeit die Verbindung wiederherstellen, wenn jeder Client versucht, die Verbindung genau zur angegebenen Zeit wiederherzustellen.

Nach Empfang einer DSO-Wiederholungsverzögerungsnachricht vom Server MUSS der Client die Wiederverbindungsverzögerung für diesen Server notieren und die Verbindung dann sofort ordnungsgemäß schließen.

Nach dem Senden einer DSO-Wiederholungsverzögerungsnachricht SOLLTE der Server dem Client fünf Sekunden Zeit geben, um die Verbindung zu schließen, und wenn der Client die Verbindung nach fünf Sekunden nicht geschlossen hat, SOLLTE der Server die Verbindung zwangsweise abbrechen.

Eine DSO-Wiederholungsverzögerungsnachricht DARF NICHT von einem Client initiiert werden. Wenn ein Server eine DSO-Wiederholungsverzögerungsnachricht empfängt, ist dies ein fataler Fehler und der Server MUSS die Verbindung sofort zwangsweise abbrechen.

6.6.1.1. Ausstehende Operationen

In dem Moment, in dem ein Server beschließt, eine DSO-Wiederholungsverzögerungsnachricht zu initiieren, können bereits DNS-Anforderungen vom Client zum Server in dieser DSO-Sitzung unterwegs sein, die beim Server ankommen, nachdem seine DSO-Wiederholungsverzögerungsnachricht gesendet wurde. Der Server MUSS solche eingehenden Anforderungen stillschweigend ignorieren und DARF KEINE Antwortnachrichten für sie generieren. Wenn die DSO-Wiederholungsverzögerungsnachricht vom Server beim Client ankommt, stellt der Client fest, dass alle DNS-Anforderungen, die er zuvor in dieser DSO-Sitzung gesendet hat und die noch keine Antwort erhalten haben, nun sicherlich keine Antwort mehr erhalten werden.

Solche Anforderungen sollten als fehlgeschlagen betrachtet und zu einem späteren Zeitpunkt erneut versucht werden, sofern dies angemessen ist.

In dem Fall, in dem einige, aber nicht alle bestehenden Operationen in einer DSO-Sitzung ungültig geworden sind (vielleicht weil der Server neu konfiguriert wurde und für einige der Namen nicht mehr autoritativ ist), der Server aber alle betroffenen DSO-Sitzungen massenhaft beendet, indem er ihnen allen eine DSO-Wiederholungsverzögerungsnachricht sendet, KANN die Wiederverbindungsverzögerung Null sein, was darauf hinweist, dass die Clients sofort versuchen SOLLTEN, Operationen wiederherzustellen.

Es ist wahrscheinlich, dass einige der Versuche erfolgreich sein werden und andere nicht, abhängig von der Art der Neukonfiguration.

In dem Fall, in dem ein Server eine große Anzahl von DSO-Sitzungen auf einmal beendet (z. B. wenn das System neu gestartet wird) und der Server nicht mit einer Flut gleichzeitiger Wiederholungsversuche überschwemmt werden möchte, SOLLTE er unterschiedliche Wiederverbindungsverzögerungswerte an jeden Client senden. Diese Anpassungen KÖNNEN zufällig, pseudozufällig oder deterministisch ausgewählt werden (z. B. Erhöhen des Zeitwerts um eine Zehntelsekunde für jeden nachfolgenden Client, was eine Wiederverbindungsrate nach dem Neustart von zehn Clients pro Sekunde ergibt).

6.6.2. Sich schlecht benehmende Clients

Ein Server kann feststellen, dass ein Client das Protokoll nicht korrekt befolgt. Es gibt möglicherweise keine Möglichkeit für den Server, die DSO-Sitzung wiederherzustellen, in welchem Fall der Server die Verbindung zwangsweise beendet. Da der Client nicht weiß, warum die Verbindung unterbrochen wurde, kann er sofort wieder eine Verbindung herstellen. Wenn der Server festgestellt hat, dass ein Client das Protokoll nicht korrekt befolgt, KANN er die DSO-Sitzung beenden, sobald sie aufgebaut ist, und eine lange Wiederholungsverzögerung angeben, um zu verhindern, dass der Client sofort wieder eine Verbindung herstellt.

6.6.3. Client-Wiederverbindung

Nachdem eine DSO-Sitzung vom Server beendet wurde (entweder durch Senden einer DSO-Wiederholungsverzögerungsnachricht an den Client oder durch zwangsweises Abbrechen der zugrunde liegenden Transportverbindung), SOLLTE der Client versuchen, eine Verbindung zu dieser Dienstinstanz oder zu einer anderen geeigneten Dienstinstanz herzustellen, falls mehr als eine verfügbar ist. Wenn er sich wieder mit derselben Dienstinstanz verbindet, MUSS der Client die angegebene Verzögerung respektieren, falls verfügbar, bevor er versucht, die Verbindung wiederherzustellen. Clients SOLLTEN NICHT versuchen, die Verzögerung zu randomisieren; der Server wird die Wiederholungsverzögerungswerte, die er an jeden Client sendet, zufällig variieren ("Jitter"), wenn dieses Verhalten gewünscht ist.

Wenn eine bestimmte Dienstinstanz nur für einen kurzen Wartungszeitraum außer Betrieb ist, sollte sie einen Wiederholungsverzögerungswert angeben, der etwas länger ist als das erwartete Wartungsfenster. Sie sollte nicht standardmäßig einen sehr großen Verzögerungswert verwenden, da Clients sonst möglicherweise nicht versuchen, die Verbindung umgehend wiederherzustellen, nachdem der Dienst wieder aufgenommen wurde.

Wenn eine Dienstinstanz nicht möchte, dass ein Client jemals wieder eine Verbindung herstellt (vielleicht wird die Dienstinstanz außer Betrieb genommen), SOLLTE sie die Wiederholungsverzögerung auf den Maximalwert 0xFFFFFFFF (2^32-1 Millisekunden, ca. 49,7 Tage) setzen. Es ist nicht möglich, einen Client anzuweisen, länger als 49,7 Tage fernzubleiben. Wenn die DNS- oder andere Konfigurationsinformationen nach 49,7 Tagen immer noch anzeigen, dass dies die gültige Dienstinstanz für einen bestimmten Dienst ist, KÖNNEN Clients versuchen, die Verbindung wiederherzustellen. In der Realität, wenn ein Client neu gestartet wird oder auf andere Weise seinen Status verliert, kann er durchaus versuchen, die Verbindung wiederherzustellen, bevor 49,7 Tage vergangen sind, solange die DNS- oder andere Konfigurationsinformationen weiterhin anzeigen, dass dies die Dienstinstanz ist, die der Client verwenden sollte.

6.6.3.1. Wiederverbindung nach einem zwangsweisen Abbruch

Wenn eine Verbindung vom Client aufgrund nicht konformen Verhaltens des Servers zwangsweise abgebrochen wurde, SOLLTE der Client diese Dienstinstanz als DSO nicht unterstützend markieren. Der Client KANN die Verbindung wiederherstellen, aber nicht versuchen, DSO zu verwenden, oder er kann sich gegebenenfalls mit einer anderen Dienstinstanz verbinden.

6.6.3.2. Wiederverbindung nach einem unerklärlichen Verbindungsabbruch

Es ist auch möglich, dass ein Server die Verbindung zwangsweise beendet; in diesem Fall weiß der Client nicht, ob die Beendigung das Ergebnis eines Protokollfehlers oder eines Netzwerkusfalls war. Wenn der Client bemerkt, dass die Verbindung unterbrochen wurde, kann er versuchen, die Verbindung sofort wiederherzustellen. Wenn die Verbindung jedoch erneut unterbrochen wird, ohne dass der Client erfolgreich tun kann, was er versucht zu tun, sollte er den Server als DSO nicht unterstützend markieren.

6.6.3.3. Testen auf funktionierende DSO-Unterstützung

Sobald ein Server vom Client als DSO nicht unterstützend markiert wurde, SOLLTE der Client KEINE DSO-Operationen auf diesem Server versuchen, bis einige Zeit vergangen ist. Ein vernünftiges Minimum wäre eine Stunde. Da zwangsweise abgebrochene Verbindungen das Ergebnis eines Softwarefehlers sind, ist es unwahrscheinlich, dass das Problem in der ersten Stunde nach dem ersten Auftreten gelöst wird. Durch die Beschränkung des Wiederholungsintervalls auf eine Stunde kann der Client jedoch bemerken, wann das Problem behoben wurde, ohne den Server übermäßig zu belasten.