3.2.1.2. Receiver Behavior (Comportamento del Ricevitore) (Sostituisce Sezione 8.4.3.2, RFC 8724)

3.2.1.2. Receiver Behavior (Comportamento del Ricevitore)

Alla ricezione di un SCHC Fragment con una coppia RuleID e DTag non in elaborazione in quel momento:

• il receiver (ricevitore) DOVREBBE verificare che il valore DTag non sia stato recentemente utilizzato per quel valore RuleID, garantendo così che lo SCHC Fragment ricevuto non sia un residuo di una precedente trasmissione di SCHC Packet frammentato. Il valore iniziale dell'Inactivity Timer (timer di inattività) è la durata di vita RACCOMANDATA per il valore DTag presso il ricevitore. Se lo SCHC Fragment viene determinato come tale residuo, il ricevitore PUÒ ignorarlo silenziosamente e scartarlo.

• il ricevitore DEVE avviare un processo per assemblare un nuovo SCHC Packet con quella coppia di valori RuleID e DTag. Il ricevitore DEVE avviare un Inactivity Timer per quella coppia di valori RuleID e DTag. DEVE inizializzare un Attempts counter (contatore dei tentativi) a 0 per quella coppia di valori RuleID e DTag. Se il ricevitore ha risorse insufficienti per farlo, DEVE rispondere al mittente con uno SCHC Receiver-Abort (interruzione del ricevitore SCHC).

Alla ricezione di qualsiasi messaggio SCHC F/R per la coppia RuleID e DTag in elaborazione, il ricevitore DEVE resettare l'Inactivity Timer relativo a quella coppia RuleID e DTag.

Tutte le ricezioni di messaggi discusse nel resto di questa sezione devono essere intese come "corrispondenti alla coppia RuleID e DTag in elaborazione", anche se non esplicitamente indicato, per brevità.

Alla ricezione di un messaggio SCHC Fragment, il ricevitore determina quali tiles sono state ricevute, in base alla lunghezza del payload e ai campi W e FCN dello SCHC Fragment.

• se il FCN è All-1 e se è presente un Payload, il Payload completo dello SCHC Fragment DEVE essere assemblato includendo i bit di padding (riempimento). Questo perché la dimensione dell'ultima tile non è nota dal ricevitore; pertanto, i bit di padding sono indistinguibili dai bit di dati della tile, in questa fase. Verranno rimossi dal sottolivello SCHC C/D. Se la dimensione del Payload dello SCHC Fragment supera o eguaglia la dimensione di una tile regolare più la dimensione di un L2 Word, questo DOVREBBE sollevare un flag di errore.

• altrimenti, le tiles DEVONO essere assemblate in base alla dimensione della tile nota a priori.

  • Se consentito dal Profile, la fine del payload PUÒ contenere l'ultima tile, che può essere più corta. I bit di padding sono indistinguibili dai bit di dati della tile, in questa fase.

  • Il payload può contenere la penultima tile che, se consentito dal Profile, PUÒ essere esattamente di un L2 Word più piccola della dimensione della tile regolare.

  • Altrimenti, i bit di padding DEVONO essere scartati. Questo è possibile perché:

    • la dimensione delle tiles è nota a priori,

    • le tiles sono più grandi di un L2 Word, e

    • i bit di padding sono sempre strettamente inferiori a un L2 Word.

Alla ricezione di uno SCHC All-0 SCHC Fragment:

• se il ricevitore è a conoscenza di windows con tiles mancanti per il pacchetto in fase di riassemblaggio (e a seconda di determinati parametri, come le condizioni di rete, la dimensione del buffer/cache del mittente e il ritardo dell'applicazione supportato, tra gli altri), PUÒ restituire uno SCHC Compound ACK per le tiles mancanti, a partire dalla window numerata più bassa.

Alla ricezione di uno SCHC ACK REQ o di un All-1 SCHC Fragment:

• se il ricevitore è a conoscenza di windows con tiles mancanti per il pacchetto in fase di riassemblaggio, DEVE restituire uno SCHC Compound ACK per le tiles mancanti, a partire dalla window numerata più bassa.

• altrimenti:

  • se ha ricevuto almeno una tile, DEVE restituire uno SCHC Compound ACK per la window numerata più alta per la quale attualmente ha tiles,

  • altrimenti, DEVE restituire uno SCHC Compound ACK per il window number 0.

Un Profile PUÒ specificare altri momenti e circostanze in cui un ricevitore invia uno SCHC Compound ACK e su quale window lo SCHC Compound ACK riporta in queste circostanze.

Alla trasmissione di uno SCHC Compound ACK, il ricevitore DEVE aumentare l'Attempts counter.

Dopo aver ricevuto un All-1 SCHC Fragment, un ricevitore DEVE verificare l'integrità dello SCHC Packet riassemblato almeno ogni volta che si prepara a inviare uno SCHC Compound ACK per l'ultima window.

Alla ricezione di uno SCHC Sender-Abort, il ricevitore PUÒ uscire con una condizione di errore.

Alla scadenza dell'Inactivity Timer, il ricevitore DEVE inviare uno SCHC Receiver-Abort, e PUÒ uscire con una condizione di errore.

Quando l'Attempts counter supera MAX_ACK_REQUESTS, il ricevitore DEVE inviare uno SCHC Receiver-Abort, e PUÒ uscire con una condizione di errore.

Il riassemblaggio dello SCHC Packet termina quando:

• è stato ricevuto un Sender-Abort,

• l'Inactivity Timer è scaduto,

• l'Attempts counter ha superato MAX_ACK_REQUESTS, o

• è stato ricevuto almeno un All-1 SCHC Fragment e il controllo dell'integrità dello SCHC Packet riassemblato ha successo.

Vedere la Figura 44 di RFC 8724 per uno tra diversi esempi possibili di una Finite State Machine (macchina a stati finiti) che implementa un comportamento del ricevitore conforme a questa specifica. L'esempio fornito è inteso per corrispondere alla Finite State Machine del mittente della Figura 43.