Duda con reinicio del temporizador en GBN

Duda con reinicio del temporizador en GBN

de Pablo Martin Baez Echevarria -
Número de respuestas: 5

Hola,

En GBN, cuando se recibe un ACK duplicado, ¿se reinicia el temporizador? La máquina de estados del libro dice que cada vez que llega un ACK y hay paquetes no reconocidos, se reinicia el temporizador. Siendo así, debe reiniciarse. Sin embargo, para mí tiene más sentido que se reinicie el temporizador sólo cuando llega un ACK reconociendo datos nuevos (o sea, cuando el ACK que llega no está duplicado).

Mi duda surge, por ejemplo, al hacer el dibujo en situaciones como la Ejercicio 9 del práctico 4. No sé si el dibujo debe ser así:

GBN como en el libro

O así:

GBN sin reiniciar temporizador en ACK duplicados

Saludos.

En respuesta a Pablo Martin Baez Echevarria

Re: Duda con reinicio del temporizador en GBN

de Juan Ramirez -

Me sumo a la consulta y agrego un detalle, porque creo que hay un error en la FSM del libro.


Según la FSM, cuando llega un ACK se ejecuta este código:

base=getacknum(rcvpkt)+1
If(base==nextseqnum)
   stop_timer
else
   start_timer


Como ACKs son acumulativos, se puede setear la base con el nro de ACK que viene en el mensaje, porque se podría tratar de un ACK mas viejo, con un número de secuencia menor.


Por lo tanto, se debería controlar que la base sea menor al nro de ACK para setear la variable, algo así:

base=max(base, getacknum(rcvpkt)+1)
If(base==nextseqnum)
   stop_timer
else
   start_timer


Por lo demás, obviando el detalle de la pregunta del compañero, entiendo que está bien: tiene sentido reiniciar el timer cada vez que se recibe un ACK nuevo porque el timer es único (no se tiene timer independiente como en selective-repeat), y obviamente no se necesita el timer si todo lo enviado fue ACK'ed.


En respuesta a Juan Ramirez

Re: Duda con reinicio del temporizador en GBN

de Pablo Martin Baez Echevarria -

Me parece que el detalle que señalas sólo sería necesario si el canal puede reordenar paquetes. Creo que el libro asume implícitamente que el canal no reordena paquetes (por ejemplo, la FSM de rdt 3.0 sería incorrecta si el canal reordenara).

Bajo la hipótesis de que el canal no reordena, la secuencia de números de ACKs que recibe el receptor es creciente entonces

 

getacknum(rcvpkt) >= base-1

por tanto ese máximo creo que no haría falta. El peor escenario sería que el número de ACK sea uno menos que el de la base (porque en ese caso al sumarle 1, no se avanza la ventana), pero no puede darse el caso de que se reciba un ACK menor que base-1 (asumiendo siempre que el canal no reordena).
En respuesta a Pablo Martin Baez Echevarria

Re: Duda con reinicio del temporizador en GBN

de Juan Ramirez -

Aja, si, tenés razón, va por ese lado. 


Un detalle interesante: el receptor no tiene ningún problema si el canal le reordena los paquetes, porque descarta lo que llegue desordenado, seguramente pensado solo por pérdida de paquetes pero ya funciona para esto (idem con SR, que se los guarda).



En respuesta a Pablo Martin Baez Echevarria

Re: Duda con reinicio del temporizador en GBN

de Matias Richart -

Buenas.

Entiendo tu duda y puede que lo que planteas sea una mejora interesante al algoritmo. Así como podría ser usar la llegada de ACKs duplicados para detectar un problema.

Sin embargo, vamos a regirnos por como está planteado el protocolo en el libro. (Cuidado que en la edición en español falta la sentencia iniciar_temporizador dentro del else)

El protocolo GBN es un caso particular de los protocolos de ventana deslizante y tiene un objetivo meramente educativo. El objetivo es introducir algunos conceptos para luego poder entender mejor los protocolos mas complicados como puede ser el protocolo de entrega confiable que implementa TCP.

Saludos