5. Cas d'utilisation

Chaque point de terminaison envoie des messages HeartbeatRequest à un rythme et avec le remplissage requis pour le cas d'utilisation particulier. Le point de terminaison ne devrait pas s'attendre à ce que son pair envoie des HeartbeatRequests. Les directions sont indépendantes.

5.1. Découverte du MTU de chemin

DTLS effectue la découverte du MTU de chemin comme décrit dans la section 4.1.1.1 de [RFC6347]. Une description détaillée de la manière d'effectuer la découverte du MTU de chemin est donnée dans [RFC4821]. Les paquets de sonde nécessaires sont les messages HeartbeatRequest.

Cette méthode d'utilisation des messages HeartbeatRequest pour DTLS est similaire à celle du protocole de contrôle de transmission de flux (Stream Control Transmission Protocol, SCTP) utilisant le bloc de remplissage (padding chunk, PAD-chunk) défini dans [RFC4820].

5.2. Vérification de vivacité

L'envoi de messages HeartbeatRequest permet à l'expéditeur de s'assurer qu'il peut atteindre le pair et que le pair est en vie. Même dans le cas de TLS/TCP, cela permet une vérification à un rythme beaucoup plus élevé que ne le permettrait la fonctionnalité de maintien en vie TCP.

En plus de s'assurer que le pair est toujours joignable, l'envoi de messages HeartbeatRequest actualise l'état NAT de tous les NAT impliqués.

Les messages HeartbeatRequest DEVRAIENT (SHOULD) être envoyés uniquement après une période d'inactivité d'au moins plusieurs fois le temps d'aller-retour. Cette période d'inactivité DEVRAIT (SHOULD) être configurable jusqu'à une période de plusieurs minutes et jusqu'à une période d'une seconde. Une valeur par défaut pour la période d'inactivité DEVRAIT (SHOULD) être configurable, mais elle DEVRAIT (SHOULD) également être réglable par pair.