SISTEMA DE APOYO AL DESARROLLO EN PARALELO (SADPD)

SISTEMA DE APOYO AL DESARROLLO EN PARALELO Y A DISTANCIA

(SADPD)

ALEJANDRO ARANGO NIETO

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE SISTEMAS Y COMPTUTACIÓN BOGOTÁ, COLOMBIA

2004

ISC-2003-2-4

2

SISTEMA DE APOYO AL DESARROLLO EN PARALELO Y A DISTANCIA

(SADPD)

ALEJANDRO ARANGO NIETO

Proyecto De Grado

Asesor JUAN PABLO QUIROGA

ANGELA CRISTINA CARRILLO

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE SISTEMAS Y COMPTUTACIÓN BOGOTÁ, COLOMBIA

2004

ISC-2003-2-4

3

A mi madre Adela y a mi hermano Joaquín

por su apoyo incondicional en todo los momentos de mi vida.

A mi padre Eduardo

y mi hermano Daniel que los siento todavía dentro de mi corazón.

Padre, hermano este trabajo se los dedico con toda mi alma.

A Lucia por ser esa bella mujer que me apoyo en todo momento

de mi trabajo.

Gracias a todos por su cariño y dedicación.

ISC-2003-2-4

4

AGRADECIMIENTOS

Agradezco a la Universidad de los Andes por brindarme una excelente formación profesional. Mil gracias a Ángela Carrillo y a Juan Pablo Quiroga por sus aportes, consejos, y guía en la elaboración de este proyecto de tesis. A los profesores del departamento de sistemas y computación, en especial a Silvia Takahashi, Claudia Jiménez, Fernando de la Rosa, Rodrigo Cardozo, José Abasolo, Maria del Pilar Villamil, y a todos los profesores del departamento que de alguna forma influyeron en mi formación profesional. A mi familia y amigos que han sido parte importante de inspiración y colaboración. A todos ustedes gracias por brindarme su apoyo. A todos muchísimas gracias.

ISC-2003-2-4

5

TABLA DE CONTENIDO 1 Introducción.................................................................................................... 10 2 Objetivos......................................................................................................... 12

2.1 Objetivos generales ................................................................................. 12 2.2 Objetivos específicos............................................................................... 12

3 Marco Teorico................................................................................................. 13 3.1 LOS IDE COMO PARTE DEL DESARROLLO..................................... 13 3.2 “IM” como Servicio de comunicación..................................................... 14 3.3 ESPECIFICACION DEL “SADPD” ....................................................... 15

3.3.1 Requerimientos funcionales ............................................................. 15 3.3.2 Requerimientos no funcionales ........................................................ 16 3.3.3 Arquitectura del sistema SADPD ..................................................... 16

4 ANáLISIS ....................................................................................................... 18 4.1 ANáLISIS “IDE” .................................................................................... 18

4.1.1 Análisis IDE JBuilder ...................................................................... 18 4.1.2 Análisis del IDE NetBeans............................................................... 20

4.2 ANálisis SERVICIO “IM” ...................................................................... 22 5 DISEÑO ......................................................................................................... 28

5.1 Diseño de arquitectura del sistema........................................................... 28 5.2 Casos de Uso del Sistema ........................................................................ 29

5.2.1 Caso de Uso parte estadística ........................................................... 49 5.2.2 Caso de Uso IM - Historial .............................................................. 49 5.2.3 Caso de Uso IM............................................................................... 51

.................................................................................................................... 52 5.3 Diagrama de clase del sistema SADPD .................................................... 52 5.4 DiagramaS de secUenciaS ....................................................................... 53

6 EL IDE JBuilder ............................................................................................. 54 6.1 Funcionamiento de JBuilder .................................................................... 54 6.2 Desarrollo de plugin o MODULOS dentro de JBuilder............................ 58 6.3 Especificación de la Arquitectura de “OpenTools”................................... 60 6.4 Requerimientos técnicos DEL “SADPD” dentro del “IDE” .................... 63

6.4.1 Datos Técnicos de OpenTools .......................................................... 63 6.4.2 Verificación de la validez de los requerimientos de compatibilidad .. 68

7 El servicio “MSN Insant Messenger” .............................................................. 77 7.1 Tipos de servidores.................................................................................. 77 7.2 Estructura Lógica .................................................................................... 77 7.3 Protocolo MSN IM................................................................................... 79

7.3.1 Comandos normales......................................................................... 79 7.3.2 Comando con carga ......................................................................... 80 7.3.3 Identificador de transacción (TranID) .............................................. 80

7.4 Versiones del Protocolo “MSN IM” ......................................................... 81 7.5 Utilización del Protocolo “MSNP8”......................................................... 81

7.5.1 Autenticación dentro del servicio “MSN IM” ................................... 81 7.5.2 Mensajes Iniciales del NOTIFICATION después de la autenticación85

ISC-2003-2-4

6

7.5.3 Apareciendo online dentro del servicio “MSN IM” .......................... 87 7.5.4 Sincronización de Lista de contactos................................................ 87

7.5.4.1 Comando SYN............................................................................. 88 7.5.4.2 Comando GTC............................................................................. 89 7.5.4.3 Comando BLP ............................................................................. 89 7.5.4.4 Comando PRP.............................................................................. 90 7.5.4.5 Comando LSG ............................................................................. 90 7.5.4.6 Comando LST.............................................................................. 91 7.5.4.7 Comando BPR ............................................................................. 91

7.5.5 Pings y challenges............................................................................ 92 7.5.6 Cambio de estado de conexión del usuario y sus contactos............... 93 7.5.7 Cambio de nombre del usuario......................................................... 93 7.5.8 Manejo de Contactos ....................................................................... 94

7.5.8.1 Comando ADD ............................................................................ 94 7.5.8.2 Comando REM ............................................................................ 95 7.5.8.3 Mover contactos entre grupos ...................................................... 95 7.5.8.4 Bloquear y/o permitir contactos.................................................... 96 7.5.8.5 Cambios en la lista de reversa. ..................................................... 96

7.5.9 Manejo de Grupos............................................................................ 96 7.5.9.1 Comando ADG ............................................................................ 97 7.5.9.2 Comando RMG............................................................................ 97 7.5.9.3 Comando REG............................................................................. 97

7.5.10 Mensajes dentro del servidor NOTIFICATION................................ 98 7.5.10.1 Mensaje text/x-msmsgsemailnotification.................................. 98 7.5.10.2 text/x-msmsgsactivemailnotification ........................................ 99

7.5.11 Servicio de chequeo de email......................................................... 100 7.5.11.1 Comando URL....................................................................... 101

7.5.12 Finalizar la sesión al servidor NOTIFICATION............................. 102 7.6 Realización de conversaciones entre contactos....................................... 102

7.6.1 Invitando un contacto a la conversación ......................................... 103 7.6.2 Recibiendo invitación a una conversación...................................... 104 7.6.3 Envió de mensajes en el SWITCHBOARD.................................... 104

7.6.3.1 Comando MSG .......................................................................... 105 7.6.3.2 Envió de mensajes instantáneos.................................................. 106 7.6.3.3 Mensaje de control de escritura .................................................. 106 7.6.3.4 Invitaciones................................................................................ 107

7.6.3.4.1 Invitación a transferencia de archivo .................................... 107 7.6.4 Salir de una conversación............................................................... 109

7.7 Protocolo de transferencia de archivos ................................................... 110 7.7.1 Protocolo de texto.......................................................................... 110 7.7.2 Protocolo binario ........................................................................... 111

8 Implementacion SADPD ............................................................................... 113 9 Problemas Encontrados ................................................................................. 114 10 Mejoras Futuras......................................................................................... 115 11 Conclusiones ............................................................................................. 116

ISC-2003-2-4

7

12 Bibliografia ............................................................................................... 117

ISC-2003-2-4

8

TABLA DE ANEXO ANEXO A. Diagrama de secuencia.................................................................. 118 ANEXO B. Ejemplo autenticación servidor DISPATCH y NOTIFICATION ... 123 ANEXO C. Ejemplo conversación en el servidor SWITCHBOARD................. 125 ANEXO D. Ejemplo de una transferencia de archivo ........................................ 127

ISC-2003-2-4

9

TABLA DE ILUSTRACIONES Ilustración 1 Arquitectura del OpenTools ................................................................ 19 Ilustración 2 Conversación entre usuarios usando OPENMESSENGER.................. 27 Ilustración 3 Diagrama de DEPLOY del SADPD .................................................... 28 Ilustración 4 Caso de Uso estadística....................................................................... 49 Ilustración 5 Caso de Uso Historial-IM ................................................................... 50 Ilustración 6 Caso de Uso IM parte 1 ...................................................................... 51 Ilustración 8 Caso de Uso IM parte 2 ...................................................................... 52 Ilustración 8 Diagrama de clase SADPD ................................................................. 53 Ilustración 9 Proyecto en JBuilder .......................................................................... 55 Ilustración 11Ejemplo de un wizard ........................................................................ 56 Ilustración 12 Esquema del GUI de JBuilder........................................................... 57 Ilustración 13 Ejemplo de plugin OpenTools........................................................... 60 Ilustración 14 Botón de ejecución de la prueba Socket y Thread ............................. 68 Ilustración 15 Ejemplo de Editor Listener ............................................................... 69 Ilustración 16 Resultado del ejemplo Editor Listener .............................................. 69 Ilustración 17 Ejemplo Editor Context Menu .......................................................... 70 Ilustración 18 Ejemplo segundo Editor ContextMenu.............................................. 70 Ilustración 19 Ejemplo Build Listener ..................................................................... 71 Ilustración 20 Ejemplo MenuItem en un Menu........................................................ 71 Ilustración 21Ejemplo ToolBarItem en el ToolBar .................................................. 71 Ilustración 22 Boton de ejecucion de la prueba Message View................................ 72 Ilustración 23 Resultado dentro del Message View ................................................. 72 Ilustración 24 Ejemplo ContextMenu en el ProjectView ......................................... 73 Ilustración 25 Ejemplo 2 del ContextMenu dentro del ProjectView......................... 73 Ilustración 26 Ejemplo de acceso a los properties.................................................... 74 Ilustración 27 Ejemplo Propertie propio .................................................................. 74 Ilustración 28 Ejemplo de como acceder al wizard SADPD ..................................... 74 Ilustración 29 Ejemplo de Wizard SADPD .............................................................. 75 Ilustración 30 Resultado después de ejecutar el wizard SADPD .............................. 75 Ilustración 31Ejemplo de visualizador de nodo propio ............................................ 75 Ilustración 32 Resultado del viewer de nodo propio ................................................ 76 Ilustración 33 Diagrama de Secuencia................................................................... 118 Ilustración 34 Diagrama de Secuencia 2................................................................ 119 Ilustración 35 Diagrama de Secuencia 3................................................................ 120 Ilustración 36 Diagrama de Secuencia 4................................................................ 121 Ilustración 37 Diagrama de Secuencia 5................................................................ 122

ISC-2003-2-4

10

INTRODUCCIÓN Durante mucho tiempo la necesidad de comunicación entre desarrolladores ha sido vital para una excelente implementación de sistemas. Pero cuando estos desarrolladores no se encuentran en un mismo espacio físico, sino que se encuentran en lugares distantes, la comunicación se ve reducida entre el equipo. Normalmente los desarrolladores se comunicaban por teléfono, e-mail, sistemas de chat o sistemas mensajería instantánea, siendo estos sistemas buenos para la solución al problema de comunicación del equipo. Últimamente se ha encontrado que los sistemas de mensajería instantánea han tenido un auge enorme y esto debido, a la facilidad del uso del sistema, la posibilidad de saber quien esta en línea, y principalmente porque la comunicación es directa e inmediata entre los usuarios del sistema. Por otra parte los desarrolladores pasan más del ochenta por ciento del tiempo en una herramienta de desarrollo implementando sistemas y esta comprobado que un desarrollador desperdicia tiempo y concentración cada vez que necesita de cambiar de aplicación para realizar una tarea que no tenga relación con el trabajo que esta realizando; por lo tanto se hace necesario para el desarrollador poder integrar dentro de su herramienta de desarrollo, un sistema de comunicación. Esta tesis tiene como fin mostrar la conjunción de dos tecnologías importantes en el mundo actual del 2004: La primera, los IDE1 o herramientas de desarrollo visual, que ofrecen a los programadores de sistemas una ayuda significativa en cuanto al desarrollo del software, sus pruebas y deploys, la segunda, las aplicaciones de mensajería instantáneas (IM por sus siglas en ingles) que ofrecen una nueva forma de comunicación entre personas por Internet. La idea de esta tesis es integrar estas dos herramientas mediante la creación de un puente que permita extender el IDE y los servicios de IM con el fin de crear un sistema que permita apoyar el desarrollo de software en paralelo y a distancia (SADPD: Sistema de Apoyo al Desarrollo en Paralelo y a Distancia). Esta tecnología tiene como fin integrar dos sistemas que durante mucho tiempo han operado por separado y que su integración podrá ayudar mucho a los equipos de desarrollo que necesiten una constante comunicación y a su vez estos debido a las limitaciones técnicas no puedan estar en el mismo espacio físico. Por otra parte esta tesis, propone un nuevo sistema de intercambio de documentos, en donde el usuario tenga la posibilidad de transferir solo archivos, y además parte de estos; también que tenga la posibilidad de transmitir no solo proyectos, sino que también pueda transmitir parte de estos. Esto ultimo con la finalidad de dar a mostrar que no todo se tiene que compartir, sino que también se pueden compartir partes. Una analogía perfecta es tener la posibilidad de poder integrar dentro de Word un sistema 1 IDE: Ambiente de Desarrollo Integrado. Son aquellos productos que integran diferentes tecnologías para ayudar a los programadores y desarrolladores para una rápida implementación de software (Integrated Development Enviroment por las siglas en ingles)

ISC-2003-2-4

11

IM que a su vez me permita compartir el documento no solamente en su totalidad, sino también parte de este y, que el usuario remoto tenga la posibilidad de recibir este documento en el mismo formato en que lo envió el usuario. Por otra parte como medida de desarrollo del software, se incluirá el desarrollo de dos sistemas de tipo servidor, que ofrecerán: el primero, un record de las conversaciones, archivos intercambiados, y demás comunicaciones entre usuarios y el segundo servicio, un sistema que permita observar como es el rendimiento del equipo de trabajo de un proyecto.

ISC-2003-2-4

12

1 OBJETIVOS

1.1 OBJETIVOS GENERALES

- Implementar un sistema que permita un apoyo al desarrollo en paralelo y a distancia de equipos de desarrollo.

1.2 OBJETIVOS ESPECÍFICOS

- Integrar dentro de una herramienta IDE, un sistema de mensajería instantánea como medida de solución al problema de la comunicación a distancia y en paralelo.

- Desarrollar e implementar un sistema que permita el intercambio de partes de documentos (partes de código fuente), archivos, proyectos y parte de proyecto usando la herramienta que integra el IDE con el servicio de IM.

- Implementar un servicio de monitoreo que capture las conversaciones entre los usuarios, los archivos intercambiados como los tipos que se intercambiaron.

- Implementar un servicio de monitoreo de desempeño del usuario con respecto al desarrollo del software. Medir sus líneas de código desarrolladas por hora, cantidad de compilaciones, y demás mediciones importantes que se puedan obtener en el desarrollo del software.

- Diseñar y documentar el modelaje de la herramienta.

ISC-2003-2-4

13

2 MARCO TEORICO Como se mencionó antes, las herramientas de IDE y servicios de IM son utilidades que se le han brindado al usuario final y en este caso, específicamente a los desarrolladores, nuevas formas de desarrollo más sencillas y eficientes. Como seres humanos se busca tratar de llevar estos límites un poco más allá de los que están establecidos actualmente.

2.1 LOS IDE COMO PARTE DEL DESARROLLO Los IDE son herramientas de desarrollo que le permiten al desarrollador poder programar, editar contenido, compilar, realizar pruebas, generar ambientes gráficos. Además ofrecen sistemas de manejo de versiones, generadores de código para la parte gráfica, manejo de bases de datos remotas, sistemas para el deploy de sistemas, integración con herramientas externas, etc. Actualmente dentro del contexto más amplio del desarrollo, las empresas que desarrollan estos IDE luchan por tener la mayoría del mercado, cada uno ofreciendo nuevas tecnologías y sistemas que le facilitan al desarrollador su trabajo y tareas diarias. Algunos de los más famosos IDE son JDeveloper2 de Oracle, JBuilder [5] de Borland, NetBeans [3] y Eclipse3, siendo las dos ultimas de software libre y las dos primeras de código propietario. Cabe anotar que la popularidad de estos IDE es muy grande y cada uno de estos trata de obtener un gran pedazo del mercado entre los desarrolladores, siendo la competencia entre ellos muy fuerte que al final se ha traducido en una evolución exponencial en cuanto a las facilidades que se le han ofrecido a los desarrolladores. Hace aproximadamente cinco años la posibilidad que el IDE ofreciera un excelente deploy de sistemas eran muy pocas, pero actualmente estos ofrecen toda una gama de deploys desde el de servicios web, hasta manejo de contenedores de aplicaciones web. Los IDE actuales ofrecen en su mayoría sistemas que permiten su extensibilidad ya sea mediante la incorporación de plugins o módulos. Esta posibilidad va a ser la que permita integrar dentro del IDE el servicio de IM. En los IDE actuales NetBeans con su OpenApi [4] y JBuilder con su OpenTools [6] ofrecen una forma de integrar el IDE con extensiones ya sea propia o de terceras personas. Cabe resaltar que dentro de esta tesis tanto NetBeans con JBuilder son los principales líderes en sus ramos de IDE, NetBeans como IDE de código libre y JBuilder como IDE de código propietario. 2 www.oracle.com 3 www.eclipse.org

ISC-2003-2-4

14

Dentro del análisis se observaran las decisiones de porqué escoger entre un sistema y el otro.

2.2 “IM” COMO SERVICIO DE COMUNICACIÓN Los servicios de IM, ya han hecho su revolución dentro del contexto de lo que es la comunicación de forma instantánea entre una o más personas. Actualmente por las mismas razones que suceden con los IDE, los servicios de IM están tratando cada uno de acaparar toda la atención del público para que utilicen sus servicios. Es el ejemplo de ICQ4, AIM5, MSN IM6, IRC7. La evolución de la mensajería instantánea comenzó cuando en Internet comenzaron a aparecer los primeros servicios de chat. Estos servicios proveían al usuario de un esquema de mensajería instantánea, donde estos podían realizar conversaciones en público con otras personas, realizar conversaciones privadas, reunirse en canales de interés. El mejor ejemplo de lo anterior es el Internet Relay Chat (IRC por sus siglas en ingles). Este servicio comenzó a ser popular en los últimos cinco años pero en la actualidad a presentado un decaimiento debido al alto Spam8, también porque no ofrece un esquema personalizado de manejo de contactos o clientes. También porque resulta difícil identificar a un usuario en especifico. Tras innumerables situaciones, el público se ha trasladado a nuevos sistemas de comunicación instantáneas, que permitan al usuario poder controlar el Spam, manejar mejor sus contactos, permitirles ofrecer un sistema de identificación de usuario para sí poder saber qué se esta conversando con el usuario y además no comunicarse con una persona no deseada. Una solución al problema anterior lo produjo la compañía Mirabilis ltda, con su producto ICQ, para mediados de los años de 1996. Este servicio a diferencia de IRC, permitía identificar de manera exacta a los usuarios, es decir que se sabía a ciencia a cierta con quién se estaba hablando. Por otra parte este ofrecía un esquema de comunicación más personalizada, la capacidad de poder realizar conferencias. Por otra parte redujo la complejidad del servicio que en esos momentos IRC tenia, que era una maquina de comandos de tipo UNIX y no una simple interfaz gráfica como sucedía dentro del ICQ. Su popularidad creció vertiginosamente convirtiéndose en uno de los sistemas de comunicación instantánea más popular del mundo. Cuando las grandes compañías como AOL (America Online), Microsoft, Yahoo, etc. observaron el potencial de este servicio, cada uno comenzó ya sea a desarrollar sus

4 www.icq.com 5 www.aim.com 6 messenger.microsoft.com 7 www.irc.org 8 contenido sin interés no solicitado que puede llegar a ser ofensivo

ISC-2003-2-4

15

protocolos o a comprar otras compañías que habían desarrollado los sistemas de mensajería instantánea. Caso de lo último le sucedió a Mirabilis cuando AOL la compro y creo su propio sistema de mensajería instantánea. Ya para los años de 1998 y 1999 el mercado de la mensajería instantánea se había monopolizado convirtiéndose las grandes empresas en ser las únicas que ofrecían sistemas de mensajería instantánea, entonces fue cuando un grupo de personas pertenecientes al software libre especificaron un protocolo de mensajería instantánea en forma libre. Este protocolo lo bautizaron con el nombre de Jabber [9]. Jabber es un protocolo libre el cual los usuarios pueden especificar partes de este protocolo. Jabber es la actual revolución independiente en lo que se refiere al servicio de mensajería instantánea. Mas adelante en el análisis se hará una comparación entre los diferentes protocolos de mensajería instantánea y cual de estos se va a utilizar.

2.3 ESPECIFICACION DEL “SADPD”

2.3.1 Requerimientos funcionales El SADPD debe poseer un sistema de mensajería instantánea básica que es:

- Manejo de contactos9, como permitir agregar y remover contactos. - Saber su estado de conexión, es decir si esta conectado o desconectado, y su

estado de trabajo es decir si esta disponible, fuera del teclado, comiendo, ocupado, etc.

- Envío de mensajes instantáneos y archivos entre contactos. - Envío de e-mails en caso de que el contacto se encuentre fuera de línea10.

Debe contar con un sistema de monitoreo de usuario, cumpliendo con las siguientes caracteristicas: conocer cuando se conectó al sistema, información estadística sobre líneas desarrolladas, cantidades de compilación y demás informaciones métricas. Este sistema debe transmitir toda la información estadística a un sistema central de datos (Opcional). Debe poseer un sistema de bitácoras de mensajes. Se debe tener en cuenta que la bitácora será importante para casos en que se requiera ver un historial de conversaciones entre integrantes de un equipo. El sistema debe guardar los mensajes instantáneos, transferencias de archivo y demás comunicaciones de todo el equipo de 9 Contactos se refiere a una lista de personas a las cuales puedo enviarles y recibirles mensajes instantáneos. 10 Fuera de línea se refiere al hecho de no estar conectado al sistema de IM y no a Internet.

ISC-2003-2-4

16

desarrollo. Todo esto se debe encontrar en un repositorio de datos que mantenga el historial de las conversaciones (Opcional). El SADPD debe poseer un sistema de intercambio de documentos, parte de documentos, intercambio de proyecto enteros e intercambio de partes de proyectos.

2.3.2 Requerimientos no funcionales

- Lenguaje de programación Java. - El SADPD debe estar integrado dentro de un IDE (ya sea JDeveloper de

Oracle, NetBeans o JBuilder de Borland, etc.) - Sistemas centrales de estadísticas e historiales pueden ser BD relacionales

como PostgreSQL, Oracle, Access, MySQL, etc. Que almacenen la información de las conversaciones y estadísticas proporcionadas por el sistema.

- El sistema de mensajería instantánea puede ser similar al Messenger de Microsoft, AOL, ICQ, JABBER, etc.

2.3.3 Arquitectura del sistema SADPD La idea es desarrollar el SADPD dentro de una herramienta de desarrollo (IDE), este sería el componente principal (Plugin IDE-SADPD). El SADPD va a contener los siguientes sistemas: el sistema de mensajería instantánea (Modulo IM), el sistema de monitor de usuario (Modulo Estadística), el sistema de historial de mensajes (Modulo Historial) y el sistema de intercambio de documentos (Modulo Intercambio de Documentos). Por otra parte este sistema exige tener por lo menos dos servicios de repositorio de información y un servicio de comunicación instantánea. Los tres servicios son: el servidor donde se almacena la información estadística (Servidor Estadística), el servidor donde se almacena la información de todas las conversaciones realizadas (Servidor Historial) y el servidor que ofrezca el servicio de mensajería instantánea (Servidor IM). Los anteriores servidores son independientes entre sí y son cada uno opcional de desarrollo, en caso de no desarrollarlos los datos de los módulos de estadística e historial permanecerán dentro del cliente y podrán ser transmitidos a demás usuarios del equipo cuando se requiera.

- Plugin IDE-SADPD: Este componente es el que va a permitir el SADPD conectarse a la herramienta IDE.

ISC-2003-2-4

17

- Módulo IM: Este modulo será el encargado de conectarse al sistema de mensajería instantánea, manejarlo y controlarlo. A través de este modulo el usuario se podrá comunicar con los demás usuarios.

- Módulo Estadística: Este modulo debe ser casi invisible al usuario, es decir que el usuario no se debe enterar que se está monitoreando. Este módulo debe tener la capacidad de poder transmitir la información estadística al servidor de cuando el usuario se encuentre en línea, en caso de no estarlo la información permanecerá dentro del cliente hasta que este se conecte de nuevo que entonces pasara al servidor de estadística.

- Módulo Historial: Este módulo realizara la labor de monitorear y enviar la información de las conversaciones, alertas, ideas y notas al servidor de historial. Esta comunicación se debe hacer siempre y cuando el cliente se encuentre conectado con el sistema de mensajería instantánea.

- Servidor Estadística: Deberá proveer los servicios de mantener la información estadística de cada uno de los integrantes del equipo, mostrar estadística al jefe o administrador del equipo de desarrolladores y mantener una monitoría constante sobre cual es el desempeño de cada persona dentro del equipo.

- Servidor Historial: Debe cruzar toda la información de conversaciones entre los diferentes clientes y debe mostrar en una línea de tiempo como se desarrollaron las conversaciones entre los clientes. Por otra parte debe mantener registro de las alertas, notas e ideas del equipo.

- Servidor IM: Este servidor debe ofrecer los servicios de mensajería instantánea básicos como mensajes instantáneos, estados conexión de usuario, etc. Este servidor se podrá crear desde cero o se pueden utilizar algunos servicios de mensajería instantánea del mercado, como pueden ser los servidores de Microsoft de Messenger, Yahoo o ICQ. Un aspecto importante es que estos sistemas tendrán algunas restricciones legales las cuales deberán tenerse en cuenta.

ISC-2003-2-4

18

3 ANÁLISIS A continuación se hará un análisis para la decisión del servicio de mensajería a utilizar, y el IDE correspondiente, para realizar la fusión entre el IDE y el servicio de IM.

3.1 ANÁLISIS “IDE” Una particularidad interesante que tienen muchos IDE comerciales y libres es que ofrecen una forma de agregarles funcionalidad a lo que originalmente traen. La incorporación de nuevas funcionalidades a los IDE se logra mediante la adición de plugins o módulos al IDE. Existen todo tipo de módulos especiales para el uso dentro del IDE tales como exploradores de bases de datos, debugger avanzados, monitores de servidores (HTTP, FTP, etc.), generadores automáticos de código, etc. La limitación de los módulos es poca y es la imaginación del desarrollador o inventor el que le pone límite al desarrollo de nuevos módulos. Todo lo anterior es parte del sustento de por qué crear el SADPD. La creación de un módulo que apoye el desarrollo de software en paralelo y a distancia se hace necesario. La comunicación entre desarrolladores no debe estar asociada a un programa externo, sino que debe estar incluida dentro del IDE, aunque no está demostrado científicamente lo anterior, si se puede analizar de forma empírica cuánto gasta en tiempo un desarrollador en cambiar de un programa a otro y cuánta concentración se pierde durante esta transición. Si lo anterior fuese cierto se sustentaría aún más la creación del módulo del SADPD dentro de un IDE. Dejando un poco lo anterior, lo que se busca a continuación es mostrar la capacidad de extensibilidad que poseen algunos IDE. Para ser un poco más preciso se analizaran la capacidad de extensibilidad de los siguientes IDE: JBuilder de Borland, y NetBeans de código abierto (o FORTE en caso de hablar de la distribución de Sun).

3.1.1 Análisis IDE JBuilder JBuilder como parte de su arquitectura una instancia de su herramienta de desarrollo de plugins llamada OpenTools, esta herramienta es un API que trae nativamente JBuilder dentro de una de las librerías de su distribución y permite el desarrollo de plugins. El OpenTools es un compendio de clases que se encuentra dividido entre dos ramas: la rama de clases dentro del paquete de com.borland.primetime y la de com.borland.jbuilder. Esta división la crearon para separar la

ISC-2003-2-4

19

implementación lógica del API de la implementación práctica que utiliza JBuilder internamente. La arquitectura propuesta por OpenTools es la siguiente:

Ilustración 1 Arquitectura del OpenTools

La explicación de cada una de las partes de la arquitectura es larga y no corresponde a esta sección11. Ejemplo de algunos módulos desarrollados para JBuilder con su OpenTools: uTest: Módulo que genera código de pruebas de clases. Utiliza el framework de JUnit (Sergei Berdnikov). EPSql: Módulo para acceder a una base de datos PostgreSQL (Eric Jean luois). JB Icon Editor V1.0: Módulo para editar iconos dentro de JBuilder (Valentino Kyriakides)12. Entre las caracteristicas de los OpenTools, se tiene una buena documentación que explica en su mayoría todos los aspectos de cómo desarrollar módulos dentro de 11 Para una mejor explicación puede dirigirse al capitulo de la arquitectura de opentools, o también se puede dirigir a la siguiente dirección para obtener más información sobre lo que es cada parte de la arquitectura: http://info.borland.com/techpubs/JBuilder dentro de “PDF books” vaya a “Developing OpenTools”. 12 Se pueden conseguir más módulos para JBuilder en la siguiente dirección: http://codecentral.borland.com/codecentral/ccweb.exe/prodcat?prodid=3&catid=11

ISC-2003-2-4

20

JBuilder. La arquitectura que ahí explican, la desarrollan en forma correcta explicando que significa cada una de las capas, sus funcionalidades y limitaciones. Por otra parte también explican como se realiza todo el proceso de creación, compilación y ejecución de un módulo. Además la comunidad actual de desarrolladores dentro de OpenTools es considerablemente grande y además de gran entusiasmo (mensaje en los newsgroups respondido en menos de 2 horas). una excelente documentación, ejemplos, y soporte en caso de problemas (por medio de mensajes en los newsgroups en el servidor de newsgroups.borland.com que seria siendo: news://newsgroups.borland.com/borland.public.JBuilder.OpenTools). Por la parte técnica de la unión del sistema SADPD y el IDE no existe gran desafío, ya que se ha encontrado módulos con interacciones similares a lo que se utilizaría probablemente dentro del SADPD.

3.1.2 Análisis del IDE NetBeans Producto de código abierto que posee varias distribuciones (por ejemplo Forte de Sun). Este producto ofrece la posibilidad de incorporar módulos dentro del sistema. Ejemplo de esto es el módulo OpenApi para la creación de nuevos módulos. El OpenApi de NetBeans es un módulo compuesto por un conjunto de clases que ofrecen la capacidad de interacción con el sistema. La documentación de OpenApi de NetBeans se encuentra en otro módulo separado del módulo de OpenApi. La documentación es buena y extensa y, también ofrecen un JavaDoc de todo el OpenApi y explican para que sirve cada uno de los sus subAPI. También se encontraron tutoriales de cómo crear los módulos, aunque falta un poco de cómo funciona la arquitectura del OpenApi, también se encontró esta. El acceso no es tan intuitivo como uno piensa, pero si uno se baja el módulo de documentación del OpenApi se puede conseguir con relativa facilidad la documentación. La Arquitectura del OpenApi se divide en subAPIs que representan al igual que en el OpenTools las diferentes capas. Los subAPIs que posee el OpenApi son los siguientes:

- Modules API: API encargado del manejo de módulos dentro de NETBEANS.

- Dialogs API: API para la creación y manejo de diálogos dentro de NETBEANS.

- Filesystems API: API encargado de la parte de la representación de archivos y su manipulación.

ISC-2003-2-4

21

- Datasystems API: API encargado de la parte de la representación de los datos especiales y su manejo.

- Nodes API: API para el manejo de los nodos, y sus acciones. - Explorer API: API encargado de la parte visual del IDE. - Actions API: API que llama y representa las acciones que un usuario puede

invocar dentro de NetBeans. - Window System API: API para la creación, manejo y control de las

ventanas de NetBeans. - Editor API: API para el manejo de los diferentes editores que posee

NetBeans, tales como editor HTML, Java, etc. Cada uno de estos módulos ofrece diferentes acceso al sistema por ejemplo el FileSystems API provee acceso a archivos. El Editor API provee acceso al conjunto de funcionalidades del editor, etc. Según varios ejemplos observados el OpenApi cumple con lo que se está pidiendo en la especificación del SADPD. Algunos de estos ejemplos son: PushToTest: Módulo que genera prueba automáticas para asegurar el correcto funcionamiento de los Web Services, su escalabilidad y su eficiencia (PushToTest). SmartCVS: Módulo que facilita a los usuarios el manejo de sistemas de control de versiones (CVS), el sistema combina la funcionalidad del sistema de CVS con el manejo sencillo que ofrece Microsoft Visual SourceSafe (Regnis). NBAM (NetBeans Annotation Module): Módulo que permite a los usuarios de NetBeans poner “sticky notes” a sus proyectos. Además ofrece sistemas de manejo de ToDo (I-Ware)13. Ahora analizando un poco al OpenApi parece ser un buen sistema de desarrollo de módulos para NetBeans. Todos los ejemplos que se han visto sobre OpenApi parecen soportar la especificación del SADPD. Ya en varios ejemplos se ha visto cómo crear ventanas dentro del sistema, cómo asociar archivos nuevos al proyecto, cómo leer archivos del proyecto, etc. El OpenApi como el OpenTools parece soportar la gran mayoría de requerimientos exigidos en el SADPD. La decisión de la elección del IDE radica un poco más en la experiencia que se tenga del IDE, que en los beneficios que este pueda prestar, como se menciono anteriormente, ambos poseen características excelentes y parecen no presentar gran reto dentro del desarrollo del módulo del SADPD. El IDE que se eligió es JBuilder, ya que este IDE ha sido con el que se ha tenido mucha más experiencia de trabajo.

13 Para mayor información sobre módulos desarrollados para NETBEANS se puede conseguir en la siguiente dirección: http://www.netbeans.org/about/third-party.html

ISC-2003-2-4

22

3.2 ANÁLISIS SERVICIO “IM” Más que realizar un análisis sobre un servicio de IM en específico, se realizara un estudio de cual API sobre mensajería instantánea provee una excelente documentación, integración, estabilidad y funcionamiento, siendo la última la más importante. Después de una investigación en el área de API de mensajería instantánea para diferentes servicios de mensajería, se encontró un conjunto considerado de API para el servicio de mensajería instantánea Jabber. Jabber mas que un servicio de IM, es la especificación de cómo debe ser implementado este protocolo. Las personas que conforman Jabber, creen en la necesidad de los protocolos abiertos dentro de la tecnología de IM. Por lo que Jabber se ha convertido en un sistema abierto, su comunidad hace aportes tales como la implementación de servidores de IM, clientes que funcionen bajo este protocolo, como también aportes para el desarrollo de API para el desarrollo de aplicaciones que utilicen IM. Jabber como tecnología de IM se basa en protocolos especificados por la comunidad entera y los cuales están estructurados en forma de XML, desde el mismismo envío de un mensaje hasta la forma de establecer el estado del usuario (ocupado, online, comiendo, etc). Jabber ofrece como estructura lógica de IM los siguientes aspectos:

- Estado de conexión: Indica si el usuario esta conectado, desconectado, etc. - Único Número de Identificación (JID): El JID es un número que poseen todos

los usuarios dentro de un servidor de Jabber, es la analogía a lo que viene siendo la cédula para un ciudadano.

- Lista de contactos (Roster): Lista de todos los usuarios que uno posee como contactos.

- Envío y recepción de IM: Obviamente como sistema de IM, este permite el envió y recibo de mensajes.

- Posibilidad de realizar Chat con múltiples usuarios: Es la idea que tiene el IRC14, que en vez de enviar el mensaje a cada persona, este se envía al canal o grupo donde se esta realizando el Chat.

Uno de los aspectos un poco desagradables de Jabber es que no da siempre la sensación de ser un sistema ordenado, además de crear un cliente que soporte todos los aspectos técnicos de Jabber, es realmente difícil y complejo, ya que son muchísimos los requerimientos de protocolo que el cliente tiene que soportar para solo poder enviar un mensaje a otra persona. Además de esto se encontraron unas limitaciones algo malas, tales como el envío de archivos se tiene que realizar a través 14 IRC: Internet Realy Chat: Sistema de Chat en grupo donde los mensajes no son enviados a personas (aunque es una opción) sino que son enviados a un Canal o Grupo de Tema.

ISC-2003-2-4

23

de un servidor HTTP. Para ser un poco más breves, el usuario A que envía el archivo tiene que dejar el archivo en un servidor HTTP no especificado por el servidor JABBER, y para dejar el archivo en el servidor se tiene que realizar por medio del comando HTTP PUT, lo que en cierto modo crea una vulnerabilidad dentro del servidor donde se encuentra (Se crean conflictos tales como repositorio de archivos no permitidos, acceso de hackers al computador, etc), y lo siguiente que hace el usuario B que recibe el archivo, es simplemente bajarlo del servidor HTTP donde lo dejo el usuario A. Todo este procedimiento no es tan directo y seguro si pensamos en el riesgo que sufre el servidor HTTP, si este permite el comando PUT. También existe otro problema de compatibilidad con el SADPD, y es que Jabber no ofrece sistema de conexión a correo, por lo tanto, no se le puede enviar al usuario que se encuentra offline un e-mail. Los siguientes API fueron los que se analizaron: JabberBeans, JSO, Muse y Smack para el caso de servicios de IM para Jabber y el OpenMessenger para el servicio de MSN IM. Estos fueron los resultados:

- JabberBeans: JabberBeans es un protocolo que actualmente se encuentra en rediseño y reimplementación ya que sus colaboradores decidieron comenzar desde cero otra vez. Aunque BuddySpace un cliente Jabber en Java (uno de los mas populares) utiliza este API todavía en su cliente. Las siguientes pruebas o ejemplos fueron los que se realizaron, la primera prueba es ver la conexión al servidor, la segunda prueba es enviar un mensaje a un contacto, la tercera prueba es obtener el roster, la cuarta prueba es realizar el ingreso a un Chat y escuchar lo que se escribe. A continuación se presentan los resultados:

Test 1: En esta prueba se obtuvo un resultado exitoso en el envío del login y la clave al servidor de IM de Jabber: Connection succeeded! Send requested for IQ Send requested for msg InputStream: parsing done

Test 2: Otra prueba con éxito: se envió HelloWorld al contacto OpenMessenger y este fue el resultado:

CLDebug: Connect Changed Connection succeeded! PLDebug: Sent Packet: <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="jabber.org">

ISC-2003-2-4

24

PLDebug: Sent Packet: <iq id="sn-0" type="set"> <query xmlns="jabber:iq:auth"> <username>Apocalipsys</username> <password>alejo256</password> <resource>jtest</resource> </query> </iq> Send requested for IQ PLDebug: Sent Packet : <presence id="sn-1"></presence> PLDebug: Sent Packet : <message to="[email protected]" id="sn-2"> <body>HelloWorld</body> </message> Send requested for msg CLDebug: Connect Changed PLDebug: RECEIVED PACKET!!! : <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="jabber.org" id="1871736030"> PLDebug: RECEIVED PACKET!!! : <iq id="sn-0" type="result"></iq> PLDebug: RECEIVED PACKET!!! : <presence to="[email protected]" from="[email protected]/BuddySpace2.1" id="2"><priority>0</priority><x xmlns="jabber:x:delay stamp="20030528T02:04:51" from="[email protected]/BuddySpace2.1"></x><x xmlns="jabber:x:delay stamp="20030528T02:04:51" from="[email protected]/BuddySpace2.1"></x></presence> Test 3: Otra prueba con éxito y se obtuvo el Roster de [email protected]

CLDebug: Connect Changed Connection succeeded! PLDebug: Sent Packet PLDebug: Sent Packet Send requested for IQ

ISC-2003-2-4

25

PLDebug: Sent Packet PLDebug: Sent Packet CLDebug: Connect Changed PLDebug: Received Packet PLDebug: Received Packet PLDebug: Received Packet Roster Replaced/Loaded <item jid="[email protected]" subscription="none" name="Lamar"><group>External</group></item> <item jid="[email protected]" subscription="both" name="OpenMessenger"><group>Friends</group></item> <item jid="[email protected]" subscription="none" ask="subscribe" name="andrew"><group>External</group></item> <item jid="[email protected]" subscription="none" ask="subscribe" name="rob"><group>External</group></item> <item jid="[email protected]" subscription="none" name="Tofu"><group>External</group></item> <item jid="[email protected]" subscription="none" name="Roc"><group>External</group></item> <item jid="[email protected]" subscription="both" name="Baccus"><group>External</group></item> PLDebug: Received Packet Test 4: Esta fue la única prueba que no tuvo éxito ya que cuando pedía la solicitud de unirse al Chat salía un error de socket.

- JSO: Este API no resultó y fue muy complicado de entender y utilizar, ya que

primero no se entendió como funcionaban los ejemplos y luego, cuando se trató de ejecutar uno, resultó con errores de JAXPER y DOM que ni en el propio sitio tenia documentado como se solucionaba.

- Muse: Resulto ser un buen API en cuanto a la estructura de programación

pero no mostró solidez, y una documentación limitada. Por lo que los ejemplos serían la máxima documentación de este. Su funcionalidad resulto ser regular.

- Smack: Resultó ser igual al Muse, tenia una estructura de programación

interesante, pero su documentación resulto ser muy pobre. En definitiva, JabberBeans sería el único API que se podría utilizar, pero resulta ser un API muy difícil manejarlo, porque para enviar un mensaje instantáneo hay que

ISC-2003-2-4

26

realizar varios pasos, los cuales hacen más difícil la programación en este. Por otra parte ninguno de los anteriores está libre por lo menos en un 90% de errores, lo que resulta ser un API de poca confiabilidad, como por ejemplo, el JSO que ni siquiera se pudo ejecutar. La otra posibilidad y ultima que actualmente existe es la implementación del protocolo del Messenger de Microsoft que realizaron Alejandro Arango y Alejandro Manrique para el seminario de grupos, que fue el OpenMessenger. El OpenMessenger es un API que trabaja bajo el protocolo especificado por Microsoft para su servicio de IM. Este API hace completamente transparente el protocolo al usuario que hace uso de este. El sistema de IM de Microsoft sí contempla el envió de e-mail y de archivos, aunque con el envió de archivos resulta que la persona que envía el archivo no puede estar detrás de un NAT, porque no se puede realizar la conexión entre el que envía y el que recibe. El OpenMessenger soporta varias conversación simultaneas, es 100% MVC, y además de todo ofrece sistema de Observable. Actualmente este protocolo implementa todo el servicio de IM, manejo de lista de contactos, actualización del estado del usuario, y cambio de nombre del contacto. Aunque el envió de archivos actualmente no está soportado, este se tendrá que implementar. A continuación se mostrara una demostración del OpenMessenger:

ISC-2003-2-4

27

Ilustración 2 Conversación entre usuarios usando OPENMESSENGER

Esta sería la conversación IM entre 2 personas, una [email protected] (Alejandro Arango) y [email protected] (Cuenta del grupo OpenMessenger). Como se observa los mensajes aparecen por igual en ambas pantallas. En definitiva se utilizará el API del OpenMessenger debido a que se tiene experiencia trabajando sobre y se conoce como es su funcionamiento. En comparación de los API de Jabber, implementar uno desde cero resultara en un problema adicional que no se desea enfrentar. Si se utiliza uno de los API de Jabber resultara ser un poco más difícil de implementar aquellas partes donde el API tenga problema debido a que no se conoce en profundidad como es el funcionamiento de este.

ISC-2003-2-4

28

4 DISEÑO A continuación se mostrara el diseño del sistema SADPD anteriormente especificado.

4.1 DISEÑO DE ARQUITECTURA DEL SISTEMA A continuación se mostrara el diagrama de deploy del sistema mostrando como será la distribución de los equipos computacionales:

Ilustración 3 Diagrama de DEPLOY del SADPD

ISC-2003-2-4

29

4.2 CASOS DE USO DEL SISTEMA A continuación se mostraran los diagramas de casos de uso del SADPD.

1. Caso de Uso: Monitorear Tiempo Conexión Actores: Sistema SADPD <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que el sistema arranque, termine y cada 5 minutos transcurridos. Precondiciones: Sesión establecida, y nombre del usuario. Curso básico de acciones:

1. Al momento de que el sistema SADPD comience a funcionar, termine o hayan transcurrido 5 minutos, se establece una marca de tiempo.

2. Si no existe una marca de tiempo durante la iniciación de la sesión, esta se establece como marca de tiempo de inicio.

3. En el caso que exista una marca de tiempo de iniciación se establece esta como la marca de tiempo final.

4. Se comparan las dos nuevas marcas de tiempo y se establece el tiempo total de conexión.

5. En el momento de salir de la aplicación, se establece el final de la sesión, dando como dato final el tiempo de duración total.

Poscondiciones: 1. El tiempo total de conexión es igual al tiempo transcurrido de inicio de la

sesión hasta el final de esta o hasta los últimos 5 minutos en el caso que la aplicación deje de funcionar.

2. El sistema SADPD debe encargarse de que la información no se pierda. Elementos por Determinar o Resolver:

2. Caso de Uso: Monitorear Compilaciones/Hora Actores: Sistema SADPD <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que el usuario compile y al finalizar la sesión. Precondiciones: Sesión establecida, y nombre del usuario. Curso básico de acciones:

1. Al momento que el usuario proceda a compilar se monitorea que archivos fueron compilados, cuanto tiempo duro y que tipo de compilación realizo.

2. Se establece dado el tiempo de inicio de la sesión cuantas compilaciones se han hecho en esa hora comparando contra cuantas se habían hecho anteriormente.

3. Se almacena la información localmente hasta que se termine la sesión.

ISC-2003-2-4

30

Poscondiciones: 1. El número de compilaciones por hora es igual al número de compilaciones

en una hora completa o al número de compilaciones en el intervalo de hora en el caso que se cierre la sesión.


3. Caso de Uso: Monitorear Líneas/Hora Actores: Sistema SADPD <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Después de cada hora, después de que el usuario haya iniciado la sesión y al finalizar la sesión. Precondiciones: Sesión establecida, y nombre del usuario. Curso básico de acciones:

1. En el momento que se ejecute la acción se procede analizar la cantidad de líneas de código de cada archivo de texto del proyecto(s).

2. En el caso que sea la iniciación de la sesión, y no exista record anterior de cuantas líneas tenia anteriormente el proyecto, se procede a establecer como inicio de líneas este punto del proyecto. En el caso que si existiese la cantidad de líneas para los archivos se establece la diferencia entre las líneas de código anterior y actual. En el caso de resultar negativa esta diferencia se establece como 0 la cantidad de líneas por hora.

3. Se almacena la información localmente, hasta que termine la sesión. Poscondiciones:

1. El número de líneas por hora es igual al número de líneas hechas en una hora completa o al número de líneas en el intervalo de hora en el caso que se cierre la sesión.


4. Caso de Uso: Conectar Servidor Estadística Actores: Sistema SADPD <<system>>, Servidor Estadística <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que el sistema arranque, o cuando se le solicite. Precondiciones: Sesión establecida Curso básico de acciones:

1. Al momento de que el sistema SADPD comience a funcionar o cuando se le solicite, se crea una conexión al Servidor Estadística.

2. Esta se mantiene hasta que se haya enviado toda la información.

ISC-2003-2-4

31

Poscondiciones: Elementos por Determinar o Resolver:

5. Caso de Uso: Enviar Tiempo Conexión Actores: Sistema SADPD <<system>>, Servidor Estadística <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que se inicie la sesión o al finalizar la sesión. Precondiciones: Conexión al servidor estadística Curso básico de acciones:

1. Al momento de que el sistema SADPD comience a funcionar o cuando se le solicite, se establece la información sobre el tiempo de conexión al servidor de estadística a enviar.

2. Una vez enviada la información, esta es eliminada del Sistema SADPD. Poscondiciones:

1. Se debe mantener la atomicidad de la información. Tanto en el servidor como en el Sistema SADPD.

Elementos por Determinar o Resolver:

6. Caso de Uso: Enviar Compilaciones/Hora Actores: Sistema SADPD <<system>>, Servidor Estadística <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que se inicie la sesión o al finalizar la sesión. Precondiciones: Conexión al servidor estadística Curso básico de acciones:

1. Al momento de que el sistema SADPD comience a funcionar o cuando se le solicite, se establece la información sobre las compilaciones por hora a enviar.




7. Caso de Uso: Enviar Líneas/Hora Actores: Sistema SADPD <<system>>, Servidor Estadística <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que se inicie la sesión o al finalizar la sesión. Precondiciones: Conexión al servidor estadística

ISC-2003-2-4

32

Curso básico de acciones: 1. Al momento en que el sistema SADPD comience a funcionar o cuando se

le solicite, se establece la información sobre las líneas por hora a enviar. 2. Una vez enviada la información, esta es eliminada del Sistema SADPD.

Poscondiciones: 1. Se debe mantener la atomicidad de la información. Tanto en el servidor

como en el Sistema SADPD. Elementos por Determinar o Resolver:

8. Caso de Uso: Listar Información Estadística General Actores: Servidor Estadística <<system>>, Usuario SADPD Prioridad: Crítica Desempeño: No debe demorar más de 10 segundos en mostrar toda la información Frecuencia: Cada vez que el usuario SADPD lo solicite. Precondiciones: Conexión al servidor estadística Curso básico de acciones:

1. Cuando el usuario lo solicita se procede a mostrar toda la información general de todos los usuarios como sus promedios de conexión, compilaciones y líneas de código.

2. Se muestra también de forma general el promedio del promedio de cada usuario.


9. Caso de Uso: Listar Información Estadística Persona Actores: Servidor Estadística <<system>>, Usuario SADPD Prioridad: Crítica Desempeño: No debe demorar más de 10 segundos en mostrar toda la información Frecuencia: Cada vez que el usuario SADPD lo solicite. Precondiciones: Conexión al servidor estadística Curso básico de acciones:

1. Dado un usuario se muestra toda la información asociada a este como sus promedios de conexión, compilaciones y líneas de código.


10. Caso de Uso: Monitorear Conversación Actores: Sistema SADPD <<system>>, Usuario SADPD Prioridad: Crítica Desempeño No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que el usuario SADPD reciba o envié un mensaje instantáneo a unos de sus compañeros. Precondiciones: Sesión establecida, nombre del usuario y conexión al servidor IM.

ISC-2003-2-4

33

Curso básico de acciones: 1. Cuando el usuario recibe o envía un mensaje instantáneo a unos de sus

compañeros. 2. Se almacena localmente entre quienes fue realizada la conversación, a que

horas se realizo y quien converso y que conversaron. Poscondiciones:


11. Caso de Uso: Monitorear Archivo Enviado/Recibido Actores: Sistema SADPD <<system>>, Usuario SADPD Prioridad: Crítica Desempeño No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que el usuario SADPD reciba o envié un archivo, parte de este, un proyecto o parte de proyecto. Precondiciones: Sesión establecida, nombre del usuario y conexión al servidor IM. Curso básico de acciones:

1. Cuando el usuario recibe o envía un archivo, parte de archivo, proyecto o parte de proyecto de unos de sus compañeros.

2. Se almacena localmente entre quienes fue realizada el intercambio de archivo, a que horas se realizo y quien envió el archivo, quien guardo el archivo y que archivo(s) se intercambiaron.

Poscondiciones: 1. El sistema SADPD debe encargarse de que la información no se pierda.


12. Caso de Uso: Conectar Servidor Historial Actores: Sistema SADPD <<system>>, Servidor Historial <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que el sistema arranque, o cuando se le solicite. Precondiciones: Sesión establecida Curso básico de acciones:

1. En el momento que el sistema SADPD comience a funcionar o cuando se le solicite, se crea una conexión al Servidor Historial.

2. Esta se mantiene hasta que se haya enviado toda la información. Poscondiciones: Elementos por Determinar o Resolver:

13. Caso de Uso: Enviar Log Archivo E/R Actores: Sistema SADPD <<system>>, Servidor Historial <<system>> Prioridad: Crítica

ISC-2003-2-4

34

Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que se inicie la sesión o al finalizar la sesión. Precondiciones: Conexión al servidor historial Curso básico de acciones:

1. Al momento de que el sistema SADPD comience a funcionar o cuando se le solicite, se establece la información sobre el Log de conversación del usuario al servidor de historial




14. Caso de Uso: Enviar Log Conversación Actores: Sistema SADPD <<system>>, Servidor Historial <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe correr en modo espía (usuario no sabe que existe). Frecuencia: Cada vez que se inicie la sesión o al finalizar la sesión. Precondiciones: Conexión al servidor historial Curso básico de acciones:

1. Al momento de que el sistema SADPD comience a funcionar o cuando se le solicite, se establece la información sobre el Log de conversación del usuario al servidor de historial




15. Caso de Uso: Mostrar Log Conversación Usuario Actores: Servidor Historial <<system>>, Usuario SADPD Prioridad: Crítica Desempeño: No debe demorar más de 10 segundos en mostrar toda la información Frecuencia: Cada vez que el usuario SADPD lo solicite. Precondiciones: Conexión al servidor historial. Curso básico de acciones:

1. Cuando el usuario lo solicita se procede a mostrar toda la información de las conversaciones que ha realizado. Se muestra con quien habló, que hablo y a que horas habló.


ISC-2003-2-4

35

16. Caso de Uso: Mostrar Log Archivos Enviados/Recibidos Actores: Servidor Historial <<system>>, Usuario SADPD Prioridad: Crítica Desempeño: No debe demorar más de 10 segundos en mostrar toda la información Frecuencia: Cada vez que el usuario SADPD lo solicite. Precondiciones: Conexión al servidor historial. Curso básico de acciones:

1. Cuando el usuario lo solicita se procede a mostrar toda la información de los archivos enviados/recibidos que ha realizado. Se muestra a quien ha enviado archivo, que archivo envió y a que horas, como también se muestra los archivos recibidos, de quien recibió, a que horas.


17. Caso de Uso: Conectar Servidor IM Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la conexión en menos de 10 segundos. Frecuencia: Cada vez que el sistema arranque, o cuando el usuario lo solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM. Curso básico de acciones:

1. Al momento de que el sistema SADPD comience o cuando el usuario lo solicite, se procede a realizar la conexión al servidor IM.

2. Al realizar la conexión al servidor IM, el usuario debe enviar su nombre de cuenta y contraseña.

3. Si su nombre de cuenta y contraseña son correctas se establece como conexión realizada al servidor IM al sistema SADPD.

4. Esta se mantiene hasta que se haya cerrado la sesión o cuando el usuario lo determine.

Poscondiciones: 1. Una vez realizada la conexión, el SADPD debe mantenerla viva y por

ningún motivo debe perderla. Elementos por Determinar o Resolver:

18. Caso de Uso: Enviar Mensaje Instantáneo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario lo solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, persona a quien enviar el mensaje, y el mensaje a enviar a esa persona. Curso básico de acciones:

ISC-2003-2-4

36

1. Una vez el usuario tenga el mensaje y el contacto a enviar el mensaje este se procede a enviarlo al sistema IM.

2. Se forma la información del mensaje instantáneo que se enviara al servidor IM.

3. Se envía la información al servidor 4. Se espera la confirmación de llegada de la información al contacto. 5. Se le informa al usuario si el mensaje llegó o se perdió


19. Caso de Uso: Recibir Mensaje Instantáneo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario recibe un mensaje a través del servidor IM. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando. Curso básico de acciones:

1. Cuando el servidor IM tenga un mensaje instantáneo para el usuario, este se le envía.

2. El sistema SADPD se encarga de decodificar la información y extraer la información del mensaje, y de quien envió.

3. Se muestra el mensaje al usuario. Poscondiciones: Elementos por Determinar o Resolver:

20. Caso de Uso: Establecer Estado Conexión Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario lo desee. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, y un nuevo estado de conexión. Curso básico de acciones:

1. Cuando el usuario realiza un cambio en su estado de conexión, este se le envía al servidor IM. Los estados de conexión posible son: Online, Busy, Away, Idle, Out of Lunch, Be Right Back y Offline

2. El sistema SADPD se encarga de codificar la información y enviársela al servidor IM.

3. Se espera la confirmación del servidor IM. 4. En caso de que el servidor acepte el cambio el sistema SADPD realiza el

cambio de estado de conexión.

ISC-2003-2-4

37


21. Caso de Uso: Enviar Archivo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción y mantenerla hasta que se termine Frecuencia: Cada vez que el usuario lo desee. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, el contacto a enviar el archivo y el archivo a enviar. Curso básico de acciones:

1. Cuando el usuario decide enviar un archivo este selecciona a quien se lo va enviar y que archivo va enviar.

2. Se procede a realizar la codificación del mensaje y enviársela al servidor IM.

3. Una vez el compañero acepte la transferencia, se procede a enviarle el archivo.


22. Caso de Uso: Enviar Parte de Archivo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción y mantenerla hasta que se termine Frecuencia: Cada vez que el usuario lo desee. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, el contacto a enviar el archivo y el archivo a enviar (parte de este). Curso básico de acciones:

1. Cuando el usuario decide enviar un archivo este selecciona a quien se lo va enviar y que parte de archivo va enviar.

2. La parte del archivo se transforma en un nuevo archivo con metadatos de la información sobre este.




23. Caso de Uso: Enviar Proyecto Actores: Usuario SADPD, Servidor IM <<system>>

ISC-2003-2-4

38

Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción y mantenerla hasta que se termine Frecuencia: Cada vez que el usuario lo desee. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, el contacto a enviar el proyecto y el proyecto a enviar. Curso básico de acciones:

1. Cuando el usuario decide enviar un proyecto este selecciona a quien se lo va enviar y que proyecto va enviar.

2. Todos los archivos del proyecto se proceden a comprimir y se le realiza a este un archivo de metadatos sobre toda la información del proyecto, tales como configuración, datos, etc.




24. Caso de Uso: Enviar Parte de Proyecto Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción y mantenerla hasta que se termine Frecuencia: Cada vez que el usuario lo desee. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, el contacto a enviar el proyecto y la parte del proyecto a enviar. Curso básico de acciones:

1. Cuando el usuario decide enviar una parte del proyecto este selecciona a quien se lo va enviar y que parte del proyecto va enviar.

2. Todos los archivos de la parte del proyecto se proceden a comprimir y se le realiza a este un archivo de metadatos sobre toda la información del proyecto, tales como configuración, datos, etc.




25. Caso de Uso: Recibir Archivo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica

ISC-2003-2-4

39

Desempeño: No debe bloquear todo el sistema, y debe realizar la acción y mantenerla hasta que se termine Frecuencia: Cada vez que el usuario recibe notificación de transferencia de archivo. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando Curso básico de acciones:

1. El servidor IM informa al usuario que un archivo va a ser recibido. 2. El usuario procede a aceptar la transferencia. 3. La transferencia comienza y el usuario comienza a recibir el archivo. 4. Una vez recibido el archivo se le informa al usuario que desea hacer con el

archivo. Si lo desea ingresar al proyecto o simplemente guardarlo. Poscondiciones: Elementos por Determinar o Resolver:

26. Caso de Uso: Recibir Parte de Archivo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción y mantenerla hasta que se termine Frecuencia: Cada vez que el usuario recibe notificación de transferencia de archivo. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando Curso básico de acciones:

1. El servidor IM informa al usuario que un archivo va a ser recibido. 2. El usuario procede a aceptar la transferencia. 3. La transferencia comienza y el usuario comienza a recibir el archivo. 4. Se le informa al sistema que es un pedazo de archivo. 5. Una vez recibido el archivo se le informa al usuario que desea hacer con la

parte del archivo. Si lo desea ingresar a un archivo de su proyecto, o simplemente guardarlo para ser utilizado mas tarde.


27. Caso de Uso: Recibir Proyecto Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción y mantenerla hasta que se termine Frecuencia: Cada vez que el usuario recibe notificación de transferencia de archivo. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando Curso básico de acciones:

1. El servidor IM informa al usuario que un archivo va a ser recibido. 2. El usuario procede a aceptar la transferencia.

ISC-2003-2-4

40

3. La transferencia comienza y el usuario comienza a recibir el archivo. 4. Se le informa al sistema que es un proyecto. 5. Una vez recibido el archivo se descomprime el proyecto y se le pregunta

al usuario si desea crear un nuevo proyecto, agregar este proyecto a uno existente o si simplemente lo desea guardar para luego utilizarlo.

6. En el caso que exista un proyecto con el mismo nombre del que el usuario esta trabajando se le preguntara si desea sobrescribirlo o simplemente agregarle los nuevos archivos faltantes.


28. Caso de Uso: Recibir Parte de Proyecto Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción y mantenerla hasta que se termine Frecuencia: Cada vez que el usuario recibe notificación de transferencia de archivo. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando Curso básico de acciones:

1. El servidor IM informa al usuario que un archivo va a ser recibido. 2. El usuario procede a aceptar la transferencia. 3. La transferencia comienza y el usuario comienza a recibir el archivo. 4. Se le informa al sistema que es una parte de proyecto. 5. Una vez recibido el archivo se descomprime la parte del proyecto y se le

pregunta al usuario si desea ingresar esa parte del proyecto a un proyecto existente o si simplemente desea guardarlo.

6. En el caso que acepte ingresarlo a un proyecto se procede a ingresar los archivos al proyecto ya sea sobrescribiendo o ingresando simplemente los archivos no existentes.


29. Caso de Uso: Enviar Email Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario lo desee. Precondiciones: Sesión establecida, cuenta en el servidor IM y con conexión a Email, conexión al servidor IM establecida y funcionando, y contacto a quien enviarle un Email. Curso básico de acciones:

1. El Usuario decide a que contacto enviarle un Email.

ISC-2003-2-4

41

2. Se le informa al servidor IM que se le desea enviar un Email al contacto 3. El servidor IM responde a donde y como se le debe enviar el Email 4. El sistema SADPD se dirige donde el servidor IM le informo ir. 5. El usuario escribe el Email al contacto.


30. Caso de Uso: Información Email Nuevo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el servidor IM informe sobre nuevos Email. Precondiciones: Sesión establecida, cuenta en el servidor IM y con conexión a Email, conexión al servidor IM establecida y funcionando. Curso básico de acciones:

1. El servidor IM informa al usuario sobre nuevos Email. 2. Se le informa al usuario sobre el nuevo Email.


31. Caso de Uso: Información Cantidad Email Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el servidor IM informe sobre cantidad de Email. Precondiciones: Sesión establecida, cuenta en el servidor IM y con conexión a Email, conexión al servidor IM establecida y funcionando. Curso básico de acciones:

1. El servidor IM informa al usuario sobre la cantidad de Email. 2. Se le informa al usuario sobre su cantidad de Email.


32. Caso de Uso: Adicionar Contacto Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a adicionar. Curso básico de acciones:

ISC-2003-2-4

42

1. El usuario ingresa el nombre de la cuenta (Email del contacto) del contacto.

2. Se envía la información de adicionar contacto al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si se pudo

adicionar el contacto. 4. En caso que responda afirmativamente el contacto es ingresado a la lista

de contactos del usuario Poscondiciones: Elementos por Determinar o Resolver:

33. Caso de Uso: Eliminar Contacto Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a eliminar. Curso básico de acciones:

1. El usuario ingresa el nombre de la cuenta (Email del contacto) del contacto.

2. Se envía la información de eliminar contacto al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si se pudo

eliminar el contacto. 4. En caso que responda afirmativamente el contacto es eliminado de la lista

de contactos del usuario. Poscondiciones: Elementos por Determinar o Resolver:

34. Caso de Uso: Listar Contactos Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Crítica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando. Curso básico de acciones:

1. El usuario solicita su lista de contactos. 2. Se envía la información de listar contactos al servidor IM. 3. El servidor IM responde con la lista de contactos del usuario. 4. El SADPD muestra la actualización de la lista de contactos.


ISC-2003-2-4

43

35. Caso de Uso: Listar Contactos Contrarios

Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Baja Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando. Curso básico de acciones:

1. El usuario solicita su lista de contactos contrarios. 2. Se envía la información de listar contactos contrarios al servidor IM. 3. El servidor IM responde con la lista de contactos contrarios del usuario. 4. El SADPD muestra la actualización de la lista de contactos contrarios.


36. Caso de Uso: Listar Contactos Permitidos Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando. Curso básico de acciones:

1. El usuario solicita su lista de contactos permitidos. 2. Se envía la información de listar contactos permitidos al servidor IM. 3. El servidor IM responde con la lista de contactos permitidos del usuario. 4. El SADPD muestra la actualización de la lista de contactos permitidos.


37. Caso de Uso: Listar Contactos Bloqueados Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando. Curso básico de acciones:

5. El usuario solicita su lista de contactos bloqueados. 6. Se envía la información de listar contactos bloqueados al servidor IM.

ISC-2003-2-4

44

7. El servidor IM responde con la lista de contactos bloqueados del usuario. 8. El SADPD muestra la actualización de la lista de contactos bloqueados.


38. Caso de Uso: Adicionar Contacto Permitido Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a adicionar. Curso básico de acciones:

1. El usuario ingresa el contacto a adicionar en la lista de permitidos. 2. Se envía la información de adicionar contactos permitidos al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si el contacto se

ingreso en la lista de permitidos. 4. El SADPD muestra la actualización de la lista de contactos permitidos.


39. Caso de Uso: Adicionar Contacto Bloqueado Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a adicionar. Curso básico de acciones:

1. El usuario ingresa el contacto a adicionar en la lista de bloqueados. 2. Se envía la información de adicionar contactos bloqueados al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si el contacto se

ingreso en la lista de bloqueados. 4. El SADPD muestra la actualización de la lista de contactos bloqueados.


40. Caso de Uso: Eliminar Contacto Permitido Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos.

ISC-2003-2-4

45

Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a eliminar. Curso básico de acciones:

5. El usuario ingresa el contacto a eliminar en la lista de permitidos. 6. Se envía la información de eliminar contactos permitidos al servidor IM. 7. El servidor IM responde afirmativamente o negativamente si el contacto se

elimino en la lista de permitidos. 8. El SADPD muestra la actualización de la lista de contactos permitidos.


41. Caso de Uso: Eliminar Contacto Bloqueado Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a eliminar. Curso básico de acciones:

1. El usuario ingresa el contacto a eliminar en la lista de bloqueados. 2. Se envía la información de eliminar contacto bloqueado al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si el contacto se

elimino en la lista de bloqueados. 4. El SADPD muestra la actualización de la lista de contactos bloqueados.


42. Caso de Uso: Crear Grupo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Critica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, grupo a crear. Curso básico de acciones:

1. El usuario ingresa el grupo a crear en la lista de contactos. 2. Se envía la información de crear grupo al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si el grupo se

creo. 4. El SADPD muestra la actualización de la lista de contactos.

Poscondiciones:

ISC-2003-2-4

46


43. Caso de Uso: Eliminar Grupo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Critica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, grupo a eliminar. Curso básico de acciones:

1. El usuario ingresa el grupo a eliminar en la lista de contactos. 2. Se envía la información de eliminar grupo al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si el grupo se

elimino. 4. El SADPD muestra la actualización de la lista de contactos.


44. Caso de Uso: Renombrar Grupo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Critica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, grupo a cambiar el nombre y nuevo nombre. Curso básico de acciones:

1. El usuario ingresa el grupo a cambiar el nombre de la lista de contactos. 2. Se envía la información de cambiar nombre al grupo con el nuevo nombre

al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si se cambio el

nuevo nombre al grupo. 4. El SADPD muestra la actualización de la lista de contactos.


45. Caso de Uso: Adicionar Contacto a Grupo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Critica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite.

ISC-2003-2-4

47

Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a adicionar y el grupo a adicionar contacto. Curso básico de acciones:

1. El usuario ingresa el contacto adicionar al grupo en la lista de contactos. 2. Se envía la información de adicionar contactos al grupo al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si el contacto se

ingreso al grupo. 4. El SADPD muestra la actualización de la lista de contactos.


46. Caso de Uso: Remover Contacto de Grupo Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Critica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a remover del grupo. Curso básico de acciones:

1. El usuario ingresa el contacto a remover del grupo en la lista de contactos. 2. Se envía la información de remover contacto del grupo al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si el contacto se

removió del grupo. 4. El SADPD muestra la actualización de la lista de contactos.


47. Caso de Uso: Cambiar Nombre Usuario Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Media Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el usuario solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, nuevo nombre del usuario. Curso básico de acciones:

1. El usuario ingresa el nuevo nombre. 2. Se envía la información de cambiar el nombre al servidor IM. 3. El servidor IM responde afirmativamente o negativamente si el nombre se

cambió. 4. El SADPD muestra el nuevo nombre del usuario.


ISC-2003-2-4

48

48. Caso de Uso: Actualización Lista Contactos

Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Critica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el servidor IM lo solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a remover del grupo. Curso básico de acciones:

1. El servidor IM informa al usuario sobre una actualización sobre su lista de contactos.

2. El SADPD recibe la nueva información sobre la lista de contactos. 3. El SADPD muestra la actualización de la lista de contactos.


49. Caso de Uso: Actualización Lista Contactos Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Critica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el servidor IM lo solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando. Curso básico de acciones:

1. El servidor IM informa al usuario sobre una actualización sobre su lista de contactos.

2. El SADPD recibe la nueva información sobre la lista de contactos. 3. El SADPD muestra la actualización de la lista de contactos.


50. Caso de Uso: Cambio Estado Usuarios Actores: Usuario SADPD, Servidor IM <<system>> Prioridad: Critica Desempeño: No debe bloquear todo el sistema, y debe realizar la acción en menos de 2 segundos. Frecuencia: Cada vez que el servidor IM lo solicite. Precondiciones: Sesión establecida, cuenta en el servidor IM, conexión al servidor IM establecida y funcionando, contacto a remover del grupo. Curso básico de acciones:

1. El servidor IM informa al usuario sobre una actualización sobre el estado de conexión de unos de sus contactos.

ISC-2003-2-4

49

2. El SADPD recibe la nueva información sobre el nuevo estado de conexión.

3. El SADPD muestra la actualización de la lista de contactos. Poscondiciones: Elementos por Determinar o Resolver:

4.2.1 Caso de Uso parte estadística

Ilustración 4 Caso de Uso estadística

4.2.2 Caso de Uso IM - Historial

ISC-2003-2-4

50

Ilustración 5 Caso de Uso Historial-IM

ISC-2003-2-4

51

4.2.3 Caso de Uso IM

Ilustración 6 Caso de Uso IM parte 1

ISC-2003-2-4

52

Ilustración 7 Caso de Uso IM parte 2

4.3 DIAGRAMA DE CLASE DEL SISTEMA SADPD

ISC-2003-2-4

53

Ilustración 8 Diagrama de clase SADPD

4.4 DIAGRAMAS DE SECUENCIAS Ver Anexo de Diagrama de Secuencia.

ISC-2003-2-4

54

5 EL IDE JBUILDER JBuilder es un programa de desarrollo de software especializado en la plataforma Java. Este IDE es bastante popular dentro del mercado por su estabilidad, confiabilidad y la facilidad en el desarrollo de proyectos de software. JBuilder siempre ha estado al día en el desarrollo de aditamentos nuevos para su plataforma; ejemplo de esto es el soporte para el desarrollo de software para móviles (J2ME), WebServices, soporta para Ant, integración con JUnit y con contenedores Web como Tomcat y demás comerciales. La cantidad de aditamentos que posee éste es innumerable pero ciertamente beneficioso para el desarrollo de software ya que lo facilita bastante. JBuilder como herramienta de desarrollo de software es interesante que sobre éste mismo se pueda extender mucho más de lo que ofrece originalmente. Un hecho de esto es que JBuilder ha incrementado considerablemente el número de aditamentos desde su versión 3 hasta la última que es la 8 en donde se tiene por ejemplo fusión con sistemas de optimización de código, formateo de código fuente, deploy de servicios, etc.

5.1 FUNCIONAMIENTO DE JBUILDER JBuilder es un IDE que trae como concepto intrínseco la idea de proyecto, que es el concepto de un conjunto de archivos (archivos de código fuentes, gráficos, xml, librerías, etc.). Además de esto, los proyectos traen consigo cómo se deber realizar la compilación, deploy y ejecución del proyecto. Es ejemplo de esto la capacidad de JBuilder de crear todo tipo de JAR (JAR, WAR, etc.) para realizar el deploy de los proyectos, tales como el deploy de webservices, rmi, corba, etc. Otra facilidad que se ofrece es la capacidad de facilitar al usuario la conexión con diferentes librerías mediante un manejo interno de CLASSPATH, en donde en el momento de la compilación estas librerías se agregan al CLASSPATH del proyecto. En la última versión de JBuilder la 8 y 9, los proyectos traen dentro de sí un manejo del formateo del texto en donde el usuario especifica cómo quiere ver el código fuente (formateo de los espacios, paréntesis, corchetes, etc.). Los proyectos dentro de JBuilder se representan por medio de un árbol, en donde la configuración del proyecto, los archivos de código fuente, los JAR se encuentran dentro de éste. Dependiendo del tipo de archivo, estos tienen un icono que los representa para facilitar al usuario su identificación. A continuación se presenta un ejemplo:

ISC-2003-2-4

55

Ilustración 9 Proyecto en JBuilder

Como se puede observa en la figura superior se presenta el árbol del proyecto SADPD. Apenas comenzando se encuentra el archivo Java HelloWorld dentro del paquete com.apocalipsys.sadpd; también se puede observar un archivo llamado Open Tool Deployment que sirve para realizar el deploy del proyecto dentro de la lib de extensiones de JBuilder. Por otra parte se pueden observar 2 archivos de texto, uno llamado classes.OpenTools que es el archivo de configuración del plugin desarrollado y el archivo things.todo que es un archivo creado para guardar la información de importancia para uno tales como direcciones web de documentación, tutoriales, etc. Otro aspecto común dentro de JBuilder es el concepto de wizard, ya que facilitan a los desarrolladores en liberarse de manejar conceptos complejos y más bien enfocarse en desarrollar software más rápido y sin tanta complejidad, un ejemplo de esto es el wizard del desarrollo de un archivo JAR. Como por ejemplo:

ISC-2003-2-4

56

Ilustración 10Ejemplo de un wizard

El gráfico se muestra un wizard de cómo desarrollar diferentes tipos de JAR tales como applet JAR, WAR, etc. JBuilder además posee templates de archivos tales como JSP, EJB, Java para facilitarle al desarrollador cómo es el esqueleto del archivo. Además de estos templates, se tiene también un sistema de desarrollo gráfico para el desarrollo de GUI de las aplicaciones dentro de los proyectos. A continuación se mencionarán las diferentes partes del GUI dentro de JBuilder:

ISC-2003-2-4

57

Ilustración 11 Esquema del GUI de JBuilder

- Project pane: Es donde se muestra el árbol del proyecto abierto. - Menu Bar: Como cualquier barra de Windows de una aplicación. - Tool Bar: Barra de acceso rápido a los diferentes recursos que ofrece

JBuider tales como compilación, ejecución, búsqueda, etc. - Code Viewer: Aquí se muestra según el archivo el código de este. Por

ejemplo en caso de abrir un JAR aquí aparece en blanco. - File Insight: Se muestra el árbol del contenido interno del archivo

abierto en el Code Viewer. En el caso de archivos Java, muestra los imports del archivo, los métodos, atributos, etc. Para el caso de un JAR, muestra el contenido interno de directorio de éste.

- Status Bar: En esta barra se muestra el status de diferentes operaciones realizadas dentro de JBuilder tales como el tiempo de duración de la compilación, cantidad de errores, etc.

- Message Pane: No mostrado en la gráfica superior; en este lugar se muestra la consola, el monitor de hilos de ejecución, detalles de los errores de compilación, el resultado de búsquedas, etc.

ISC-2003-2-4

58

Todo esto en su gran mayoría, es el esquema grafico de cómo está conformado JBuilder. La idea a continuación es mostrar mediante un ejemplo cómo es el proceso de desarrollo del plugin, su compilación, deploy y ejecución.

5.2 DESARROLLO DE PLUGIN O MODULOS DENTRO DE JBUILDER A continuación se mostrará una guía de cómo es el desarrollo de plugins dentro de JBuilder. Para el desarrollo del plugin, primero, hay que realizar un proyecto dentro de JBuilder (aunque realmente esto no es necesario, ya que se puede desarrollar el plugin en otra plataforma sin ningún inconveniente). La idea de crear el proyecto es realizar un manejo integral de los archivos a utilizar y de cómo se van a desarrollar los diferentes procesos de compilación, deploy y ejecución. Una vez creado el proyecto en JBuilder, se procede a apoyar este con la librería del API de OpenTools, este API es simplemente un JAR con un gran número de clases necesarias para poder acceder a las diferentes partes de JBuilder. Esta asociación del proyecto con el API es simplemente agregar el JAR del API al CLASSPATH del proyecto. Después de haber asociado el API se procede a crear una nueva clase; esta clase creada va a tener como característica principal que va a ser el punto de entrada del plugin, como sucede con los archivos Java ejecutables, o los archivos de Applets de Java, estos poseen siempre un método estático de invocación. Para el caso del archivo ejecutable es el método main para el Applet es el run, para el caso del plugin este método se llama initOpenTool (byte major, byte minor); este método recibe dos parámetros que son la versión del API de OpenTools, el atributo major se refiere a la versión significativa del API de OpenTools y el minor a que versión aumentativa del API de OpenTools. Un ejemplo de esto es el caso de ejecutar el plugin dentro de JBuilder 5 y JBuilder 8, para ambos el atributo major es igual a 4 porque no habido una nueva versión significativa en el API de OpenTools, pero para el minor JBuilder 5 es de 2 y para JBuilder 8 es 5 ya que desde el JBuilder 4 se comenzó a incrementar de uno en uno el API de OpenTools. Para verlo un poco más claro, en JBuilder 5 el API de OpenTools es de versión 4.2 y el de JBuilder 8 es 4.5 con la clase creada, el método correctamente escrito se proceden a importar los diferentes paquetes del OpenTools para poder crear los diferentes elementos dentro de JBuilder. Usualmente estos paquetes son: import com.borland.JBuilder.*; import com.borland.primetime.*; import com.borland.primetime.ide.*;

ISC-2003-2-4

59

Los paquetes anteriores poseen las clases con las cuales el puglin puede interactuar. Ahora a continuación se presentara lo que viene siendo un posible esqueleto para futuros desarrollos de plugins: package com.apocalipsys.sadpd; import Javax.swing.*; import com.borland.JBuilder.*; import com.borland.primetime.*; import com.borland.primetime.ide.*; // Se realiza el import de las diferentes clases que se piensa a utilizar Public class Hello World { //Metodo de entrada del plugin Public static void initOpenToo(byte major, byte minor) { // Se verifica la version de JBILDER para saber si son //compatibles. if(major!=PrimeTime.CURRENT_MAJOR_VERSION){return;} //Por medio de la clase JBuilderMenu a este se le ingresa //un Nuevo item en su lista de menu JBuilderMenu.GROUP_Help.add(new BrowserAction(“Say Hello”) { //Se desarrolla una clase anonima que implemente el //metodo de accion. public void action Performed(Browser browser) { //Se muestra un dialogo cada vez que el usuario presione el boton del menu en help. JoptionPane.showConvirmDialog(null, “Hello, World!”) } } ); } } En esta clase HelloWorld se puede observar con detenimiento el método initOpenTool y los imports que hacen la clase. Esta clase simplemente agrega un nuevo Menultem “Say Hello” al menú Help. Ya teniendo creado todo lo anterior, se procede a crear un archivo de configuración de plugin llamado clases.OpenTools, este archivo de configuración se crea con

ISC-2003-2-4

60

el propósito de indicarle a JBuilder cual es la clase que tiene que ejecutar para poder acceder a inicializar el plugin. La manera de cómo se debe configurar el archivo de classes.OpenTools es la siguiente: OpenTools-UI: com.Apocalipsis.sadpd.HelloWorld Con esta línea escrita por dentro del archivo15 JBuilder puede identificar a quien llamar para ejecutar el archivo. Para realizar el deploy del plugin se procede a compilar el proyecto y crear un JAR del mismo. Este JAR debe contener solamente las clases del proyecto y no debe poseer las librerías del OpenTools, además, se debe poner como manifiesto el archivo classes.OpenTools. Ya teniendo el JAR este se copia al directorio [JBuilder_HOME]\lib\ext. Una vez puesto el JAR en este directorio se procede a cerrar JBuilder y a volverlo abrir, y listo el plugin ya está instalado. Se procede a verificar que esté funcionando mediante la observación que el menú Help aparezca el Menulten “Say Hello”. A continuación se muestra el menú Help sin plugin y con plugin.

Ilustración 12 Ejemplo de plugin OpenTools

5.3 ESPECIFICACIÓN DE LA ARQUITECTURA DE “OPENTOOLS” En la ilustración numero 2 se encuentra la representación de la arquitectura extensible de OpenTools. A continuación se explicará qué es cada sección su definición y qué acceso se le provee al desarrollar.

15 Hay que tener en cuenta que todo archivo classes.OpenTools debe terminar con un fin de línea, es decir con un /r/n como sucede igual cuando uno crea los manifest dentro de los JAR.

ISC-2003-2-4

61

CORE (Núcleo): Está compuesto por el OpenTools Loader Node System y por el Virtual File System (VFS).

- OpenTools Loader: es el cargador de OpenTools, es un mecanismo crítico que es responsable de descubrir todas las extensiones al IDE de JBuilder y de iniciarlas cuando el producto es iniciado. El cargador es también responsable de analizar la línea de comando en el momento de cargar JBuilder.

- Node System: proporciona la infraestructura para manejar los proyectos de JBuilder. Todos los proyectos son instancias que descienden de la clase genérica del proyecto Prime Time, y la mayoría de los proyectos de JBuilder serán realmente casos de la subclase de JBProject. El proyecto maneja una jerarquía de objetos individuales de nodo, típicamente cualquier objeto de FileNode representa un archivo en el VFS, o uno de tipo LightweightNode que representa conceptos lógicos tales como carpetas y paquetes.

- VFS: proporciona el acceso a un sinnúmero de diversas técnicas del almacenamiento, cada uno definidas por la implementación de la interfaz de FileSystem. Por ejemplo los archivos ZIP, archivos físicos (por ejemplo) y documentos sin nombre son tres implementaciones diferentes del FileSystem dentro del Core del VFS.

BROWSER: Está compuesto por el Action FrameWork, Message View, Project View, Status View y por el Content Manager.

- Action FrameWork: es el conjunto de acciones de JBuilder que asocia al ToolBar y al MenuBar. JBuilder representa cada uno de los objetos dentro del ToolBar y el MenuBar como acciones (Acciones se refiere a la clase Javax.swing,action). JBuilder provee un conjunto de acciones asociadas que proveen más funcionalidad como son las acciones de tipo UpdateAction, BrowserAction, StateAction y DelegateAction, cada uno con una manera diferente de representar las acciones de estos menús.

- Message View: es la visualización de Message Panel inicialmente descrito; éste se muestra cada vez que se le adiciona el contenido o cambia. El Message Panel está compuesto por un conjunto de tabs que uno puede decidir como removerlos o crearlos. Estos tabs pueden contener componentes gráficos complejos los cuales se pueden agregar sin ningún problema.

- Proyect View: refleja el estado del proyecto activo dentro de JBuilder, representado visualmente a través de la información disponible del sistema de nodos (Node System). La información se muestra jerárquicamente con sus nombres, íconos y nivel en la jerarquía. La mayoría de la interacción con el Proyect View se hace indirectamente a través del Node System.

- Status View: es la representación de mensajes al usuario de una sola línea, por ejemplo la duración de la compilación, cantidad de líneas de código

ISC-2003-2-4

62

en el archivo abierto actualmente, ayuda corta sobre la información de botones, etc. En caso de que los mensajes sean de más de una sola línea, se aconseja utilizar el Message View.

- Content Managerer: muestra la información del archivo abierto, actualmente aunque, este no se puede remover o cambiar sí se le puede adicionar Tabs para la extensión de la utilidad del archivo abierto, ejemplo de esto son los visualizadores de código UML de archivos de código fuente.

VIEWERS AND EDITORS: Está compuesto por Source Editor y por el Visual Designer.

- Source Editor: se exhibe automáticamente para los archivos de texto. Cada tipo de archivo de texto puede proveer su propio verificador de sintaxis, code insight (ejemplo un visualizador de métodos), un scanner, etc. También se puede agregar shorcuts de teclado para facilitar el desarrollo del código.

- Visual Designer: se exhibe automáticamente para los archivos Java, el cual muestra gráficamente el desarrollo gráfico de una aplicación. Este utiliza el sistema de JavaBeans para presentar la edición de propiedades de componentes. También provee acceso al editor automático de código para la generación de código.

STANDARD PROCESSES: Está compuesto por el Build System, RunTime System y por el Debugger.

- Build System: es responsable de programar las tareas necesarias cuando el usuario invoca la compilación o el rebuild del proyecto. Cada tarea entonces se invoca por turnos y puede divulgar los errores o las advertencias que se acumulan. OpenTools puede agregar tareas en el proceso de la estructura basado en el tipo de nodos seleccionados para la compilación.

- RunTime System: es el encargado de correr los diferentes proyectos según su configuración. Esta configuración puede extenderse y crear nuevos tipos de ejecución mediante la implementación de la clase Runner.

- Debugger: no se puede extender, pero si se puede utilizar y en el caso que se utilice, se puede aprovechar este con todos los beneficios.

CODE GENERATION: Está compuesto por el FrameWork Wizard y por el Java Object Tool (JOT).

- FrameWork Wizard: provee un acceso común de Look and Feel en donde el usuario puede crear Wizards que concuerden con los de JBuilder.

- Java Object Tool (JOT): provee un sistema de parsing de código de fuente y clases, al igual que DOM provee una reflexión del código leído. El JOT también permite la creación y modificación en línea de código, ejemplo de esto es la generación automática del código por parte del Visual Designer.

ISC-2003-2-4

63

USER EXPIRIENCE: Está compuesto por el Properties System, Help y el Utilities Classes.

- Properties System: proveen de un esquema de mantener el Look and Feel que maneja JBuilder. Estos esquemas deben ser extendidos de las clases Propertys.

- Help: ayuda de JBuilder que provee mediante la implementación de un browser de HTML y un sistema de indexamiento basado en la tecnología del JdataStore.

- Utilities Classes: conjunto de clases genéricas que le ofrecen al desarrollador un sistema de utilidades para el desarrollo de los plugins.

5.4 REQUERIMIENTOS TÉCNICOS DEL “SADPD” DENTRO DEL “IDE”

- Poder crear Sockets y Thread. (Requerimiento debido a seguridad). - Acceso al Editor. La idea es poder obtener el texto seleccionado, o poder

agregar texto a un archivo de texto. - Poder obtener datos estadísticos, tales como cantidad de veces de

compilación, errores, cantidad de ejecuciones, debugs, tiempo de estos 2 anteriores, etc.

- Poder ingresar a la interfaz grafica los componentes gráficos que va a mostrar el SADPD.

- Poder obtener datos del proyecto, ingresar archivos al proyecto, y obtener datos de este mismo.

5.4.1 Datos Técnicos de OpenTools El cargador de OpenTools es un sistema simple que hace uso de reflection16, el cual carga la clase registrada dentro del archivo clases.OpenTools. El archivo classes.OpenTools sigue el mismo patrón de construcción que los archivos manifest.mf de los archivos JAR. En este archivo clases.OpenTools se escribe cual es el Loader de OpenTools que se va a utilizar seguido de la clase que se ejecuta, por ejemplo: OpenTools-UI: com.example.ThisClassToRun17 Los archivos clases.OpenTools pueden contener un sin número de clases que ejecutar y diferentes clases de Loaders, por ejemplo cargar un sistema de Core, otro de UI, y otro de Wizard (Como sucede con el proyecto de prueba creado para este

16 Se refiere al hecho de poder obtener un conjunto de métodos y atributos de una clase mediante reflection. La idea detrás de esto es que uno conoce el método de la clase pero no la clase, es por eso que se utiliza el reflection 17 Cabe agregar que los archivos de manifiesto terminan siempre en “/n/r” en la ultima línea.

ISC-2003-2-4

64

informe) y a su vez el Loader de UI puede contener varias clases a ejecutar, un ejemplo a continuación: OpenTools-Core: com.apocalipsys.sadpd.test.EjemploNodeType OpenTools-Wizard: com.apocalipsys.sadpd.test.EjemploWizardConfiguratio OpenTools-UI: com.apocalipsys.sadpd.test.EjemploMenuToolbar com.apocalipsys.sadpd.test.EjemploBuildListener com.apocalipsys.sadpd.test.EjemploContextMenuItem com.apocalipsys.sadpd.test.EjemploMesageViewPane com.apocalipsys.sadpd.test.EjemploNodeFactory com.apocalipsys.sadpd.test.EjemploEditorListener com.apocalipsys.sadpd.test.EjemploPropertySetup com.apocalipsys.sadpd.test.EjemploThreadSocketTest Dentro de esas clases que se mostraron anteriormente cada una de ellas debe implementar un método llamado public static void initOpenTools(byte minor, byte major). En el caso que no se escriba bien, o no se le de la visibilidad correcta18, o no acepte los datos de entradas especificados, durante el cargado del OpenTools, este arrojará una excepción del tipo ClassLoaderException. Una vez que exista el archivo de clases.OpenTools, también debe existir otro archivo que es el JAR de las clases que componen todo el componente de OpenTools desarrollado, este JAR debe tener como manifiesto el archivo clases.OpenTools, por otra parte este archivo JAR debe ser copiado al directorio: [JBuilderRoot]/lib/ext donde JBuilderRoot es el directorio de instalación de JBuilder. Una vez hecho los pasos anteriores, se procede a ejecutar JBuilder. Durante la ejecución inicial de JBuilder, este inicia un sistema de cargado de OpenTools, este revisa todos los JAR dentro de la carpeta [JBuilderRoot]/lib/ext en busca de los manifiestos y comienza a seleccionar el orden como el Loader va a cargar los OpenTools. Un ejemplo de la salida de JBuilder en modo verbose19: --- Initializing OpenTools-Core OpenTool com.borland.JBuilder.build.BuildCommand (681+0ms) OpenTool com.borland.JBuilder.JBuilderCore (0+210ms) Disabling offscreen DirectDraw acceleration

18 Refierase a visibilidad a los atributos de public, protected, y private 19 Este modo muestra en la consola como es el cargado, y la ejecución de los diferentes paquetes de OpenTools

ISC-2003-2-4

65

OpenTool com.apocalipsys.sadpd.test.EjemploNodeType (1222+10ms) --- OpenTools-Core initialized (2123ms total) --- Initializing OpenTools-PreUI OpenTool com.borland.JBuilder.IntlSwing (0+40ms) OpenTool com.borland.JBuilder.util.NullSecurityManager (10+100ms) OpenTool com.borland.JBuilder.teamdev.clearcase.CCProjectInit (0+1462ms) Como se puede observar en el ejemplo del cargado de OpenTools se ve el cargado de la clase “com.apocalipsys.sadpd.test.EjemploNodeType” como parte del cargado de JBuilder. El IDE de JBuilder posee un componente gráfico general que es el llamado Browser. Este componente grafico puede tener 1 ó más instancias siendo cada una, independiente una de la otra (Con sus excepciones de concurrencia). En el caso que no existan más ítems de Browser se conoce como el cierre de JBuilder. El Browser se compone de varios componentes que son:

- MenuBar: como su nombre se refiere, es la barra de menús que se localiza debajo de la franja superior de la ventana. Esta barra de menús contiene diferentes ítems también llamados MenuList, a su vez estos compuestos de MenuItems. Los OpenTools permiten diferentes accesos a esta barra mediante la clase com.borland.JBuilder.JBuilderMenu o mediante la clase com.borland.primetime.ide.Browser. Esta dos accesos son muy diferentes unos del otro mientras el primero es la especificación estricta de como esta compuesto el JBuilderMenu, es decir que ítems lo componen (HelpMenu, FileMenu), la segunda es simplemente un acceso sin conocimiento de los ítems, pero la segunda permite el ingreso de nuevos MenuList que el primero no permite. Claro cabe agregar que por los dos métodos se pueden ingresar nuevos MenuItems. También cabe aclarar que el JBuilderMenu no importa cuantos Browser existan, siempre será el mismo JBuilderMenu, por lo tanto, cualquier cambio a esta clase se ve representado como un cambio a todas los Browser.

- ToolBar: Similar al del MenuBar, este es un conjunto de barra de herramientas que se localiza debajo del MenuBar, esta barra funciona de forma similar a como funciona el MenuBar, con la diferencia que el orden gráfico de esta barra puede ser modificado por el usuario (Mover los conjuntos de herramientas de un lugar a otro). Con respecto a lo de funcionamiento similar, este posee dos tipos de clase donde la clase com.borland.JBuilder.JBuilderToolBar es la de acceso

ISC-2003-2-4

66

específico y la de acceso por Browser es la de acceso general. Y que si se modifica el JBuilderToolBar, este se verá afectado en todas las instancias de los Browser.

- ProjectView: el ProjectView se encuentra localizado en la parte superior izquierda debajo del ToolBar. El ProjectView es la representación en Árbol de lo que viene siendo el proyecto dentro de JBuilder, este puede ser de cero o muchas instancias; en el caso de cero indica que no se tiene un proyecto abierto. Este ProjectView se puede acceder mediante el Browser, o según la documentación de JBuilder preferiblemente por el com.borland.primetime.ide.ProjectView. Para el ProjectView uno puede registrar acciones del tipo de contexto20, estas acciones normalmente asociadas a los nodos, es decir, a la representación de los archivos dentro del proyecto, por ejemplo los archivos JAVA, son llamado JavaFileNode, y los JAR JarFileNode.

- ContentManager: el ContentManager es el encargado de mostrar el contenido de los diferentes archivos, y además de poder mostrar no solo el contenido sino también sus diferentes vistas, por ejemplo un archivo Java se puede ver el código fuente como también su JavaDoc y el uso de JavaBeans por parte del archivo Java. el ContentManager posee cero ó muchos archivos abiertos, cada uno dependiendo del tipo de archivo sus respectivos viewers.

- StructureView: el StructureView se encuentra en la parte inferior izquierda., Este muestra la estructura del archivo actualmente abierto. El StructureView puede ser de cero o una instancia, que este exista o no depende del viewer del nodo. El StructureView para archivos Java posee una estructura de árbol, el cual muestra los atributos, métodos e innerclasses. Tanto el ContentManager y el StructureView pueden extenderse y crearse propios ContentManager y StructureView para los tipos de nodos especializados.

- MessageView: el MessageView es un componente gráfico que tiene la habilidad de poderse esconder y mostrarse, según lo desee el usuario. Este se encuentra localizado en la parte inferior. El MessageView posee una sola instancia, pero a este se le puede ingresar diferentes Tab de Panels21. JBuilder ofrece un método sencillo de ingreso de mensajes al MessageView a un Tab propio del desarrollador del OpenTools. Aunque el MessageView también ofrece métodos de visualización de mensajes complejos tales como árboles, tablas, combobox, etc y conjuntos combinados de estos. Este MessageView es un importante medio de información de mensajes del OpenTools al usuario.

- StatusView: el StatusView es una barra simple que muestra mensajes de una sola línea, tiene siempre una instancia, y este no puede extenderse ya que no existe mucha viabilidad para hacer esto, aunque si permite ser accesible.

20 Las acciones de tipo contexto son cuando se hace clic derecho sobre un area y en este aparece un conjunto de acciones asociadas a esta, por ejemplo hacer clic derecho sobre un archivo aparecerán las opciones de renombrar, abrir, borrar, etc. 21 Tab de Paneles se refiere al conjunto de pestañas que posee un TabPanel

ISC-2003-2-4

67

- EditorManager: el EditorManager es una subinstancia del ContentManager. Este EditorManager es el encargado de manejar los archivos de texto, es decir todos aquellos que poseen caracteres reconocibles por los seres humanos. Este EditorManager provee métodos de registro de acciones de tipo contexto (las acciones de clic derecho). Este también provee de métodos de obtención, modificación, y etc. Aunque el manual recomienda el uso del JOT22 para casos complejos de archivos Java.

- NodeTypes: los NodeTypes son la representación abstracta de los diferentes archivos físicos. La importancia de los NodeTypes es que permiten al usuario diferenciar los archivos uno de otros por su función, descripción, etc. El desarrollador de los OpenTools de JBuilder puede crear sus propios NodeTypes para su mayor facilidad y extensibilidad. Los NodesTypes como se mencionó anteriormente, poseen un sinnúmero de viewers para sus tipos de nodos. Esto permite al desarrollador utilizar estos y extenderlos para crear sus propios viewers.

- Properties: los properties son las propiedades que posee JBuilder para sus diferentes sistemas, que realmente son las propiedades de los nodos del sistema. JBuilder ofrece un FrameWork, según ellos, completo de funciones para esto. Ellos ofrecen un sistema de salvado de propiedades que permite al desarrollador guardar información importante sobre la propiedad del nodo y luego recuperarlo mas tarde sin muchas líneas de código. Además de lo anterior ofrece un conjunto base para la creación de páginas de propiedades que el desarrollador puede implementar, es decir que el usuario puede extender las propiedades de un nodo JAR y agregarles funciones de ultra compresión o funciones de firmas digitales (MD5, SHA1).

- Wizard: los wizard se crearon con la intención de facilitarle al usuario el trabajo de realizar tareas rutinarias y convertirlas en simples clic. JBuilder ya tiene especificado una forma de cómo se deben mostrar los wizard, por eso el desarrollador del OpenTools se puede beneficiar de esto, desarrollando de forma sencilla wizard de apoyo al usuario.

El paquete primetime que posee los OpenTools hace referencia al hecho de clases e interfaces genéricas de JBuilder, mientras que el paquete JBuilder posee clases especificas de JBuilder. Un ejemplo de esto es el paquete com.borland.primetime.viewer contra com.borland.JBuilder.viewer. En el primer paquete se encuentran visualizadores predefinidos como el TextFileNode; mientras que en el segundo se tienen cosas mas especificas como XMLFileNode. Como se observa el TextFileNode es simplemente una clase genérica mientras que el segundo es una clase mucho mas especifica. Para ser más exacto él paquete primetime es el que verdaderamente se debe utilizar para desarrollar los OpenTools, mas sin embargo se pueden utilizar los del paquete de JBuilder con el fin de extenderlo o utilizarlos. En el paquete

22 JOT es la interfaz de JBuilder para la creación y parsing de código Java.

ISC-2003-2-4

68

primetime no se encuentran súbpaquetes como los de Ant, Debugger, etc. En definitiva los ítems dentro del paquete JBuilder vienen siendo los OpenTools, desarrollado por la gente de Borland para JBuilder .

5.4.2 Verificación de la validez de los requerimientos de compatibilidad Socket, Thread: Para este caso se desarrollo un OpenTool (EjemploThreadSoket) con una acción asociada al ToolBar, que este al ser llamado (se presiona la acción), crea un thread y se llaman a los puertos HTTP de los siguientes sitios: www.uniandes.edu.co, www.hotmail.com, www.google.com . El resultado del éxito o fracaso de las conexiones se muestran por la consola.

Ilustración 13 Botón de ejecución de la prueba Socket y Thread

Al realizar la accion el resultado fue el siguiente: Connected to Uniandes Disconnected from Uniandes Connected to Hotmail Disconnected from Hotmail Connected to Google Disconnected from Google Como conclusión, el riesgo a la seguridad de las máquinas o demás no radica en el programa, sino en el administrador de seguridad. Por lo tanto para el proyecto SADPD no existe ningún riesgo asociado con este. . Acceso al editor: Para esto existen 2 ejemplos: el que obtiene estadísticas (EjemploEditorListener) y otro que mediante ContextMenus23 en el Editor, (EjemploContextMenuItem), indica si se seleccionó texto y en el caso que si se haya seleccionado al ejecutar la acción asociada devuelve el texto por la consola Para el primer ejemplo:

23 Menus de clic derecho

ISC-2003-2-4

69

Ilustración 14 Ejemplo de Editor Listener

Se puede ver la acción asociada al menú. El resultado de este menú aparece así, debido a la forma como se construyo este. Al ejecutar la acción aparece lo siguiente:

Ilustración 15 Resultado del ejemplo Editor Listener

Se puede observar como el editor de estadística analiza el documento y averigua cuantas líneas, palabras y caracteres de código fueron desarrollados. Para el segundo ejemplo:

ISC-2003-2-4

70

Ilustración 16 Ejemplo Editor Context Menu

Como se ve cuando se hizo clic derecho sobre el editor apareció el MenuItem No texto seleccionado casi al final del Menu. Cuando se selecciona el texto el resultado es el siguiente:

Ilustración 17 Ejemplo segundo Editor ContextMenu

Con estos dos ejemplos se demuestra el total acceso que ofrece el Editor de JBuilder al desarrollador. Datos estadísticos: Con respecto a este punto se llegó a un reto o mejor dicho a un problema dentro del SADPD. Se descubrió que solo se pueden sacar estadísticas de la cantidad de compilaciones, errores de este, pero no se puede saber cuantas veces se ejecutó este o su duración de la ejecución. Por lo tanto este se vió reducido a implementar la mitad de este. El siguiente ejemplo

ISC-2003-2-4

71

(EjemploBuildListener) demuestra la funcionalidad del monitoreo de las compilaciones:

Ilustración 18 Ejemplo Build Listener

Cada vez que se compilaba se mostraban por la consola los siguientes datos: Numero total de compilaciones: 7 Tiempo total de duracion: 6046ms Con un promedio de duracion: 863.0ms Con un total de errores: 4 Con errores por compilacion de: 0.0 Esta información fue arrojada después de la séptima compilación. Ingresar a la interfaz grafica de JBuilder: Con este se lograron desarrollar varios ejemplos, entre los cuales se encuentra los siguientes: acceso a los menú y toolbar (EjemploMenuToolBar). Creación de un MessageView Propio (EjemploMessageViewPane). Acceso a los menús de contexto (EjemploContextMenuItem). Acceso a las propiedades de los nodos (EjemploPropertySetup). Acceso a los wizard de JBuilder (EjemploWizardConfiguration). Y la creación de un nodo propio (EjemploNodeViewer, EjemploNodeType y EjemploNodeFactory).

Acceso al menú y al toolbar:

Ilustración 19 Ejemplo MenuItem en un Menu

Ilustración 20Ejemplo ToolBarItem en el ToolBar

Este ejemplo agrega un MenuItem y un ToolBarItem a sus respectivos lugares. Acceso al MessageView:

ISC-2003-2-4

72

Ilustración 21 Boton de ejecucion de la prueba Message View

Cuando se ejecuto la acción en el MessageView apareció lo siguiente:

Ilustración 22 Resultado dentro del Message View

Como se puede observar es un Message View propio. Acceso a los ContextMenu: Ya se mostró anteriormente los ContextMenu del editor, ahora se mostraran los del ProjectView.

ISC-2003-2-4

73

Ilustración 23 Ejemplo ContextMenu en el ProjectView

Ilustración 24 Ejemplo 2 del ContextMenu dentro del ProjectView

Se observa que cuando se selecciono el nodo proyecto aparece el ContextMenuItem “Nodo Proyecto, Borrar?”. Pero cuando se selecciona otro tipo de nodo aparece el ContextMenuItem “Otro tipo de nodo”. Acceso a los properties: Para este ejemplo se definió un nuevo tipo de propiedad para los archivos SADPD msn.

ISC-2003-2-4

74

Ilustración 25 Ejemplo de acceso a los properties

Al visualizar las propiedades de este nodo se obtiene el siguiente resultado:

Ilustración 26 Ejemplo Propertie propio

Como se observa se creo un propio property. Esto seria bueno para la configuración del SADPD. Acceso al Wizard: Se creó un wizard para demostrar la funcionalidad de este y como posible método de creación del archivo de configuración del SADPD.

Ilustración 27 Ejemplo de como acceder al wizard SADPD

Se puede ver un nuevo Item dentro de la galería de Wizards. Al ejecutar este obtenemos lo siguiente:

ISC-2003-2-4

75

Ilustración 28 Ejemplo de Wizard SADPD

Al presionar el okay aparece un nuevo item dentro del proyecto.

Ilustración 29 Resultado después de ejecutar el wizard SADPD

Y al abrirlo aparece lo que se escribió en el wizard. Acceso a visualizadores de nodos propios:

Ilustración 30Ejemplo de visualizador de nodo propio

Se creo un nuevo tipo de viewer llamado el MSN Viewer. Y al acceder a ese viewer se obtiene lo siguiente:

ISC-2003-2-4

76

Ilustración 31 Resultado del viewer de nodo propio

Ahora se tiene un nuevo tipo de viewer asociado a un nuevo tipo de nodo. Acceso a los archivos del proyecto: Este ejemplo es el mismo desarrollado para el wizard (EjemploWizardConfiguration). Por lo tanto se vuelve un poco redundante volverlo a explicar. El ejemplo wizard accede al nodo proyecto y obtiene la dirección en disco de la raíz del proyecto, luego se le ingresa un nuevo archivo o mejor dicho un nuevo nodo el cual se le asocia con el nodo padre del proyecto. Por eso después de ejecutar el wizard aparece el archivo config.msn.

ISC-2003-2-4

77

6 EL SERVICIO “MSN INSANT MESSENGER” La mensajería instantánea es el medio revolucionario en la actualidad. Es un estilo de chat personalizado, donde la privacidad de la conversación es lo prioritario. Esta comunicación es directa, inmediata y con retroalimentación instantánea, de la misma forma que una conversación normal por teléfono, por ejemplo: en el caso de la mensajería instantánea de MSN Instant Messenger (MSN IM), este servicio no solo incluye el servicio de mensajería instantánea, sino un mundo de servicios adicionales tales como el conocer el estado de conexión del compañero, manejar niveles de privacidad, según lo desee el usuario; poder manejar de quienes desee contactarse y que lo contacten, tener acceso al email, envió de archivos etc. A continuación se mostrara como es el funcionamiento del servicio MSN IM, sus servidores, su protocolo, y como funciona24.

6.1 TIPOS DE SERVIDORES El servicio de MSN IM posee tres tipos de servidores, y cada uno maneja un subconjunto de comandos, estos servidores son: DISPATCH, NOTIFICATION y el SWITCHBOARD.

- El servidor DISPATCH es el encargado de establecer a que servidor de NOTIFCATION debe conectarse el cliente. Este servicio lo hace con el fin de manejar el balanceo de carga dentro de los servidores de NOTIFICATION.

- El servidor NOTIFICATION es el encargado de manejar toda la información referente al usuario y los servicios del servidor, tales como cantidad de emails nuevos, lista de contactos, estado del usuario, adición de usuarios, etc.

- El servidor SWITCHBOARD es el encargado de realizar las comunicaciones entre usuarios. Tales como envío de invitaciones, mensajes instantáneos y mensajes de control de mensajes instantáneos.

Estos servidores utilizan conexiones de tipo TCP/IP usualmente con conexión al puerto 1863.

6.2 ESTRUCTURA LÓGICA La estructura lógica de un usuario del servicio MSN IM es la siguiente:

24 La documentación a continuación es una recopilación adaptada de varios sitios de Internet [1] [2]. Para información mayor información dirigirse a la bibliografía.

ISC-2003-2-4

78

El usuario posee cuatro listas de contactos que son: lista de contactos, lista de contactos permitidos, lista de contactos bloqueados y lista de contactos en reversa, y adicionalmente posee una lista de grupos.

- Lista de contactos (FL): Es la lista de contactos con los que se puede realizar mensajería instantánea, invitaciones a programas y transferencias de archivos.

- Lista de contactos permitidos (AL): Es la lista de los contactos amigos con los cuales no se tiene problema de que vean el estado de usuario, recibir mensajes instantáneos, invitaciones, etc.

- Lista de contactos bloqueados (BL): Es la lista de los contactos amigos con los cuales se tiene el problema de que se vea el estado de usuario, recibir mensajes instantáneos, invitaciones, etc.

- Lista de contactos en reversa (RL): Es la lista de los contactos amigos que tienen al usuario del servicio dentro de la lista de sus contactos.

- Lista de grupos (GL): Es la lista de los grupos que posee el usuario dentro de su FL. Todo contacto dentro de la FL tiene un grupo al cual esta asociado.

- Hay una regla que hay que tener en cuenta y es que no se puede tener un contacto dentro de la AL y la BL al mismo tiempo si uno trata de realizar esto, el servicio de MSN IM envía un error al cliente. Las listas de AL y BL se crearon con el fin de establecer de quienes se quieren recibir mensajes y de quienes no, por lo tanto es normal que toda la gente dentro de la FL o la RL este dentro de la AL o la BL. Si un contacto esta en la RL y no esta ni en la AL o BL, es un contacto que lo adicionó a uno dentro de su FL y esta solicitando que lo ingresen dentro de la FL de uno. Si una persona esta dentro de la AL o BL y no esta dentro de la RL es que ese contacto ya no desea hablar con uno, por lo tanto, eliminarla de la AL o BL no molesta. Si se trata de ingresar una persona dentro de la RL, el servicio de MSN IM retorna un error. Cabe agregar que todos los contactos dentro de la FL obligatoriamente deben de ir dentro de un grupo. Osea que la FL posee una lista de grupos, estos grupos poseen un identificador de grupo al cual se le asigna a cada uno de los contactos de ese grupo. La GL viene establecida por defecto, es decir que siempre se posee una al iniciar una cuenta. Además de la lista de contactos y grupos, el usuario como sus contactos tiene un listado de teléfonos de contacto. También para seguridad del usuario el servicio MSN IM ofrece un sistema de privacidad en donde el usuario del servicio establece si los usuarios, que solo están en su AL, lo contacten, o si todos los usuarios que no están en su BL lo contacten. Por otra parte el servicio de MSN IM ofrece la posibilidad de que el cliente adicione contactos automáticamente o manualmente. El usuario siempre tiene un estado de conexión de acuerdo con su situación y estas son: conectado (NLN), desconectado (FLN), escondido (HDN), ocupado (BSY), idle

ISC-2003-2-4

79

(IDL), ya regreso (BRB), ausente (AWY), en el teléfono (PHN) y comiendo (LUN)25 .

6.3 PROTOCOLO MSN IM El Protocolo del MSN Instant Messenger utiliza un protocolo verbal no encriptado, en donde los comando que envía el cliente y los que recibe del servidor son en caracteres de texto y no comandos binarios como sucede en otros servicios de mensajería instantánea como son el ICQ y el AIM. También la codificación de caracteres que se utiliza dentro del protocolo es de tipo UTF-8 compatible con la tabla ASCII. El protocolo del MSN IM es un protocolo de comunicaciones cliente/servidor. Este protocolo tiene la característica que es 100% asincrónico, es decir que no se sabe cuando el cliente envía un comando y el servidor responda con la respuesta del comando enviado. El protocolo del MSN IM consta de dos tipos de comandos: los comandos normales y los comandos con carga.

6.3.1 Comandos normales Los comandos normales son comandos de una sola línea, que poseen como estructura lo siguiente: CMD [TranID] [Param1] [Param2] … [ParamN]\r\n. En donde CMD es una instrucción de tres letras, TranID es el identificador de transacción del comando y Param1, Param2, ParamN son la lista de parámetros del comando y el \r\n es el indicador de fin de comando. Ejemplo de comandos normales son los siguientes: >>> CHG 12 NLN\r\n (Comando enviado por el cliente “>>>”) <<< CHG 12 NLN 0\r\n (Comando recibido por el cliente “<<<”) Se puede observar el comando de instrucción CHG que se refiere a cambiar el estado del usuario, 12 que es el número de transacción, NLN y 0 que son parámetros de la instrucción del comando, y el \r\n que es el indicador de fin de línea.

25 Para saber más sobre el estado de conexión diríjase a la sección de estado de conexión.

ISC-2003-2-4

80

6.3.2 Comando con carga Los comandos con carga son los mismos comandos normales pero estos tienen una adición de carga dentro de sus mensajes, es decir que el comando de carga consta de dos partes: el comando normal seguido de la carga de comando. Debido a que la carga no posee indicadores de fin tales como \r\n entonces estos se delimitan por el último parámetro del comando normal. Esta delimitación se realiza por medio de la indicación de la cantidad de caracteres que posee la carga. La estructura normal de un comando de carga es el siguiente: CMD [TranID] [Param1][Param2]… [Param N-1] [TamCarga]\r\n Hola Mundo Que mas. (Donde Hola Mundo\r\nQue mas tiene TamCarga caracteres, nótese que visualmente \r\n no se ve pero este va dentro de la cuenta de caracteres.) Estos comandos de carga son solo utilizados por las instrucciones MSG, QRY, PAG y NOT. Para el caso de comandos de carga del MSG la carga viene en formato MIME como esta descrito dentro del RFC 1521. Dentro de la explicación del comando MSG se dará una mejor explicación de cómo es la estructura del comando. En el comando QRY su carga corresponde a caracteres hexadecimales (0123456789abcdef). El comando PAG y NOT su carga son mensajes XML indicando su contenido. Es interesante observar la cantidad de información que se puede enviar dentro de la carga. Un ejemplo de un mensaje de carga es el siguiente: QRY 1049 [email protected] 32\r\n 8f2f5a91b72102cd28355e9fc9000d6e Observe el comando normal corresponde a la primera línea del ejemplo que posee instrucción, TranID y dos parámetros donde el ultimo indica el largo del comando o sea 32 y se observa la carga esta corresponde a treintaidos caracteres y estos caracteres están en formato hexadecimal.

6.3.3 Identificador de transacción (TranID) El TranID es un identificador que poseen la mayoría de comandos, y este parámetro sirve para identificar cual fue la respuesta a la pregunta que se le hizo al servidor tratando de dar solución al problema de la asincronía dentro del protocolo. Por ejemplo, si se le envió al servidor VER 1 MSNP8 y el servidor respondió VER 1 MSNP8. Se observa que el TranID es 1 y que la respuesta del comando VER 1 MSNP8 es VER 1 MSNP8. O si se envió GTC 22 N que tiene como parámetro N

ISC-2003-2-4

81

invalido el servidor responderá con 218 22. El 218 es un código de error utilizado por el servidor para indicar que hubo un error y de que tipo fue. Se nota el TranID es 22 en ambos mensajes y que la respuesta para el comando enviado fue un error. Cada vez que se envía un comando con TranID este identificador aumenta en 1 por ejemplo si el TranID es 5 el siguiente es 6 y si se envía otro comando el siguiente es 7 y así sucesivamente.

6.4 VERSIONES DEL PROTOCOLO “MSN IM” Actualmente el servicio de MSN IM posee diez tipos versiones públicas de su protocolo siendo la MSNP10 la última de ellas. Esta ultima apareció cuando se público el MSN IM versión 6.1*. Para Octubre 15 del 2003 se prohibió la utilización del MSN IM version 4.* hacia abajo sin soporte para el protocolo MSNP8 debido a problemas de seguridad. Por lo anterior actualmente el MSNP8, MSNP9 y el MSNP10 son los actualmente utilizados y los únicos que se pueden utilizar con los servicios de MSN IM. El MSNP8 es la más fácil de entender e implementar. La documentación sobre el protocolo MSNP9 y MSNP10 es compleja y difícil de entender, por lo tanto se documentara todo sobre el protocolo MSNP8.

6.5 UTILIZACIÓN DEL PROTOCOLO “MSNP8” Para la utilización de este protocolo hay que conocer que comandos van dentro del servidor SWITCHBOARD, NOTIFICATION y el DISPATCH. Además de esto las conexiones que se realizan a estos servidores son tipo TCP/IP normalmente al puerto 1863 aunque esto no es obligatorio. El protocolo MSNP8 utiliza una codificación de caracteres Unicode UTF-8 para el envío de mensajes con carga y codificación URL para parámetros que posean caracteres de escape tales como \r\n, el espacio, las comillas, etc. Es importante también poseer un sistema de transformación de mensajes a hash de tipo MD5, ya que existen partes del protocolo donde se envían hash de tipo MD5 al servidor. Para la estructura de los comandos normales recordar que siempre finalizan con un \r\n y que en cambio los mensajes con carga no siempre lo son. Para una mejor compresión de cómo se utiliza este protocolo diríjase a los ejemplos de autenticación, Anexo de comandos de protocolo.

6.5.1 Autenticación dentro del servicio “MSN IM” Para la utilización del protocolo se tiene que hacer un primer gran paso que es el de la autenticación26. Ya una vez autenticados se podrá enviar y recibir todo tipo de comandos. Para poder realizar la autenticación dentro del MSN IM primero se tiene

26 Para una mejor guía proceda a leer estas instrucciones a la vez que lea el anexo de ejemplo de autenticación.

ISC-2003-2-4

82

que acceder al servidor DISPATCH que es el messenger.hotmail.com en el puerto 1863. En este servidor se envía los comandos de manera ordena y de forma sincrónica es decir una vez recibido la respuesta del mensaje hay que devolver la respuesta. En caso que no se haga de la forma correcta, sucederá un error y el servidor se desconectará del cliente. El primer comando que se envía es el comando VER con el tipo de protocolo soportado que será el MSNP8 y con chequeo de versión ósea el parámetro CVR0. Cuando se envía este comando se recibe del servidor el comando VER con sus parámetros para este caso será el MSNP8 y CVR0 como protocolos soportados. Después el cliente tiene que enviar el comando de chequeo de versión de MSN IM CVR este comando se le envía el tipo de versión de IM que se utiliza, tipo de Windows etc., y con el email del usuario que tiene registrado a su cuenta. El servidor responde con la versión del último IM, y de donde bajarlo. Una vez chequeado la versión se procede a realizar la autenticación del usuario, se envía el comando USR con TWN como procedimiento de autenticación, y como parámetro que el usuario se esta identificando y, ultimo parámetro el email del usuario registrado. Pero como estamos en el servidor DISPATCH este nos responderá con un comando de cambiar de host llamado XFR el cual nos indica dentro de sus parámetros el tipo de servidor al cual nos conectamos NS (NOTIFICATION SERVER) y el ip y puerto del nuevo servidor al cual debemos realizar la autenticación. Se procede a realizar la conexión al servidor de NOTIFICATION y se realizan los pasos exactamente como se realizo en el DISPATCH, es decir se envía la instrucción VER, luego la CVR y luego la USR pero en vez de recibir el XFR al enviar la instrucción USR este nos envía devuelta el comando USR con 3 parámetros el TWN S y una cadena de caracteres larga, que se utiliza luego dentro de la autenticación. Si el servidor respondió con un TWN dentro de su instrucción USR habrá que realizar una autenticación a través del sistema de Passport de Microsoft. El servicio de Passport tiene como fin ahorrar al usuario final el crear cuentas distintas en todos los diferentes servicios de Microsoft, mediante la creación de una sola cuenta universal que le permite al usuario ingresar a diferentes servicios, con un mismo login y password. Para realizar la autenticación dentro del servicio Passport se requieren los siguientes datos:

- Login del usuario (usualmente es la cuenta de correo con la cual se inscribió). - Password. - La cadena larga del comando USR que se recibió del servidor o el challenge.

ISC-2003-2-4

83

Una vez se tengan los datos se procede a realizar una conexión de tipo HTTPS al servidor nexus.passport.com. Este servidor al igual que el DISPATCH tiene la funcionalidad de redirigir al cliente hacia el verdadero servidor de autenticación. Al servidor nexus se le envía la siguiente información: >>> GET /rdr/pprdr.asp HTTP/1.0\r\n \r\n Este servidor responde con un encabezado HTTPS sin contenido, lo importante no es el contenido sino el encabezado de PassportURLs: porque dentro de este encabezado se encuentran los diferentes URL que utiliza Passport que para nuestro caso tenemos que ingresar al servicio de Login, por eso tomaremos el URL de DALogin. Usualmente este DALogin tiene como valor “login.passport.com/login2.srf”. Una vez se sepa a que servidor se tiene que conectar, se procede a realizar otra conexión a este nuevo servidor otra vez por el protocolo HTTPS, pero esta vez se envía una información adicional que corresponde a la autenticación del servidor. El tipo de formato de autenticación se muestra a continuación: >>> GET /login2.srf HTTP/1.1\r\n >>> Authorization: Passport1.4 OrgVerb=GET,OrgURL=http%3A%2F%2Fmessenger%2Emsn%2Ecom,sign-in=example%40passport.com,pwd=password,lc=1033,id=507,tw=40,fs=1,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1062764229,kpp=1,kv=5,ver=2.1.0173.1,tpf=43f8a4c8ed940c04e3740be46c4d1619\r\n >>> Host: login.passport.com\r\n Debido al formato del mensaje la parte del encabezado de Authorization solo corresponde a una línea de texto y no como aparece dentro del documento. Cabe anotar que el único encabezado que hay que agregar es el Authorization. Este encabezado se crea de la siguiente forma. Se crea una cadena de caracteres el cual comienza con la cadena: “Passport1.4 OrgVerb=GET,OrgURL=http%3A%2F%2Fmessenger%2Emsn%2Ecom,” (nótese que no hay nueva línea). Esta cadena representa que servicio estamos pidiendo para autenticación. Luego se le agrega la cadena siguiente: “sign-in=example%40passport.com,pwd=password,” Esta cadena corresponde a la parte de autenticación. La parte de “sign-in=” y la parte de “pwd=” son constantes, pero la parte de “example%40passport.com” y “password” son variables y corresponde la primera al login que usualmente es la cuenta de correo

ISC-2003-2-4

84

del usuario y la segunda que es password del usuario, pero la cuenta de correo y el password deben de ir en formato URL27. Por ejemplo esta la cuenta de [email protected] y tiene como password holamundo este debe tener como cadena lo siguiente: “sign-in=Juanpedro%40hotmail.com,pwd=holamundo,” Y por ultimo viene la cadena del challenge que se obtuvo dentro del comando USR que envió el servidor. Este challenge se le concatena al resto de la cadena formando una sola, de la siguiente forma: Passport1.4 OrgVerb=GET,OrgURL=http%3A%2F%2Fmessenger%2Emsn%2Ecom,sign-in=Juanpedro%40hotmail.com,pwd=holamundo,lc=1033,id=507,tw=40,fs=1,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1062764229,kpp=1,kv=5,ver=2.1.0173.1,tpf=43f8a4c8ed940c04e3740be46c4d1619 (Nótese que es solo una línea). Una vez se forme el encabezado dentro del paquete se procede a enviar la información al servidor. Este responderá según el éxito de la autenticación con el código de respuesta HTTPS con:

- 302: Habrá que redirigirse a otro servidor. Si este es el caso se tendrá que repetir la secuencia de autenticación con el nuevo servidor que se obtiene del encabezado location. Simplemente habrá que rehacer la cadena de authorization pero en vez de usar el servidor DALogin del servidor nexus se utiliza el servidor del encabezado location.

- 401: El login o el password están erróneos por lo tanto la autenticación se termino y habrá que solicitar al usuario de nuevo el login y el password.

- 200: Para este caso la autenticación fue todo un éxito por lo tanto se tendrá que obtener el ticket. Este ticket se encuentra dentro del encabezado Authentication-Info este comienza desde la parte de “‘t=hgdhdg...” hasta la finalización de la comillas sencillas “jdhjdhdkjhjkd’”. Las comillas no son necesarias pero la parte del t= hasta el final de las comillas es la parte importante28. Esta información corresponde al ticket y este se guarda con el propósito de enviárselo al servidor NOTIFICATION.

Una vez finalizado la autenticación se procede a realizar la parte final de la autenticación dentro del servidor NOTIFICATION. Para esto se envía al servidor el comando USR con los parámetros TWN S y el ticket que se obtuvo del servidor de 27 Para mayor información sobre el formato URL diríjase al glosario y busque formato URL. 28 Para mejor comprensión de que es el ticket diríjase al glosario y también al ejemplo de la autenticación en donde se muestra cual es la cadena del ticket.

ISC-2003-2-4

85

autenticación Passport. Si resulta válido este ticket, entonces el servidor responderá con la siguiente información: <<< USR 4 OK [email protected] JUANPEDRO%20amigo 1 0\r\n Como se observa, el servidor devuelve la instrucción USR, como parámetro un OK que indica éxito dentro de la autenticación, y devuelve 4 parámetros adicionales: el primero corresponde al email del usuario, el segundo corresponde al nombre de apariencia del usuario en formato URL; el tercero indica si el usuario esta habilitado dentro del Passport, normalmente es 1 y el ultimo tiende a ser siempre 0 sin ninguna razón. Una vez se reciba este parámetro del servidor, el proceso de la autenticación esta terminada y ya se puede proceder a ejecutar todos los comandos permitidos dentro del servidor NOTIFICATION.

6.5.2 Mensajes Iniciales del NOTIFICATION después de la autenticación Cuando el usuario se autentica, este recibe dos mensajes (cuando se refiere a mensajes dentro del protocolo se refiere a un comando con carga llamado MSG): el primer mensaje que el cliente recibe es el de text/x-msmsgsprofile: MSG Hotmail Hotmail 432\r\n MIME-Version: 1.0\r\n Content-Type: text/x-msmsgsprofile; charset=UTF-8\r\n EmailEnabled: 1\r\n MemberIdHigh: 84352\r\n MemberIdLow: 1317109683\r\n lang_preference: 1033\r\n preferredEmail: \r\n country: UK\r\n PostalCode: \r\n Gender: \r\n Kid: 0\r\n Age: \r\n BDayPre: \r\n Birthday: \r\n Wallet: \r\n Flags: 1031\r\n sid: 507\r\n kv: 5\r\n MSPAuth: 4sCuECZ4UsAaBIy0AIsk!c9bWcuATTmuQ$$\r\n ClientIP: 81.99.77.64\r\n ClientPort: 260\r\n \r\n

ISC-2003-2-4

86

En este mensaje se observa la información del usuario dentro del servidor de correo Hotmail u otro servicio de correo. Por ejemplo el encabezado EmailEnabled: 1 se refiere a que posee email activado. De este mensaje los encabezados más importantes son: EmailEnabled que indica si tiene email activado, sid, kv y MSPAuth que se son los valores que se utilizan para revisar el email29. El ClientIP y el ClientPort, el primero indica cual es el IP de donde el usuario se esta comunicando y el segundo el puerto que esta utilizando el usuario en la comunicación. Cabe anotar que el valor del ClientPort esta byteswapped, es decir que el byte primero y el byte segundo de un mensaje están intercambiados y para solucionar esto hay que realizar el siguiente calculo: ((ClientPort AND30 255) * 256) + ((ClientPort AND 65280) / 256) con este método se puede realizar el byte-swapping necesario para obtener el verdadero valor del puerto del cliente. Cuando se obtiene el valor del IP y puerto de la tarjeta de red del usuario y se compara con la devuelta dentro del mensaje y este resulta que no hay diferencia, entonces lo que se tiene es una conexión directa pero, si el valor del IP del usuario o el valor del puerto del usuario no coincide con el valor del IP o puerto que envió el servidor entonces, la conexión que se tiene con el servidor puede ser que se realice a través de un NAT o un servidor Proxy, por lo tanto hay que establecer dentro del cliente que se esta realizando una conexión NATTED. El segundo mensaje que se obtiene del servidor es el mensaje de text/x-msmsgsinitialemailnotification. Este mensaje no es obligatorio ya que existe la posibilidad de no tener la cuenta de correo activada. Si se tiene la cuenta de correo activada dentro del servicio MSN, entonces este mensaje llegara al usuario. En este mensaje enviado por el servidor se encuentran los datos esenciales de la cuenta de correo del usuario, la información puede ser la cantidad de email nuevos en el fólder de INBOX o en otras carpetas, también se encuentran los URL’s para el chequeo de email. Un ejemplo de un mensaje text/x-msmsgsinitialemailnotification es: MSG Hotmail Hotmail 221\r\n MIME-Version: 1.0\r\n Content-Type: text/x-msmsgsinitialemailnotification; charset=UTF-8\r\n \r\n Inbox-Unread: 1\r\n Folders-Unread: 0\r\n Inbox-URL: /cgi-bin/HoTMaiL\r\n

29 Para averiguar más información de cómo chequear el email a través del servicio MSN, diríjase a la sección de chequeo de email. 30 Este AND es BITWISE es decir que se realiza un AND no de un booleano contra otro booleano sino de un conjunto de voléanos contra otro mismo conjunto de voléanos (el tamaño de los 2 conjuntos debe ser igual recomendablemente. Ejemplo 10101010 AND (BITWISE) 10000000 = 10000000)

ISC-2003-2-4

87

Folders-URL: /cgi-bin/folders\r\n Post-URL: http://www.hotmail.com\r\n \r\n Se observan los encabezados Inbox-Unread que indican los emailes no leídos en la carpeta Inbox, lo mismo sucede para el encabezado Folders-Unread. Y los encabezados de URL para el chequeo de email: Inbox-URL, Folders-URL y Post-URL31.

6.5.3 Apareciendo online dentro del servicio “MSN IM” Después de haber realizado la autenticación dentro del servidor NOTIFICATION, el estado inicial del usuario es de OFFLINE para cambiar este estado, se procede a enviar al servidor el comando CHG con el TranID y con el nuevo estado que puede ser: NLN, HDN, IDL, AWY, BSY, BRB, PHN, LUN. Ahí que anotar que el estado FLN no se puede establecer ya que es un estado invalido, si se quiere aparecer offline o desconectado se tendrá que establecer el estado como HDN que es escondido. Cuando se envía al servidor NOTIFICATION, este comando por primera vez, aquel no solo responde con la confirmación del nuevo estado, sino con la confirmación de los nuevos estados de los contactos. Por ejemplo: >>> CHG 12 NLN\r\n <<< CHG 12 NLN\r\n <<< ILN 12 AWY [email protected] Mike\r\n <<< ILN 12 NLN [email protected] Name_123\r\n <<< ILN 12 BSY [email protected] My%20Name\r\n Se observa que hay más de un comando con más de una misma TranID, esto se debe a la respuesta del servidor de saber cual es el estado de cada uno de los contactos. Por defecto los contactos con estado FLN no aparecen dentro de la respuesta del servidor. El comando ILN indica los estados de los contactos dentro de la FL que se encuentran ONLINE.

6.5.4 Sincronización de Lista de contactos Para obtener la lista de contactos del usuario se puede obtener mediante el envió del comando de sincronización SYN. Este comando tiene como único parámetro el identificador de lista. El identificador de lista es un número que representa los cambios que ha sufrido la información de contactos del usuario. Cuando se envía el comando SYN con parámetro 0 en su identificador de lista, este envía todo la lista

31 Para averiguar más información de cómo chequear el email a través del servicio MSN, diríjase a la sección de chequeo de email.

ISC-2003-2-4

88

completa de contactos, grupos y configuración de seguridad. Si en cambio al servidor se le envía el comando SYN con un número diferente de 0, el servidor responderá con los cambios que ha sufrido la lista desde el identificador de lista hasta el actual identificador de lista que se encuentra en el servidor. Si sucede el caso en que el identificador de lista del usuario es igual al del servidor, el servidor responderá solo con el comando de confirmación SYN. Ejemplo: >>> SYN 1 0\r\n <<< SYN 1 139 5 4\r\n <<< GTC A\r\n <<< BLP AL\r\n <<< PRP PHH 01%20234\r\n <<< PRP PHM 56%20789\r\n <<< LSG 0 Other%20Contacts 0\r\n <<< LSG 1 Coworkers 0\r\n <<< LSG 2 Friends 0\r\n <<< LSG 3 Family 0\r\n <<< LST [email protected] user1 4\r\n <<< LST [email protected] user2 10\r\n <<< LST [email protected] user3 11 0,1,2,3\r\n <<< LST [email protected] user4 11 0\r\n <<< BPR PHH 01%20234\r\n <<< BPR MOB Y\r\n <<< LST [email protected] user5 12\r\n Para este caso como se le envió el comando SYN con parámetro 0, el servidor respondió con todo el listado de contactos, grupos, teléfonos y configuraciones de privacidad. Más tarde se dará una mejor descripción de cada comando dentro del SYN. Un ejemplo de un SYN con el mismo identificador de lista dentro del usuario como dentro del servidor: >>> SYN 1 139 \r\n <<< SYN 1 139 0 0\r\n Se observa que el servidor respondió sólo con el comando SYN. Esto se debe a que no existe ninguna actualización de lista de contactos, grupos, privacidad.

6.5.4.1 Comando SYN El comando SYN va siempre acompañado del TranID, acompañado luego del identificador de lista. El identificador de lista debe ser mayor a cero o igual o menor que el identificador de lista del servidor. El servidor siempre responderá el comando SYN de la siguiente manera, primero el TranID igual al que mandó el cliente, luego el último identificador de lista, seguido del numero de contactos dentro de las

ISC-2003-2-4

89

diferentes listas de contactos (FL, RL, AL, BL) y finalmente el número de grupos. Además de esto el servidor responderá con los siguientes comandos GTC, BLP, PRP, LSG, LST y BPR que se explicará cada uno a continuación:

6.5.4.2 Comando GTC El comando GTC es uno de los dos valores de privacidad que maneja el cliente. Este comando sirve para decirle al cliente que los nuevos contactos, es decir aquellos contactos que no están en la BL o AL, pero sí están en la RL, debe adicionarlos automáticamente o manualmente a la lista de contactos FL. Este comando cuando aparece dentro de un SYN no tiene TranID, y sólo devuelve A o N. Si el servidor devuelve A, el cliente debe preguntarle al usuario si ingresa a los nuevos usuarios dentro de la AL o la BL y si desea ingresarlo dentro de la FL dentro de un grupo. En caso que sea N el cliente automáticamente debe ingresar el nuevo contacto dentro de la AL. El usuario también puede cambiar el valor de GTC mas no lo puede consultar fuera del SYN. Para cambiar el valor del GTC hay que enviar al servidor el comando GTC TranID y el valor de GTC deseado ya sea A o N, enviar uno diferente causa un error y el servidor cerrara la conexión al cliente. En caso que el nuevo GTC que se le envió al servidor sea igual al que esta en el servidor, este ultimo responderá con un error pero no cerrara la conexión. En caso que sea exitoso el servidor responderá con el comando GTC luego el TranID, luego el nuevo valor del identificador de lista seguido por el valor del GTC dado por el usuario. Ejemplo: >>> GTC 20 A\r\n <<< GTC 20 200 A\r\n >>> GTC 21 N\r\n <<< GTC 21 201 N\r\n Se observa el cambio del identificador de lista, que pasa del 200 al 201 cuando se produce un cambio dentro de la estructura de la lista.

6.5.4.3 Comando BLP El comando BLP representa el nivel de privacidad del usuario. Este nivel de privacidad se ve reflejado en cuanto desea el usuario qué personas extrañas a su AL lo contacten. Existen dos valores para esta situación, el valor de AL que indica que personas solo dentro del AL pueden invitar al usuario a conversaciones. Si el valor es BL entonces todas las personas menos las del BL podrán invitar al usuario a conversaciones con este. Este comando al igual al GTC solo se podrá consultar dentro del SYN, pero se puede cambiar enviando el comando BLP con el TranId y luego el valor que se quiere establecer ya sea AL o BL. El servidor responderá con el comando

ISC-2003-2-4

90

BLP, el TranID, con el identificador de lista y finalmente la confirmación del valor enviado. Si se envía un valor diferente al AL o BL, este servidor este desconectará al cliente de la conexión. En el caso que se establezca de nuevo el mismo valor de BLP, el servidor responderá con un error, pero se mantendrá la conexión.

6.5.4.4 Comando PRP Este comando aparece en el SYN usualmente debajo del GTC y el BLP, en el caso que alguno de los dos aparezca. Este comando representa los valores de configuración telefónica del cliente. El propósito de este comando es con propósitos informativos a excepción del establecimiento de una comunicación a través del MSN IM con aparatos móviles, es decir el poder enviar mensajes cortos a los contactos a través de su equipo móvil. Por propósitos de este trabajo realizado no se documentara como se realiza el envío de mensajes a equipos móviles. El comando PRP es el encargado de listar los valores telefónicos del usuario dentro del mensaje SYN. También se puede establecer los valores de este. Cuando se envía el comando SYN, el servidor responderá con el comando PRP, sin TranID seguido del valor del tipo de teléfono y el valor de este tipo de teléfono en codificación URL. Los valores de tipo de teléfono son: PHH (Teléfono de casa), PHW (Teléfono del trabajo), PHM (Teléfono móvil), MOB (Personas pueden contactarme al móvil), MBE (Se posee conexión al servicio MSN Mobile). Los valores de PHH, PHM y PHW pueden ser de cualquier tipo, pero los valores de MOB y MBE solo pueden ser Y o N, donde Y es el valor booleano de verdadero y N el valor booleano de negativo. El valor MBE solo puede ser Y si y solo si el valor de MOB es Y. En este documento los valores de de teléfono de PHH, PHM y PHW son los que nos interesa. En el caso que el valor de uno de los tipos de teléfono sea nulo durante el SYN este valor de teléfono no aparecerá. Para establecer el valor de teléfono habrá que enviar al servidor el comando PRP seguido del TranID, luego el valor del tipo de teléfono PHH, PHM, PHW, MOB o MBE, seguido del valor correspondiente a cada uno de estos. El servidor responderá con el comando PRP, si tuvo éxito, luego el TranID, seguido del identificador de lista, seguido del valor del tipo de teléfono y finalmente con el valor de confirmación del comando, es decir el valor enviado.

6.5.4.5 Comando LSG Este comando indica al cliente que se esta recibiendo la lista de grupos del contacto. Todo contacto tiene una lista de grupos por defecto. Esta lista de grupos se recibe durante el SYN, y su número corresponde al último parámetro recibido por el comando SYN. Cada LSG representa un grupo dentro de los valores del contacto. Durante el SYN el servidor envía cantidad de LSG como el último parámetro se lo

ISC-2003-2-4

91

haya indicado, si este indicó 5, entonces habrá 5 LSG. El LSG enviado por el SYN tiene el siguiente formato: El comando LSG sin TranID, seguido por el identificador de grupo (ojo que es diferente al identificador de lista) y seguido por el nombre del grupo en codificación URL. Es importante anotar que el identificador de grupo es esencial recordarlo ya que el comando LST hace uso de este para establecer en que grupo va cada contacto. El comando LSG también se puede enviar por parte del cliente, pero este al igual que el LST no son necesarios si se tiene un cliente robusto y que sabe mantener la integridad de sus datos.

6.5.4.6 Comando LST El comando LST representa la lista de contactos del usuario. Este comando es enviado durante el SYN con el fin de listar todos los contactos que posee el usuario y este es enviado por el usuario tantas veces como el valor penúltimo envía por el servidor dentro del comando SYN que este envió. Hay que anotar que un contacto debe de ir en un grupo obligatoriamente si y solo si este contacto se encuentra en la FL, mas sin embargo un contacto puede ir no solo en un grupo sino que puede ir en uno o mas de un grupo, por lo tanto es importante mantener una integridad de los datos dentro del cliente. El comando LST que envía el servidor durante el SYN tiene el siguiente formato: El servidor envía el comando LST sin TranID, seguido del email del contacto, continuando con su nombre dentro del MSN IM en codificación URL, seguido en que listas aparece (FL, AL, BL y/o RL) y finalmente si aparece en la FL se devuelve en un listado separado por comas los identificadores de grupo donde este contacto aparece. Durante el LST dentro del SYN el parámetro en que lista aparece el contacto viene representado por un número que a su vez este, representa en código binario en que listas aparece el usuario. Al hacer un Bitwise AND con el 1 si el numero final es 1 entonces el contacto esta dentro de la FL, si se hace el Bitwise AND con el 2 y resulta igual a 2 entonces el contacto esta en la AL, si se hace el Bitwise AND con el 4 y es 4 entonces esta en la BL y si se hace con el 8 y es 8 entonces esta en la RL. Como se sabe si un contacto esta en la FL entonces el comando LST devuelve una lista separada por comas de los identificadores de grupos en los que aparece el contacto.

6.5.4.7 Comando BPR Este comando aparece debajo de cada uno de los nombres de los contactos. Es para el usuario saber cuales son los teléfonos de sus contactos. Este comando es similar al PRP con la excepción que el valor del MOB no aparece y que no se puede establecer los valores. Cuando este valor se recibe dentro del comando SYN, el servidor envía el comando BPR seguido del identificador de lista, con el valor de tipo de teléfono y finalmente con el valor del teléfono en codificación URL. Para saber de quien es el

ISC-2003-2-4

92

BPR que mando el servidor simplemente hay que recordar de quien era el último LST. Cabe anotar que si el contacto no tiene establecido uno de los valores de tipo de teléfono durante el SYN, este valor no aparecerá dentro de los mensajes enviados durante el SYN. Por otra parte el servidor puede enviar el mensaje BPR al usuario si uno de sus contactos cambió sus valores de teléfono. El usuario recibe el comando BPR sin TranID seguido del identificador de lista, seguido del email del contacto, seguido del tipo de teléfono y finalmente el valor del tipo de teléfono en codificación URL.

6.5.5 Pings y challenges El servicio de MSN IM tiene implementado un sistema de pings y challenges para su funcionamiento. El primero el Ping es un comando que es el PNG y tiene el propósito de realizar un Ping al servidor pero a diferencia del Ping que se realiza a través del ICMP, este se realiza a través de la conexión al NOTIFICATION. Este Ping tiene el propósito de mantener la conexión abierta y evitar que las conexiones por estar en estado IDLE sean desconectadas por Firewall, Nats o Proxies. Para realizar el Ping hay que mandar el comando PNG solamente y esperar que el servidor responda con el comando QNG32. El challenge a diferencia del PNG no lo envía el cliente sino que es enviado por el NOTIFICATION solamente. Su fin es el de establecer si el cliente todavía sigue conectado y verificar si este es el cliente original que se conectó. Para que suceda esto el servidor envía el comando CHL con valor de parámetro 0 y otro de normalmente de 20 caracteres que representa un hash de sesión. Es obligatorio por parte del cliente que después de un CHL el cliente lo responda de los contrario la conexión con el servidor NOTIFICATION se pierde. Para responder al servidor se realiza lo siguiente: se envía el comando de carga QRY con el TranID seguido por la cadena PROD0038W!61ZTF9, y que posee una carga de 32 caracteres. Estos 32 caracteres son el MD5 hash de una cadena que se compone del hash de sesión que se obtuvo dentro del comando CHL concatenado por la cadena VT6PX?UQTM4WM%YR. Este MD5 hash es obligatoriamente de 32 caracteres y todos los caracteres hexadecimales en minúsculas es decir que las letras de la “a” a la “f” van en minúscula. Un ejemplo de un challenge es el siguiente: <<< CHL 0 15570131571988941333\r\n >>> QRY 1049 PROD0038W!61ZTF9 32\r\n 8f2f5a91b72102cd28355e9fc9000d6e <<< QRY 1049\r\n

32 Nota del autor: Es interesante saber que en el mIRC cuando se envía un Ping el servidor responde con un Pong, y que en el MSN IM el servidor responde con la siguiente letra del abecedario que sigue a la letra P de Ping y se trasforma el Ping en Quing es decir en comandos MSNP8 en PNG a QNG.

ISC-2003-2-4

93

Como se muestra dentro del ejemplo el comando de carga QRY con su carga de treintaidos caracteres que corresponde al MD5 hash que se obtuvo de la cadena 15570131571988941333VT6PX?UQTM4WM%YR. El servidor luego de enviar el comando QRY este responde si se tuvo éxito con el comando QRY seguido del TranID, pero si se obtuvo un error, este responde con un error y luego se desconecta.

6.5.6 Cambio de estado de conexión del usuario y sus contactos Para cambiar el estado de conexión de un usuario como se mencionó antes hay que enviar el comando CHG seguido del TranID y finalmente el valor del nuevo estado de conexión que puede ser NLN, HDN, BSY, IDL, AWY, BRB, PHN, LUN. El servidor confirmara el nuevo estado devolviendo el comando CHG, seguido del TranID y luego el nuevo valor de estado de conexión. Como se mencionó antes el estado FLN no se pude establecer debido a que este estado es inválido y si lo que se desea es aparecer fuera de línea hay que enviar el comando CHG con el parámetro HDN. Cabe anotar que durante el estado de oculto o HDN no se puede ni recibir, ni hacer invitaciones de conversaciones, para hacer eso hay que estar en los 7 diferentes estados que no sea el HDN ni FLN. Además de esto el usuario puede recibir los cambios de estado de sus contactos dentro de la FL. Estos cambios se reciben con el comando NLN, si el usuario cambio de estado a uno de tipo en línea como los son BSY, BRB, IDL, AWY, LUN, PHN, NLN. Pero también recibe los cambios de estado de desconexión y estos se reciben mediante el comando FLN. Cuando un usuario dentro de la FL se conecta el servidor envía al cliente el comando NLN sin TranID, seguido del tipo de conexión ya sea BSY, BRB, IDL, AWY, LUN, PHN, NLN, seguido por el email del contacto y su nombre en codificación URL. Para el caso de que un contacto se desconecte el servidor envía el comando FLN sin TranID seguido del email del contacto.

6.5.7 Cambio de nombre del usuario El usuario dentro del servicio del MSN IM tiene un nombre de usuario, como una especie de alias o nickname. Este nombre de usuario se puede cambiar a petición del dueño de la cuenta. El usuario originalmente tiene el nombre de usuario establecido igual al email del usuario, cuando este lo decide cambiar lo puede cambiar por lo que sea a excepción de nombres vulgares, insultantes o reservados. El usuario puede establecer tanto un nombre simple como uno complejo que puede ser una frase o una oración. Para cambiar el nombre hay que enviar al servidor el comando REA seguido

ISC-2003-2-4

94

por el TranID el email del usuario seguido por el nombre en codificación URL. El servidor sino existe ningún problema, enviara el comando REA con el TranID el nuevo identificador de lista, el email del usuario seguido por la confirmación del nuevo nombre del usuario. Este comando también sirve para consultar el nombre del usuario de los diferentes contactos, para realizar esto hay que enviar el comando REA seguido por el TranID y seguido 2 veces por el email del contacto. El servidor responderá con el comando REA seguido por el TranID, luego el identificador de lista y finalmente el email del contacto seguido por el nombre del usuario del contacto en codificación URL.

6.5.8 Manejo de Contactos Para manejar los contactos dentro del MSN IM se dispone de dos comandos básicos que son el ADD que se refiere el adicionar usuarios y el REM que se refiere a remover usuarios.

6.5.8.1 Comando ADD El comando ADD se puede utilizar cuando sea siempre y cuando los parámetros sean los correctos. El comando ADD posee el siguiente formato: Primero el comando ADD seguido por el TranID, seguido del tipo de lista al cual se desea adicionar (los tipos de lista son: FL, AL, BL) y seguido por el email del contacto 2 veces, en el caso que el tipo de lista sea la FL habrá que ingresar el grupo donde el usuario quiere ingresar el contacto. Un ejemplo del comando ADD es el siguiente: >>> ADD 20 AL [email protected] [email protected]\r\n <<< ADD 20 AL 1200 [email protected] [email protected]\r\n >>> ADD 23 FL [email protected] [email protected] 1\r\n <<< ADD 23 FL 1201 [email protected] [email protected] 1\r\n <<< BPR 1201 [email protected] PHH\r\n <<< BPR 1201 [email protected] PHW\r\n <<< BPR 1201 [email protected] PHM\r\n <<< BPR 1201 [email protected] MOB N\r\n Como se observa el servidor responde con el Comando ADD seguido por el TranID, el tipo de lista, el identificador de lista y finalmente el email del usuario que se agregó. En el caso cuando se agrego a la FL este devolvió un parámetro extra que es

ISC-2003-2-4

95

identificador de grupo. También el servidor devolvió una lista de comando BPR que representan los números telefónicos del usuario en ese momento. Existen ciertas reglas para la adición de usuarios que son:

- No se pueden ingresar un contacto dentro de la AL y la BL al mismo tiempo, ya que esto produce un error.

- No se pueden adicionar personas dentro de la RL, ya que esto esta fuera del alcance del usuario.

- Si se trata de ingresar un contacto inválido este devolverá un error. - Si al tratar de ingresar un contacto a un grupo invalido, el servidor devolverá

un error. - Si trata de ingresar un contacto que ya existe en esa lista, el servidor devolverá

un error.

6.5.8.2 Comando REM El comando REM se utiliza para realizar lo contrario al comando ADD, y este utiliza los mismos parámetros que el comando ADD y devuelve los mismos parámetros y de la misma estructura. Aunque este tiene unas cuantas restricciones adicionales tales como:

- No se puede remover un contacto si no existe en la lista o grupo para el caso de la FL si este no existe en ese lugar, así sea el contacto válido o inválido.

- Si se trata de remover un usuario de la RL, el servidor desconectara al cliente de la conexión.

- Si se trata de remover un contacto que esta en la FL, pero este no esta en el grupo que se le envió, el servidor respondera con un error.

- Si se trata de remover un contacto que esta en la FL, pero no existe el grupo, el servidor arrojara un error.

Un ejemplo de comandos REM son los siguientes: >>> REM 32 FL [email protected] 1\r\n <<< REM 32 FL 1203 [email protected] 1\r\n >>> REM 33 AL [email protected]\r\n <<< REM 33 AL 1204 [email protected]\r\n Como se observa el formato de los comandos REM, es similar al formato de los comandos ADD.

6.5.8.3 Mover contactos entre grupos

ISC-2003-2-4

96

Para mover contactos entre grupos simplemente hay que eliminar el contacto del grupo original y luego adicionarlo al nuevo grupo. Es decir que se envía al servidor primero el comando REM con los parámetros de usuario y grupo y luego se envía el comando ADD con los parámetros de usuario y del nuevo identificador de grupo.

6.5.8.4 Bloquear y/o permitir contactos Para bloquear o permitir contactos hay que tener en cuenta si el usuario se encuentra en lista de AL o BL. Si el usuario no esta en ninguna de las dos listas, entonces se envía el comando ADD con sus parámetros normales, pero el tipo de lista debe ser igual a AL si se desea permitir el contacto y BL si se desea bloquear el contacto. En el caso que el contacto esté en alguna de las 2 listas entonces habrá que enviar el comando REM primero y luego el comando ADD. El comando REM se envía con la finalidad de remover el usuario de la lista original y poderlo agregar a la lista contraria, si esta medida no se realiza, se viola una regla del estado de lista anteriormente mencionada.

6.5.8.5 Cambios en la lista de reversa. El servidor envía unos comandos ADD y REM con un TranID igual a 0 y con parámetro de tipo de lista igual a RL. En el caso que esto suceda indica que un contacto ajeno acabó de ingresar al usuario dentro de su FL. Cabe anotar como se comento anteriormente el comando GTC indica al cliente si este debe ingresar a los contactos de manera automática o manual, para el caso de un GTC con valor N cuando se recibe un comando ADD o REM con valor de tipo de lista igual al RL, este no es necesario que haga nada debido a que está puesto en modo manual, pero si este está en modo A este debe ingresar los contactos automáticamente a la AL cuando recibe un comando ADD o REM, con un parámetro de tipo de lista igual a RL. Un ejemplo de lo anterior se muestra a continuación: <<< ADD 0 RL 3051 [email protected] My%20Name\r\n >>> ADD 25 AL [email protected] My%20Name\r\n Como se observa la respuesta al comando ADD con tipo de lista igual al RL, el cliente responde automáticamente ingresando el nuevo contacto a la AL.

6.5.9 Manejo de Grupos Para el manejo de grupos se poseen 3 comandos a disposición. Estos comandos son el ADG, RMG, y el REG. Donde ADG es el comando de adición de grupos, el RMG el de

ISC-2003-2-4

97

remover grupos y el REG el de renombrar grupos. Como se mencionó inicialmente en la sección de la estructura lógica del usuario el servicio MSN IM dentro de sus contactos, posee un grupo por defecto y este grupo es el grupo con identificador de grupo número 0, este grupo es importante tenerlo en cuenta ya que es un grupo con unas condiciones especiales.

6.5.9.1 Comando ADG El comando ADG se envía con la finalidad de agregar grupos. Este comando tiene la siguiente estructura: primero el comando ADG seguido por el TranID, el nombre del grupo codificación URL y como ultimo parámetro el valor 0. El servidor responderá con el comando ADG seguido por el TranID, continuado por el identificador de lista, seguido por los valores confirmados del nombre del grupo en codificación URL seguido por el identificador del grupo del nuevo grupo y seguido por el valor 0. Los grupos pueden tener el mismo nombre ya que cada uno se diferencia por identificador de grupo y no por el nombre. Las limitaciones que posee este comando es que no pueden existir más de 30 grupos dentro de la lista de grupos del usuario.

6.5.9.2 Comando RMG El comando RMG se utiliza para remover grupos de la lista de grupos. Si se trata de remover un grupo se recomienda que este esté vació ya que si se elimina el grupo todos los contactos dentro de este grupo serán eliminados de la FL, sino están en otro grupo, en el caso que estén en otro grupo simplemente serán eliminados del grupo que se desea eliminar. Si se trata de eliminar un grupo no existente, es decir un grupo con identificador de grupo que no existe, el servidor responderá con un error. También existe la restricción con este comando y es que no se puede eliminar el grupo con identificador de grupo igual a 0, si se trata de eliminar este grupo el servidor responderá con un error. El comando RMG se utiliza enviando el comando RMG seguido por el TranID, continuado por el identificador de grupo del grupo a remover. Si tuvo éxito el servidor responderá con el comando RMG continuado por el TranID, seguido por el nuevo identificador de lista y el valor del identificador de grupo eliminado.

6.5.9.3 Comando REG El comando REG tiene como finalidad la opción de poder renombrar grupos. El grupo con identificador de grupo igual a 0 se puede renombrar y no existe ningún problema al realizar esto. Existe la restricción que solo los grupos existentes se pueden renombrar, el tratar de renombrar un grupo no existente, el servidor responderá con

ISC-2003-2-4

98

un error. Para enviar el cambiar el nombre de un grupo se envía el comando REG seguido por el TranID, continuado por el identificador de grupo, seguido por el nuevo valor del nombre del grupo en codificación URL y seguido finalmente por el valor 0. Si se tuvo éxito con el comando el servidor responderá con el comando REG seguido por el TranID, el nuevo identificador de lista, seguido por el identificador de grupo, la confirmación del nuevo nombre del grupo en codificación URL y seguido por el valor 0.

6.5.10 Mensajes dentro del servidor NOTIFICATION El servidor NOTIFICATION envía mensajes con carga del comando MSG. Estos comandos con carga son comandos que su carga es un mensaje de tipo MIME. Estos mensajes (se refiere al comando MSG) solo los envía el servidor NOTIFICATION al cliente y nunca el cliente podrá devolver una confirmación al servidor. Por otra parte la carga de estos mensajes solo posee encabezado y no posee cuerpo es decir que sólo tiene campos de valores de tipo MIME. La razón que no posee cuerpo radica en que los mensajes que envía el servidor NOTIFICATION son valores de información para el cliente. Tales valores de información que el cliente recibe son por ejemplo los valores de los emails leídos, el valor MSAuth para el chequeo de emails, los URL para revisar el email etc. Estos mensajes que envía el servidor NOTIFICATION solo tienen que ver con la parte de email del usuario. Los diferentes tipos de mensajes que envía el servidor NOTIFICATION son:

- text/x-msmsgsprofile: Son mensajes en donde se envía la información pertinente del usuario en cuanto a su correo e información personal. La descripción de este tipo de mensaje se realizó en la sección de mensajes iniciales del NOTIFICATION.

- text/x-msmsgsinitialemailnotification: Son mensajes que indican los valores del estado del email del cliente tales como la cantidad de emails nuevos, y los URL de cada una de sus partes. La descripción de este tipo de mensaje se realizó en la sección de mensajes iniciales del NOTIFICATION.

- text/x-msmsgsemailnotification: Son mensajes que envía el NOTIFICATION cuando un email llega a la cuenta de correo.

- text/x-msmsgsactivemailnotification: Son mensajes que envía el NOTIFICATION cuando el usuario lee o elimina mensajes no leídos dentro de su cuenta de correo.

6.5.10.1 Mensaje text/x-msmsgsemailnotification

ISC-2003-2-4

99

Este mensaje es enviado cuando un email nuevo llega a la cuenta de correo. Los encabezados importantes de este mensaje son:

- From: Que indica de quien provino el mensaje, es decir el campo desde dentro del email.

- Message-URL: El URL del directorio que hay que visitar para leer el mensaje.

- Post-URL: El URL del servidor que hay que visitar. - Subject: El asunto del email. - Dest-Folder: El nombre del fólder a donde llego el nuevo mensaje. - From-Addr: La dirección de email de la persona que envío el email. - Id: El identificador de email que utiliza el MSN IM para chequear emails.

Un ejemplo de un tipo de mensaje de text/x-msmsgsemailnotification es: MSG Hotmail Hotmail 355\r\n MIME-Version: 1.0\r\n Content-Type: text/x-msmsgsemailnotification; charset=UTF-8\r\n \r\n From: Friend Email\r\n Message-URL: /cgi-bin/getmsg?msg=MSG1050451140.21&start=2310&len=2059&curmbox=ACTIVE\r\n Post-URL: https://loginnet.passport.com/ppsecure/md5auth.srf?lc=1038\r\n Subject: =?"us-ascii"?Q?newsubject?=\r\n Dest-Folder: ACTIVE\r\n From-Addr: [email protected]\r\n id: 2\r\n Hay que anotar que quien envía estos mensajes es el usuario Hotmail, pero esto no es constante y tampoco representa un contacto. También se observa que los mensajes no poseen TranID.

6.5.10.2 text/x-msmsgsactivemailnotification Este mensaje es enviado por el servidor NOTIFICATION cuando un email no leído es leído o es borrado. Los encabezados de este mensaje son:

- Src-Folder: El fólder donde el email sin leer se encontraba. - Dest-Folder: El fólder destino donde el email fue a parar. - Message-Delta: El número de email que sufrieron la misma acción.

ISC-2003-2-4

100

Hay que anotar que cuando un email es leído, el Src-Folder y el Dest-Folder tienen el mismo valor y como no mas se puede leer un email a la vez el Message-Delta es siempre 1. En cambio si un email no leído es movido este tiene el Src-Folder y el Dest-Folder distinto. Un ejemplo de este tipo de mensajes se muestra a continuación. MSG Hotmail Hotmail 145\r\n MIME-Version: 1.0\r\n Content-Type: text/x-msmsgsactivemailnotification; charset=UTF-8\r\n \r\n Src-Folder: ACTIVE\r\n Dest-Folder: trAsH\r\n Message-Delta: 2\r\n

6.5.11 Servicio de chequeo de email El servicio MSN IM ofrece la posibilidad del chequeo de email. Este chequeo no se realiza dentro del cliente, sino que se realiza a través de un servicio de autenticación del MSN PASSPORT que luego lo redirecciona al usuario a un chequeo de email por web. Este servicio de chequeo lo poseen todos los usuarios que posean servicios de email a través del servicio MSN, ya sea por Hotmail, MSN u otro tipo de servicio asociado. Para chequear el email se necesitan los siguientes datos:

- El URL que se obtiene en el encabezado de Post-URL en el mensaje de notificación inicial de email.

- El parámetro action que se obtiene dentro del comando URL enviando como parámetro ya sea INBOX, FOLDERS o COMPOSE. Este parámetro es el segundo que devuelve el servidor con la respuesta del comando URL.

- El email del usuario. - Los valores de sid y kv que se obtiene en el mensaje inicial de profile. - El id deriva del comando URL o del encabezado id del mensaje text/x-

msmsgsemailnotification. - El parámetro sl que viene siendo el número de segundos entre el tiempo

unix desde que se recibió el mensaje profile hasta el tiempo que se desea chequear el email.

- El parámetro rru que puede ser el URL del encabezado Inbox-URL, Folders-URL, Message-URL, o Compose-URL. Estos valores pueden obtenerse también del primer parámetro del comando URL.

- El parámetro auth que viene del encabezado MSPAuth del mensaje profile del usuario.

ISC-2003-2-4

101

- El parámetro creds es el valor MD5 hexadecimal de los parámetros concatenados de las cadenas MSPAuth + sl + y la clave del usuario.

Luego de eso se crea un archivo html con la siguiente estructura: <html> <head> <noscript> <meta http-equiv=Refresh content="0; url=http://www.hotmail.com"> </noscript> </head> <body onload="document.pform.submit(); "> <form name="pform" action="https://loginnet.passport.com/ppsecure/md5auth.srf?lc=1033" method="POST"> <input type="hidden" name="mode" value="ttl"> <input type="hidden" name="login" value="example"> <input type="hidden" name="username" value="[email protected]"> <input type="hidden" name="sid" value="507"> <input type="hidden" name="kv" value="4"> <input type="hidden" name="id" value="2"> <input type="hidden" name="sl" value="9"> <input type="hidden" name="rru" value="/cgi-bin/HoTMaiL"> <input type="hidden" name="auth" value="4wn8Flsh2DXiHWLalsdfgdssdfgfgsgfG4mzp2Vu2du3I3*cLC8DUP$$"> <input type="hidden" name="creds" value="c1252ecb80b52af6becba4533d12828f"> <input type="hidden" name="svc" value="mail"> <input type="hidden" name="js" value="yes"> </form> </body> </html> Lo que se encuentra en negrilla es la información que se debe remplazar.

6.5.11.1 Comando URL Como se mencionó anteriormente el comando URL se necesita para obtener información importante para poder chequear el email del usuario. Para utilizar este comando hay que enviar el comando URL seguido por el TranID y con el código de que tipo de URL se desea, que puede ser INBOX, COMPOSE, FOLDERS. El servidor si tuvo éxito responderá con el comando URL seguido por el TranID

ISC-2003-2-4

102

continuado por dos URL, el primero corresponde al valor del parámetro rru para el chequeo del email; el segundo corresponde al valor de action. El ultimo parámetro que devuelve es el valor id que se utiliza en el chequeo de email.

6.5.12 Finalizar la sesión al servidor NOTIFICATION La sesión del servidor NOTIFICATION sólo puede ser una para cada usuario, es decir que un usuario conectado sólo puede tener una y sólo una sesión aunque el usuario puede tener una o más de una cuenta activada y tener varias sesiones abiertas con diferentes cuentas. Si un usuario se conecta al servidor NOTIFICATION y esta tiene otra sesión abierta el usuario de la primera sesión abierta recibe del servidor NOTIFICATION el comando OUT sin TranID y parámetro OTH que indica que otra persona se autenticó con éxito desde otro lugar. En el caso que el MSN IM se encuentre en reparaciones, el servidor envía el comando OUT sin TranID y parámetro SSD para indicar que el servidor se va a desconectar. Pero el usuario también puede enviar el comando OUT para salir de la sesión. El comando OUT se envía sin TranID y sin parámetros, después de haber enviado este comando el cliente tiene que cerrar cada una de los conexiones que este tenga abierta, es decir todas conexiones de SWITCHBOARD y la de NOTIFICATION. Cuando el usuario envía el comando OUT el servidor automáticamente pone al usuario en estado FLN, si el cliente en vez de enviar el OUT cierra la conexión es posible que el usuario aparezca NLN cuando en realidad este se encuentra FLN. Cabe anotar que lo anterior no esta mal, pero se recomienda para terminar la sesión, enviar el comando OUT al final.

6.6 REALIZACIÓN DE CONVERSACIONES ENTRE CONTACTOS Ya una vez se conozca como realizar las funciones administrativas del manejo de cuenta del usuario del MSN IM, ahora se procede a mostrar como se envían los mensajes instantáneos entre contactos. Para poder realizar cualquier comunicación instantánea entre cualquier contacto, primero habrá que conocer cuando se pueden establecer estas comunicaciones. Inicialmente el usuario debe estar en estado diferente a FLN o HDN, si el usuario esta en HDN o cuando se autenticó no cambio su estado (esta en estado FLN), el servidor no permitirá realizar conversaciones con este y arrojara un error. Por otra parte, sólo se podrán realizar o recibir conversaciones con contactos que no estén en la BL, si se tiene un BLP de BL, pero si se tiene el BLP en AL sólo se podrá llamar o recibir mensajes instantáneos de aquellos que estén en la AL. Lo anterior aplica para ambas partes para el usuario que contacta, como el contacto contactado si alguno de los dos no cumple con lo anterior, no se podrá establecer una comunicación instantánea. Todas las conversaciones instantáneas se tendrán dentro del servidor SWITCHBOARD, es decir que se realizará una conexión

ISC-2003-2-4

103

al servidor SWITCHBOARD. Las conexiones pueden ser de cero a muchas, donde cada sesión es independiente una de la otra y es posible que se puedan tener dos conversaciones con el mismo contacto en dos sesiones por separado. Las sesiones de SWITCHBOARD se recomienda que se realicen entre dos pero se puede realizar entre tres ó más participantes. Para realizar una conversación instantánea este se puede realizar de dos formas una: es que uno solicite la conversación y la otra es que uno lo inviten a la conversación.

6.6.1 Invitando un contacto a la conversación Para invitar un contacto a una conversación se tendrá que obtener primero una sesión de SWITCHBOARD. Para obtener este hay que enviar el comando XFR con el TranID seguido por el parámetro SB, que representa el SWITCHBOARD. El servidor responderá si tuvo éxito con el comando XFR seguido por el TranID, luego el parámetro SB seguido de un parámetro que tiene una ip y puerto separados estos por dos puntos, luego de esto se encuentra el método de autenticación CKI seguido por el hash de sesión SWITCHBOARD. Una vez se tenga lo anterior se procede a realizar una nueva conexión TCP/IP, dejando la conexión al NOTIFICATION quieta. Se crea la conexión al ip y puerto recibido. Cuando se crea la conexión se envía el comando USR con un nuevo TranID que no necesariamente debe ser igual al TranID del servidor NOTIFICACION, seguido por el email del usuario y como último parámetro el hash de sesión que se recibió del comando XFR en el servidor NOTIFICATION. Si el comando tuvo éxito el servidor responderá con el comando USR seguido por el TranID (este TranID corresponde al del comando USR que se le envió al servidor SWITCHBOARD) seguido por el parámetro OK, el email del usuario y el nombre del usuario (El nombre que se obtuvo en el comando REA). Ya autenticados dentro del servidor SWITCHBOARD, se procede a llamar al invitado este puede ser uno o mas invitados dependiendo de la situación. Para llamar al invitado se procede a enviar el comando CAL, este comando ya lo puede enviar cualquier contacto que ya este autenticado dentro del servidor SWITCHBOARD. Ya sea invitado o invitador. Para enviar el comando CAL se envía este seguido por el TranID, y el email del contacto a invitar. Si el usuario invitado tiene al usuario bloqueado o su preferencia de privacidad tiene al invitador bloqueado, o si el contacto que se invita esta FLN o si el usuario no existe entonces el servidor respondera con un error, de lo contrario responderá este con el comando CAL, seguido por el TranID, seguido del parámetro RINGING y seguido del hash de sesión del SWITCHBOARD. Cuando se envía el comando CAL y tiene éxito es cuando el servidor envía al invitado el comando RNG a su sesión de NOTIFICATION. Hay que anotar que si no se tiene éxito el comando CAL, el comando RNG no es enviado a nadie, por lo tanto la invitación de la persona no túvo éxito.

ISC-2003-2-4

104

Si el invitado se conecta correctamente después del comando CAL que envía el servidor, aparece el comando JOI. Este comando lo envía el servidor sin TranID, seguido por el email del contacto invitado, seguido de su nombre en codificación URL.

6.6.2 Recibiendo invitación a una conversación También existe la posibilidad que un usuario sea contactado para ingresar en una conversación. Esto sucede cuando en la conexión al servidor NOTIFICATION se recibe el comando RNG, seguido por el hash de la sesión SWITCHBOARD, continuado por el ip y puerto del servidor SWITCHBOARD al que hay que conectarse, seguido por el parámetro CKI, seguido por la segunda parte del hash de sesión, y por el email y el nombre en codificación URL del usuario que lo esta invitando a participar. El invitado se procede a conectar al servidor SWITCHBOARD especificado dentro del ip y puerto del comando RNG y procede a enviar el comando ANS seguido por el TranID de la sesión SWITCHBOARD, seguido por el email del usuario, la segunda parte del hash y finalmente la primera parte del hash. Cuando se envía este comando se recibe un comando IRO, que representa la lista de usuarios dentro de la conversación, y este comando lo envía el servidor la cantidad de veces que existan esos usuarios dentro del servidor. El formato del comando IRO es el siguiente: el comando IRO seguido por el TranID, continuado por el numero incremental de personas dentro de la conversación, seguido por el numero total de personas dentro de la conversación, seguido por el email de los contactos participantes seguido por sus nombres en codificación URL. Después del IRO el servidor responde con el comando ANS seguido por el TranID y seguido por el parámetro OK. Cuando se recibe este parámetro es cuando al invitador recibe el comando JOI por parte del servidor SWITCHBOARD.

6.6.3 Envió de mensajes en el SWITCHBOARD Luego que los invitados y el invitador ya se hayan autenticado se podrán enviar mensajes instantáneos entre los participantes. Estos mensajes instantáneos no se dirigen a una persona en especial, sino que se envían a todos los participantes dentro de la conexión SWITCHBOARD. Durante el envío de mensajes instantáneos entre los participantes se pueden enviar mensajes de información sobre el estado del usuario en la conversación, es decir si está escribiendo un nuevo mensaje o no. La forma de enviar los mensajes instantáneos, mensajes de control o información y las invitaciones que se describirá más adelante se realiza mediante el envío del comando MSG.

ISC-2003-2-4

105

6.6.3.1 Comando MSG El comando MSG es enviado por el usuario únicamente en conversaciones dentro del SWITCHBOARD. Los comandos MSG son comandos con carga, como se explicó anteriormente son comandos que tienen como ultimo parámetro de la parte del comando normal, el tamaño de la carga del mensaje. Como se menciono anteriormente en la sección de la especificación de los mensajes con carga, los mensajes dentro del comando MSG tienen un formato de tipo MIME 1.0. Para poder enviar un mensaje de estos hay que enviar el comando MSG seguidor por el TranID, seguido por uno de los siguientes valores U, N, o A y finalmente el tamaño de la carga del mensaje. Para calcular el tamaño de la carga del mensaje hay que contar el número de caracteres que posee el mensaje desde su principio hasta su final, cabe anotar que los caracteres de escape \r\n y similares también se deben tener encuentra dentro del conteo de caracteres. Los valores de U, N y A son valores de que tipo de acuse de recibo que se desea. Si el usuario selecciona el valor de U, el servidor no responderá al usuario si el mensaje fue enviado o no. En el caso del valor de N el servidor sólo contestara si el mensaje no llega a uno de sus destinatarios. El servidor responderá con el comando NAK para el caso que no se pudo enviar el mensaje. Para el valor de A el servidor siempre dará razón de acuse, es decir que ya sea el mensaje recibido o no el servidor responderá si llego o no el mensaje. Para los mensajes no recibidos el servidor responderá con el comando NAK y para los mensajes recibidos el servidor responderá con el comando ACK. El comando ACK y NAK que se recibe del servidor tiene la estructura de un comando normal, que posee TranID y sin parámetros. Ejemplo de un comando MSG: >>> MSG 247 A 139\r\n MIME-Version: 1.0\r\n Content-Type: text/plain; charset=UTF-8\r\n X-MMS-IM-Format: FN=Arial; EF=I; CO=0; CS=0; PF=22\r\n \r\n Hola, que mas? Todo bien? <<< ACK 4 Cuando un cliente recibe un mensaje de carga tipo MSG el cliente recibe el comando MSG seguido por el email del contacto y el nombre del contacto y finalmente por el

ISC-2003-2-4

106

tamaño de la carga y su respectiva carga. La carga del comando MSG que recibe el usuario es igual a la carga que envía el contacto.

6.6.3.2 Envió de mensajes instantáneos Los mensajes instantáneos son simplemente comandos con carga de tipo MSG, que poseen como parámetro MIME dentro del encabezado Content-Type el valor de text/plain. El valor de text/plain dentro de la carga del comando MSG identifica a este como un mensaje instantáneo. Para enviar el mensaje instantáneo, simplemente hay que crear la carga del comando MSG de la siguiente forma: Se especifica que tipo de versión MIME se esta utilizando, siempre se esta utilizando la versión 1.0. Después se especifica que tipo de contenido se lleva, como es mensaje instantáneo se especifica con el tipo text/plain seguido de la codificación que es el UTF-8. Después de esto se especifica el formato de texto, color, tamaño, tipo de letra dentro del encabezado X-MMS-IM-FORMAT. Este encabezado se puede omitir ya que es de simple presentación y no es fundamental dentro de los mensajes instantáneos. Seguido viene un separador de fin de línea que indica fin del encabezado. Luego del fin de línea viene el texto del mensaje instantáneo. Cabe anotar que dentro de este mensaje si se quiere poner un fin de línea es aconsejable hacerlo con el valor \r y no con el valor \r\n, ya que este ultimo es reservado como indicador de fin de comando. En el ejemplo anterior se muestra un mensaje enviado por un usuario en una conversación.

6.6.3.3 Mensaje de control de escritura Los mensajes de control de escritura son mensajes de carga de tipo MSG que envía el cliente, para informarle a los participantes dentro de la conversación que el usuario esta escribiendo un mensaje. Este mensaje no es necesario enviarlo ya que no forma parte vital del envió de mensajes instantáneos, sino que en cambio sirve como información que la otra persona dentro de la conversación esta escribiendo un mensaje. Ejemplo: >>> MSG 17 U 105\r\n MIME-Version: 1.0\r\n Content-Type: text/x-msmsgscontrol\r\n TypingUser: [email protected]\r\n El tipo de contenido que identifica el mensaje de control de escritura es el de text/x-msmsgscontrol, además del tipo de contenido también se tiene quien es la persona que esta escribiendo, irónicamente ya se sabía de antemano quien estaba escribiendo si se observa el encabezado enviado por el comando MSG.

ISC-2003-2-4

107

6.6.3.4 Invitaciones Las invitaciones son otra parte de los mensajes de carga del comando MSG. Estas invitaciones las puede realizar cualquiera dentro del servidor de SWITCHBOARD. Las invitaciones se realizan con otros clientes ya sea para intercambiar archivos, realizar conversaciones de voz, o participar en programas de forma online. Para realizar esto primero se tiene que establecer que tipo de servicio se piensa utilizar, quien va a ser el responsable del servidor, a donde se tiene que conectar el servidor y demás información que las diferentes situaciones necesiten. De forma práctica de documentación, solo la parte de la documentación de la invitación a transferencia de archivo será documentada, ya que el resto de las invitaciones para aspectos de esta tesis, no tiene ninguna relevancia. Las invitaciones tienen la siguiente secuencia:

- El usuario que desea invitar procede a enviar un mensaje de invitación al contacto con el que desea realizar la invitación.

- El contacto decide si acepta o no la invitación, también se analiza si el sistema soporta el sistema de invitación (Por ejemplo si soporta conferencias de audio o video),

- En el caso que el sistema soporte la invitación y el usuario acepta, las aplicaciones o sistemas se conectaran y realizaran sus comunicaciones de forma independiente.

De la forma anterior es como normalmente se realizan las invitaciones, cabe agregar que en cualquier momento cualquiera de los 2 usuarios en el cual participan, puede cancelar la invitación. Como se mencionó anteriormente, las invitaciones se envían por el comando de carga MSG. A la carga del mensaje se le especifica su contenido como text/x-msmsgsinv es decir en el encabezado MIME de content-type. Como se mencionó anteriormente se documentará a continuación como se realiza la invitación a una transferencia de archivo entre 2 usuarios.

6.6.3.4.1 Invitación a transferencia de archivo Cuando se decide enviar un archivo a un contacto, se procede a enviar una invitación especificando que se desea realizar una transferencia de archivo. Lo anterior se logra mediante el envió del comando MSG con la siguiente carga33:

33 Para casos prácticos proceda ver los anexos en la parte de invitaciones de cómo es que se realiza las invitaciones.

ISC-2003-2-4

108

Primero la especificación MIME, seguido debajo del tipo de contenido que para este caso será text/x-msmsgsinvite; charset=UTF-8, claro seguido por el tipo de codificación que se piensa usar. Luego se envían los siguientes campos: Application-Name: Que puede ser desde “File Transfer” a “Transferencia de Archivo”. Application-GUID: Este debe ser {5D3E02AB-6190-11d3-BBBB-00C04F795683} para el caso de la transferencia de archivo, cualquier otra cadena indica un diferente tipo de invitación. Realmente este campo es el que verdaderamente indica si se desea realizar una transferencia de archivo o no. Esto se sabe por la cadena anterior. Invitation-Command: Este campo indica el estado de la invitación. Cuando uno inicialmente realiza la invitación envía el valor de INVITE, Cuando el contacto acepta la invitación el valor toma el valor de ACCEPT y para el caso de la cancelación toma el valor de CANCEL. Todos estos valores van en mayúscula. Invitation-Cookie: Esta campo envía un identificador de invitación, el valor de este esta entre 1 y 232-1. La idea de este campo es para identificar la invitación. Application-File: El nombre del archivo que se piensa transferir. Application-FileSize: El tamaño del archivo en bytes. El contacto que recibe esta invitación, tiene 2 posibilidades: aceptar la invitación o cancelarla. Para cancelar la invitación simplemente se debe de enviar el mensaje con carga MSG con la siguiente carga: Como ocurre anteriormente se envía el encabezado MIME, el tipo de contenido que es igual para todas las invitaciones, y seguido por los campos: Invitation-Command: En este caso como se cancela la transferencia se envía el valor de CANCEL. Invitation-Cookie: El identificador de invitación. Cancel-Code: La razón de la desconexión puede ser por espera larga que es el valor de FTTIMEOUT o puede ser REJECT para el caso en que el usuario cancele la transferencia de archivo. Existen otros tipos de error que ocurren muy pocas veces esos son: OUTBANDCANCEL se envía cuando el servidor SWITCHBOARD recién acaba de cerrar la conexión, REJECT_NOT_INSTALLED cuando el usuario no posee el sistema de invitación solicitada, esta es enviada no por el usuario sino por el sistema. TIMEOUT Se cancela la transferencia debido a que se superó el tiempo de espera. Si el contacto en vez de cancelar decide aceptar, el contacto envía la siguiente invitación: El comando MSG con la siguiente carga, primero el encabezado MIME seguido por el tipo de contenido que es el de invitación, y seguido por los campos:

ISC-2003-2-4

109

Invitation-Command: Se envía el valor de ACCEPT ya que se esta aceptando la transferencia de archive. Invitation-Cookie: El identificador de invitación. Launch-Application: Debido a que la transferencia de archive no es una aplicación se envía el valor de FALSE. Request-Data: Este campo indica que el contacto desea obtener los datos de conexión para realizar la transferencia de archivos. Este se logra mediante el envío del valor IP-Address: este valor es el único que se ha observado en la transferencia de archivo. Cuando el usuario que envía el archivo, es aceptado por el contacto y este último envía su confirmación, el usuario le envía la información pertinente para finalizar la negociación de transferencia de archivo. Pero el usuario envía 3 campos adicionales al anterior mensaje recibido por el contacto. Los campos que componen este mensaje son: Invitation-Command: El valor de ACCEPT indicando la finalización de la negociación de invitación. Invitation-Cookie: El identificador de invitación. IP-Address: El IP del usuario que envía el archivo. Port: 6891 El puerto donde el usuario tiene establecido el servidor de transferencia de archivo. Normalmente y por compatibilidad el puerto tiene el numero 6891. AuthCookie: Similar al Invitation-Cookie, es un valor entre 1 y 232-1 que es el identificador no de invitación sino de identificación de transferencia de archivo. Launch-Application: El valor de FALSE por la razón anteriormente mencionada. Request-Data: IP-Address: Lo mismo que el valor anteriormente mencionado. Una vez realizado los pasos anteriores se puede comenzar con el protocolo de transferencia de archivo, conectándose el que recibe el archivo al servidor que crea el que envía el archivo. Se procederá a documentar el protocolo de transferencia de archivo en la sección de transferencia de archivo.

6.6.4 Salir de una conversación Las conversaciones pueden terminar ya sea por el usuario o por el contacto con el cual se esta conversando. También puede ser desconectado por el servidor debido a inactividad. Para salir de una conversación, el usuario tiene que enviar el comando OUT al servidor SWITCHBOARD donde se esta realizando la conversación. El comando es

ISC-2003-2-4

110

enviado sin TranID y sin parámetros, después de enviar este comando habrá que cerrar la conexión con el servidor. Los otros usuarios se enteran que alguien sale de la conversación cuando el servidor SWITCHBOARD envía a cada uno de los participantes el comando BYE sin TranID y con el parámetro de la persona que se retiro de la conversación. Cuando el comando BYE es enviado por el servidor y este tiene un segundo parámetro adicional este corresponde a que el servidor SWITCHBOARD se dispone a cerrar la conexión debido a inactividad, el valor del segundo parámetro que el servidor envió es el valor 1. Cuando el servidor envía un BYE se debe a que uno de los usuarios envió un OUT o simplemente se desconectó de la sesión. Las conexiones a los servidores SWITCHBOARD y NOTIFICATION son independientes una de las otras, por lo tanto si se cierra la conexión al NOTIFICATION todavía se pueden tener conversaciones con los demás clientes en las conexiones a los servidores SWITCHBOARD. Cabe anotar que si no existe conexión al servidor NOTIFICATION entonces no se pueden realizar nuevas conversaciones.

6.7 PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS Antes de documentar el protocolo de transferencia de archivos, se procederá a documentar como es que se realiza la conexión entre los contactos. Antes de que se realice la conexión el contacto que envía el archivo crea un socket de tipo servidor cuando envía la confirmación de invitación de transferencia de archivo es decir el mensaje que envía con el encabezado de IP-Address y Port. Cuando el contacto que recibe el mensaje anterior, este crea un socket inmediatamente al puerto y al ip que recibe dentro del mensaje. Una vez realizada la conexión entre el cliente y el servidor, el servidor cierra el socket servidor y continúa la conexión con el socket del cliente. Una vez realizada la conexión entre el cliente y el servidor se procede a realizar la comunicación entre clientes. El protocolo de transferencia de archivos consta de 2 secciones: una que corresponde a la parte del protocolo de texto y otro a la parte del protocolo binario. A continuación se especificara es como este protocolo se maneja.

6.7.1 Protocolo de texto El protocolo de texto es similar al protocolo del MSN IM, con la excepción que no se maneja el concepto de TranID. En este protocolo maneja un conjunto reducido de

ISC-2003-2-4

111

comandos y no se maneja ningún mensaje con carga34. El primer mensaje que se envía, lo hace el contacto que recibe el archivo y la idea es establecer cual es el protocolo de transferencia de archivo, este se establece con el comando VER seguido por el parámetro MSNFTP. Para este caso es el protocolo MSNFTP que corresponde al protocolo de transferencia de archivo. Cuando el que envía el archivo recibe este mensaje, este devuelve el comando VER seguido por el MSNFTP indicando que soporta la transferencia de archivo. Ya intercambiado los mensajes de versiones, el cliente que recibe el archivo procede autenticarse con el comando USR seguido por el email del contacto y el AuthCookie. Es obligación por parte del servidor manejar la autenticación es decir el contacto que envía el archivo. Es importante esto para evitar confusión dentro del cliente. Se procede a comparar el AuthCookie que tiene el servidor contra el AuthCookie que envía el contacto que recibe el archivo. Ya validado esto, el servidor le devuelve al cliente el comando FIL seguido del número de bytes que le va a proceder a enviar. Es parte de la seguridad que este valor coincida con el mismo valor que le fue enviado al cliente inicialmente. Cuando el cliente recibe el tamaño del archivo este procede a enviar el comando TFR que indica que se puede comenzar con la transferencia del archivo. Ya esta parte pasa del protocolo de texto al protocolo binario. Cabe anotar que después de haber finalizado la parte de transferencia de archivo, el cliente le envía al servidor, que en este caso el que recibe el archivo le envía al contacto que envía el archivo el comando BYE, con el parámetro que si tuvo éxito o no o el comando CCL, sin parámetro indicando que se canceló la transferencia de archivo. Los parámetros de los comandos BYE, el único que se ha observado es el de 16777989 que indica que la transferencia tuvo éxito. Ya recibido por parte del servidor el comando BYE, tanto el cliente como el servidor pueden cerrar sus respectivas conexiones.

6.7.2 Protocolo binario Ya resuelto la negociación entre el cliente y el servidor, este último cambia su formato de protocolo y pasa al protocolo binario. Este protocolo se compone de mensajes binarios con la siguiente forma: El primer byte indica el estado de la transferencia de archivo un 0 para transferencia todavía en progreso y el valor de 1 para indicar que ha finalizado. El segundo byte y tercer byte indican el tamaño del mensaje binario a ser enviado. El tamaño se deduce de la siguiente formula: TAM = byte [2] + byte [3]*256. Es decir que los

34 Para un mejor entendimiento proceder al ejemplo de transferencia de archivo en los anexos.

ISC-2003-2-4

112

bytes tanto dos y tres están byte-swapped. Ya conociendo el tamaño de la información este es igual al tamaño en bytes del archivo a leer, por ejemplo si se tienen los tres primeros bytes como 0, 4, 1, el tamaño de bytes del archivo que se debe enviar, debe de ser de 260 bytes. La secuencia de estos mensajes es la siguiente:

- Mientras el tamaño restante del archivo a enviar sea igual o mayor a 2045 bytes se envía el mensaje de 0, 253, 7 (en binario y sin comas). Se leen estos bytes del archivo y se le envía al cliente esta información. Después de enviar el mensaje se repite este proceso hasta que la condición siguiente se cumpla.

- Si por el contrario resulta ser menor de 2045, indicación que se terminará de enviar el archivo, se envía la cantidad de bytes restantes e indicando la cantidad de bytes a enviar en el encabezado, si por ejemplo restan 35 bytes se envía el encabezado 0, 35, 0 seguido por los bytes del archivo. Terminado de enviar esto, se espera del cliente que envié el comando BYE o CCL.

Ya finalizada la transferencia de archivo, el cliente podrá continuar normalmente. En el caso que se produzca un error, es normal que tanto el cliente como el servidor respondan con los mensajes de carga de cancelación de invitación en la conexión al servidor SWITCHBOARD.

ISC-2003-2-4

113

7 IMPLEMENTACION SADPD Se desarrollo un proyecto dentro de JBuilder 9 que utiliza las librerías de OpenTools. La idea es integrar el API del OpenMessenger dentro de JBuilder. Esto se desarrollo mediante el desarrollo de las interfaces que existe entre OpenTools y OpenMessenger. De OpenTools se utilizo las interfaces de nodos (tanto nodos, como visualizadores), y propiedades. Para los nodos se creo tanto una representación de nodo del SADPD, como también se creo una representación visual del nodo (visualizador), es en esta representación visual es en donde se realiza la comunicación entre el IDE y el OpenMessenger. Esta unión se realiza mediante la creación de un GUI que es el encargado de llamar a la clase Factory del OpenMessenger que devuelve un modelo del servicio de IM. El GUI a su vez tiene que implementar dos interfaces del OpenMessenger, una encargada de la parte del manejo del servicio IM y la otra encargada de las conversaciones entre usuario. Por otra parte el GUI del sistema también se encarga de actualizarse automáticamente cuando el modelo del servicio IM cambia. Tambien para el nodo SADPD se asocio un sistema de propiedad que le pide al usuario, su información para poderse conectar al servcio de IM. Por la parte del OpenMessenger se implementaron cuatro capas, cada una encargada de una función específica: Capa comunicación: Es la capa encargada de las comunicaciones de bajo nivel, tanto comunicaciones a bases de datos, como también comunicaciones a nivel de sockets y a servidores HTTPS. Capa protocolo: Se encarga del manejo del protocolo y utiliza la capa de comunicación como fuente de sus conexiones. En esta capa de protocolo se implementaron cuatro tipos de protocolos: el primero el de autenticación a Passport, el segundo el servidor NOTIFICATION/DISPACTH, el tercero el servidor SWITCHBORAD y por ultimo el de transferencia de archivo. Capa modelo: Se encarga del manejo lógico de la información del OpenMessenger, tales como lista de contactos, lista de grupos, nombre de usuario, estado de conexión, etc. Capa GUI: Que es la interfaz grafica del programa. Esta interfaz grafica posee la posibilidad de poderse reutilizar. Esta posibilidad la utiliza el visualizador de nodo del SADPD ya que llama al GUI de copnversaciones. Cabe anotar que la capa de protocolo es la encargada de realizar las conexiones y el manejo de threads del sistema de IM. Por lo tanto el SADPD no se tiene que preocupar por la concurrencia, ni el manejo de conexiones.

ISC-2003-2-4

114

8 PROBLEMAS ENCONTRADOS Durante el desarrollo de la tesis a mediados de Octubre, por decisión de Microsoft se cambio el protocolo de comunicación del servicio de MSN IM. Al iniciar el desarrollo del SADPD se estuvo trabajando con el MSNP7 que era el protocolo mas avanzado de ellos hace un año, pero lo decidieron cambiar por efectos de seguridad y solo permitir la utilización del protocolo de la versión MSNP8 para arriba. Esto implico un desgaste dentro del desarrollo de la aplicación. Ya que se tuvo que reimplementar, y probar las nuevas especificaciones del protocolo. Debido a lo anterior no se pudo implementar los servicios de estadísticas que inicialmente se había propuesto. Por otra parte el MSNP8 exigía una autenticación con el servidor de Passport de Microsoft, esto implico una investigación a profundidad sobre el sistema HTTPS y sobre como se realiza la autenticación con el sistema Passport. Con esto reduciendo el tiempo de implementación de mejoras al SADPD. También se tuvo que enfrentar con la implementación de la transferencia de archivos que fue tediosa y complicada, debido a su forma asincrónica de comunicación. Esto desplazo los tiempos de desarrollo enormemente impidiendo la implementación del sistema de intercambio de parte de documentos y texto. Aunque la transferencia de archivo si se logro. También, durante mucho tiempo se tuvo un defecto en el sistema de comunicación que técnicamente consumía casi todos los recursos de la maquina impidiendo un desarrollo rápido y consistente con lo que se había planeado. En definitiva si no se hubieran presentado todos estos inconvenientes hubiera sido posible implementar un excelente SADPD.

ISC-2003-2-4

115

9 MEJORAS FUTURAS

- La principal de todas, tener toda la funcionalidad inicialmente especificada. Por otra parte mejorar y desarrollar mejor todo el sistema de concurrencia y conexiones del OpenMessenger. También desarrollar un mejor GUI para el SADPD.

- Implementarle un conjunto de protocolos de mensajería instantánea, para que no solo se comunique con la gente de MSN IM, sino que pueda comunicarse con la gente que se encuentra en AIM, ICQ, Jabber, etc.

- Desarrollarle un buen sistema de historial y estadistica y observar cual es el uso específico que se le da a esta herramienta.

- Tambien se puede extender el SADPD no solo a JBuilder, sino a Eclipse, NetBeans, JDeveloper, etc. Esto con el fin de poder unir mucho más a los equipos de desarrollo.

- Hacer mediciones sobre el uso de la herramienta y compararla cuando no se utiliza la herramienta, esto con el fin de comprobar si el SADPD es realmente una herramienta de apoyo.

ISC-2003-2-4

116

10 CONCLUSIONES Se tuvo una experiencia grata en la investigación de protocolos de mensajería instantánea como también en la investigación de herramientas de desarrollo en especial JBuilder. Se amplio mucho mas los conocimientos sobre la realización de aplicaciónes que se integran a herramientas de desarrollo, como también la realización de aplicaciones de mensajería instantánea. Se mejoraron los conocimientos sobre desarrollo a mediana escala, y sobre el manejo de aplicaciones de multi-threading, y aplicaciones orientadas a cliente-servidor. Con respecto al SADPD se observó que es una herramienta con futuro si se implementa en su totalidad ya que permite a los desarrolladores poseer dentro de su IDE una herramienta que le amplia las posibilidades de comunicación y control. Por otra parte se incursionaría en el tema de lo que son las herramientas colaborativas, de alta investigación sobre todo en el área de apoyo y administración de equipos de desarrollo. También se estaría manejando el tema de las comunicaciones empresariales y el impacto que podría tener los sistemas de mensajería instantánea dentro de las organizaciones. Por ultimo, que la experiencia que se obtuvo de este trabajo fue enorme. Se incursiono en temas desconocidos, se realizo investigación seria sobre los temas, se buscó información en toda la Internet. Todo esto guiando al desarrollo del SADPD.

ISC-2003-2-4

117

11 BIBLIOGRAFIA [1] Mike Mintz. MSN Messenger Protocol. http://www.hypothetic.org/docs/msn/index.php [2] Zonorax. http://wisoftware.host.sk/msn6/ [3] NetBeans. http://www.netbeans.org/ [4] NetBeans OpenApi. http://openide.netbeans.org/ [5] Borland JBuilder. http://www.borland.com/JBuilder/ [6] Borland OpenTools. http://info.borland.com/techpubs/JBuilder/ [7] Borland OpenTools Repository. http://codecentral.borland.com/codecentral/ccweb.exe/prodcat?prodid=3&catid=11 [8] Borland Newsgroups. news://newsgroup.borland.com/ [9] Jabber. http://www.jabber.org/ [10] JabberBeans. http://jabberbeans.jabberstudio.org/ [11] JSO. http://www.jabberstudio.org/projects/jso/project/view.php [12] SMACK. http://www.jivesoftware.com/xmpp/smack/ [13] BuddySpace. http://buddyspace.sourceforge.net/

ISC-2003-2-4

118

ANEXO A. Diagrama de secuencia

Ilustración 32 Diagrama de Secuencia

ISC-2003-2-4

119

Ilustración 33 Diagrama de Secuencia 2

ISC-2003-2-4

120


ISC-2003-2-4

121


ISC-2003-2-4

122


ISC-2003-2-4

123

ANEXO B. Ejemplo autenticación servidor DISPATCH y NOTIFICATION

A continuación se muestra el normal ejemplo de una autenticación al servidor de DISPATCH y NOTIFICATION. Los mensajes que envía el cliente al servidor van iniciados por la cadena >>>, y los que recibe el cliente del servidor van iniciados por la cadena <<<. Conexión al servidor DISPATCH <messenger.hotmail.com:1863> >>> VER 0 MSNP8 CVR0 <<< VER 0 MSNP8 CVR0 >>> CVR 1 0x0409 win 4.10 i386 MSNMSGR 5.0.0544 MSMSGS [email protected] <<< CVR 1 6.0.0602 6.0.0602 5.0.0527 http://download.microsoft.com/download/8/a/4/8a42bcae-f533-4468-b871-d2bc8dd32e9e/SETUP9x.EXE http://messenger.msn.com >>> USR 2 TWN I [email protected] <<< XFR 2 NS 207.46.106.182:1863 0 207.46.104.20:1863 Conexión al servidor NOTIFICATION <207.46.106.182:1863> >>> VER 3 MSNP8 CVR0 <<< VER 3 MSNP8 CVR0 >>> CVR 4 0x0409 win 4.10 i386 MSNMSGR 5.0.0544 MSMSGS [email protected] <<< CVR 4 6.0.0602 6.0.0602 5.0.0527 http://download.microsoft.com/download/8/a/4/8a42bcae-f533-4468-b871-d2bc8dd32e9e/SETUP9x.EXE http://messenger.msn.com >>> USR 5 TWN I [email protected] <<< USR 5 TWN S lc=1033,id=507,tw=40,fs=1,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1074574867,kpp=1,kv=5,ver=2.1.0173.1,tpf=50a355e31b002f11d7042cd40e124708 Conexión al servidor nexus <https://nexus.passport.com> y se obtiene el ticket. El ticket corresponde a la parte en negrilla. >>> USR 6 TWN S t=5xiWQ8Da3DuUJcixU6u1DNGF1yH!l1JawuWbWwDE3SkdB*acwHq2qNsu2r3O5R6*jPPKA6lnLMXmBTIZtl9bj7QA$$&p=5Zb4!2Q9eDAfxmeiF60pDw5IA4B79bJqaOTRudehl56DGYxuqpTgFBSk5EGhWRcuRtVvTf5ccLqD*1GlMcKTzGDGZyD6iwvgmZyV1P1dE0iT2drWKnNj9L4jYguJ**Jhsv492ABrQxsovlKurFNKdx8vQE2y0aRF0ZGcipzNbodHSxhDuL4VwOT1B2Ykt!RmY2 <<< USR 6 OK [email protected] openmesenger 1 0 >>> CHG 7 NLN 0 <<< MSG Hotmail Hotmail 461 MIME-Version: 1.0 Content-Type: text/x-msmsgsprofile; charset=UTF-8 LoginTime: 1074574871 EmailEnabled: 1 MemberIdHigh: 425982 MemberIdLow: -2072679306 lang_preference: 1033 preferredEmail:

ISC-2003-2-4

124

country: CO PostalCode: Gender: Kid: 0 Age: BDayPre: Birthday: Wallet: Flags: 1027 sid: 507 kv: 5 MSPAuth: 5xiWQ8Da3DuUJcixU6u1DNGF1yH!l1JawuWbWwDE3SkdB*acwHq2qNsu2r3O5R6*jPPKA6lnLMXmBTIZtl9bj7QA$$ ClientIP: 200.118.49.52 ClientPort: 10000 No se recibe el mensaje text/x-msmsgsinitialemailnotification ya que no había ningún nuevo email en ese momento. <<< CHG 7 NLN 0 >>> SYN 8 0 <<< ILN 7 NLN [email protected] :)%20The%20Apocalipsys%20:) 0 <<< SYN 8 46 5 1 <<< GTC A <<< BLP AL <<< LSG 0 Hello 0 <<< LST [email protected] [email protected] 8 <<< LST [email protected] [email protected] 11 0 <<< LST [email protected] [email protected] 11 0 <<< BPR PHH 57%20(1)%203479661 <<< LST [email protected] ;)%20%20alejo 5 0 <<< LST [email protected] [email protected]%20(E-mail%20Address%20Not%20Verified) 13 0 <<< CHL 0 14090302242700512076 >>> QRY 9 PROD0038W!61ZTF9 32 213de646567f2af20f2e0f6c9069a102 <<< QRY 9

ISC-2003-2-4

125

ANEXO C. Ejemplo conversación en el servidor SWITCHBOARD

Se muestra a continuación como un usuario llama a un contacto y viceversa. Ejemplo de un usuario contactando un contacto Servidor NOTIFCATION >>> XFR 9 SB <<< XFR 9 SB 207.46.108.96:1863 CKI 256558.1074575086.12265 Servidor SWITCHBOARD <207.46.108.96:1863> >>> USR 0 [email protected] 256558.1074575086.12265 <<< USR 0 OK [email protected] openmesenger >>> CAL 1 [email protected] <<< CAL 1 RINGING 256558 <<< JOI [email protected] :)%20The%20Apocalipsys%20:) Envió de mensajes de conversación instantánea. >>> MSG 2 N 137 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-MMS-IM-Format: FN=Microsoft%20Sans%20Serif; EF=I; CO=0; CS=0; PF=22 Hola Envió de mensajes de invitación de transferencia de archivo. >>> MSG 3 N 279 MIME-Version: 1.0 Content-Type: text/x-msmsgsinvite; charset=UTF-8 Application-Name: File Transfer Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F795683} Invitation-Command: INVITE Invitation-Cookie: 1519818011 Application-File: README.TXT Application-FileSize: 2070 <<< MSG [email protected] :)%20The%20Apocalipsys%20:) 186 MIME-Version: 1.0 Content-Type: text/x-msmsgsinvite; charset=UTF-8 Invitation-Command: ACCEPT Invitation-Cookie: 1519818011 Launch-Application: FALSE Request-Data: IP-Address: >>> MSG 4 N 246 MIME-Version: 1.0 Content-Type: text/x-msmsgsinvite; charset=UTF-8 Invitation-Command: ACCEPT Invitation-Cookie: 1519818011 IP-Address: 200.118.49.52 Port: 6891

ISC-2003-2-4

126

AuthCookie: 161284561 Launch-Application: FALSE Request-Data: IP-Address:

ISC-2003-2-4

127

ANEXO D. Ejemplo de una transferencia de archivo En este ejemplo el usuario esta enviando un archivo a un contacto. <Conexión al cliente 200.118.49.52:6891> <<< VER MSNFTP >>> VER MSNFTP <<< USR [email protected] 161284561 >>> FIL 2070 <<< TFR <Transferencia Binaria del archivo README.TXT> <<< BYE 16777989

SISTEMA DE APOYO AL DESARROLLO EN PARALELO (SADPD)

Documents

Transcript of SISTEMA DE APOYO AL DESARROLLO EN PARALELO (SADPD)