Académique Documents
Professionnel Documents
Culture Documents
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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).
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:
Teora de un protocolo
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.
Teora de un protocolo
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
Teora de un protocolo
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 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:
Teora de un protocolo
Teora de un protocolo
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.
Teora de un protocolo
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.
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
Teora de un protocolo
conectar a la red haciendo uso de algn protocolo de modo que pueda enviar por ella paquetes de IP
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
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
Teora de un protocolo
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
Teora de un protocolo
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
13
Teora de un protocolo
14
Teora de un protocolo
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
Teora de un protocolo
\. 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
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
Teora de un protocolo
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
El mensaje a su vez se encuentra separado por el carcter \ que separa las partes 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
Teora de un protocolo
Imagen 9 Unidad del UDP el cual contendra nuestro mensaje de aplicacin en el campo dato.
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.
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
Teora de un protocolo
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).
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).
19
Teora de un protocolo
DATO DE APLICACIN
El dato de aplicacin corresponde al valor de la segunda columna de las especificaciones
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)
20
Teora de un protocolo
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
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
Teora de un protocolo
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
Teora de un protocolo
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.
23
Teora de un protocolo
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.
Cld_Origen
24
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
28
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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.
Cld_Origen
Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada Entrada
Cld_Destino
Se recibe la celda a la cual el usuario del servidor desplazo la celda. Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
31
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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
34
Teora de un protocolo
Para mas informacion vea DETALLE DE LAS ESPECIFICACIONES.
35
Teora de un protocolo
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).
36
Teora de un protocolo
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.
37
Teora de un protocolo
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.
38
Teora de un protocolo
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)
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
Teora de un protocolo
Msj_Servidor|Confirmacion_Solicitud
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
40
Teora de un protocolo
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.
41
Teora de un protocolo
42
Teora de un protocolo
43
Teora de un protocolo
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
Teora de un protocolo
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.
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
Teora de un protocolo
46
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
#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
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
56
Teora de un protocolo
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
57
Teora de un protocolo
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.
58
Teora de un protocolo
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
59
Teora de un protocolo
60
Teora de un protocolo
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
Teora de un protocolo
Imagen 31
Imagen 32
62
Teora de un protocolo
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.
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
Teora de un protocolo
64
Teora de un protocolo
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
Teora de un protocolo
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.
66
Teora de un protocolo
67
Teora de un protocolo
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
Teora de un protocolo
Imagen 40
69
Teora de un protocolo
70
Teora de un protocolo
71
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
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
Teora de un protocolo
75
Teora de un protocolo
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
Teora de un protocolo
Imagen 54
77
Teora de un protocolo
78
Teora de un protocolo
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.
79
Teora de un protocolo
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.
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
Teora de un protocolo
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
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
Teora de un protocolo
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 .
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
Teora de un protocolo
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