Practica 09
Michael Cruz
Joshua Mendoza
inversión de bits? (que lidia el checksum con)?
En el tercer punto, eso se envía al servidor que va a hostear los
archivos? (así como decirle en que ruta meter el archivo que va a
enviar? y como especificas el nombre del archivo que vas a enviar?)
En el quinto, es obligatorio que el server no responda nada? Ni por
ejemplo, ACKs?
On Nov 10, 2:08 pm, Michael Cruz <dja...@gmail.com> wrote:
> Practica 09 lista.
David Flores-Peñaloza
La idea de la práctica es que implementen un protocolo de trransmisión confiable tipo stop and wait que lidie con:
1.- inversiones de bits.
2.- extravío y retraso de paquetes.
3.- Entrega de paquetes en desorden. (Mucho ojo: recuerden que esto podemos solucionarlo usando más de un bit para el número de secuencia).
Para que sea simple, lo implementarán como una pequeña biblioteca de funciones.
Las funciones principales deben ser rdt_send() y rdt_rcv().
El programa cliente y el programa servidor usarán únicamente esas dos funciones para comunicarse de manera confiable.
La idea de escoger un servicio "tipo" megaupload es que se use una pareja cliente/servidor que requiera comunicación confiable
pero que sea muy simple. No queremos nada sofisticado en la funcionalidad de la transferencia del archivo. Esta vez el énfasis es en
el protocolo de transmisión confiable.
Habiendo dicho lo anterior, contesto tus preguntas.
El 10/11/2011, a las 18:18, Joshua Mendoza escribió:
> En el segundo punto, lo de corrección de errores no te refieres a la
> inversión de bits? (que lidia el checksum con)?
UDP sí tiene detección de bits mediante un checksum. Pero es mejor que lo implementen de manera independiente haciendo ustedes su propio
checksum. Es más didáctico y la detección de errores en todas las capas de red es una buena práctica.
>
> En el tercer punto, eso se envía al servidor que va a hostear los
> archivos? (así como decirle en que ruta meter el archivo que va a
> enviar? y como especificas el nombre del archivo que vas a enviar?)
El protocolo a nivel de aplicación puede pensarse de la siguiente manera (y esto es debido a que estamos pensando en que
la funcionalidad del intercambio de archivo es minimalista y su único propósito es comprobar los servicios de transporte confiable):
1.- El cliente envía el nombre del archivo y un caracter de nueva línea.
2.- El cliente envía la longitud del archivo (en bytes) y una nueva línea.
3.- El cliente envía el contenido del archivo y termina.
(El cliente sólo usa rdt_snd() para enviar los mensajes).
Es decir, el flujo de bytes para un archivo cuyo contenido es "hola" y cuyo nombre es "hola.txt" podría ser:
""""hola.tx
5
hola"""
1'.- El servidor, al iniciar, espera un flujo de bytes con el formato anterior (usando múltiples invocaciones de rdt_rcv()),
crea el archivo especificado, escribe su contenido y termina. (El comportamiendo tan simple es para ayudar a que el protocolo de aplicación sea simple).
>
> En el quinto, es obligatorio que el server no responda nada? Ni por
> ejemplo, ACKs?
>
La funcionalidad de transferencia de archivo no debe enviar nada. La funcionalidad de transporte confiable ( rdt_rcv() ) SÍ debe enviar ACK's.
Espero que ahora sea mucho más clara la práctica. Si hay dudas escriban. Recuerden, el énfasis es en la trasmisión confiable, no en el "protocolo de aplicación".
Saludos,
David.