5. Casi d'uso

Ogni endpoint invia messaggi HeartbeatRequest con la frequenza e il riempimento richiesti per il particolare caso d'uso. L'endpoint non dovrebbe aspettarsi che il suo peer invii HeartbeatRequests. Le direzioni sono indipendenti.

5.1. Scoperta del MTU di percorso

DTLS esegue la scoperta del MTU di percorso come descritto nella sezione 4.1.1.1 di [RFC6347]. Una descrizione dettagliata di come eseguire la scoperta del MTU di percorso è fornita in [RFC4821]. I pacchetti di prova necessari sono i messaggi HeartbeatRequest.

Questo metodo di utilizzo dei messaggi HeartbeatRequest per DTLS è simile a quello per il protocollo di trasmissione del controllo di flusso (Stream Control Transmission Protocol, SCTP) che utilizza il blocco di riempimento (padding chunk, PAD-chunk) definito in [RFC4820].

5.2. Controllo della vitalità

L'invio di messaggi HeartbeatRequest consente al mittente di assicurarsi di poter raggiungere il peer e che il peer sia attivo. Anche nel caso di TLS/TCP, ciò consente un controllo con una frequenza molto superiore a quella che consentirebbe la funzionalità keep-alive di TCP.

Oltre ad assicurarsi che il peer sia ancora raggiungibile, l'invio di messaggi HeartbeatRequest aggiorna lo stato NAT di tutti i NAT coinvolti.

I messaggi HeartbeatRequest DOVREBBERO (SHOULD) essere inviati solo dopo un periodo di inattività che è lungo almeno più volte il tempo di andata e ritorno. Questo periodo di inattività DOVREBBE (SHOULD) essere configurabile fino a un periodo di diversi minuti e fino a un periodo di un secondo. Un valore predefinito per il periodo di inattività DOVREBBE (SHOULD) essere configurabile, ma DOVREBBE (SHOULD) anche essere regolabile su base per-peer.