Especificacion de Un Protocolo 0.92

Teora de un protocolo
UNIVERSIDAD NACIONAL DE MISIONES

FACULTAD DE CIENCIAS EXACTAS, QUMICAS Y NATURALES
TEMA: Teora de un protocolo
CTEDRAS: Computacin 3 Profesor: Ingeniero Castao Ruben.
ALUMNO: Kornuta Cristian LEG:991511 LS00069
MSN: C27205533@hotmail.com
5 de Abril del 2007
INDICE
INTRODUCCIN: CONSIDERACIONES DEL JUEGO QUE ES UN PROTOCOLO? LA SINTAXIS, SEMNTICA, TEMPORIZACION CARACTERSTICAS DE UN PROTOCOLO:
EL MODELO OSI PRINCIPIO DE DISEO EL MODELO TCP/IP
CAPA DE INTERRED CAPA DE TRANSPORTE CAPA DE APLICACIN CAPA DE RED
DIAGRAMA DE ESTADO (Nuevo). ALGO SOBRE LA APLICACIN FORMATO DE MENSAJE TAMANO DE LOS CAMPOS SIGNIFICADO DE LOS DIFERENTES CAMPOS
ESPECIFICACIONES DE LOS FORMATOS DE MENSAJES DE LA APLICACIN
CABECERA DE TRANSPORTE SEPARADOR DE CAMPO DE CABECERA DE TRANSPORTE Y NUMERO DE PAQUETE NUMERO DE PAQUETE SEPARADOR DE CAMPO DE NUMERO DE PAQUETE Y BANDA DE CONFIRMACION BANDA DE CONFIRMACION SEPARADOR DE PARTE TRANSPORTE Y APLICACION CAMPO CABECERA DE APLICACIN SEPARADOR DE CABECERA DE APLICACIN Y DATO DE APLICACION DATO DE APLICACION
FORMATO DE MENSAJE ANTES DE SER ENVIADOS

AGREGAR CAMPOS DE TRASPORTE Y SEPARADOR DE TRASPORTE Y MENSAJE DE APLICACION
MENSAJE DE APLICACON ENCRYPTACION Y RRELLENO (Nuevo). MENSAJE FINAL A SER ENVIADO
DETALLE DE LAS ESPECIFICACIONES PUERTO DE COMUNICACION TEMPORIZADORES ORDEN DE PAQUETE DE LLEGADA DE LOS PAQUETES TAMAO DE VENTANA MENSAJES DE CONFIRMACION DE LLEGADA ESTABLECER CONEXION
ATENCION MENSAJE DE SOLICITUD DE PARTIDA, CON EL CAMPO ARK EN 1
CERRAR CONEXION CAIDA DEL SISTEMA MENSAJE RECHAZADO!, Pero si era un mensaje con el formato de la aplicacion ? Sld_Retrasmicion. MENSAJE DE CHAT QUIEN COMIENZA LA PARTIDA? ORDEN DE TURNO DE JUGADA EL TABLERO DE JUEGO COLOCACIN DE LAS FICHAS ALEATORIAS
UN POCO DE AYUDA Procedimientos de colocacion de la celdas aleatorias ERROR AL VERIFICAR LAS CELDAS COLOCADAS ALEATORIAMENTE Error_Recepcion_Fichas_Aleatorias (Nuevo).
TIPOS DE ERRORES AL RECIBIR LAS FICHAS ALEATORIAS (Nuevo). SE RECIBIR UNA SERIE DE FICHAS MENOS QUE LAS 8 O MAYORES (Nuevo). NO SE HAN RECIBIDOS LAS 4 FICHAS VISITANTES O LAS TRES LOCAL (Nuevo). CON LAS FICHAS ENVIADAS GENERAS TATETI (Nuevo).
HASTA CUANTAS VECES EL SERVIDOR O EL CLIENTE SE ENCONTRARAN PERSEVERANDO EN ESTE ERROR ? (Nuevo). EL PORQUE DE CELDAS ORIGEN Y DESTINO? MOVIMIENTOS DE FICHAS RECEPCION DE UNA CELDA DE POSICION NO VALIDA POSICION_INCORRECTA (Nuevo).
INTERFASE DE USUARIO
INICIANDO EL SERVIDOR
CREAR UNA NUEVA PARTIDA ATENDIENDO UNA SOLICITUD DE PARTIDA EL MENU ACERCA DE...
ALGUNAS SUGERENCIAS PARA LA IMPLEMENTACIN DE UNA NUEVA VERSIN PARA EL PROTOCOLO (Nuevo).
CANTIDAD DE MENSAJES ENVIADOS (Nuevo). LA IMPLEMENTACION DE PODER ELEGIR ENTRE UNA SERIE DE PERSONAJES (Nuevo).
UTILIZAR 6 FICHAS EN VEZ DE LAS 8 (Nuevo). SEGURIDAD (Nuevo).

SSL (Nuevo)
IMPLEMNTAR LA APLICAION PERO WEB(Nuevo) ALGUNAS BIBLIOGRAFAS SUGERIDAS (Nuevo). ERRORES QUE PUEDEN SURGIR QUE NO SON POR PARTE DEL USUARIO (Nuevo). CONCLUSIN (Nuevo).
BIBLIOGRAFA:
INTRODUCCIN:
Esta aplicacin la he desarrollado con el objetivo de poder cumplir con los requerimientos solicitados para poder promocionar la prctica de la ctedra Computacin 3 de la carrera analista en sistemas de computacin; Este documento pretende cumplir con las especificaciones del protocolo de aplicacin desarrollado. La aplicacin fue desarrollada sobre el protocolo UDP con el fin de poder desarrollar los procedimientos de control de transporte el cual no posee UDP con el objetivo de poner en prctica lo estudiado sobre los servicios brindados por la capa de transporte. De esta manera poner a prueba los diferentes escenarios que se podran presentar en la conexin, trasporte, cada de la conexin de aplicacin y cierre de conexin. Por ultimo debo aclarar que esta aplicacin se encuentra desarrollada hasta la versin que se considera que es la 0,63 Beta, con lo cual significa que no se encuentra desarrollada en su totalidad hasta una versin 1,0, el motivo por el cual se desarrollo hasta esta versin y no se continuo con el desarrollo fue por los plazo de tiempo a que se haba cumplido para la entregar. Pero de igual forma se considera que se encuentra desarrollada con todos los requisitos solicitados por la propia ctedra. Alumno: Kornuta Cristian. 5 de Abril del 2007
En la preparacin para la batalla siempre he encontrado que los planes son intiles, pero que la planificacin es indispensable. Dwight D. Eisenhower.
CONSIDERACIONES DEL JUEGO

PRACTICO: JUEGO DE TA TE TI EN RED
El juego debe respetar las reglas bsicas de TA-TE-TI. El juego se desarrollara en dos computadoras las cuales se comunicaran a travs de una red LAN con protocolos TCP/IP debidamente configurados. Cada encuentro se jugara a 3 partidas ganadas. Debindose poner de acuerdo quien realizara el movimiento inicial del encuentro. Turnndose en cada partida el jugador que inicie el movimiento. Se podr hacer TA-TE-TI alineando tres fichas del mismo color tanto en la horizontal, vertical o diagonal. Una vez colocadas las fichas en el tablero se realizaran los movimientos a posiciones contiguas no ocupadas por ninguna otra ficha. Se podr hacer Ta-Te-Ti incluso en el arranque de la partida, es decir al momento de colocar las fichas en el tablero.
SE REQUIERE:
Desarrollo de un protocolo abierto para el intercambio de mensajes las aplicaciones de juegos de Ta-Te-Ti: Maquina de Estado, Formato de Mensajes, CodOperaciones, Parmetros. Cliente grafico para el Juego de Tateti. El lenguaje de desarrollo queda a criterio del programador. Nota: El programa deber respetar el protocolo presentado en el punto 1. El protocolo de capa 4 podr ser UDP o TCP
QUE ES UN PROTOCOLO?
Algunas de las caractersticas principales que engloban a lo que se conoce como protocolo son las siguientes:
Los modos de operacin, la estructura de los mensajes, los tipos de rdenes y respuestas, constituyen las diferentes piezas constructivas del protocolo. Pueden definirse 4 funciones bsicas o primitivas de un servicio de comunicacin: 1. Solicitud: Se solicita un servicio por parte del servidor. 2. Notificacin: Se notifica a un ente de la solicitud de un servicio; Un ente es notificado de la ocurrencia de un evento. 3. Responder: Se genera una respuesta a la solicitud del servicio si se reconoce. 4. Confirmacin: Se confirma la prestacin del servicio.
LA SINTAXIS, SEMNTICA, TEMPORIZACION

datos. La sintaxis: Establece las cuestiones referidas con el formato de los bloques de
La semntica: Hace referencia a los procedimientos encargados del control de errores referidos a la trasmisin de los datos La temporizacion: Se encuentra referidos a los temas de la temporizacion de los envos de los datos y la secuencia.
CARACTERSTICAS DE UN PROTOCOLO
EL MODELO OSI
El modelo OSI presenta una arquitectura de 7 capas el cual es utilizado para crear un protocolo, las capas se presentan y detallan a continuacin:
CAPAS DEL MODELO OSI
PRINCIPIO DE DISEO
Algunas de las caractersticas o premisas a tener en cuenta al disear un protocolo pueden ser las siguientes: No establecer demasiadas capas de tal forma que las implementaciones de ellas no generen ms complicaciones que las necesarias. Las capas implementadas no deben de comunicarse un nmero muy amplio de veces. Se debe crear una capa siempre que se necesite, un nivel de abstraccin diferente. La funcin de cada capa se debe elegir de acuerdo a las especificaciones establecidas internacionalmente. La cantidad de capas deber ser suficientes, para que no tener que agrupar funciones distintas en las mismas capas y a la vez tratar que la arquitectura no se vuelva demasiado grande para que sea difcil de manejar Agrupar funciones similares en la misma capa. Crear capas las cuales se puedan implementar en su totalidad. Permitir que cambios o modificaciones se puedan llevar a cabo sin que esto afecte las otras capas o su desempeo. Para cada capa creada establecer separacin con su capa superior. Se podra de disear dentro de cada capa crear otras funciones que facilitara la creacin de tales y de esta forma establecer un mayor abstraccin entre ellas.
EL MODELO TCP/IP
Este es el protocolo utilizado en su mayora en Internet y que fue utilizado para llevar a cabo la aplicacin. Su nombre recibe por unin de palabra de sus principales protocolos primarios que se basa, los cuales son TCP (Protocolo Control Trasporte) y IP (Protocolo de Internet) presenta una serie de capas las cuales son.
Imagen1 Modelo TCP/IP
CAPA DE INTERRED
Es el eje que mantiene unida toda la arquitectura. La misin de esta capa es que los paquetes puedan ser trasmitidos por cualquier nodos, los paquetes puede llegar al receptor en un orden diferente al trasmitido y es responsabilidad de la capa superior ordenarlo y entregarlo.
CAPA DE TRANSPORTE
Permite que pares en los hosts de fuente y destino puedan conversar. Hay dos protocolos: Transmission Control Protocol (TCP). Provee una conexin confiable que permite la entrega sin errores de un flujo de bytes desde una mquina, a alguna otra en la internet. Parte el flujo en mensajes discretos y lo monta de nuevo en el destino. Maneja el control de flujo.
User Datagram Protocol (UDP). Es un protocolo no confiable y sin conexin

para la entrega de mensajes discretos. Se pueden construir otros protocolos de aplicacin sobre UDP. Tambin se usa UDP cuando la entrega rpida es ms importante que la entrega garantizada.
CAPA DE APLICACIN
Como en OSI. No se usan niveles de sesin o presentacin.
CAPA DE RED
Bajo la capa de interred existe un gran vaci. El modelo de referencia TCP/IP no dice mucho de lo que aqu realmente sucede, fuera de indicar que el nodo se ha de
10
conectar a la red haciendo uso de algn protocolo de modo que pueda enviar por ella paquetes de IP
OSI vs. TCP/IP

OSI define claramente las diferencias entre los servicios, las interfaces, y
los protocolos.
Servicio: lo que un nivel hace Interfaz: cmo se pueden accesar los servicios Protocolo: la implementacin de los servicios TCP/IP no tiene esta clara separacin. Porque OSI fue definido antes de implementar los protocolos, los
diseadores no tenan mucha experiencia con donde se debieran ubicar las funcionalidades, y algunas otras faltan. Por ejemplo, OSI originalmente no tiene ningn apoyo para broadcast. adecuan perfectamente. Pero no otras pilas de protocolos.
El modelo de TCP/IP fue definido despus de los protocolos y se OSI no tuvo xito debido a Mal momento de introduccin: insuficiente tiempo entre las
investigaciones y el desarrollo del mercado a gran escala para lograr la estandarizacin
Mala tecnologa: OSI es complejo, es dominado por una mentalidad de
telecomunicaciones sin pensar en computadores, carece de servicios sin conexin, etc.
Malas implementaciones Malas polticas: investigadores y programadores contra los ministerios

de telecomunicacin
UDP
User Datagram Protocol (UDP). Es un protocolo no confiable y sin conexin para la entrega de mensajes discretos. Se pueden construir otros protocolos de aplicacin sobre UDP. Tambin se usa UDP cuando la entrega rpida es ms importante que la entrega garantizada. Adems muchas aplicaciones utilizan este protocolo por su simpleza y utilizan esta ventaja para sobre este protocolo desarrollar sus propios protocolos de aplicacin que adems brindaran los servicios de transporte.
11
Imagen 2 Formato UDP
DIAGRAMA PROTOCOLO
DE
ESTADOS
FINITOS
DEL
El diagrama de estado finito permite representar los diferente estados que se podra encontrarse el protocolo. El diagrama de este protocolo es similar al del TCP debido a que se encarga de brindar los mismos servicios que el TCP por este motivo se utilizo el diagrama de estados finitos del TCP/IP para representar el de la aplicacin en cuestin. Cada conexin comienza en el estado CERRADO y abandona ese esta cuando recibe una solicitud, pasando al estado LISTEN, o a una conexin concreta CONECTADO. Si el otro lado realiza la accin opuesta, se establece una conexin y el estado pasa ha ESTABLECIDO. La liberacin de la conexin puede iniciarse desde cualquier de los dos lados. Al completarse el estado regresa a CLOSE. La maquina de estados finitos se muestra en la imagen 3 y los diferentes estados como as tambin su descripcin de cada uno de ellos en la tabla de abajo. El caso comn de un cliente que se conecta activamente a un servidor se indica con lneas gruesas (Contiguas para el cliente, punteadas para el servidor). Las lneas delgadas son secuencias de eventos pocos comunes Cada lnea de imagen 3 con un par de evento/ accin. El evento puede ser llamado de sistema iniciado por el usuario (Conectado, Listen, Enviar o Close) la llegada de un mensaje (ARK) o en un caso de la espiracin del doble de tiempo de vida mxima del paquete. La accin es el reenvi del mensaje con el campo ARK cambiado a 1 o nada como aparecen en los comentarios entre parntesis
12
Estados CERRADO LISTEN Solicitud_Partida Confirmacion_Solicitud Conexion_Establecida Desconexion_Aceptada Aviso_Desconexion_Simultanea Aviso_Desconexion Descripcion No hay conexin activa o pendiente. El servidor espera una llamada. Llego una solicitud de partida; Se espera confirmacin paquete enviado. La aplicacin conexin. comenz a abrir una
Estado normal de transferencia de datos. El otro lado acord terminar. Ambos lados simultneamente. intentaron comenz cerrar una
La otra aplicacin desconexin.
13
Imagen 3 Maquina de estado finitos del Protocolo

Las lineas continuas gruesas es la trayectoria normal del cliente.Las lineas punteadas gruesas es la trayectoria normal del servidor. Las lineas delgadas son eventos pocos comunes.
(Ref. James F. Kurose;Andrew S. Tanenbaum)
14
ALGO SOBRE LA APLICACIN

La aplicacin utiliza el protocolo UDP para poder comunicarse con las diferentes partes; La aplicacin posee sus propios procedimientos de control de transporte para poder lograr una comunicacin fiable. En las dos partes tanto cliente como servidor se encuentran desarrollados dentro de dos grandes grupos de procedimientos para poder cumplir con los requerimientos de la aplicacin y el poder brindar una transmisin confiable. Los dos grupos que se podran identificar como los procedientos de control de transmisin y lo de aplicacin, los cuales se encuentras desarrollados sobre la misma aplicacin se tratan de brindar una cierta abstraccin entre los dos grupos.
Imagen 3 Los dos grupos de procedimientos que poseen la aplicacion.
FORMATO DE MENSAJE
El formato de mensaje a ser enviado por la dos parte es el mismo, el cual se divide en unas series de campos como podemos apreciar en la imagen 4.
Imagen 4 Los campos que integran el formatos de el mensaje de la aplicacin.
15
TAMANO DE LOS CAMPOS

Los tamaos de los campos se expresan en caracteres por que pueden diferir si no se tratase del cdigo ASCII Vea Tanenbaun Cabecera de Transporte. Tamao en 10 caracteres Carcter de separacin de Cabecera de Transporte y Numero de paquete/. Tamao en 1 caracteres Numero de paquete. Tamao en 2 caracteres Carcter de separacin de Numero de paquete y Banda de confirmacin/. Tamao en 1 caracteres Banda de confirmacin. Tamao en 1 caracteres Carcter de separacin de Banda de confirmacin y Cabecera de aplicacin
\. Tamao en 1 caracteres
Entre la cabecera de la aplicacin y el dato de aplicacin conforman un campo de 41 Caracteres Cabecera de aplicacin. Carcter de separacin de Cabecera de aplicacin y Datos de aplicacin|. Datos de aplicacin. Un ejemplo de mensaje que podra recibir el cliente el caso de que solicite una partida y el servidor se encentre en el estado de estar jugando una partida o en el acuerdo de conexin es el de la imagen 5
Imagen 5 Un ejemplo del formato del mensaje de apliacion.
En sistencis el tamao del mensaje seria de 57 caracteres Fijos. En el cual podemos identificar los campos descriptos anteriormente que en este caso serian: Cabecera de Transporte Cbc_TATETI. Carcter de separacin de Cabecera de Transporte y Numero de paquete/. Numero de paquete 11. Carcter de separacin de Numero de paquete y Banda de confirmacin /. Bande de confirmacion 0. \. Carcter de separacion de Bande de confirmacion y Cabecera de aplicacin
16
Cabecera de aplicacin Msj_Servidor Carcter de separacin de Cabecera de aplicacin y Datos de aplicacin |. Datos de aplicacin Partida_Inciada_Servidor. Todos los mensajes que la aplicacin tanto cliente como el servidor reconocen como el anterior se divide en dos parte. La parte de transporte y la de aplicacin .La parte que corresponde a la de trasporte se puede apreciar en la imagen 6, esta ser procesada por los procedimientos de transporte
Imagen 6 Cabecera de transporte con sus diferentes canpos.
El mensaje a su vez se encuentra separado por el carcter \ que separa las partes Transporte y Aplicacin
Imagen 7 Separador de la parte Transporte y aplicacin.
La parte de aplicacin corresponde al mensaje que se enva a las parte los cuales se describen en las tablas de las especificaciones mas adelantes. Un ejemplo de este mensaje es el de la imagen 8
Imagen 8 Parte de datos de aplicacin de un mensaje con su separador de parte Cabecera aplicacin y Datos mas el relleno de caracteres para cumplir un formatos de 41 caracteres.
El cual luego formara parte del paquete del protocolo UDP con sus diferentes cabeceras que son agregados propios del mismo; El mensaje de la aplicacin formara parte del dato del paquete como podemos apreciar en la figura 9.
17
Imagen 9 Unidad del UDP el cual contendra nuestro mensaje de aplicacin en el campo dato.
SIGNIFICADO DE LOS DIFERENTES CAMPOS Y SU SIGNIFICADO

Los diferentes campos que describimos anteriormente tienen un significado para la aplicacin los cuales cumplen las funciones de interaccin entre las identidades como son el cliente y servidor y brindar un servicio de comunicacin confiable
CABECERA DE TRANSPORTE
La cabecera de aplicacin cumple con el objetivo principal de identificar un mensaje de la aplicacin en el caso de no poseer el mensaje este campo se rechazara sin enviarlo a los procedimientos de aplicacin de esta forma no congestionamos a la aplicacin con procesamientos innecesarios.
SEPARADOR DE CAMPO DE CABECERA DE TRANSPORTE Y NUMERO DE PAQUETE

Una vez agregado la cabecera de aplicacin se agregar el carcter de separacin de la cabecera de aplicacin y el numero de paquete el cual es /.
NUMERO DE PAQUETE
El numero de paquete corresponde al numero de paquete a ser enviado el cual comienza con el 10 este numero es el utilizado como valor predeterminado debido a que de esta manera podemos cumplir con los establecido con el tamao del campo numero de paquete el cual se utiliza 2 caracteres. Se a elegido este valor debido que de esta manera el rango de valores es muy amplio entre 10 99 con esto queremos evitar que se produzca un escenerario en el cual se espera una confirmacin de un paquete el cual puede ser Confirmacion_Paquete_8 este tema lo explicar mas adelante .El cual nunca llega debido a que ese paquete con numero de paquete 8 se perdi pero si llega una
18
confirmacin de un paquete numero 8 pero corresponde a una trasmisin anterior que se encontraba en la red, debido a que el rango de valores del campo numero de paquete era pequeo, y el flujo de paquete es amplio (En este caso no).No se dio el tiempo para que el paquete sea eliminado de la red. Por lo tanto nunca la otra parte recibi el paquete. Con esto logramos que esto no se cumpla (Ref. James F. Kurose).
SEPARADOR DE CAMPO DE NUMERO DE PAQUETE Y BANDA DE CONFIRMACION

campo. Este carcter cumple la misma funcin que el carcter anterior de separacin de
BANDA ARK
La banda ARK se utiliza para informar a la aplicacin receptora que este mensaje fue enviado anteriormente pero no se a recibido confirmacin por este motivo se a vuelto a enva. Para lo cual se cambio el valor de este campo a 1 para identificar que este mensaje corresponde a un mensaje enviado anteriormente. En el caso de ser enviado por primera vez el valor por defecto es el 0 (Ref. Andrew S. Tanenbaum).
SEPARADOR DE PARTE TRANSPORTE Y APLICACIN

Este carcter difiere de los dos anteriores porque cumple la funcin de dividir el mensaje en dos parte la parte de transporte la que ser procesada por los procedimientos de transporte y la parte de aplicacin que por su parte sern procesador por los procedimientos de aplicacin.
CAMPO CABECERA DE APLICACIN

El campo cabecera de aplicacin corresponde a una (Categora) dentro del procedimientos encargado de procesar los mensaje de la aplicacin en la tabla de especificaciones de encuentra en la primer columna. Este campo deber de ser acompaado siempre del dato de la aplicacin.
SEPARADOR DE CABECERA DE APLICACIN Y DATO DE APLICACIN

El separador de Los campos de aplicacin se utiliza para dividir los dos campos el de cabecera de aplicacin el cual es el mensaje de la primera columna de la las especificaciones mas el mensaje de la segunda columna de las especificaciones los cuales se encontraran divididos por el carcter |.Un ejemplo de esto es el siguiente Msj_Servidor|Partida_Iniciada
19
DATO DE APLICACIN
El dato de aplicacin corresponde al valor de la segunda columna de las especificaciones
FORMATO DE MENSAJE ANTES DE SER ENVIADOS

El mensaje de la aplicacin ante de ser enviado se debe cumplir con unos pasos previos los cuales son
MENSAJE DE APLICACON RRELLENADO

La parte del mensaje que corresponde a la aplicacin como el ejemplo anterior Msj_Servidor|Partida_Iniciada Deber de ser encriptado previamente ante de ser enviado por el siguiente algoritmo el cual se encuentra codificado en visual Basic por su facilidad de lectura de el cdigo Este cdigo corresponde a un algoritmo de sustitucin debido a que presenta un buen equilibrio en cuanto a complejidad de implementacin y el grado de encriptacin (Ref. Andrew S. Tanenbaum).
En desarrollo
Una vez cumplido este paso se debe rellena esta parte del mensaje con el siguiente carcter el espacio en blanco para poder cumplir con el tamao del campo que es de 41 caracteres (Ref. Stalling)
MENSAJE FINAL A SER ENVIADO

Por ultimo un ejemplo de mensaje a ser enviado podra ser el siguiente
Imagen 1 0 Ejemplo de un mensaje de la aplicacion
20
ESPECIFICACIONES DE MENSAJES DE LA APLICACIN
LOS
FORMATOS
DE
La tabla detalla y describe los diferentes mensajes que puede identificar las aplicaciones y el resultado que provoca como as tambin los mensajes que puede enviar la aplicacin
ESPECIFICACIN DE LOS PARMETROS QUE EL SERVIDOR IDENTIFICA

PARMETROS
CABECERA DE APLICACIN Msj_Cliente DATO DE APLICACIN (SUBCATEGORA) Solicitud_Partida SENTIDO Entrada DESCRIPCIN
El servidor recibe una invitacin a comenzar una partida del juego; Se envia una solicitud de peticion de confirmacion "Msj_Servidor| Confirmacion_Solicitud" y se comienza el timer para que luego de una series de intentos al no recibir la confirmacion se borra la IP de la lista de IP solicitudes de conexiones del servidor y se comienza la espera de una nueva solicitud. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Solicitud_Confirmada
Entrada
Se recibe la confirmacion de la solicitud de partida, solicitada anteriormente ;Se le envia al cliente la confirmacion por parte del servidor "Msj_Servidor| Solicitud_Aceptada" ,una vez enviada se informa al usuario de la aplicacin que se a aceptado una solicitud de partida con el ususario con direccion IP de la otra maquina. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Solicitud_Fichas_Aleatorias
Entrada
El cliente solicita que se envie las fichas colocadas aleatoriamente. El servidor en este caso recibe este mensaje cuando
Error_Recepcion_Fichas_Aleatorias Entrada
21
Por ejemplo una vez recibida las fichas arrojadas aleatoriamente por el servidor verifica que las fichas enviadas no cumplen con las siguientes caracteristicas La cantidad de fichas enviadas deben ser 8 de las cuales 4 corresponden a la fichas del local y 4 a las del Visitante las cuales no deben esta distribuidas por el tablero de forma que cunplan ta-te-ti. Verificacion_Conexion Entrada El servidor solicita el envio de un mensaje de Vericacion_Conexion para saber si el servidor se encuentra conectado. El cliente envia el mensaje al servidor que el usuario del cliente a cedido su turno a la otra perona por ejemplo porque la la ubicacin de las fichas collocadas en el tablero no le permiten realizar un movimiente. El cliente envia este mensaje cuando una vez recibido la jugada verifica si corresponde a una jugada valida Por ejemplo: Si es valido que el visitante pueda desplazar las ficha de la celda_11 a la celda_22 en caso contrario se dispone a enviar este mensaje para alertar al servidor y por su parte el cliente anula esta jugada la cual no es valida. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Jugada_Realizada_Fuera_Turno Entrada El cliente envia este mensaje cuando recibe una mensaje de una jugada pero en un momento fuera del desarrollo de la partida Por ejemplo cuando se reciben las fichas aleatorias en ese caso daria como resultado un disposicion de las fichas no arbitarias. Aviso_Desconexion Entrada Se recibe un aviso que el cliente desea desconectarse de la aplicacin por lo
Turno_Cedido
Entrada
Posicion_Incorrecta
Entrada
22
tanto se envia el mensaje que se acepta la desconexion
"Msj_Servidor|Desconexion_Aceptada"
y se comienza el timer para luego de una serie de intentos si no se recibe su confirmacion, la aplicacin se desconectara, comunicandole previamente al usuario Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Sld_Retrasmicion Entrada Se ha generado un error en los procedimientos de procesar la informacion recibida y se ha solicitado que sa envie nuevamente el mensaje anteriormente trasmitido. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Cld_Origen Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31 Celda_32 Celda_33 Cld_Destino Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31 Celda_32 Celda_33 Msj_Dialogo Msj_Servidor Msg_Chat Comienzo_Envio_Aleatorias Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Salida Se recibe un mensaje de Chat. Por parte del cliente. Se envia el mensaje que se comienza a Hace referencia a la celda, la cual el usuario del cliente selecciono para colocar la ficha. Hace referencia a la celda la cual el usuario del cliente selecciono para desplazarla. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
23
enviar una series de filas aleatorias para lo cual el tablero del cliente debe encontrarse libre de fichas (preparado para una nueva partida). Cld_Aleatoria Celda_11_Local Celda_12_Local Celda_13_Local Celda_21_Local Celda_22_Local Celda_23_Local Celda_31_Local Celda_32_Local Celda_33_Local Salida Salida Salida Salida Salida Salida Salida Salida Salida Se enva la celda que se han visualizan en el tablero, a partir de los procedimiento de colocacin de celdas aleatorias (se realiza esto cada vez que se a iniciado una partida o se comienza una nueva partida, pero de las celdas locales visualizadas en el servidor). Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Ejemplo: Celda_11_Local corresponde a la celda_11 y la imagen que se debe visualizarse es la ficha con la imagen del Visitante, la cual corresponder con la del servidor que es la que arrojo los procedimientos de aleatoriedad. Se enva la celda que se han visualizan en el tablero, a partir de los procedimiento de colocacin de celdas aleatorias (se realiza esto cada vez que se a iniciado una partida o se comienza una nueva partida, pero de las celdas locales visualizadas en el servidor). Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Ejemplo: Celda_11_ Visitante corresponde a la celda_11 y la imagen que se debe visualizarse es la ficha con la imagen del Local, la cual corresponder con la del servidor que es la que arrojo los procedimientos de aleatoriedad. Se enva la celda que el usuario selecciono para desplazarla. Hace referencia a la celda la cual el usuario selecciono para desplazarla; Una vez recibido su destino se deber desplazar a su nuevo destino o no. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Celda_11_Visitante Celda_12_Visitante Celda_13_Visitante Celda_21_Visitante Celda_22_Visitante Celda_23_Visitante Celda_31_Visitante Celda_32_Visitante Celda_33_Visitante
Salida Salida Salida Salida Salida Salida Salida Salida Salida
Cld_Origen
Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31
Salida Salida Salida Salida Salida Salida Salida
24
Celda_32 Celda_33 Cld_Destino Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31 Celda_32 Celda_33 Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Se enva la celda que el usuario selecciono para colocarla. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Hace referencia a la celda la cual el usuario selecciono para colocar la ficha.
25
Msj_Servidor Confirmacion_Solicitud Salida Se solicita la confirmacion de la solicitud de comenzar una partida. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Solicitud_Aceptada
Salida
Se enva una confirmacin de que se ha aceptado la invitacin a jugar; A partir de ahora, se a de rechaza cualquier otra solicitud de invitacin, y se comienza con el dialogo por medio del chat de la aplicacion. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Partida_Iniciada
Salida
Se enva el mensaje de que se a rechazador la invitacin debido a que se esta jugando una partida. S e envia al cliente la confirmacion que el servidor se encuentra conectado. El servidor le envia al cliente el aviso que se procedera a enviar las fichas generadas aleatoria mente por el servidor para que el usuario de la otra aplicacin prepare el tablero. Se enva un confirmacin que se ha finaliza la transmisin de los datos arrojados aleatoria mente por medio de los procedimientos en la parte del servidor. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Servidor_Conectado Comienzo_Envio_Aleatorias
Salida Salida
Fin_Aleatorias
Salida
Turno_Cedido
Salida
El servidor envia el mensaje al cliente que el usuario del cliente a cedido su turno a la otra perona por ejemplo porque la la ubicacin de las fichas collocadas en el tablero no le permiten realizar un movimiente.
Posicion_Incorrecta
Salida
26
Jugada_Realizada_Fuera_Turno
Salida
El servidor envia este mensaje cuando recibe una mensaje de una jugada pero en un momento fuera del desarrollo de la partida Por ejemplo cuando se reciben las fichas aleatorias en ese caso daria como resultado un disposicion de las fichas no arbitarias.
Desconexion_Aceptada
Salida
Se envia un aviso que se acepta la desconexion y se comienza un timer para que luego de una serie de intentos la aplicacin cierra previo aviso al usuario. Se envia un aviso que el servidor desea desconextarse para lo cual se envia el aviso de desconexion y se comienza el timer para lugo de una serie de intentos de recibir el aviso de desconexion por parte del cliente se desconecta. Se ha generado un error y se ha perdido el dato recibido se vuelva a enviar Se recibe un mensaje de Chat de la aplicacin. Se enva una invitacin a comenzar una partida como el juego se plantea de forma que previamente aceptan jugar (Informalmente) comienza el Chat para ponerse de acuerdo quien es que inicia la partida. Hace referencia a la celda la cual el usuario selecciono para desplazarla; Una vez recibido su destino se deber desplazar a su nuevo destino o no. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Desconexion_Servidor
Salida
Sld_Retrasmicion
Salida
Msj_Dialogo
Msg_Chat Incia_Usted
Salida Salida
Inicia_El
Salida
Se recibe un aviso que el servidor se ha desconectado abruptamente Se enva un aviso que el cliente se ha desconectado abruptamente.
27
28
ESPECIFICACIN DE LOS PARMETROS QUE EL CLIENTE IDENTIFICA

PARMETROS
CABECERA DE APLICACIN Msj_Servidor DATO DE APLICACIN (SUBCATEGORA) Confirmacion_Solicitud SENTIDO Entrada DESCRIPCIN
Se solicita una confirmacion de solicitud de comenzar una partida por lo tanto se envia el siguiente mensaje para confirmar la solicitud de partida. "Msj_Cliente|Solicitud_Confirmada" Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Solicitud_Aceptada
Entrada
El cliente recibe la confirmacion a comenzar una partida del juego con el servidor; Se inicia el tablero y se abilita el Chat para ponerse de acuerdo quien es que inicia la partida una vez deacuerdos se espera a que el usuario del servidor abilite el juego para enpezar con el turno segn lo estableecido. pero a pesar de esto queda a cargo de su criterio. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Partida_Iniciada
Entrada
Se recibe el mensaje que se a rechazador la invitacin debido a que se esta jugando una partida. Se recibe el mensaje que el servidor comenzara a enviar las filas aleatoria para lo cual el tablero de encontrarse como una nueva partida. El servidor envia el mensaje Servidor_Conectado para que el cliente sepa que se encuentra activo. Se recibe la confirma la finalizacin de la transmisin de los datos arrojados aleatoria mente de las fichas aleatorias cargadas en la parte servidor. El servidor envio el mensaje alcliente
Comienzo_Envio_Aleatorias
Entrada
Servidor_Conectado
Entrada
Fin_Aleatorias
Entrada
Turno_Cedido
Entrada
29
que el usuario del servidor a cedido su turno a la otra perona por ejemplo porque la la ubicacin de las fichas collocadas en el tablero no le permiten realizar un movimiente. Posicion_Incorrecta Entrada
Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Jugada_Realizada_Fuera_Turno Entrada El servidor envia este mensaje cuando recibe una mensaje de una jugada pero en un momento fuera del desarrollo de la partida Por ejemplo cuando se reciben las fichas aleatorias en ese caso daria como resultado un disposicion de las fichas no arbitarias. Desconexion_Servidor Entrada Se recibe un aviso que el servidor desea desconectarse de la aplicacin por lo tanto se envia el mensaje que se acepta la desconexion "Msj_Cliente| Desconexion_Aceptada" y se comienza el timer para luego de una serie de intentos si no se recibe su confirmacion, la aplicacin se desconectara, comunicandole previamente al usuario. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Sld_Retrasmicion Entrada Se ha generado un error y se ha perdido el dato recibido se solicita que se vuelva a enviar .
30
Cld_Aleatoria Celda_11_Local Celda_12_Local Celda_13_Local Celda_21_Local Celda_22_Local Celda_23_Local Celda_31_Local Celda_32_Local Celda_33_Local Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Se recibe las celdas de las posiciones de las celdas locales que se visualizaron en el tablero del servidor que en este caso correspondera a las del visitante. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Ejemplo: Celda_11_Local corresponde a la celda_11 y la imagen que se debe visualizarse es la ficha con la imagen del local, la cual corresponder con la del servidor que es la que arrojo los procedimientos de aleatoriedad que ac seria la del visitante. Se recibe las celdas de las posiciones de las celdas Visitante que se visualizaron en el tablero del servidor que en este caso correspondera a las del Local Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Ejemplo: Celda_11_ Visitante corresponde a la celda_11 y la imagen que se debe visualizarse es la ficha con la imagen del Visitante, la cual corresponder con la del servidor que es la que arrojo los procedimientos de aleatoriedad. Se recibe la celda que el usuario en el servidor selecciono para desplazarla; Una vez recibido su destino se deber desplazar a su nuevo destino o no. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Celda_11_Visitante Celda_12_Visitante Celda_13_Visitante Celda_21_Visitante Celda_22_Visitante Celda_23_Visitante Celda_31_Visitante Celda_32_Visitante Celda_33_Visitante
Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada
Cld_Origen
Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31 Celda_32 Celda_33
Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada
Cld_Destino
Celda_11 Celda_12 Celda_13 Celda_21
Se recibe la celda a la cual el usuario del servidor desplazo la celda. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
31
Celda_22 Celda_23 Celda_31 Celda_32 Celda_33 Msj_Dialogo Msj_Chat Incia_Usted Entrada Entrada Entrada Entrada Entrada Entrada Entrada Se recibe un mensaje de Chat de la aplicacin. Se enva una invitacin a comenzar una partida como el juego se plantea de forma que previamente aceptan jugar (Informalmente) comienza el Chat para ponerse de acuerdo quien es que inicia la partida. Hace referencia a la celda la cual el usuario selecciono para desplazarla; Una vez recibido su destino se deber desplazar a su nuevo destino o no. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Inicia_El Entrada Se recibe un aviso que el servidor se ha desconectado abruptamente Se enva un aviso que el cliente se ha desconectado abruptamente . Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Msj_Cliente Solicitud_Partida Salida Se enva una invitacin a comenzar una partida con el juego. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Solicitud_Confirmada Salida Se enva la confirmacion de querer iniciar una partida con el juego. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Solicitud_Fichas_Aleatorias Salida El cliente solicita las fichas aleatorias al servidor Por ejemplo por que se a terminado con las animamaciones de la partida ganada. Error_Recepcion_Fichas_Aleatorias Salida El cliente envia este mensaje cuando
32
Por ejemplo una vez recibida las fichas arrojadas aleatoriamente por el servidor verifica que las fichas enviadas no cumplen con las siguientes caracteristicas La cantidad de fichas enviadas deben ser 8 de las cuales 4 corresponden a la fichas del local y 4 a las del Visitante las cuales no deben esta distribuidas por el tablero de forma que cunplan ta-te-ti. Verificacion_Conexion Salida Se envia este mensaje para saber si el servidor se encuentra activo luego de un lapso de tiempo cuando el cliente por ejemplo no puede enviar un mensaje para saber si el sevidor se encuentra activo por ejemplo cuando esperan las fichas aleatorias del servidor en el cual el usuario del cliente no puede chatear con el usuario del servidor. El cliente envia el mensaje al servidor que el usuario del cliente a cedido su turno a la otra perona por ejemplo porque la la ubicacin de las fichas collocadas en el tablero no le permiten realizar un movimiente.
Turno_Cedido
Salida
Posicion_Incorrecta
Salida
Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Jugada_Realizada_Fuera_Turno Salida El cliente envia este mensaje cuando recibe una mensaje de una jugada pero en un momento fuera del desarrollo de la partida Por ejemplo cuando se reciben las fichas aleatorias en ese caso daria como resultado un disposicion de las fichas no arbitarias. Desconexion_Aceptada Salida Se envia un aviso que se acepta la desconexion y se comienza un timer para que luego de una serie de intentos la aplicacin cierra previo
33
aviso al usuario. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Aviso_Desconexion Salida Se envia un aviso que la aplicaion se desconectara y se comienza un timer para que luego de una serie de intentos la aplicacin cierra previo aviso al usuario. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES. Sld_Retrasmicion Salida Se ha generado un error y se ha perdido el dato recibido se solicita que se vuelva a enviar. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Cld_Origen
Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida Salida
Hace referencia a la celda la cual el usuario selecciono para desplazarla; Una vez recibido su destino se deber desplazar a su nuevo destino o no. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Cld_Destino
Hace referencia a la celda la cual el usuario selecciono para colocar la ficha. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
Msj_Dialogo
Msj_Chat
Se enva un mensaje de Chat de la aplicacin.
34
35
DETALLE DE LAS ESPECIFICACIONES PUERTO DE COMUNICACIN

El puerto de comunicacin para el cliente como para el servidor es el puerto es el 11000 (Ref. James F. Kurose).
TEMPORIZADORES
Se utiliza por la parte de el servidor 4 temporizadores para realizar detergidas acciones entre un lazo de tiempo especificado que para cada unos de los temporizadores independientes es distintas. Cada unos de los temporizadores se utilizan para las siguientes tareas Solicitud de conexin Enviar las fichas arrojadas aleatoria mente Retransmitir un mensaje. Cerrar conexin. Para el cliente se utilizan 4 temporizadores para las siguientes tareas Establecer la conexin. Para verificar la linea luego de un tiempo si no llegan una nueva ficha arrojada aleatoriamente por el servidor verifica si esta activo el servidor. Res trasmitir mensaje. Cerrar conexin. No se utiliza en ninguna de las dos parte un temporizador con la funcin de que en un cierto periodo de tiempo si la otra parte no se comunica verificar si se encuentra activo debido a que la aplicacin posee el chat el cual le brinda al usuario la posibilidad de comunicarse en cualquier momentos sin tener que encontrarse nicamente esperando su turno(Ref. James F. Kurose).
DETALLE DE LOS TEMPORIZADORES:

Temporizadores del Servidor:
Solicitud de conexin Una vez recibido la solicitud de Msj_Cliente|Solicitud_Partida Se enva al otro usuario la peticin de la confirmacin de solicitud Msg_Servidor|Solicitud_Confirmacion y se habilita el un timer para que luego de expire el timer y cumplido una serie de envi del paquete, no haber recibido confirmacin alguna se inicia el servidor nuevamente a la espera de una nueva solicitud de partida. Enviar la fichas arrojadas aleatoria mente
36
Una vez arrojadas las fichas aleatoriamente sobre el tablero se enva al cliente el mensaje de Msj_Servidor|Comienzo_Envio_Aleatorias para que el cliente prepare el tablero para una nueva partida. Una vez espirado el timer en el servidor se dispone a enviar una ficha por vez hasta completa el total de las 8 fichas enviadas aleatoriamente; Luego se Se enva el mensaje de Msj_Servidor|Fin_Aleatorias . Retransmitir un mensaje. Cada vez que se enva un paquete al cliente se comienza el timer de retrasmisin el cual una vez que este espira, verifica si a llegado la confirmacin del paquete anteriormente enviado y que la cantidad de veces de la retrasmisin del paquete sea menor a un cierto numero, si es que no a llegado la confirmacin y el numero de veces res trasmitido es menor a lo establecido lo res trasmite nuevamente pero con el campo ARK de la parte de transporte a 1 para que el cliente sepa que es un paquete enviado anteriormente En el caso de se cumpla con el numero de establecido de retrasmisin de un paquete se haba al usuario que el servidor se a desconectada. En el caso de recibir una confirmacin se habilita la posibilidad de enviar un nuevo paquete. Cerrar conexin. Para realizar el cierre de la conexin cualquiera de la dos parte enva a la otra un aviso de cierre de conexin Aviso_Desconexion habilita el timer de cierre de conexin para que cada vez que espire el tiempo del timer, enva el aviso nueva mente de desconexin si es que no a enviado previamente un cierto numero preestablecido de avisos, si es que cumpli con cantidad de avisos de desconexin previamente y no a recibido confirmacin del paquete enviado o el mensaje de Desconexion_Aceptada procede a desconectarse de la otra parte independientemente aunque esta siga conectada. En el caso de la otra parte si recibe el mensaje Aviso_Desconexion proceder a enviar el mensaje Desconexion_Aceptada y habilitara su timer correspondiente de cierre de conexin de la misma forma que la otra parte que se desea desconectase cada vez que se espire el timer y que no haya recibido la confirmacin de desconexin y que adems no se a cumplido que previamente fue enviado una cierta cantidad de avisos de desconexin proceder a enviarlo de nuevo, en el otro caso que cumpli con la cantidad de mensajes enviados o recibi la confinacin de su paquete se dispondr a avisarlo al usuario que la otra parte se desconecto y que la aplicacin se cerrara.
Temporizadores del cliente:

Establecer la conexin Una vez que el usuario a configurado la direccin a la maquina que desea establecer la conexin, se trata de establecer la conexin a travs del procedimiento Establecer_conexion posteriormente se habilita el timer para
37
enviar solicitud; El cual cada vez que espira el timer procede a verificar si se podido establecer la conexin sino lo intenta de nuevo hasta un cierto numero de intentos una vez establecida la conexin procede a enviar la solicitud de conexin al servidor . Para verificar la linea luego de un tiempo si no llegan una nueva ficha arrojada aleatoriamente por el servidor verifica si esta activo el servidor. Una vez que el cliente recibe el mensaje Msj_Servidor|Comienzo_Envio_Aleatorias Procede a preparar el tablero para una nueva partida y habilita el timer de Verificacion de conexin activa con el fin de verificar si el servidir se encuentra conectado, si el timer espira el y no se a recibido recientemente un ficha aleatoria el cliente se dispone a enviar el mensaje Msj_Cliente|Verificacion_Conexion
El cual el servidor se dispone a contestar con
Msj_Servidor|Servidor_Conectado
Una vez que el servidor envia el mensaje Msj_Servidor|Fin_Aleatorias el timer se deabilita.
Restrasmitir mensaje Cumple la misma funcion del servidor. Cerrar conexin. Cumple la misma funcion del servidor.
ORDEN DE PAQUETE DE LLEGADA DE LOS PAQUETES

Desde el principio cuando comenc a estudiar y disear el protocolo de la aplicacin tuve presente que al utilizar UDP los paquetes podran llegar desordenados. Sin embargo me he planteado que como los requerimientos del juego presentaban el diseo del protocolo para un Ta-Te-Ti sin tomar en consideracin el chat que es una condicin propia agregada a lo solicitado, Se dara el caso seria un protocolo de parada y espera esto quiere decir que se basa en turnos y por lo tanto no se dara el caso del llegada de una jugada ante de otra. Adems si no llegase el paquete, se volvera a res trasmitir cuando se espirase el temporizador y en el caso que llegara despus de esto seria rechazado este paquete Por este motivo no he implementado nada objetivamente para prever el orden de llegada de los paquetes Aunque se podra dar el caso de que en el chat lleguen en forma desordenada los mensajes. Pero el escenario que se presenta en la solicitud de el Tatet pagina 5 es un escenario muy Idealista.
38
TAMAO DE VENTANA
El tamao de la ventana o del buffer se utiliza un tamao de una ventana porque el juego solamente enva una jugada a la vez y luego espera su turno por este motivo no se pens en implementar otra tcnica. Referente al chat que en cualquier momento el usuario puede enviar un mensaje pens que si deshabilitara la opcin de enviar el mensaje hasta recibir su confirmacin no dara ningn inconveniente al usuario en el promedio de los casos Aunque en otras situacin se debera de implementar otra tcnica como utilizar una de n ventanas. (Ref. James F. Kurose;Andrew S. Tanenbaum)
MENSAJES DE CONFIRMACION DE LLEGADA

Cada vez que una de la partes recibe un mensaje de la otra aplicacin, el campo numero de paquete contiene, el numero de paquete de que la otra aplicacin coloco para enviar y luego confirmar su llegada con este numero Esto se ocurre porque cuando unas de la entidad recibe un mensaje de la aplicacin, debe posteriormente tomar ese nmero y enviarlo junto el siguiente texto a la otra entidad Cbr_TATETI_Confirmacion_Paquete\ Str_Numero_Paquete_Recibido En el que se remplaza Str_Numero_Paquete_Recibido por el numero de paquete que se recibio Ej Se recibe el siguiente mensaje Cbc_TATETI/20/0\Cld_Destino |Celda_33 La aplicacin en este caso deberia enviar a la otra parte de la aplicacin la confirmacin de llegada de este paquete de la siguiente forma Cbr_TATETI_Confirmacion_Paquete\ 20 En el caso de que la otra parte no recibe esta confirmacin una vez espirado el tiempo del su timer realizara el envi nuevamente de este mensaje pero con el campo ARK en 1 en vez de 0 para notificar que este mensaje fue enviado anteriormente pero no se a recibido confirmacin por este motivo se volvi a reenviarse. En este escenario en el cual la aplicacin a recibi el mensaje como sabemos, la aplicacin lo debe recibir descartarlo porque fue la ultima trasmisin recibida y enviar nuevamente el mensaje de confirmacin de recepcin anteriormente enviado el cual era Cbr_TATETI_Confirmacion_Paquete\ 20 (Ref. James F. Kurose;Andrew S. Tanenbaum)
ESTABLECER CONEXIN
La conexin se realiza de la siguiente forma
Paso 1: El cliente enva una solicitud de conexin con la siguiente Msj_Cliente| Solitud_Partida Paso 2: El servidor al recibir este mensaje procede a enviar al cliente
39
Msj_Servidor|Confirmacion_Solicitud
Paso 3: El cliente al recibir este mensaje enva la confirmacin de la

peticin de conexin con el siguiente mensaje
Msj_Cliente|Confirmacion_Solicitud Paso 4 Al recibir este mensaje el servidor enva al cliente el siguiente

mensaje Msj_Servidor|Solicitud_Aceptada
(Ref. Andrew S. Tanenbaum)
ATENCION MENSAJE DE SOLICITUD DE PARTIDA, CON EL CAMPO ARK EN 1

En cada unos de de los mensajes de solicitud de partida el campo ARK debera de encontrarse en 0, por que en el caso de encontrarse en 1 el servidor lo rechazara al ser un mensaje de solicitud duplicadopor que podriese traterse de una solictud enviada hace tiempo atras.
CERRAR CONEXIN
Para cerrar una conexin cualquiera de las dos partes se dispone a enviar a la otra parte el siguiente mensaje Aviso_Desconexion y procede a habilitar un timer y a partir de ahora rechazara cualquir mensaje que no sea la confirmacin de desconexin. Cada vez que este espire si no ha recibido el mensaje Desconexion_Aceptada y previamente no ha enviado una serie de avisos previos retransmite el mismo mensaje y en cabio recibe la confirmacin del paquete o el mensaje Desconexion_Acepta o a cumplido con la cantidad de retransmisiones del mensaje cierra la aplicacin. En el caso de la otra parte una vez que recibe el mensaje Aviso_Desconexion habilita de la misma forma que la otra parte el timer de desconexin que cumple la misma funcin pero con el mensaje siguiente mensaje Desconexion_Acepta. (Ref. Andrew S. Tanenbaum)
Imagen 13
CAIDA DEL SISTEMA (Nuevo)

En el caso de generarse un error en el lado del servidor el cual pudo ser capturado, el servidor enviara al cliente el mensaje que se a producido un error en el lado del servidor. En este caso se podra llegar a implementar que cuando suceda este escenario o el servidor simplemente se desconecta el una vez conectado nuevamente, el servidor podra mantener un registro de el usuario que se encontraba conectado y enviarle un mensaje a el de forma de informarle que se encuentra activo nuevamente Pero para este caso el cliente debera de encontrarse en un estado latente como los programas de mensajera que una vez que alguien se conecta el cual se encuentra en su lista de contactos informa al usuario de tal evento.
MENSAJE RECHAZADO!, Pero si era un mensaje con el formato de la aplicacion ? Sld_Retrasmicion.
40
Se puede da el escenario que se reciba un mensaje de la aplicacin que cumpla con todas las condiciones de la parte de transporte y que se envi la confirmacin del mismo, el cual le llega a la otra parte, pero cuando es procesado por la parte de la aplicacin sea rechazado por no ser identificado su mensaje esto ocurri por que la aplicacin envi un mensaje no reconocido por la aplicacin o porque esta parte del mensaje fue corrompido. Por este motivo los protocolos de aplicacin poseen un mensaje de retransmisin para estos casos.(Ref. James F. Kurose;Andrew S. Tanenbaum)
MENSAJE DE CHAT
Una vez enviado el mensaje aparece el tablero donde en la parte inferior del mismo encontramos la seccin donde podemos chatear con la aplicacin de la otra parte esto es lo mismo para la aplicacin cliente o servidor imagen 14. Al escribir un mensaje como podemos observar en la imagen 15 y presionamos enter, el mensaje ser enviado a la otra aplicacin, de la siguiente forma MsJ_Dialogo|MsJ_Chat Donde MsJ_Chat en este caso se remplazara con el siguiente mensaje que figura en la imagen el cual no debe supera los 29 caracteres Quieres empezar tu y el resultado al recibir la otra aplicacin ser la que podemos observar en la imagen 16 y as vise versa.
Imagen 15 (Mensaje de chat a ser enviado)
41
Imagen 16 (Mensaje de Chat recivido)
42
QUIEN COMIENZA LA PARTIDA?

Una vez puesto de acuerdo quien inicia la partida, el usuario de la parte del servidor es quien posee la opcin de quien inicia la partida a partir del men INICIO JUGADA como podemos ver en la imagen 17 en el caso de haber elegido la opcin LOCAL el servidor enviara el siguiente mensaje: MsJ_Dialogo|Incia_El En caso contrario si eligiria la opcion de visitante se enviara: MsJ_Dialogo|Incia_Usted Una vez realizado esto el servido colocas las fichas aleatorias en el tablero Y la aplicacin cliente al recibir el mensaje anterior, espera a que se enven las imgenes colocadas aleatoria mente para posteriormente habilitar las celdas libres y por ultimo habilitar el tablero segn el turno de la partida como se esplicare mas adelante.
Imagen 17 (Menu inicio de juego)
ORDEN DE TURNO DE JUGADA

El inicio de una partida, una vez establecida una conexin comienza la persona que el usuario del servidor a elegido a travs del men inicia jugador explicado anteriormente. Basndonos con un ejemplo seria de la siguiente forma la asignacin de los turno de inicio de una nueva jugada como un nuevo partido
43
El usuario del servidor decide que el usuario de una partida lo iniciara el, por lo tanto el primer turno le correspondera al usuario del servidor. Una vez completada un jugada, gana el usuario del servidor, aunque a ganado el usuario del servidor, el nuevo turno le corresponder al usuario del cliente luego de haber completado otra nueva partida le corresponder iniciar al servidor porque el turno anterior era del cliente indistintamente de quien a ganado. La secuencia de los turno seria de la siguiente manera Inicia una nueva partida El usuario del servidor decide que iniciara el Una vez completado una jugada le corresponder el turno al cliente Luego la prxima partida al servidor as sucesivamente.
44
EL TABLERO DE JUEGO
El juego se desarrolla sobre el tablero de la imagen 18, la cual cada una de sus celdas es representada con un valor los cuales se pueden observar en la imagen 18.
Imagen 18 (Valores de las celdas)
La fichas que intervienen en el juego son la de sus contrincantes la imagen 19 representa a la ficha del jugador de la aplicacin donde se encuentra ejecutndose sin diferencias si es servidor o el cliente y la imagen 20 representa a la del visitante que es la representa a la de la otra aplicacin.
45
Imagen 19(Fichas del Local)
Imagen 20 (Fichas del Visitante)
46
COLOCACIN DE LAS FICHAS ALEATORIAS

Luego de ponerse de acuerdo quien inicia la partida, el servidor arroja una serie de celdas aleatorias las cuales tienen las siguientes caractersticas: Se arrojas 8 fichas 4 del visitante y 4 del local No se colocan de forma que el resultado genere una alineacin que genere un punto a favor de cualquier de los dos participante.
En la imagen 21 podemos observar el resultado de arrojar las celdas, las cuales se encuentran rotulado con los mensajes que una vez terminados lo enviara en este caso serian:
Cld_Aleatoria|Celda_11_Local Cld_Aleatoria|Celda_12_Visitante Cld_Aleatoria|Celda_13_Local Cld_Aleatoria|Celda_21_Visitante Cld_Aleatoria|Celda_22_Local Cld_Aleatoria|Celda_23_Visitante Cld_Aleatoria|Celda_31_Local Cld_Aleatoria|Celda_33_Visitante
Imagen 21 (mensajes a ser enviados de los resultados de las imgenes cargadas aleatorias mente)
47
y por ultimo se enva un mensaje de fin de la trasmisin de filas aleatorias: MsJ_Servidor|Fin_Aleatorias una vez recibido este mensaje se habilita las celdas libres en ambas aplicaciones. Cuando la aplicacin del cliente recibe los mensajes anteriores el resultado ser el de la imagen 22 debido a que en la aplicacin del cliente las imgenes que se generaron como locales aca pasaran a ser visitante.
Imagen 22 (Mensajes recibidos de los resultados de las imgenes cargadas aleatorias mente ) ACLARACION LOS ROTULOS EN LA FICHAS SON SOLO DE ILUSTRACION
48
UN POCO DE AYUDA Procedimientos de colocacion de la celdas aleatorias

El siguiente codigo se encuentra escrito en Visual Basic.net, fue el utilizado para colocar las fichas aletoria mente, la intencion es que se pueda utilizar como referencia.
#Region "colocar fichas aleatorias en el tablero" #Region "Colocar fichas aleatoriamente individuales" Sub Colocar_Fichas_Aleatorias_Tablero(ByVal Imagen As Bitmap) Try Dim Valor_Aleatorio As String Randomize() Do While Int_Cantidad_Fichas_Colocadas < 4 Int_Cantidad_Intentos_Realizados = 0 Bln_Posicion_Valida = False Do While Not Bln_Posicion_Valida And Int_Cantidad_Intentos_Realizados < 9 Int_Cantidad_Intentos_Realizados += 1 Int_Valor_Fila_Aleatorio = CInt(Int((3 * Rnd()) + 1)) Int_Valor_Columna_Aleatorio = CInt(Int((3 * Rnd()) + 1)) Valor_Aleatorio = CStr(Int_Valor_Fila_Aleatorio) + CStr(Int_Valor_Columna_Aleatorio) Select Case Valor_Aleatorio Case "11" Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_11, Imagen) Case "12" Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_12, Imagen) Case "13" Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_13, Imagen) Case "21"
49
Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_21, Imagen) Case "22" Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_22, Imagen) Case "23" Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_23, Imagen) Case "31" Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_31, Imagen) Case "32" Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_32, Imagen) Case "33" Verificar_Fichas_Aleatoria_Continuas(PictBox_Imagen_33, Imagen) End Select Loop If Int_Cantidad_Intentos_Realizados = 9 Then Preparar_Nueva_Partida() Int_Cantidad_Fichas_Colocadas = 0 Colocar_Fichas_Aleatorias_Tablero(Btmp_Imagen_Celda_Local) Int_Cantidad_Fichas_Colocadas = 0 Colocar_Fichas_Aleatorias_Tablero(Btmp_Imagen_Celda_Visitante) End If Loop Catch ex As Exception MsgBox(ex.Message & ",Error interno al al colocar la fichas aleatorias", MsgBoxStyle.Critical, "Atencion") End Try End Sub #End Region #Region "Verificacion si se realizo Ta-Te-Ti con las fichas colocadas aleatorias"
50
Sub Verificar_Fichas_Aleatoria_Continuas(ByVal Control As PictureBox, ByVal Imagen As Bitmap) Try Bln_Posicion_Valida = False If Not Control.Visible Then Control.Visible = True Control.Image = Imagen If Not Verificacion_Jugada(Imagen) Then Bln_Posicion_Valida = True Int_Cantidad_Fichas_Colocadas += 1 Else Control.Image = Nothing Bln_Posicion_Valida = False Control.Visible = False End If End If Catch ex As Exception MsgBox(ex.Message & ",Error interno en la verificacion de la colocacion de fichas aleatorias", MsgBoxStyle.Critical, "Atencion") End Try End Sub #End Region #Region "Prepara una nueva partida" '************************** '* Igual a lo del Cliente * '************************** Sub Preparar_Nueva_Partida() Try PictBox_Imagen_11.Image = Nothing PictBox_Imagen_12.Image = Nothing PictBox_Imagen_13.Image = Nothing PictBox_Imagen_21.Image = Nothing
51
PictBox_Imagen_22.Image = Nothing PictBox_Imagen_23.Image = Nothing PictBox_Imagen_31.Image = Nothing PictBox_Imagen_32.Image = Nothing PictBox_Imagen_33.Image = Nothing PictBox_Imagen_11.Visible = False PictBox_Imagen_12.Visible = False PictBox_Imagen_13.Visible = False PictBox_Imagen_21.Visible = False PictBox_Imagen_22.Visible = False PictBox_Imagen_23.Visible = False PictBox_Imagen_31.Visible = False PictBox_Imagen_32.Visible = False PictBox_Imagen_33.Visible = False PictBox_Imagen_11.Enabled = False PictBox_Imagen_12.Enabled = False PictBox_Imagen_13.Enabled = False PictBox_Imagen_21.Enabled = False PictBox_Imagen_22.Enabled = False PictBox_Imagen_23.Enabled = False PictBox_Imagen_31.Enabled = False PictBox_Imagen_32.Enabled = False PictBox_Imagen_33.Enabled = False Bln_Tablero_LLeno_Fichas = True Mn_Nueva_Partida.Enabled = True GrpBox_Panel_Juego.Enabled = True Catch ex As Exception MsgBox(ex.Message & ",Error interno al iniciar una nueva partida", MsgBoxStyle.Critical, "Atencion") End Try End Sub #End Region #Region "Hacer visible los controles" Sub Hacer_Visibles_Controles() PictBox_Imagen_11.Visible = True PictBox_Imagen_12.Visible = True PictBox_Imagen_13.Visible = True PictBox_Imagen_21.Visible = True
52
PictBox_Imagen_22.Visible = True PictBox_Imagen_23.Visible = True PictBox_Imagen_31.Visible = True PictBox_Imagen_32.Visible = True PictBox_Imagen_33.Visible = True End Sub #End Region #Region "Verifica que control quedo libre para ser seleciona y lo avilita" Sub Habilitar_Control_Libre() ' Aca deberia ir el algoritmo para habilitar las celdas continuas a la celda libre de imagen, pero las celdas continuas deben corresponda a la imagen de la ficha del local. End Sub #End Region 'La llamada se puede realizar desde este o el otro '************************** '* Procedimiento principal * '************************** #Region "Colocar fichas aleatorias animadas" Sub Colocar_Fichas_aleatorias_animada() Preparar_Nueva_Partida() PictBox_Imagen_11.Size = New System.Drawing.Size(8, 8) PictBox_Imagen_12.Size = New System.Drawing.Size(8, 8) PictBox_Imagen_13.Size = New System.Drawing.Size(8, 8) PictBox_Imagen_21.Size = New System.Drawing.Size(8, 8) PictBox_Imagen_22.Size = New System.Drawing.Size(8, 8) PictBox_Imagen_23.Size = New System.Drawing.Size(8, 8) PictBox_Imagen_31.Size = New System.Drawing.Size(8, 8) PictBox_Imagen_32.Size = New System.Drawing.Size(8, 8) PictBox_Imagen_33.Size = New System.Drawing.Size(8, 8) Int_Cantidad_Fichas_Colocadas = 0 Colocar_Fichas_Aleatorias_Tablero(Btmp_Imagen_Celda_Local) Int_Cantidad_Fichas_Colocadas = 0 Colocar_Fichas_Aleatorias_Tablero(Btmp_Imagen_Celda_Visitante)
53
Tmr_Fichas_Agrandar.Start() Hacer_Visibles_Controles() Habilitar_Control_Libre() Enviar_Celdas_Colocadas_Aleatoriamente() End Sub #End Region 'La llamada se puede realizar desde este o el otro '************************** '* Procedimiento principal * '************************** #Region "Colocar fichas aleatorias" Sub Colocar_Fichas_Aleatorias() Int_Cantidad_Fichas_Colocadas = 0 Colocar_Fichas_Aleatorias_Tablero(Btmp_Imagen_Celda_Local) Int_Cantidad_Fichas_Colocadas = 0 Colocar_Fichas_Aleatorias_Tablero(Btmp_Imagen_Celda_Visitante) Tmr_Cartel.Stop() Hacer_Visibles_Controles() Habilitar_Control_Libre() Enviar_Celdas_Colocadas_Aleatoriamente() End Sub #End Region #End Region #End Region
54
ERROR AL VERIFICAR LAS CELDAS COLOCADAS ALEATORIAMENTE Error_Recepcion_Fichas_Aleatorias (Nuevo)

Este escenario se podra dar en el caso de por ejemplo que el cliente una vez que reciba las celdas aleatorias verifica si lo recibido cumple con las condiciones preestablecidas.
TIPOS DE ERRORES AL RECIBIR LAS FICHAS ALEATORIAS (Nuevo)

En esta sesin se trata de presentar algunos de los casos de errores que se podra presentar en la recepcin de las fichas aleatorias enviadas por el servidor.
SE RECIBIR UNA SERIE DE FICHAS MENOS QUE LAS 8 O MAS (Nuevo)

Se verifica que el tablero contiene menos de las 8 fichas con las cuales se juega el juego.
NO SE HAN RECIBIDOS LAS 4 FICHAS VISITANTES O LAS 4 LOCAL (Nuevo)

Al terminar la recepcin de las fichas arrojadas aleatoriamente por el servidor se confirma que el tablero posee mas fichas del Local o el Visitante por lo cual se presenta un estado de ventaja para uno de los dos, en cual no se debera presentar.
CON LAS FICHAS ENVIADAS GENERAS TATETI (Nuevo)

Se verifica que con las fichas enviadas se realizan automatcenle una condicin de Ta-Te-Ti para algunas de las dos partes lo cual no es contemplado por las condiciones del juego pre establecido.
HASTA CUANTAS VECES EL SERVIDOR O EL CLIENTE SE ENCONTRARAN PERSEVERANDO EN ESTE ERROR? (Nuevo)
Se establece que en el caso del servidor se dispondr a enviar las fichas aleatoriamente generadas por el hasta se no se cumpla que el cliente la solicita por mas de 10 veces de seguido; Por que en el caso contrario supondr que se trata de un error por parte de el cliente y se dispondr a notificarlo al usuario y cerrara la conexin establecida.
55
MOVIMIENTOS DE FICHAS EL PORQUE DE CELDAS ORIGEN Y DESTINO?

El porque de dos mensajes para un solo movimientos?, se debe a que desde el principio unas de las caractersticas que quera otorgarle a la aplicacin era la posibilidad, que el usuario pueda desplazar la ficha sobre el tablero y ubicarla sobre su posicin si es que se encuentra sobre ella sino volver a su lugar de origen cuando suelta el botn del mouse, pero esto se dara solo con las fichas habilitadas, porque recordemos que la solo se poda trasladar la fichas continuas a la ficha libre Esto nos brindara las mismas caractersticas que el juego de carta de Windows que de igual manera nos permite desplazar la carta. Un ejemplo seria si un usuario selecciona la ficha Celda_11 y presiona la tecla del mouse se enviara Celda_Origen_11 y si se desplazara a la celda 13 la cual estara libre en este caso y suelta la tecla del mouse se enviara Celda_Destino_13, en cambio si el usuario suelta la tecla con la ficha en el mismo posicin (lugar de origen) o se desplazara a un lugar incorrecto y la soltara se volvera la ficha al mismo lugar y se enviara Celda_Destino_11 anulando de esta forma su turno de la misma forma que en el ajedrez se levanta una ficha y se coloca en el mismo lugar para de esta forma ceder el turno a la otra persona.
UN EJEMPLO DE MOVIMIENTO DE FICHA

Si recibimos el siguiente mensaje cuando nos encontramos jugando una partida Cld_Origen |Celda_32 Lo debemos interpretar de la siguiente forma; Que el usuario el cual tiene su turno ha desplazado la imagen de la celda Celda_32 a otra posicin continua como podemos observar en la imagen 24
56
Imagen 24 (Mensaje recibido del origen de la imagen)
Una vez recibido su destino el cual ser en este caso la celda Celda_21 como no informa el siguiente mensaje recibido a continuacin del anterior: Cld_Destino|Celda_21 Debemos hacer desaparecer la imagen de la celda Celda_32 y hacerla visible en la celda Celd_21 como podemos ver en la imagen 25 que tambin aparece rotulado con el mensaje recibido
Imagen 25 (Mensaje recibido del destino de la imagen)
57
En este caso resulta que se aliiaron tres fichas iguales segn la reglas del TA TE TI , entonces una vez visible cada parte de las dos aplicaciones verificara si se realizo un punto. Y si es que fue as se contara como un punto mas una vez que se cumple que el primero que anote 3 punto aparecer la pantalla ganador correspondientes en cada una de la parte de las aplicaciones como podemos observar en las imgenes 26 y 27 correspondiente mente y se guardara el puntaje, en los archivos creados independiente mente y temporarios en el disco C del computador para registrar los puntos; Una vez terminada la seccion o cerrada la aplicacin, se elimara los archivo. Todo esto se lleva a cabo en cada una de las aplicaciones internamente.
Imagen 27 (Imagen ganador del local)
58
Imagen 28 (Imagen ganador del Visitante)
Para poder observar los punjes de las partidas se debe dirigir al menu ARCHIVO , PARTIDA.... hay se visualizara una cuadro con los puntos obtenidos Imagen 29
Imagen 29 Pantalla de el puntaje de los jugadores de la aplicacin.
59
RECEPCION DE UNA CELDA DE POSICION NO VALIDA POSICION_INCORRECTA (Nuevo)

Este ecenario se presenta cuando algunas de las dos partes recibe un movimiento realizado por la otra parte la cual no corresponde con un movimiento correcto. Un ejemplo seria si el cliente desea desplazar las ficha_11 a la posicion Celda_22 por que este desplazamiento es en diagonal y no se encunetra contemplado Otro seria si se desea desplazar de ficha_12 a la celda_13 pero en esta celda se encuentra otra imagen.
60
INTERFASE DE USUARIO
La aplicacin posee una Demo de introduccin el cual se puede ver en cualquier momento acediendo al la barra de herramienta de la aplicacin y de hay la opcion PRESENTACION DE INICIO como se eplicare mas adelante. El fin de esto era poder brindar un marco de referencia para los personajes (una historia) memorando el primer juego de tercera persona que brindaba una historia, la que enmarcaba al personaje del juego, en los aos 60, este concepto brindo una nueva visin para los nuevos desarrolladores de juegos de esa poca y hasta hoy en dias. Las historia gira alrededor de un hecho que haba pasado hace tiempo entre el enfrentamiento de dos personajes importante, por el control de unos territorios de Buenos Aires en los aos 60 rodeado de los encantos de de Buenos Aries de la poca sus bares y el tango, El archivo que guarda esta historia que poco se sabe se encuentra en un computador de una persona el cual se desempea en el gobierno. Para poder cargar dicho archivo la persona entra a su sistema operativo el cual el mismo lo ha creado y lo ha dado a llamar Da Vinchi cuyo logo es unas de las obras mas importante del aquel visionario, al lograr cargar el archivo nos permite ver esa historia que poco saben que ocurri y cuyo desenlace tuvo como intermediario el siguiente juego........
Imagen 30
61
Imagen 31
Imagen 32
62
Los personajes que giran alrededor de esta historia son: El cholo Ramirez El Cholo Ramrez es un mercenario del Per que vino a establecerse en Buenos Aries La profesin es desconocida, pero lo que se sabe es que entre sus actividades se encuentra el contrabando y la ventas de armas la imagen de abajo es la nica imagen que se pose de el,hasta el da de la fecha.
Imagen 33 Historial del Cholo Ramirez.
el otro es: El malevo Ferreira: Malevo residia en la ciudad de Buenos Aries, datos de sus comienzos no se posee pero se sabia que comenz como protegido de unas de las personas mas influyentes de la mafia de aquellos tiempos, posea un restaurante donde se reuna a menudo lo principales exponentes de la mafias de aquellos tiempos entre sus negocios se encontraba el trafico de productos, el marco trafico, el cual fue el motivo del enfrenamiento con el Cholo, como as tambin se sabia que manejaba a la polica de la provincia y algunos jueces como politicos.
63
Imagen 34 Historial del Malevo Ferreira.
64
INTERACCIN ENTRE EL SERVIDOR Y EL CLIENTE

INICIANDO EL SERVIDOR
La aplicacin de la parte del servidor al igual que la del cliente posee diferentes opciones en las cuales podes elegir las siguientes opciones Iniciar el servidor. Ver la demostracion de incio de la aplicacin. Poder ver el historial del participante local El Malevo. Poder ver el historial del participante visitante El Cholo. Y por ultimo salir de la aplicacin.
Imagen 35 Pantalla del inicio del servidor
Para iniciar el servidor debemos elegir de la opciones anteriores debemos elegir INICIAR SERVIDOR como podemos observar en la imagen 35 una vez clique ado se cierra la pantalla y se abre el Monitor de red este no ira informndonos de lo pasos que realiza los procedimientos de red como as tambin lo errores que pudieran surgir, en este caso se informa que el servidor fue iniciado Imagen 36 como asi tambien el tablero en espera de una nueva solicitud Imagen 38.
65
La aplicacin una vez iniciado el servidor coloca un icono el la barra de tareas, el cual nos permite visualizar el tablero o salir de aplicacin como podemos observar el la imagen 37 . Una vez recibido una solicitud de partida se abre el tablero de la aplicacin para comenzar a jugar con el usuario de la parte de cliente.
Imagen 36 Monitor de sistema del servidor.
66
Imagen 37 Icono de la aplicacin en la barra de tarea.
Imagen 38 El tablero del servidor en espera de una solicitud de conexin.
67
CREAR UNA NUEVA PARTIDA

Para crear una partida del juego debemos iniciar el cliente y elegir la opcin crear partida de la misma forma que en el servidor imagen 39.
Imagen 39 Pantalla de inicio del cliente.
Una vez realizado esto se abre el formulario que nos permite ingresar el valor de la direccin IP de la otra Terminal . La otra opcin que no brinda es la de conectarnos a la Terminal local imagen 40 Este formulario se encuentra adaptado para que el usuario no pueda ingresar una direccin IP que no corresponda con el formato de las direcciones IP. Brindando de esta manera parte de lo requerido en cuanto a la capa de aplicacion. Luego de haber ingresado la direccin o haber elegido la opcin localHost debe hacer click en el botn establecer conexin; Si el cliente no logra la conexin lo informara en con un cuadro informativo o en el MONITOR DE RED imagen 42.
68
Imagen 40
Imagen 41 Pantalla de configuracin de conexin del cliente.
69
Imagen 42 Monitor de sistema del cliente.
70
ATENDIENDO UNA SOLICITUD DE PARTIDA

El servidor si se encuentra iniciado y recibe un mensaje, lo primero que realiza es verificar si cumple con los requerimientos en cuanto formato del mensaje si lo cumple trata de dividirlo en los diferentes campos luegos de esto lo prosesa por separado en el caso de la parte de la aplicacin lo desencrypta elimina el relleno y lo envia al procedimientos de procesamiento de aplicacin. Todos estos pasos son a grandes rasgos en la realidad esto se hace de forma mas detallada Cada unas de las tareas que va realizando se van listando en el monitor de sistema como podemos ver en las imagenes 43,45,47,48,50,52 las que ilustran los diferentes pasos para la solicitud de una partida para el cliente de misma manera todo este proceso inverso sucede en el monitor del servidor como podemos observar en las imagenes42,44,46,49,51,53 (En el caso de no cumplir con el formato de mensaje simple mente lo descarta en el momento de recibirlo y se informa en el monitor).
Imagen 43 Envio de la solicitud de partida
71
Imagen 44 Recepcin del mensaje de la solicitud de partida por parte del cliente y el envi de la confirmacin del paquete recibido.
Imagen 45 Recepcin de la confirmacin del paquete enviado de solicitud de partida y las acciones realizadas al recibir la confirmacin como deshabilitar el timer de retrasmisin y habilitar el envi de nuevos mensajes.
72
Imagen 46 La recepcin de la solicitud de la confirmacin de la solicitud de partida por parte del servidor y el envi de la confirmacin de la llegada del paquete recibido.
Imagen 47 Recepcin de la confirmacin de paquete llegado del envi de solicitud de confirmacin de partida por parte del cliente al servidor.
73
Imagen 48 El envi de la confirmacin de la solicitud por parte del cliente
Imagen 49 recepcin de la confirmacin de solicitud de partida por parte del cliente al servidor y en vio de la confirmacin del paquete llegado.
74
Imagen 50 La recepcin de la confirmacin de llegada al servidor del mensaje de la confirmacin de solicitud.
Imagen 51 El envi de la solicitud aceptada por parte del servidor al cliente.
75
Imagen 52 la recepcin del mensaje del servidor de la confirmacin de la solicitud recibida y el envi de la confirmacin de la recepcin de su mensaje.
Imagen 53 La recepcin del mensaje del cliente de la confirmacin del la recepcin del mensaje.
76
EL MENU ACERCA DE...

EL menu ACERCA DE... brinda una simple referencia de los creditos de la aplicacin.
Imagen 54
77
ALGUNAS SUGERENCIAS PARA LA IMPLEMENTACIN DE UNA NUEVA VERSIN PARA EL PROTOCOLO(Nuevo)

En esta sesin se desea brindar las sugerencias recibidas para incorporarlas en este protocolo que aun no fueron implementadas por una cuestin de tiempo, pero que las cuales fueron recibidas con mucho agradecimiento
CANTIDAD DE MENSAJES ENVIADOS (Nuevo)

Con respecto a la cantidad de mensajes que se tramite entre las partes precisamente con la cantidad de mensaje que se utilizan para un movimiento y los resultados de las fichas generadas aleatoriamente en el servidor que son enviadas al clientes, en estas dos situaciones se generan una cantidad de mensajes muy grande que son enviados por la red, debido a que cada mensaje seran parte del paquete UDP el cual a los 54 caracteres del mensaje de la aplicacin debemos sumarles los Bits de UPD por sus diferentes campos. Con este escenario tenemos para las fichas aleatorias 8 paquetes de UDP de 32 Bits por parte del UDP + 54 Carcter del mensaje de la aplicacin. Con lo cual se sugiri utilizar un solo mensaje para enviar todo el resultado y eliminar los requerimientos de utilizar un mensaje de tamao fijo. Con respecto a los 2 mensajes de la jugada se sugiri enviarlo como lo anterior en un solo mensaje. Aunque quisiera aclarar que desde el principio fue la idea de implementar esta dos forma de enviarl los dos tipos de mensajes sugeridos, pero mi problema se presentaba porque las caractersticas pensadas para el modelo se enmarcaban en utilizar un mensaje fijo con lo cual si se enviara las fichas aleatorias juntas mi mensaje tendra que ser de esa longitud con lo cual me encontrara desperdiciando espacio con diferencia a los otros mensajes, La otra opcin que se me haba ocurrido era reemplazar los tamaos fijos de los mensajes por un campo longitud de datos el cual contendra el tamao de la carga til del mensaje, pero no lo he implementado porque no sabia con exactitud como debera de controlar lo errores de los mensajes que se pudieran surgir.
LA IMPLEMENTACION DE PODER ELEGIR ENTRE UNA SERIE DE PERSONAJES (Nuevo)

Se podra implementar las opciones de elegir entre una serie de personajes por ejemplo no solo que participen del desafo los dos personajes principales de la historia sino que podra se entre otros como los Matones que pudieran tener las banda del Ramrez o los mercenarios del Cholo, lo cual dara la posibilidad de ampliar las caractersticas del juego como as tambin las prestaciones algunos de los personajes incluidos pudieran ser como las imagen de abajo
78
Aunque en este caso de llegarse a implementar esto se debera de crear personajes propios que se enmarquen con la historia que se desarrolla la cual puede de ser ampliada.
UTILIZAR 6 FICHAS EN VEZ DE LAS 8 (Nuevo)

Aqu aclaro que esta no fue una sugerencia sino que era unas de las condiciones que debera contar el juego. Lo que sucedido es que no lo haba investigado previamente este juego para plantermelo correctamente como debera ser implementado. En el caso de haberse implementado que utilizaran 6 fichas en vez de las 8 utilizadas actualmente, el juego seria mucho, mucho mas interenzante; Por el motivo a que la complejidad del juego creceria mucho mas, lo cual el reto seria mayo. Lo que se debera volver a redisear seria la colocacin de las fichas aleatorias sobre el tablero pero con 6 fichas. Y el anlisis de las celdas que se podran desplazar, como as tambin, controlar los diferentes movimientos que podran surgir.
79
ERRORES QUE PUEDEN SURGIR QUE NO SON POR PARTE DEL USUARIO (Nuevo).
No solo a de suponer y capturar simplemente los errores que puedan surgir po parte de la aplicacin y que surgen por interacion de la aplicacin con el usuario que es lo comun que uno trata de preveer en este caso que se desarrolla una aplicacin que no solamente interactuara con el usuario a travez de la interface sino tambien aique considerar que la aplicacin interactuara con los mensajes condicionados del desarrollados de la otra aplicacin la cual puede ser indistintamente la parte del cliente como el servidor.
ALGUNAS BIBLIOGRAFAS SUGERIDAS(Nuevo)

La Bibliografa sugerida para consulta adems de la utilizada fue sugerida la de las especificaciones de los protocolos de aplicacin, los mas populares como podran se FTP,HTTP,POP3. Lo cual correspondera con algunas de las siguientes especificaciones
rfc0959 (FTP). rfc0854 (Telnet). rfc1459 (IRC).
SEGURIDAD (Nuevo)
La aplicacin desarrollada no brinda una seguridad a los mensajes que son intercambiados porque es una aplicacin que se encuentra orientada a juego, pero de igual manera al estar incorporado un chat las personas de cualquier de las dos parte pueden ser victimas de violacin del sistema y por lo tanto una de las personas se puede hacer pasar por otra; Con lo cual imagnese el dao que esto pudriera de causar a la relacin de las dos persona. Una de parte vulnerables del sistema que no se contemplo es la conexin entre el cliente y el servidor el cual se realiza por el acuerdo de tres vas. Primer escenario: El escenario que se podra presentar es el siguiente por ejemplo Victoria y Julio quieren jugar en red al Tatet, con lo cual se ponen de acuerdo para conectarse en una hora determina. Julio se conecta unos minutos antes, inicia el servidor y Victoria luego de un tiempo inicia el cliente envindole al servidor de Julio la solicitud de partida, el cual el servidor de julio le solicita la confirmacin este mensaje es interceptado por Gertrudis la que se encuentra husmeando (Leer y almacenar) los paquetes de la comunicacin, al saber que ellos se encontraran. Gertrudis capta la confirmacin de julio y previamente rechaza la solicitud de Victoria por deduccin Victoria supone que Julio no se haba conectado y abandona la conexin. Y por otra parte Gertrudis enva a Julio su confirmacin. Como resultado se obtiene que julio se encuentre conectado con Gertrudis en ves de Victoria aunque Julio cree que es Victoria
80
Esto no resulta difcil llevarse a cabo, por ejemplo con el cdigo del ncleo de un sistema operativo como Linux o cualquier otro los cuales hay cientos; Podemos crear un datagrama IP, con la direccin de origen IP que queramos, por ejemplo la direccin que conocemos de Victoria por que quizs ella se conecta desde su casa con una IP fija por ejemplo. Con lo cual podemos hacernos pasar por otra persona si no basamos simplemente de la direccin IP para identificar a la persona. Adems existen muchas de estas tcnicas para obtener los mismos resultados. Segundo escenario: El segundo escenario es que se podran utilizar una palabra clave Julio y Victoria para identificarse pero de igual manera si Gestrudis se encuentra Husmeando los paquetes de la red los puede grabar este mensaje y en cualquier momento que no se encuentre conectado Victoria reproducirlo y lograr la conexin. Esta tcnica puede ser utilizada a pesar de encontrarse encriptado porque con solo el hecho de reproducirle a julio el mismo mensaje encriptado alcanza para
identificarse como Victoria frente a Julio.

Estos escenario se puede solucionar de la siguiente manera si al conectarse Julio le solicita a Victoria que le confirme la solicitud pero adems le agrega un N numero generado aleatoriamente para identificar la solicitud que solo utilizara esa vez para identificarlo, el cual ser reutilizado luego de una serie amplia de conexiones, adems estos mensajes debern de sern encriptados por un algoritmo simtrico DES de clave publica. Con esto lograramos un nivel de seguridad aceptable. No hay que olvidarse que vivimos en un mundo que lo nico seguro es la eterna seguridad de la inseguridad, y que tu cadena es tan segura como tu eslabn mas dbil. Los algoritmos de encriptacin DES fue surgidos en 1973, el NBS (National Bureau of Standards, USA ) organizo un concurso solicitando un algoritmo de encriptacin para la proteccin de datos de computadoras durante su transmisin y almacenaje. En 1974, la corporacin IBM presento entre otras, una propuesta, en su sistema propietario LUCIFER, que convenientemente modificada, dio lugar al Data Encryption Standard (Norma de encryptacion de datos) abreviadamente DES. la aprobacin y modificacin de la propuesta se hizo supervisin de la NSA . Para mas informacion sobre el tema vea (2001 Amparo Fuster Sabater, Tecnicas Criptograficas de proteccion de datos, 2 edicion actulizada).
SSL
Este protocolo fue introducido por Netscape para dotar de seguridad a las comunicaciones sobre internet. Existen tres versiones La ultima conocida como SSL -v3. Puede de se utilizada para proteger datos de cualquier aplicacin porque agregar una nueva capa entre la de transporte y la de aplicacin.
81
Por ejemplo cuando un servidor Web se encuentra en modo SSL utiliza un puerto distinto (normalmente, el 443) para las comunicaciones cifradas SSL proporciona los servicios de integridad, confiabilidad y autenticacin. Lo algoritmos disponibles son:

Funciones Hsh:MD5,SHA-1.
Cifrado simetrico: DES-CBC, Triple -DES-CBC, RC2,RC4. Cifrado asimtricos: RSA,DSS.
Estos contemplan la posibilidad de elegir la longitud de clave segn el algoritmo elegido, existiendo una versin de exportacin de baja seguridad que solo permite la utilizacin de RC2, como clave de 40 Bits y RSA, con clave de 512 bits .
IMPLEMENTAR LA APLICACION PERO WEB(Nuevo)

Esta idea la presento para la situacion de tener que desarrollar la aplicacin, en ese caso se puede desarrollarla para una pataforma que se encuentre orientada a la Web presisamente un cliente y un servidor Web o un servidor que administre una serie de jugadores que se encuentre compitiendo en partidas diferentes.
CONCLUSIN (Nuevo)
Como conclusin quisiera ms que una conculcacin sobre el proyecto desarrollado, quisiera terminar con una conclusin personal Simplemente quiero expresar que fue realmente una satisfaccin muy grande el poder haber recibido la posibilidad de desarrollar esta aplicacin , y aunque no lo he terminado hasta lo que hubiese querido desarrollar. Pero como todo proyecto terminado es simplemente un paso hacia otro mas grande. Para terminar agradezco realmente a la persona que me ha ayudado con las sugerencias y lo solicitado como as tambin el echo de haberse preocupado por este trabajo y haberme brindado su tiempo. Gracias.
82
BIBLIOGRAFA:
2004 James F. Kurose, Keith W. Ross , Redes de computadores Un Enfoqu Descendente Basado en Internet . 2004 William Stallings. Comunicacin y redes de Computadoras. 2001 Amparo Fuster Sabater, Dolores de la guia Martinez,Luis Hernandez Encinas ,Fausto Montoya Vitini, Jaime Muoz Masque, Tecnicas Criptograficas de proteccion de datos, 2 edicion actulizada. 1997 Andrew S. Tanenbaum. Redes de Computadoras. Francisco Ojeda. Programacion en visual.Net. Coleccin Users Visual.Net Francisco Ojeda. Programacion en C#. Jeff Ferguson La bliblia de C#. RFC: 793 ,Protocolo de control de transmisin DARPA internet,program especificacin de protocolos, septiembre de 1981
83

Especificacion de Un Protocolo 0.92

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Especificacion de Un Protocolo 0.92

Hochgeladen von

Copyright:

Verfügbare Formate

Teora de un protocolo

UNIVERSIDAD NACIONAL DE MISIONES

5 de Abril del 2007

FORMATO DE MENSAJE ANTES DE SER ENVIADOS

UTILIZAR 6 FICHAS EN VEZ DE LAS 8 (Nuevo). SEGURIDAD (Nuevo).

CONSIDERACIONES DEL JUEGO

LA SINTAXIS, SEMNTICA, TEMPORIZACION

CAPAS DEL MODELO OSI

Imagen1 Modelo TCP/IP

User Datagram Protocol (UDP). Es un protocolo no confiable y sin conexin

OSI vs. TCP/IP

Mala tecnologa: OSI es complejo, es dominado por una mentalidad de

telecomunicaciones sin pensar en computadores, carece de servicios sin conexin, etc.

Malas implementaciones Malas polticas: investigadores y programadores contra los ministerios

Imagen 2 Formato UDP

La otra aplicacin desconexin.

Imagen 3 Maquina de estado finitos del Protocolo

(Ref. James F. Kurose;Andrew S. Tanenbaum)

ALGO SOBRE LA APLICACIN

Imagen 3 Los dos grupos de procedimientos que poseen la aplicacion.

TAMANO DE LOS CAMPOS

Imagen 5 Un ejemplo del formato del mensaje de apliacion.

Imagen 6 Cabecera de transporte con sus diferentes canpos.

Imagen 7 Separador de la parte Transporte y aplicacin.

SIGNIFICADO DE LOS DIFERENTES CAMPOS Y SU SIGNIFICADO

SEPARADOR DE CAMPO DE CABECERA DE TRANSPORTE Y NUMERO DE PAQUETE

SEPARADOR DE CAMPO DE NUMERO DE PAQUETE Y BANDA DE CONFIRMACION

SEPARADOR DE PARTE TRANSPORTE Y APLICACIN

CAMPO CABECERA DE APLICACIN

SEPARADOR DE CABECERA DE APLICACIN Y DATO DE APLICACIN

FORMATO DE MENSAJE ANTES DE SER ENVIADOS

MENSAJE DE APLICACON RRELLENADO

MENSAJE FINAL A SER ENVIADO

Imagen 1 0 Ejemplo de un mensaje de la aplicacion

ESPECIFICACIONES DE MENSAJES DE LA APLICACIN

ESPECIFICACIN DE LOS PARMETROS QUE EL SERVIDOR IDENTIFICA

Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.

Celda_11_Visitante Celda_12_Visitante Celda_13_Visitante Celda_21_Visitante Celda_22_Visitante Celda_23_Visitante Celda_31_Visitante Celda_32_Visitante Celda_33_Visitante

Salida Salida Salida Salida Salida Salida Salida Salida Salida

Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31

Salida Salida Salida Salida Salida Salida Salida

Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.

ESPECIFICACIN DE LOS PARMETROS QUE EL CLIENTE IDENTIFICA

Celda_11_Visitante Celda_12_Visitante Celda_13_Visitante Celda_21_Visitante Celda_22_Visitante Celda_23_Visitante Celda_31_Visitante Celda_32_Visitante Celda_33_Visitante

Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada

Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31 Celda_32 Celda_33

Celda_11 Celda_12 Celda_13 Celda_21

Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31 Celda_32 Celda_33

Celda_11 Celda_12 Celda_13 Celda_21 Celda_22 Celda_23 Celda_31 Celda_32 Celda_33

Se enva un mensaje de Chat de la aplicacin.

DETALLE DE LAS ESPECIFICACIONES PUERTO DE COMUNICACIN

DETALLE DE LOS TEMPORIZADORES:

Temporizadores del cliente:

ORDEN DE PAQUETE DE LLEGADA DE LOS PAQUETES

MENSAJES DE CONFIRMACION DE LLEGADA

Paso 3: El cliente al recibir este mensaje enva la confirmacin de la

Msj_Cliente|Confirmacion_Solicitud Paso 4 Al recibir este mensaje el servidor enva al cliente el siguiente

ATENCION MENSAJE DE SOLICITUD DE PARTIDA, CON EL CAMPO ARK EN 1

CAIDA DEL SISTEMA (Nuevo)

MENSAJE RECHAZADO!, Pero si era un mensaje con el formato de la aplicacion ? Sld_Retrasmicion.

Imagen 15 (Mensaje de chat a ser enviado)

Imagen 16 (Mensaje de Chat recivido)

QUIEN COMIENZA LA PARTIDA?

Imagen 17 (Menu inicio de juego)