# Protocol de finestra lliscant

Un protocol de finestra lliscant és una característica dels protocols de transmissió de dades basats en paquets. Els protocols de finestra lliscant s'utilitzen quan cal un lliurament fiable de paquets en ordre, com ara a la capa d'enllaç de dades (capa OSI 2), així com al Protocol de control de transmissió (TCP). També s'utilitzen per millorar l'eficiència quan el canal pot incloure una latència elevada.
Els sistemes basats en paquets es basen en la idea d'enviar un lot de dades, el paquet, juntament amb dades addicionals que permeten al receptor assegurar-se que s'ha rebut correctament, potser una suma de verificació. El paradigma és semblant a una finestra lliscant lateralment per permetre l'entrada de paquets nous i rebutjar els que ja s'han reconegut. Quan el receptor verifica les dades, envia un senyal de reconeixement, o "ACK", al remitent per indicar que pot enviar el següent paquet. En un simple protocol de petició de repetició automàtica (ARQ), l'emissor s'atura després de cada paquet i espera que el receptor ACK. Això garanteix que els paquets arribin en l'ordre correcte, ja que només se'n pot enviar un a la vegada.El temps que triga a rebre el senyal ACK pot representar una quantitat de temps important en comparació amb el temps necessari per enviar el paquet. En aquest cas, el rendiment global pot ser molt inferior al possible teòricament. Per solucionar-ho, els protocols de finestra lliscant permeten enviar un nombre seleccionat de paquets, la finestra, sense haver d'esperar un ACK. Cada paquet rep un número de seqüència i els ACK envien aquest número. El protocol fa un seguiment de quins paquets han rebut l'ACK i, quan es reben, envia més paquets. D'aquesta manera, la finestra llisca al llarg del flux de paquets que formen la transferència.
Les finestres corredisses són una part clau de molts protocols. És una part clau del protocol TCP, que permet de manera inherent que els paquets arribin fora d'ordre, i també es troba en molts protocols de transferència de fitxers com UUCP-g i ZMODEM com una manera de millorar l'eficiència en comparació amb protocols sense finestra com XMODEM. Vegeu també SEAlink.

## Concepte bàsic

Conceptualment, a cada part de la transmissió (paquets a la majoria de les capes d'enllaç de dades, però bytes en TCP) se li assigna un número de seqüència consecutiu únic i el receptor utilitza els números per col·locar els paquets rebuts en l'ordre correcte, descartant els paquets duplicats i identificant els que falten. El problema amb això és que no hi ha límit en la mida del número de seqüència que es pot requerir.
En posar límits al nombre de paquets que es poden transmetre o rebre en un moment donat, un protocol de finestra lliscant permet comunicar un nombre il·limitat de paquets mitjançant números de seqüència de mida fixa. El terme "finestra" al costat del transmissor representa el límit lògic del nombre total de paquets que encara no han reconegut el receptor. El receptor informa al transmissor en cada paquet d'avís de la mida màxima actual del buffer del receptor (límit de la finestra). La capçalera TCP utilitza un camp de 16 bits per informar de la mida de la finestra del receptor al remitent. Per tant, la finestra més gran que es pot utilitzar és 2$^{16}$ = 64 kilobytes.

## Motivació

En qualsevol protocol de comunicació basat en la sol·licitud de repetició automàtica per al control d'errors, el receptor ha d'acusar els paquets rebuts. Si el transmissor no rep un reconeixement en un temps raonable, torna a enviar les dades.

## Funcionament del protocol

El transmissor i el receptor tenen cadascun un nombre de seqüència actual n$_t$ i n$_r$, respectivament. Cadascun també té una mida de finestra w$_t$ i w$_r$. Les mides de la finestra poden variar, però en implementacions més senzilles es fixen. La mida de la finestra ha de ser superior a zero perquè es pugui fer qualsevol progrés.
Tal com s'implementa habitualment, n$_t$ és el següent paquet a transmetre, és a dir, el número de seqüència del primer paquet que encara no s'ha transmès. De la mateixa manera, n$_r$ és el primer paquet encara no rebut. Ambdós nombres augmenten monòtonament amb el temps; només augmenten.
El receptor també pot fer un seguiment del número de seqüència més alt encara rebut; la variable n$_s$ és un més que el número de seqüència del número de seqüència més alt rebut. Per als receptors simples que només accepten paquets en ordre (w$_r$ = 1), això és el mateix que n $_r$, però pot ser més gran si w$_r$ > 1. Tingueu en compte la distinció: s'han rebut tots els paquets per sota de n$_r$, no s'han rebut cap paquet per sobre de n$_s$ i entre n$_r$ i n$_s$ s'han rebut alguns paquets.
Quan el receptor rep un paquet, actualitza les seves variables adequadament i transmet un reconeixement amb el nou n$_r$. El transmissor fa un seguiment del reconeixement més alt que ha rebut n$_a$. El transmissor sap que s'han rebut tots els paquets fins a, però sense incloure n$_a$, però no està segur sobre els paquets entre n$_a$ i n$_s$ ; és a dir , n$_a$ ≤ n$_r$ ≤ n$_s$.
* n$_a$ ≤ n$_r$ : el reconeixement més alt rebut pel transmissor no pot ser superior al n$_r$ més alt reconegut pel receptor.
* n$_r$ ≤ n$_s$ : l'abast dels paquets totalment rebuts no pot estendre's més enllà del final dels paquets parcialment rebuts.
* n$_s$ ≤ n$_t$ : el paquet més alt rebut no pot ser superior al paquet més alt enviat.
* n$_t$ ≤ n$_a$ + w$_t$ : el paquet més alt enviat està limitat per l'avís de recepció més alt rebut i la mida de la finestra de transmissió.

## Referències

* ↑ «Sliding Window Protocol: Complete Step-by-Step Guide | Simplilearn» (en anglès americà). [Consulta: 11 novembre 2023].
* ↑ «Sliding Window Protocol | Set 1 (Sender Side)» (en anglès americà), 13-12-2016. [Consulta: 11 novembre 2023].
* ↑ «Sliding Window Protocol - javatpoint» (en anglès). [Consulta: 11 novembre 2023].
* ↑ «Sliding Window Protocol - Studytonight» (en anglès). [Consulta: 11 novembre 2023].