ACK
Ahora debemos lidiar con el problema principal de evitar que el emisor sature al receptor enviando tramas a una
mayor velocidad de la que este último puede procesarlas. Esta situación puede ocurrir con facilidad en la práctica,
por lo que es de extrema importancia evitarla. Sin embargo, aún existe el supuesto de que el canal está libre de
errores y el tráfico de datos sigue siendo simplex.
Una solución es construir un receptor lo suficientemente poderoso como para procesar un flujo continuo de tramas,
una tras otra sin interrupción (lo equivalente sería definir la capa de enlace de modo que fuera lo bastante lenta
como para que el receptor pudiera mantenerse a la par). Debe tener suficiente capacidad en el búfer y de
procesamiento como para operar a la tasa de transmisión de la línea; asimismo debe ser capaz de pasar las tramas
que se reciben en la capa de red con la rapidez suficiente. Sin embargo, ésta es una solución para el peor de los
casos. Requiere hardware dedicado y se pueden desperdiciar recursos si el enlace se usa poco. Además, sólo cambia
el problema de tratar con un emisor demasiado rápido a otra parte; en este caso, a la capa de red.
Una solución más general para este dilema es hacer que el receptor proporcione retroalimentación al emisor. Tras
haber pasado un paquete a su capa de red, el receptor regresa al emisor una pequeña trama ficticia que, de hecho,
autoriza al emisor para que transmita la siguiente trama. Después de enviar una trama, el protocolo exige que el
emisor espere hasta que llegue la pequeña trama ficticia (es decir, la confirmación de recepción). Este retraso es un
ejemplo simple de un protocolo de control de flujo.
Los protocolos en los que el emisor envía una trama y luego espera una confirmación de recepción antes de
continuar se denominan de parada y espera.
El canal de comunicación entre las dos capas de enlace de datos necesita tener capacidad de transferencia de
información bidireccional. Sin embargo, este protocolo implica una alternancia estricta de flujo: primero el emisor
envía una trama, después el receptor envía una trama, después el emisor envía otra trama, luego el receptor envía
otra, y así sucesivamente. Aquí sería suficiente un canal físico semidúplex.
Al igual que en el protocolo 1, el emisor comienza obteniendo un paquete de la capa de red, lo usa para construir
una trama y enviarla a su destino. Sólo que ahora, a diferencia del protocolo 1, el emisor debe esperar hasta que
llegue una trama de confirmación de recepción antes de reiniciar el ciclo y obtener el siguiente paquete de la capa
de red. La capa de enlace de datos emisora ni siquiera necesita inspeccionar la trama entrante, ya que sólo hay una
posibilidad. La trama entrante siempre es de confirmación de recepción.
El protocolo 1 (utopía) provee la transmisión de datos en una sola dirección, del emisor al receptor. Se supone que el
canal de comunicación está libre de errores, y que el receptor es capaz de procesar todas las entradas a una rapidez
infinita. En consecuencia, el emisor se mantiene en un ciclo, enviando datos a la línea tan rápido como puede.
El protocolo 2 (parada y espera) también provee un flujo unidireccional de datos del emisor al receptor. Se da por hecho
nuevamente que el canal de comunicación está libre de errores, como en el protocolo 1. Sin embargo, esta vez el receptor
tiene capacidad finita de búfer y capacidad finita de procesamiento, por lo que el protocolo debe evitar de manera
explícita que el emisor sature al receptor con datos a una mayor velocidad de la que pueda manejar.
NACK
Ahora consideremos la situación normal de un canal de comunicación que comete errores. Las tramas pueden llegar
dañadas o se pueden perder por completo. Sin embargo, suponemos que, si una trama se daña en tránsito, el
hardware del receptor detectará esto cuando calcule la suma de verificación. Si la trama está dañada de tal manera
que pese a ello la suma de verificación sea correcta (una ocurrencia muy poco probable), este protocolo (y todos los
demás) puede fallar (es decir, tal vez entregue un paquete incorrecto a la capa de red).
A primera vista puede parecer que funcionaría una variación del protocolo 2: agregar un temporizador. El emisor
podría enviar una trama, pero el receptor sólo enviaría una trama de confirmación de recepción si los datos llegaran
correctamente. Si llegara una trama dañada al receptor, se desecharía. Después de un tiempo el temporizador del
emisor expiraría y éste enviaría la trama otra vez. Este proceso se repetiría hasta que la trama por fin llegara intacta.
Pero el esquema anterior tiene un defecto fatal. Para ver lo que puede resultar mal, recuerde que el objetivo de la
capa de enlace de datos es proporcionar una comunicación transparente y libre de errores entre los procesos de las
capas de red. La capa de red de la máquina A pasa una serie de paquetes a su capa de enlace de datos, la cual debe
asegurar que se entregue una serie de paquetes idénticos a la capa de red de la máquina B a través de su capa de
enlace de datos. En particular, la capa de red en B no tiene manera de saber si el paquete se perdió o duplicó, por
lo que la capa de enlace de datos debe garantizar que ninguna combinación de errores de transmisión, por
improbables que sean, pudiera causar la entrega de un paquete duplicado a la capa de red.
Sin duda, lo que se necesita es alguna manera de que el receptor sea capaz de distinguir entre una trama que está
viendo por primera vez y una retransmisión. La forma evidente de lograr esto es hacer que el emisor ponga un
número de secuencia en el encabezado de cada trama que envía.
Como el protocolo debe ser correcto y es probable que el campo de número de secuencia en el encabezado sea
pequeño como para poder usar el enlace en forma eficiente el encabezado podría proveer 1 bit, unos cuantos bits, 1
byte o varios bytes para un número de secuencia, dependiendo del protocolo.
Si la trama m se pierde o se daña, el receptor no confirmará su recepción y el emisor seguirá tratando de enviarla.
Una vez que la trama se reciba correctamente, el receptor regresará una confirmación de recepción al emisor. Es
aquí donde surge el problema potencial. Dependiendo de si el emisor recibe correctamente la trama de
confirmación de recepción o no. La única ambigüedad es entre una trama y su antecesor o sucesor inmediato, no
entre el antecesor y el sucesor.
Por lo tanto, basta con un número de secuencia de 1 bit (0 o 1). En cada instante, el receptor espera un número de
secuencia en particular. Cuando llega una trama que contiene el número de secuencia correcto, se acepta y se pasa a
la capa de red, para después confirmar su recepción. Luego, el número de secuencia esperado se incrementa módulo
2 (es decir, 0 se vuelve 1 y 1 se vuelve 0). Cualquier trama que llegue y que contenga el número de secuencia
incorrecto se rechaza como duplicada. Sin embargo, la última confirmación de recepción válida se repite de modo
que el emisor pueda descubrir en un momento dado que se recibió la trama.
Los protocolos en los que el emisor espera una confirmación de recepción positiva antes de avanzar al siguiente
elemento de datos se conocen comúnmente como ARQ (Solicitud Automática de Repetición)
0
