SCTP : séparer une association, c'est aussi déplacer sa fermeture

Résumé

• L'opération sctp_peeloff détache une association SCTP déjà établie d'une socket « un-vers-plusieurs » pour lui attribuer une socket « un-vers-un ».
• Toutes les opérations ultérieures passent par le nouveau descripteur. Fermer l'ancienne socket ne termine pas l'association détachée : l'isolation doit être accompagnée d'un suivi de son cycle de vie.

La fermeture d'un point d'entrée n'est pas toujours la fermeture du service qui y avait commencé. Une application SCTP peut avoir extrait certaines associations de sa socket commune, puis continuer à présenter cette dernière comme le centre de toutes ses activités. Lors de l'arrêt, le programme ferme correctement ce centre. Les associations déjà parties restent pourtant hors de portée de cette opération.

Il n'y a pas nécessairement de bogue du protocole dans cette scène. C'est précisément le comportement exposé par la RFC 6458. Son opération sctp_peeloff permet de donner une socket indépendante à une association établie. Ce qui change est l'interface locale de commande, non l'existence de l'association entre les extrémités.

Ce petit déplacement pose une question de direction très concrète : lorsque l'on approuve la séparation d'une charge, approuve-t-on également la nouvelle façon de la terminer ? Une décision d'isolation incomplètement documentée peut laisser la responsabilité de fermeture dans le périmètre ancien, alors que le contrôle effectif l'a quitté.

L'économie d'une socket commune a ses conditions

L'interface « un-vers-plusieurs » permet de représenter plusieurs associations sur une même socket. L'application utilise un identifiant d'association pour désigner celle qu'elle souhaite traiter. Cette organisation réduit le nombre de points d'accès à gérer ; elle ne prouve pas que toutes les ressources sous-jacentes sont indépendantes.

La section 3.3 examine le cas où une implémentation partage l'allocation du tampon de sortie entre associations. Une association qui ne progresse plus peut remplir cette allocation et empêcher les autres d'émettre. Le mode non bloquant ne supprime pas cette dépendance. Ne pas attendre dans un appel et disposer d'une capacité indépendante sont deux propriétés différentes.

Le document présente plusieurs leviers : réserver des ressources par association, limiter par le protocole applicatif la quantité de données non lues, adopter des sockets individuelles dès le départ, ou extraire une association avant un échange volumineux susceptible de s'enliser. Ces choix distribuent autrement la contrainte. Ils ne constituent ni un classement universel ni une mesure de performance.

La réserve est essentielle. Le raisonnement dépend du partage réellement effectué par l'implémentation. Il ne permet pas d'annoncer la mémoire économisée, le débit obtenu ou la manière dont les données déjà en file seraient transférées sur un système particulier. Le bénéfice documenté est une possibilité de séparation ; le résultat d'exploitation demande des éléments supplémentaires.

Le descripteur nouveau n'est pas un détail comptable

Pour effectuer l'extraction, l'application fournit la socket initiale et l'identifiant d'une association existante. L'appel réussi retourne un descripteur non négatif ; un échec retourne moins un avec une indication d'erreur. Ce n'est donc pas l'acceptation ordinaire d'une nouvelle association entrante.

La section 9.2 précise que toutes les opérations de données et de contrôle ultérieures sur l'association utilisent la nouvelle socket. Fermer la socket d'origine ne termine pas l'association extraite. La séparation concerne bien la commande, et pas seulement le chemin utilisé par les octets.

Prenons un service hypothétique qui isole un échange lourd tout en gardant les autres dans la socket commune. Lorsque son arrêt ferme cette dernière, l'échange lourd n'est plus compris dans son périmètre. Le fait qu'il soit entré par ce point d'accès ne suffit plus. Il faut conserver son nouveau descripteur dans l'inventaire des activités à terminer.

Cette situation n'implique pas une fuite. La poursuite de l'échange peut être voulue. Elle devient problématique lorsque la continuité résulte de l'absence de propriétaire, et non d'une décision explicite. Le même acte qui limite une interdépendance crée un objet de gestion supplémentaire.

Une règle d'inactivité n'est pas une garantie de transfert

Les options ont elles aussi un périmètre. Dans la RFC 6458, les options de niveau socket et IP s'appliquent à la socket concernée. Pour une socket commune, cela inclut les associations qui lui appartiennent ; pour une socket individuelle, l'association qu'elle représente. Les sections sur les tampons signalent par ailleurs des comportements dépendant de l'implémentation dans le modèle partagé.

La section 8.1.8 réserve SCTP_AUTOCLOSE aux sockets « un-vers-plusieurs ». L'inactivité porte sur les données utilisateur échangées. La valeur par défaut, zéro, désactive la fonction ; une autre valeur exprime une durée en secondes. L'application doit activer les notifications de changement d'association si elle veut être informée de ces fermetures.

Cela ne dit pas ce que devient un temporisateur déjà armé lors d'une extraction. Affirmer qu'il serait automatiquement annulé, réinitialisé ou hérité dépasserait les passages examinés. La conclusion utile est de vérifier la politique de durée de vie sur la nouvelle socket et dans l'implémentation utilisée, au lieu de supposer que l'ancien réglage suffit.

Le mot fermeture mérite la même précision. Par défaut, close sur une socket individuelle déclenche un arrêt SCTP ordonné et rend le descripteur inutilisable pour les opérations suivantes. Si SO_LINGER est activé avec une durée nulle, close provoque au contraire un abandon de l'association. Une durée positive limite l'attente de l'appel ; l'arrêt du protocole peut continuer après son retour.

L'interface shutdown permet, dans le cas décrit, de conserver le descripteur pour recevoir des notifications. Mais SHUT_WR déclenche un arrêt complet du protocole SCTP, et non une demi-fermeture à la manière de TCP. Aucun de ces événements ne constitue, à lui seul, la preuve qu'une transaction applicative est achevée.

Documenter ce qui a réellement changé

La notice du RFC Editor classe ce texte parmi les documents Informational, avec une publication en décembre 2011. Il ne recense pas les comportements de tous les systèmes actuels. La liste d'errata consultée comporte des corrections vérifiées ailleurs dans le texte, mais aucune correction directe de la section 9.2. Les propositions conservées pour une mise à jour et les propositions rejetées ne sont pas des modifications acceptées.

L'analyse de gouvernance vient ensuite. Dans son texte sur le problème d'agence, Lu Heng interroge le lien entre pouvoir de décision et exposition aux conséquences. Ici, ce lien se vérifie en demandant qui accepte l'isolation, puis qui assume la fin de l'activité séparée. Ce n'est pas une accusation d'intention contre les concepteurs.

Son explication de la raison d'être de BTW Media privilégie le réel observable au plaidoyer. La traduction opérationnelle est simple : suivre les descripteurs qui commandent encore des associations, plutôt que se satisfaire du récit selon lequel le point d'entrée est fermé.

L'extraction rend une limite plus nette. L'organisation doit seulement éviter de continuer à gouverner le travail avec la carte d'avant la séparation.