Résumé

  • MAX_DATA et MAX_STREAM_DATA annoncent des plafonds absolus d’offset, pas un volume neuf ni une mesure de mémoire libre.
  • Un plafond inférieur ne révoque aucun crédit, et l’absence de DATA_BLOCKED ne démontre pas que l’émetteur peut avancer.
  • Une conclusion de capacité exige de joindre crédit, offsets, tailles finales, consommation applicative, mémoire et congestion.

Un tableau de bord voit MAX_DATA passer à 16 Mio et affiche 16 Mio de marge. Le calcul est faux : la valeur est cumulative et les offsets déjà engagés en consomment une partie. L’interprétation l’est aussi : ce nombre autorise l’émetteur à étendre son registre d’octets, sans mesurer directement la RAM disponible ni la vitesse de lecture de l’application.

La RFC 9000 §4.1 impose deux limites simultanées. Le contrôle de connexion borne l’ensemble des données STREAM ; celui du flux empêche un seul flux d’absorber tout le tampon. L’autorisation utile dépend donc du plus grand plafond de connexion, de sa consommation cumulée, du plafond du flux concerné et de son plus grand offset.

Ces nombres sont absolus. Une valeur MAX_DATA plus petite envoyée ensuite n’a aucun effet ; le pair ignore tout message qui n’augmente pas la limite. Conserver seulement « la dernière valeur » détruit la vérité du protocole. Il faut retenir le maximum accepté et l’arithmétique qu’il gouverne.

La RFC 9000 §19.9 compte toutes les données STREAM. La somme des tailles finales, y compris celles de flux terminés, reste sous le plafond. La RFC 9000 §4.5 définit précisément la taille finale comme le crédit consommé. Fermer ou réinitialiser un flux stabilise le compte ; cela ne restitue pas rétroactivement ses offsets.

Au niveau du flux, la RFC 9000 §19.10 retient le plus grand offset. Perte et réordonnancement peuvent le placer au-delà des octets contigus déjà livrables. Des octets reçus ou la taille instantanée d’un tampon ne remplacent donc pas le registre d’offsets.

La RFC 9000 §4.2 laisse à l’implémentation le moment et le volume des hausses. De petites annonces fréquentes coûtent du contrôle ; des annonces rares demandent des incréments et des engagements de ressources plus grands. L’auto-ajustement peut utiliser le RTT et la consommation applicative. Ce sont des facteurs de politique, pas une conversion garantie entre crédit et mémoire libre.

Le crédit ne promet pas davantage un débit. La RFC 9000 §4.3 explique que le débit devient limité par le contrôle de flux si le crédit disponible reste sous le produit bande passante-délai. Il peut être nécessaire sans être suffisant : congestion, pertes, ordonnancement et application demeurent des contraintes séparées.

Enfin, DATA_BLOCKED n’est qu’un indice. La RFC 9000 §19.12 indique qu’un émetteur devrait le produire lorsqu’il veut écrire mais atteint la limite. Pourtant il n’y est pas obligé, et §4.2 interdit au récepteur d’attendre ce signal avant d’accorder du crédit. Son absence ne prouve donc pas une marge disponible.

Le dossier exploitable réunit plafond maximal, consommation cumulée, offsets, tailles finales, signaux de blocage, frontière de lecture applicative, occupation mémoire, fenêtre de congestion, RTT, pertes et horodatage des mises à jour. Le crédit ne prouve que la permission protocolaire.