Alvaro Nortes Garca

F Miguel Lpez-Navarro Alcalde

Practica de Redes de Comunicaciones.
Implementacin de protocolos confiables 2013/14.
Introduccin.
asdf
Decisiones de implementacin del emisor.
Teniendo en cuenta el autmata diseado en la anterior entrega hemos implementado el emisor
teniendo en cuenta las siguientes condiciones:
El emisor es el que enva en primera instancia la peticin al cliente, por lo tanto es el que
inicia la conexin confiable.
El emisor no puede ms que esperar una confirmacin de su peticin antes de hacer cual
quier otra cosa.
!na ve" establecida la conexin puede tanto enviar como recibir datos, pero siempre me
diante peticiones que el efect#a.
El emisor no puede cerrar la conexin antes de haber enviado o recibido todos los mensa
$es que ha solicitado o enviado anteriormente.
%unque en primer lugar el diseo del autmata era ms comple$a debido a las fases de conexin &
desconexin 'se hacan en tres & cuatro fases anteriormente( ms adelante decidimos simplificarlo
porque pensamos que conceptualmente era mu& similar & sin embargo simplificaba mucho la im
plementacin.
El emisor inicia una conexin confiable. )ara esto, mediante el m*todo connect, se enva
un segmento de sincroni"acin a servidor para ello se vale de la direccin +) del servidor 'pasada
como parmetro( & del puerto por el que *ste escucha 'atributo de la clase servidor(, *ste espera a
recibir un segmento que confirme el de sincroni"acin, & entonces es cuando se puede asegurar
que la conexin ha sido establecida correctamente. ,ientras la informacin que reciba no sea la
que espera o sea corrupta se quedar bloqueado o a la espera de que salte el tempori"ador que
reenviar el segmento de sincroni"acin.
Decisiones de implementacin del receptor.
-ado que la conexin es fulld#plex, las diferencias entre la implementacin del emisor & las del
receptor son mnimas. .emos tenido en cuenta las siguientes condiciones para la implementacin
de este apartado:
El emisor espera que le llegue una solicitud de conexin & hasta entonces no puede hacer
otra cosa.
!na ve" recibe la solicitud de sincroni"acin, enva un %c/ de sincroni"acin & el receptor
da por hecho que va a tener lugar la conexin. Esto se confirmar definitivamente con el
primer mensa$e que mande el emisor, o bien recibiremos de nuevo la peticin de sincroni
"acin indicando que no ha llegado bien la confirmacin & que debemos reenviarla.
Establecida la conexin, quedamos a la espera de que el emisor enve un archivo o la peti
cin de uno.
0i recibimos una peticin de fin de conexin, no podemos en ning#n caso concluir con *sta
si no hemos acabado de emitir un archivo. Esta situacin no debe darse tericamente
Alvaro Nortes Garca
F Miguel Lpez-Navarro Alcalde
puesto que el emisor hace la misma comprobacin antes de pedir el fin de la conexin, por
tanto en ning#n caso querr terminarla si a#n le quedan cosas por enviar o recibir. %de
ms, es con *ste segmento de fin con el que se confirmaran los paquetes restantes que
pudieran quedar en la ventana de emisin del receptor la #nica causa posible de esta ex
cepcin.
1omo se ha mencionado antes, las etapas de conexin & desconexin se hacen en tres & dos fa
ses. !na ve" iniciada la conexin confiable, esperamos a la recepcin de uno de los tres coman
dos aceptados & procedemos a gestionar los paquetes que se tengan que recibir o enviar.
Detalles generales de la implementacin.
Mtodo gestionaSegmento()
1reamos *ste m*todo para poder gestionar de una manera ms sencilla todos los segmentos que
puedan recibir uno u otro host. El procedimiento anali"a el tipo de segmento. )uesto que siempre
llevar un n#mero de confirmacin, descarta los segmentos, si los hubiera de la ventana de envo,
si adems lleva datos, lo almacena en la ventana de recepcin del host. %dems lleva un parme
tro que indica si tiene que enviar una confirmacin del segmento recibido, puesto que si se estn
enviando datos, la confirmacin ir con *stos & no es necesario generar ms trfico.
Mtodo enviarEM()
El m*todo enviarE,'( se cre para solucionar el problema de la exclusin m#tua que surge de la
implementacin del Time2ut. %l saltar el tempori"ador 'que est implementado como un hilo( tiene
que reenviar el primer paquete del buffer de envo, sin embargo en este mismo punto puede ser
que se enve un paquete & se trate de aadir al mismo buffer. )ara solucionar esto declaramos la
funcin como synchronized & as no podr acceder ms de un hilo al mismo tiempo.
anual de usuario de las aplicaciones.
El emisor.
El emisor muestra por pantalla los mensa$es correspondientes a la fase de conexin & $usto des
pu*s muestra el men# con las posibles opciones a introducir por pantalla. Todos los archivos de
ben estar en la ruta del espacio de traba$o, & todos los ficheros se generan ah tambi*n.
El receptor.
El receptor muestra por pantalla una serie de mensa$es al comien"o que confirman la fase de co
nexin. % partir de aqu queda a la espera de informacin del emisor.