Estaba estudiando la FSM del receptor y vi algo que me llamó la atención:
Se agregó un timer que al expirar activa el reenvío del ACK. Por lo que pude entender, sustituye la transición ocasionada por recibir un paquete corrupto (ya se maneja el caso de recibir un paquete con seq# correcto e incorrecto).
La pregunta es: Por qué se tomó este camino? No entiendo por qué sería necesario un timer en receptor si el emisor ya está controlando esos casos. Tampoco veo que exista algún evento en el que le interese esperar, es decir, la letra no dice nada de que deba existir cierto throughput, o que deba existir una especie de keep alive por parte del receptor.
También son confusos los estados, entiendo que debería esperar por paquetes con seq# 0 o 1, pero no por ACKs.
Agrego letra del ejercicio y captura de la solución:
mediante un canal de broadcast. Dicho canal puede perder o corromper paquetes (por ejemplo, un
paquete enviado por A puede ser recibido correctamente por B pero no por C). Diseñe un
protocolo basado en el rdt 3.0 visto en el curso que permita la transferencia de datos confiable
desde a A a B y C, de forma tal que A no acepte nuevos datos de la capa superior hasta
asegurarse que tanto B como C han recibido correctamente el paquete actual.
