Reliable Data Transfer
Desafío: Proveer transferencia confiable (reliable) sobre un medio no confiable (unreliable)
Versión 1.0. Canal de transmisión confiable.
Supuesto fuerte, pero simple.
Sender
- Al recibir solicitud de envío, crea un paquete y envía
Receiver
- Al recibir paquete, extrae mensaje y lo pasa a aplicación
Problema: Los paquetes pueden llegar con errores
Versión 2.0. Protocolo ARQ (Automatic Repeat reQuest)
- Detección de errores. Envía checksums.
- Paquetes de feedback. ACK (acknowledgment) y NAK (negative ACK)
- Retransmisiones.
¿ACK o NAK con errores? El sender no sabe si el receiver recibió correctamente o no.
- ¿Retransmitir al recibir un ACK o NAK corrupto? Pueden llegar duplicados.
Versión 2.1. Agregar un sequence number. Por ahora, 1-bit.
Versión 2.2. Podemos eliminar los NAK. Cada ACK adjunta el sequence number
¿Y si se pierden paquetes?
Versión 3.0. Timeout para retransmisión en el sender.
Funcionamiento sin pérdida. (b) Con un paquete perdido
Funcionamiento con ACK perdido. (d) Con un timeout prematuro
Protocolos mandan de un paquete a la vez (stop and wait). Se envían varios paquetes simultáneos en modo pipelined.
Se necesitan más características.
- Números de secuencia deben ser incrementales
- Tanto emisor como receptor necesitan buffers
- Dos enfoques para manejar paquetes: Go-Back-N, Selective Repeat
Go-back-N
- Emisor puede mantener hasta $N$ paquetes sin ACK
- Receptor envía ACK por el último paquete recibido correctamente
- Emisor usa timer para paquete más antiguo sin ACK
- Si el timer expira, se retransmite todo el grupo de paquetes sin ACK
base
es el paquete más antiguo que aún no tiene ACKnextseqnum
es el próximo número de secuencia a usarN
es un window size. También se conoce como sliding window protocol
- Ejemplo con
N=4
Selective Repeat
- Emisor puede mantener hasta $N$ paquetes sin ACK
- Receptor envía ACK para cada paquete individual
- Emisor usa timer para paquete más antiguo sin ACK
- Si el timer expira, se retransmite solo paquetes sin ACK