6. Cycle de vie de la session DSO et minuteurs

6.1. Initiation de la session DSO

Une session DSO commence comme décrit dans la section 5.1.

Une fois qu'une session DSO a été créée, le client ou le serveur peut initier autant d'opérations DNS qu'il le souhaite en utilisant la session DSO.

Lorsqu'un initiateur a plusieurs messages à envoyer, il NE DEVRAIT PAS attendre chaque réponse avant d'envoyer le message suivant.

Un répondeur DOIT agir sur les messages dans l'ordre où ils sont reçus, et DEVRAIT renvoyer les réponses aux messages de demande dès qu'elles sont disponibles. Un répondeur NE DEVRAIT PAS retarder l'envoi des réponses dans le but de livrer les réponses dans le même ordre que les demandes correspondantes ont été reçues.

La section 6.2.1.1 de la spécification DNS-over-TCP [RFC7766] précise cela plus en détail.

6.2. Délais d'expiration de la session DSO

Deux valeurs de délai d'expiration sont associées à une session DSO : le délai d'inactivité et l'intervalle de maintien en vie (keepalive). Les deux valeurs sont communiquées dans le même TLV, le TLV Keepalive (section 7.1).

La première valeur de délai, le délai d'inactivité, est la durée maximale pendant laquelle un client peut maintenir spéculativement une session DSO inactive ouverte dans l'espoir qu'il puisse avoir de futures demandes à envoyer à ce serveur.

La seconde valeur de délai, l'intervalle de maintien en vie, est l'intervalle maximal autorisé entre les messages si le client souhaite maintenir la session DSO en vie.

Les deux valeurs de délai sont indépendantes. Le délai d'inactivité peut être plus court, identique ou plus long que l'intervalle de maintien en vie, bien que dans la plupart des cas, on s'attend à ce que le délai d'inactivité soit plus court que l'intervalle de maintien en vie.

Un délai d'inactivité plus court avec un intervalle de maintien en vie plus long signale au client qu'il ne devrait pas maintenir spéculativement une session DSO inactive ouverte très longtemps sans raison, mais lorsqu'il a une raison active de maintenir une session DSO ouverte, il n'a pas besoin d'envoyer un niveau agressif de trafic de maintien en vie DSO pour maintenir cette session. Un exemple de ceci serait un client qui s'est abonné aux notifications DNS Push. Dans ce cas, le client n'envoie aucun trafic au serveur, mais la session n'est pas inactive car il y a une demande active au serveur pour recevoir des notifications push.

Un délai d'inactivité plus long avec un intervalle de maintien en vie plus court signale au client qu'il peut maintenir spéculativement une session DSO inactive ouverte pendant une longue période, mais pour maintenir cette session DSO inactive, il devrait envoyer beaucoup de trafic de maintien en vie DSO. On s'attend à ce que cette configuration soit moins courante.

Dans le cas habituel où le délai d'inactivité est plus court que l'intervalle de maintien en vie, ce n'est que lorsqu'un client a une opération de longue durée et à faible trafic que l'intervalle de maintien en vie entre en jeu afin de garantir qu'une quantité résiduelle suffisante de trafic est générée pour maintenir l'état du NAT et du pare-feu, et pour assurer au client et au serveur qu'ils ont toujours une connectivité l'un avec l'autre.

Sur une nouvelle session DSO, si aucun échange explicite de message DSO Keepalive n'a eu lieu, la valeur par défaut pour les deux délais est de 15 secondes.

Pour les deux délais, des valeurs de délai plus faibles entraînent un trafic réseau plus élevé et une charge CPU plus élevée sur le serveur.

6.3. Sessions DSO inactives

Au niveau des serveurs et des clients, la génération ou la réception de tout message DNS complet (y compris les demandes DNS, les réponses, les mises à jour, les messages DSO, etc.) réinitialise les deux minuteurs pour cette session DSO, à la seule exception qu'un message DSO Keepalive réinitialise uniquement le minuteur de maintien en vie, et non le minuteur de délai d'inactivité.

De plus, tant que le client a une opération en cours, le minuteur d'inactivité reste effacé et un délai d'inactivité ne peut pas se produire.

Pour les opérations DNS à courte durée de vie comme les requêtes traditionnelles et les mises à jour, une opération est considérée comme "en cours" pendant le temps entre la demande et la réponse, généralement une période de quelques centaines de millisecondes au plus. Au niveau du client, le minuteur d'inactivité est effacé lors de la transmission d'une demande et reste effacé jusqu'à la réception de la réponse correspondante. Au niveau du serveur, le minuteur d'inactivité est effacé lors de la réception d'une demande et reste effacé jusqu'à la transmission de la réponse correspondante.

Pour les opérations DNS avec état à longue durée de vie (telles qu'un abonnement aux notifications Push [Push] ou un abonnement à une interface de relais de découverte [Relay]), une opération est considérée comme "en cours" tant que l'opération est active, c'est-à-dire jusqu'à ce qu'elle soit annulée. Cela signifie qu'une session DSO peut exister avec des opérations actives, sans aucun message circulant dans l'une ou l'autre direction, pendant bien plus longtemps que le délai d'inactivité. Ce n'est pas une erreur. C'est pourquoi il y a deux minuteurs distincts : le délai d'inactivité et l'intervalle de maintien en vie. Le simple fait qu'une session DSO n'ait pas de trafic pendant une période prolongée ne rend pas automatiquement cette session DSO "inactive", si elle a une opération active qui attend des événements.

6.4. Le délai d'inactivité

Le but du délai d'inactivité est pour le serveur d'équilibrer le compromis entre les coûts d'établissement de nouvelles sessions DSO et les coûts de maintenance des sessions DSO inactives. Un serveur avec une capacité de session DSO abondante peut offrir un délai d'inactivité élevé pour permettre aux clients de maintenir une session DSO spéculative ouverte pendant une longue période et d'économiser le coût d'établissement d'une nouvelle session DSO pour les communications futures avec ce serveur. Un serveur avec des ressources mémoire limitées peut offrir un délai d'inactivité faible pour amener les clients à fermer rapidement les sessions DSO chaque fois qu'ils n'ont pas d'opérations en cours avec ce serveur, puis à créer une nouvelle session DSO plus tard si nécessaire.

6.4.1. Fermeture des sessions DSO inactives

Lorsque le délai d'inactivité d'une connexion est atteint, le client DOIT commencer à fermer la connexion inactive, mais un client n'est pas tenu de maintenir une connexion inactive ouverte jusqu'à ce que le délai d'inactivité soit atteint. Un client PEUT fermer une session DSO à tout moment, à la discrétion du client. Si un client détermine qu'il n'a aucun besoin actuel ou futur raisonnablement anticipé pour une session DSO actuellement inactive, alors le client DEVRAIT fermer gracieusement cette connexion.

Si, à tout moment pendant la durée de vie de la session DSO, la valeur du délai d'inactivité (c'est-à-dire 15 secondes par défaut) s'écoule sans qu'il y ait d'opération active sur la session DSO, le client DOIT fermer la connexion gracieusement.

Si, à tout moment pendant la durée de vie de la session DSO, trop de temps s'écoule sans qu'il y ait d'opération active sur la session DSO, alors le serveur DOIT considérer le client comme délinquant et DOIT interrompre de force la session DSO. Ce qui est considéré comme "trop de temps" dans ce contexte est de cinq secondes ou deux fois la valeur actuelle du délai d'inactivité, selon la valeur la plus élevée. Si le délai d'inactivité a sa valeur par défaut de 15 secondes, cela signifie qu'un client sera considéré comme délinquant et déconnecté s'il n'a pas fermé sa connexion après 30 secondes d'inactivité.

Dans ce contexte, une opération active sur une session DSO inclut une requête en attente d'une réponse, une mise à jour en attente d'une réponse ou une opération active de longue durée, mais pas un échange de messages DSO Keepalive lui-même. Un échange de messages DSO Keepalive réinitialise uniquement le minuteur d'intervalle de maintien en vie, et non le minuteur de délai d'inactivité.

Si le client souhaite maintenir une session DSO inactive ouverte plus longtemps que la durée par défaut, il utilise alors le message DSO Keepalive pour demander des valeurs de délai plus longues comme décrit dans la section 7.1.

6.4.2. Valeurs pour le délai d'inactivité

Pour la valeur du délai d'inactivité, des valeurs plus faibles entraînent des fermetures et des rétablissements de session DSO plus fréquents. Des valeurs plus élevées entraînent un trafic plus faible et une charge CPU plus faible sur le serveur, mais une charge mémoire plus élevée pour maintenir l'état des sessions DSO inactives.

Un serveur peut dicter n'importe quelle valeur de son choix pour le délai d'inactivité (soit dans une réponse à une demande initiée par le client, soit dans un message initié par le serveur), y compris des valeurs inférieures à une seconde, ou même zéro.

Un délai d'inactivité de zéro informe le client qu'il ne devrait pas du tout maintenir spéculativement des connexions inactives, et dès que le client a terminé l'opération ou les opérations relatives à ce serveur, le client devrait immédiatement commencer à fermer cette session.

Un serveur interrompra de force une session client inactive après cinq secondes ou deux fois la valeur du délai d'inactivité, selon la valeur la plus élevée. Dans le cas d'une valeur de délai d'inactivité de zéro, cela signifie que si un client ne ferme pas une session client inactive, alors le serveur interrompra de force la session inactive après cinq secondes.

Un délai d'inactivité de 0xFFFFFFFF représente "l'infini" et informe le client qu'il peut maintenir une connexion inactive ouverte aussi longtemps qu'il le souhaite. Notez qu'après avoir accordé un délai d'inactivité illimité de cette manière, à tout moment le serveur peut réviser ce délai d'inactivité en envoyant un nouveau message DSO Keepalive dictant de nouvelles valeurs de délai de session au client.

Le plus grand délai d'inactivité fini pris en charge par le TLV Keepalive actuel est 0xFFFFFFFE (2^32-2 millisecondes, environ 49,7 jours).

6.5. L'intervalle de maintien en vie (Keepalive)

Le but de l'intervalle de maintien en vie est de gérer la génération de suffisamment de messages pour maintenir l'état dans les boîtiers intermédiaires (tels que les passerelles NAT ou les pare-feu) et pour que le client et le serveur vérifient périodiquement qu'ils ont toujours une connectivité l'un avec l'autre. Cela leur permet de nettoyer l'état lorsque la connectivité est perdue et d'établir une nouvelle session si nécessaire.

6.5.1. Expiration de l'intervalle de maintien en vie

Si, à tout moment pendant la durée de vie de la session DSO, la valeur de l'intervalle de maintien en vie (c'est-à-dire 15 secondes par défaut) s'écoule sans qu'aucun message DNS ne soit envoyé ou reçu sur une session DSO, le client DOIT prendre des mesures pour maintenir la session DSO en vie en envoyant un message DSO Keepalive (section 7.1). Un échange de messages DSO Keepalive réinitialise uniquement le minuteur de maintien en vie, et non le minuteur d'inactivité.

Si un client se déconnecte du réseau brusquement, sans fermer proprement sa session DSO, laissant peut-être une opération de longue durée non annulée, le serveur l'apprend après avoir échoué à recevoir le trafic de maintien en vie DSO requis de ce client. Si, à tout moment pendant la durée de vie de la session DSO, deux fois la valeur de l'intervalle de maintien en vie (c'est-à-dire 30 secondes par défaut) s'écoulent sans qu'aucun message DNS ne soit envoyé ou reçu sur une session DSO, le serveur DEVRAIT considérer le client comme délinquant et DEVRAIT interrompre de force la session DSO.

6.5.2. Valeurs pour l'intervalle de maintien en vie

Pour la valeur de l'intervalle de maintien en vie, des valeurs plus faibles entraînent un volume plus élevé de trafic de maintien en vie DSO. Des valeurs plus élevées de l'intervalle de maintien en vie réduisent le trafic et la charge CPU, mais ont un effet minimal sur la charge mémoire du serveur car les clients maintiennent une session DSO ouverte pendant la même durée (déterminée par le délai d'inactivité) quel que soit le niveau de trafic de maintien en vie DSO requis.

Il peut être approprié pour les clients et les serveurs de sélectionner différents intervalles de maintien en vie selon le type de réseau sur lequel ils se trouvent.

Un serveur DNS d'entreprise qui sait qu'il ne dessert que des clients sur le réseau interne, sans passerelles NAT ni pare-feu intermédiaires, peut imposer un intervalle de maintien en vie plus long car un trafic de maintien en vie DSO fréquent n'est pas nécessaire.

Un serveur DNS public qui dessert principalement des clients consommateurs résidentiels, où il est probable qu'il y aura une passerelle NAT sur le chemin, peut imposer un intervalle de maintien en vie plus court pour générer un trafic de maintien en vie DSO plus fréquent.

Un client intelligent peut être adaptatif à son environnement. Un client utilisant une adresse IPv4 privée [RFC1918] pour communiquer avec un serveur DNS à une adresse en dehors de ce bloc d'adresses privées IPv4 peut conclure qu'il est probable qu'il y ait une passerelle NAT sur le chemin, et demander en conséquence un intervalle de maintien en vie plus court.

Par défaut, il est RECOMMANDÉ que les clients demandent, et que les serveurs accordent, un intervalle de maintien en vie de 60 minutes. Cet intervalle de maintien en vie permet une détection raisonnablement rapide si un client se déconnecte brusquement sans fermer proprement la session. De plus, il est suffisant pour maintenir l'état dans les pare-feu et les passerelles NAT qui suivent la meilleure pratique actuelle recommandée par l'IETF selon laquelle le "délai d'inactivité de connexion établie" utilisé par les boîtiers intermédiaires doit être d'au moins 2 heures et 4 minutes [RFC5382] [RFC7857].

Notez que plus la valeur de l'intervalle de maintien en vie est courte, plus la charge sur le client et le serveur est élevée. De plus, pour une valeur de maintien en vie plus courte que le temps nécessaire au transport pour retransmettre, la perte d'un seul paquet amènerait un serveur à interrompre la connexion avec excès de zèle. Par exemple, une valeur d'intervalle de maintien en vie (hypothétique et irréaliste) de 100 ms entraînerait un flux continu de dix messages par seconde ou plus (si autorisé par la fenêtre de contrôle de congestion actuelle) dans les deux sens pour maintenir la session DSO en vie. Et, dans cet exemple extrême, une seule retransmission sur un chemin avec, par exemple, 100 ms de RTT introduirait une pause momentanée dans le flux de messages assez longue pour amener le serveur à interrompre la connexion.

En raison de cette préoccupation, le serveur NE DOIT PAS envoyer un message DSO Keepalive (soit une réponse DSO à une demande DSO initiée par le client, soit un message DSO initié par le serveur) avec une valeur d'intervalle de maintien en vie inférieure à dix secondes. Si un client reçoit un message DSO Keepalive spécifiant une valeur d'intervalle de maintien en vie inférieure à dix secondes, c'est une erreur fatale et le client DOIT interrompre de force la connexion immédiatement.

Une valeur d'intervalle de maintien en vie de 0xFFFFFFFF représente "l'infini" et informe le client qu'il ne devrait générer aucun trafic de maintien en vie DSO. Notez qu'après avoir signalé que le client ne devrait générer aucun trafic de maintien en vie DSO de cette manière, le serveur peut à tout moment réviser cette exigence de trafic de maintien en vie DSO en envoyant un nouveau message DSO Keepalive dictant de nouvelles valeurs de délai de session au client.

Le plus grand intervalle de maintien en vie fini pris en charge par le TLV Keepalive actuel est 0xFFFFFFFE (2^32-2 millisecondes, environ 49,7 jours).

6.6. Fin de session DSO initiée par le serveur

En plus d'annuler sélectivement des opérations individuelles de longue durée (section 5.6), il y a aussi des occasions où un serveur peut avoir besoin de terminer une ou plusieurs sessions DSO entières. Une session DSO entière peut devoir être terminée si le client is défectueux d'une manière ou d'une autre ou quitte le réseau sans fermer sa session DSO. Les sessions DSO peuvent également devoir être terminées si le serveur devient surchargé ou est reconfiguré et n'a pas la capacité d'être sélectif sur les opérations qui doivent être annulées.

Cette section discute des diverses raisons pour lesquelles une session DSO peut être terminée et des mécanismes pour le faire.

En fonctionnement normal, la fermeture d'une session DSO est la responsabilité du client. Le client détermine quand fermer une session DSO sur la base d'une évaluation de ses propres besoins et de la valeur du délai d'inactivité dictée par le serveur. Un serveur ne provoque la fin d'une session DSO que dans les circonstances exceptionnelles décrites ci-dessous. Certaines des situations exceptionnelles dans lesquelles un serveur peut terminer une session DSO incluent :

• Le logiciel d'application serveur ou le système d'exploitation sous-jacent s'arrête ou redémarre.

• Le logiciel d'application serveur se termine de manière inattendue (peut-être en raison d'un bogue qui le fait planter, amenant le système d'exploitation sous-jacent à envoyer un TCP RST).

• Le serveur subit une procédure de reconfiguration ou de maintenance qui, en raison de la manière dont le logiciel serveur est implémenté, nécessite que les clients soient déconnectés. Par exemple, certains logiciels sont implémentés de telle sorte qu'ils lisent un fichier de configuration au démarrage, et changer la configuration du serveur implique de modifier le fichier de configuration puis de tuer et redémarrer le logiciel serveur, ce qui entraîne généralement une perte des connexions réseau.

• Le client ne respecte pas son obligation de générer le trafic de maintien en vie DSO requis ou de fermer une session inactive dans le délai prescrit (cinq secondes ou deux fois l'intervalle de temps dicté par le serveur, selon la valeur la plus élevée, comme décrit dans la section 6.2).

• Le client envoie une demande grossièrement invalide ou malformée qui indique une implémentation client sérieusement défectueuse.

• Le serveur est en surcapacité et a besoin de délester une partie de la charge.

6.6.1. Message de délai de nouvelle tentative initié par le serveur

Dans les cas décrits ci-dessus où un serveur choisit de terminer une session DSO, il pourrait le faire simplement en interrompant de force la connexion. Cependant, s'il faisait cela, le comportement probable du client pourrait être simplement de traiter cela comme une panne réseau et de se reconnecter immédiatement, mettant plus de charge sur le serveur.

Par conséquent, pour éviter cette implosion de reconnexion, un serveur DEVRAIT plutôt choisir de délester la charge client en envoyant un message de délai de nouvelle tentative (Retry Delay) avec une valeur RCODE appropriée informant le client de la raison pour laquelle la session DSO doit être terminée. Le format du TLV DSO Retry Delay et les interprétations des diverses valeurs RCODE sont décrits dans la section 7.2. Après avoir envoyé un message DSO Retry Delay, le serveur NE DOIT PAS envoyer d'autres messages sur cette session DSO.

Le serveur PEUT randomiser les délais de nouvelle tentative dans les situations où de nombreux délais de nouvelle tentative sont envoyés en succession rapide afin d'éviter que tous les clients tentent de se reconnecter en même temps. En général, les implémentations devraient éviter d'utiliser le message DSO Retry Delay d'une manière qui entraînerait la reconnexion de nombreux clients en même temps si chaque client tentait de se reconnecter à l'heure exacte spécifiée.

Dès réception d'un message DSO Retry Delay du serveur, le client DOIT prendre note du délai de reconnexion pour ce serveur et ensuite fermer immédiatement la connexion gracieusement.

Après avoir envoyé un message DSO Retry Delay, le serveur DEVRAIT accorder au client cinq secondes pour fermer la connexion, et si le client n'a pas fermé la connexion après cinq secondes, alors le serveur DEVRAIT interrompre de force la connexion.

Un message DSO Retry Delay NE DOIT PAS être initié par un client. Si un serveur reçoit un message DSO Retry Delay, c'est une erreur fatale et le serveur DOIT interrompre de force la connexion immédiatement.

6.6.1.1. Opérations en suspens

À l'instant où un serveur choisit d'initier un message DSO Retry Delay, il peut y avoir des demandes DNS déjà en vol du client vers le serveur sur cette session DSO, qui arriveront au serveur après que son message DSO Retry Delay a été envoyé. Le serveur DOIT ignorer silencieusement de telles demandes entrantes et NE DOIT PAS générer de messages de réponse pour elles. Lorsque le message DSO Retry Delay du serveur arrive au client, le client déterminera que toute demande DNS qu'il a précédemment envoyée sur cette session DSO et qui n'a pas encore reçu de réponse ne recevra désormais certainement aucune réponse.

De telles demandes devraient être considérées comme échouées et devraient être réessayées ultérieurement, le cas échéant.

Dans le cas où certaines, mais pas toutes, les opérations existantes sur une session DSO sont devenues invalides (peut-être parce que le serveur a été reconfiguré et ne fait plus autorité pour certains des noms), mais que le serveur termine toutes les sessions DSO affectées en masse en leur envoyant toutes un message DSO Retry Delay, le délai de reconnexion PEUT être zéro, indiquant que les clients DEVRAIENT immédiatement tenter de rétablir les opérations.

Il est probable que certaines des tentatives réussiront et d'autres non, selon la nature de la reconfiguration.

Dans le cas où un serveur termine un grand nombre de sessions DSO à la fois (par exemple, si le système redémarre) et que le serveur ne veut pas être inondé par un déluge de nouvelles tentatives simultanées, il DEVRAIT envoyer des valeurs de délai de reconnexion différentes à chaque client. Ces ajustements PEUVENT être sélectionnés aléatoirement, pseudo-aléatoirement ou de manière déterministe (par exemple, en incrémentant la valeur temporelle d'un dixième de seconde pour chaque client successif, donnant un taux de reconnexion après redémarrage de dix clients par seconde).

6.6.2. Clients se comportant mal

Un serveur peut déterminer qu'un client ne suit pas le protocole correctement. Il peut n'y avoir aucun moyen pour le serveur de récupérer la session DSO, auquel cas le serveur termine de force la connexion. Comme le client ne sait pas pourquoi la connexion a été coupée, il peut se reconnecter immédiatement. Si le serveur a déterminé qu'un client ne suit pas le protocole correctement, il PEUT terminer la session DSO dès qu'elle est établie, en spécifiant un long délai de nouvelle tentative pour empêcher le client de se reconnecter immédiatement.

6.6.3. Reconnexion du client

Après qu'une session DSO est terminée par le serveur (soit en envoyant au client un message DSO Retry Delay, soit en interrompant de force la connexion de transport sous-jacente), le client DEVRAIT essayer de se reconnecter à cette instance de service ou à une autre instance de service appropriée si plus d'une est disponible. Si la reconnexion se fait à la même instance de service, le client DOIT respecter le délai indiqué, s'il est disponible, avant de tenter de se reconnecter. Les clients NE DEVRAIENT PAS tenter de randomiser le délai ; le serveur fera varier aléatoirement les valeurs de délai de nouvelle tentative qu'il envoie à chaque client si ce comportement est souhaité.

Si une instance de service particulière ne sera hors service que pour une courte période de maintenance, elle devrait indiquer une valeur de délai de nouvelle tentative un peu plus longue que la fenêtre de maintenance prévue. Elle ne devrait pas utiliser par défaut une très grande valeur de délai, sinon les clients pourraient ne pas tenter de se reconnecter rapidement après la reprise du service.

Si une instance de service ne veut pas qu'un client se reconnecte jamais (peut-être que l'instance de service est mise hors service), elle DEVRAIT régler le délai de nouvelle tentative à la valeur maximale 0xFFFFFFFF (2^32-1 millisecondes, environ 49,7 jours). Il n'est pas possible d'ordonner à un client de rester à l'écart pendant plus de 49,7 jours. Si, après 49,7 jours, le DNS ou d'autres informations de configuration indiquent toujours qu'il s'agit de l'instance de service valide pour un service particulier, alors les clients PEUVENT tenter de se reconnecter. En réalité, si un client est redémarré ou perd autrement son état, il pourrait bien tenter de se reconnecter avant que 49,7 jours ne s'écoulent, tant que le DNS ou d'autres informations de configuration continuent d'indiquer qu'il s'agit de l'instance de service que le client devrait utiliser.

6.6.3.1. Reconnexion après une interruption forcée

Si une connexion a été interrompue de force par le client en raison d'un comportement non conforme du serveur, le client DEVRAIT marquer cette instance de service comme ne prenant pas en charge DSO. Le client PEUT se reconnecter mais ne pas tenter d'utiliser DSO, ou il peut se connecter à une instance de service différente le cas échéant.

6.6.3.2. Reconnexion après une perte de connexion inexpliquée

Il est également possible qu'un serveur termine de force la connexion ; dans ce cas, le client ne sait pas si la terminaison était le résultat d'une erreur de protocole ou d'une panne réseau. Lorsque le client remarque que la connexion a été coupée, il peut tenter de se reconnecter immédiatement. Cependant, si la connexion est coupée à nouveau sans que le client puisse réussir à faire ce qu'il essaie de faire, il devrait marquer le serveur comme ne prenant pas en charge DSO.

6.6.3.3. Sondage pour une prise en charge DSO fonctionnelle

Une fois qu'un serveur a été marqué par le client comme ne prenant pas en charge DSO, le client NE DEVRAIT PAS tenter d'opérations DSO sur ce serveur jusqu'à ce qu'un certain temps se soit écoulé. Un minimum raisonnable serait d'une heure. Comme les connexions interrompues de force sont le résultat d'une défaillance logicielle, il n'est pas probable que le problème soit résolu dans la première heure après sa première rencontre. Cependant, en limitant l'intervalle de nouvelle tentative à une heure, le client pourra remarquer quand le problème a été corrigé sans imposer une charge excessive au serveur.