El siguiente diagrama ilustra esta falla. Simplificaremos el diagrama, centrándose en los aspectos cruciales del reordenamiento de mensajes y el desglose del protocolo.
`` `` ``
+--------+red (reordenar)+--------+
| Remitente | ----------------------------> | Receptor |
+--------+<----------------------------+--------++
| |
| Paquete 2 (Seqnum =1) |
V ^
+--------+-------> [Red] <-------+--------++
| | | Paquete 1 (Seqnum =0)
| Paquete 1 (Seqnum =0) |
+--------+-------> [Red] <-------+--------++
+-----------------++-----------------++
| Acciones del remitente | | Acciones del receptor |
+-----------------++-----------------++
| Envía paquete 1 | | Recibe el paquete 2 (seqnum =1) - ¡inesperado! |
| Envía paquete 2 | | (El paquete 2 está fuera de servicio, rdt3.0 no maneja esto) |
| | | El receptor está esperando la secuencia número 0. |
+-----------------++-----------------++
^ |
| (El tiempo de espera finalmente ocurre en el remitente si no se recibe ACK) |
| V
| Paquete de retransmites de remitente 1 | El receptor finalmente recibe el paquete 1 (seqnum =0), pero aún potencialmente problemático debido a duplicaciones si se perdió ACK.
`` `` ``
Explicación:
1. remitente: Envía el paquete 1 (seqnum =0) y el paquete 2 (seqnum =1).
2. Red: La red reordera los paquetes, entregando el paquete 2 antes del paquete 1 al receptor.
3. receptor: El receptor espera el paquete 1 (seqnum =0) pero recibe el paquete 2 (seqnum =1). El diseño de RDT3.0 dicta que descartará el paquete 2 porque no es el número de secuencia esperado. No enviará un ACK para el paquete 2 porque está fuera de servicio.
4. Falla: El remitente se desprende de un ACK para el paquete 1 (o posiblemente el paquete 2 dependiendo de la implementación del tiempo de espera). Se retransmite, lo que lleva a una duplicación potencial en el receptor. El receptor podría tener problemas para procesar los paquetes duplicados y secuenciar correctamente los eventos si no se implementó un mecanismo para lidiar con esto.
Punto crucial: RDT3.0 se basa en la red subyacente para entregar paquetes en el orden que fueron enviados. Si la red reordera los paquetes, el mecanismo de reconocimiento simple del protocolo se rompe, lo que resulta en una entrega de datos poco confiable. Para manejar la entrega fuera de orden, sería necesario un protocolo más sofisticado (como el mecanismo de ventana deslizante de TCP o un protocolo diseñado explícitamente para manejar el reordenamiento).