Fundamentos de los Protocolos de Transferencia de Datos Fiables (RDT)

Protocolos de Transferencia de Datos Fiables (RDT)

rdt1.0: Canal Ideal

Se define como un canal 100 % fiable donde no existen errores de bits ni pérdida de paquetes. El receptor puede recibir datos a cualquier velocidad y no requiere notificar al emisor; por tanto, no se utilizan asentimientos.

Protocolos ARQ (Automatic Repeat Request)

Se basan en la retransmisión automática de unidades de datos erróneas. Para gestionar la presencia de errores de bits, se requieren tres capacidades adicionales:

• Detección de errores: Mediante información redundante (checksum).
• Asentimientos explícitos: Realimentación del receptor al emisor mediante ACK (para paquetes no corruptos) y NAK (para paquetes corruptos).
• Retransmisión: Procedimiento para la corrección de errores (corrección hacia atrás) mediante el protocolo Stop-and-Wait (parada y espera).

rdt2.0: Canal con Errores de Bits

Diseñado para un canal no fiable con errores de bits, pero sin pérdida de paquetes. Implementa la fiabilidad mediante checksum, Stop-and-Wait y ARQ.

rdt2.1: Gestión de Paquetes Corruptos

Versión mejorada de rdt2.0 que posibilita la gestión de paquetes ACK/NAK corruptos mediante números de secuencia en los paquetes de datos. Requiere un campo de control para el número de secuencia (basta con un bit en Stop-and-Wait). El receptor está capacitado para detectar paquetes de datos duplicados.

rdt2.2: Optimización sin NAK

Versión mejorada de rdt2.1 que soluciona el problema de los paquetes duplicados eliminando el uso de NAK y empleando sólo paquetes ACK. El ACK incluye el número de secuencia del paquete de datos que se está confirmando; los ACK repetidos producen el mismo efecto que un NAK.

• Receptor: Añade número de secuencia a los ACK y descarta paquetes duplicados.
• Emisor: Comprueba el número de secuencia de los ACK recibidos.

rdt3.0: Gestión de Pérdida de Paquetes

Versión mejorada de rdt2.2 diseñada para un contexto real donde los canales pueden corromper y perder paquetes (tanto de datos como de control). Dado que en rdt2.2 el emisor no detecta la pérdida, este protocolo añade dos funciones críticas para el emisor: detectar la pérdida de paquetes y gestionar dicha pérdida.