Duda Practica 9
juanciencias
dices que debemos implementar un protocolo tipo stop and wait que
lidie con inversion de bits, paquetes perdidos y con paquetes llegados
fuera de orden, mi duda es acerca de esta ultima, tengo entendido que
stop and wait envia un paquete y no puede enviar otro hasta no haber
recibido un ack del paquete antes enviado, entonces de esta manera no
se tendría paquetes en desorden, es correcto?
Ahora me confunde el hecho de que tenemos que utilizar sockets UDP
para el envio de datos, el hecho de implementar el protocolo de
transmision confiable, para resolver la inversion de bits tenemos que
hacer uso del checksum o para resolver que un ack sea corrupto tenemos
que hacer uso de numeros de secuencia, estos datos el checksum y
numero de secuencia tienen que ser enviados mediante el socket UDP?
David Flores-Peñaloza
El 14/11/2011, a las 12:36, juanciencias escribió:
> Hola tengo una duda con las especificaciones de la practica,
>
> dices que debemos implementar un protocolo tipo stop and wait que
> lidie con inversion de bits, paquetes perdidos y con paquetes llegados
> fuera de orden, mi duda es acerca de esta ultima, tengo entendido que
> stop and wait envia un paquete y no puede enviar otro hasta no haber
> recibido un ack del paquete antes enviado,
Recuerda que tienes que lidiar con paquetes perdidos. Entonces debes reenviar un paquete si no se ha confirmado en un cierto
intervalo de tiempo. Eso implica que PUEDES (y en estos casos debes) enviar un paquete, aún cuando no hayas recibido su confirmación.
> entonces de esta manera no
> se tendría paquetes en desorden, es correcto?
Considera el siguiente escenario (anexo figura para ilustralo):
1.- Emisor envía paquete 0.
2.- Receptor recibe y confirma paquete de (1) , pero la confirmación se retrasa. Ahora el receptor espera el paquete 1.
3.- Hay timeout y el emisor reenvía paquete 0, de (1), que se retrasa también.
4.- La confirmación (2) llega al emisor.
5.- El emisor envía paquete 1.
(En este momento hay dos mensajes del emisor hacia el receptor viajando en la red: los de (3) y (5))
(Si la red pudiera entregar mensajes en orden inverso, podría entregar (5) antes de (3))
(Eso ocasionaría lo siguiente):
6.- El receptor recibe y confirma el paquete 1 de (5). Ahora el receptor espera el paquete 0.
7.- El receptor recibe y confirma el paquete 0 de (3).
(Este paquete tiene el número de secuencia que el receptor espera, por lo cual lo considera un paquete nuevo, y no un paquete repetido).
(En este escenario el receptor considera que ha recibido tres paquetes con datos nuevos, cuando en realidad el emisor sólo ha enviado dos!).
Si usamos un conjunto de números de secuencia suficientemente grande como para asegurar que un número de secuencia se reciclará sin
riesgo de que un paquete "viejo" con el mismo número de secuencia se haya quedado "atorado" en la red, entonces podemos lidiar con
la entrega de mensajes fuera de orden.
David Flores-Peñaloza
El 14/11/2011, a las 12:36, juanciencias escribió:
Por cierto, dejen la implementación del checksum al final. El checksum no es tan importante como
la implementación de la transmisión confiable. Déjenla al final por que si no acaban, es mejor que hayan
hecho la transmisión confiable sin la verificación de bits, que la verificación de bits sin la transmisión confiable.
Saludos,
David.