Casa abierta al tiempo UNIVERSIDAD AUT~NOMA METROPOLITANA

Reporte de Proyecto Terminal

Servicios de Información y Mensajes para Sistemas en Tiempo Real.

Margarita Vidal Vivar. 87334250.

Reporte de Proyecto Terminal I y II Título : Servicios de Información y Mensajes para Sistemas en Tiempo Real.

Alumna: Vidal Vivar Margarita. Asesor : Soto Guadarrama Jorge.

Matrícula: 87334250. Licenciatura: Computación. i: b I

El alumno

' \ 1 .

Vidal Vivqr Margarita.

El Asesor

. i " [

rofr. Soto Guadarrama Jorge.

INDICE

I . Introducción ................................................................................................... 2 I I . Identificación del problema y Determinación de requerimientos ................... 3 Ill . Análisis y Diseño del sistema ........................................................................ 4

A . Metodología Tradicional ............................................................................ 4 B . Metodología lteractive life - cycle (for real time systems) ......................... 4 C . Análisis y diseño de los servicios ............................................................... 8

A . FinRX32 ................................................................................................... 10

2 . Plataforma y Características del Servidor ............................................ 10 3 . Arquitectura .......................................................................................... 10 4 . Proceso de Recepción de tramas ........................................................ 11 5 . Tratamiento de Datagramas ................................................................. 11 6 . Análisis de la Información .................................................................... 13 7 . Conmutación de Medio ........................................................................ 13 8 . lnterfaz Visual ...................................................................................... 14

B . FinTCP .................................................................................................... 16 1 . Funcionalidad ....................................................................................... 16 2 . Herramientas de Programación y Base de Datos ................................ 16 3 . Plataforma y Características del Servidor ............................................ 16 4 . Arquitectura .......................................................................................... 16 5 . Proceso de Recepción de Notificación ................................................. 17 6 . Tratamiento de Información y notificación a usuarios ......................... 17 7 . DDE ..................................................................................................... 17 8 . Interfaz Visual ...................................................................................... 18

V . Bibliografía .................................................................................................. 19

IV . Desarrollo de Aplicaciones (Servicios) ........................................................ 10

1 . Funcionalidad ....................................................................................... 10

VI . Apendice A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Reporte de Proyecto Terminal . 1

1. Introducción. La motivación principal para la realización de este proyecto es la participación en un sub proyecto de un sistema real de características críticas y complejas por ser un sistema de Información Financiera en Tiempo Real. Este proyecto representa un reto entre la integridad de datos y la medición del tiempo en que llega a la aplicación de escritorio finalmente . Actualmente existe varios tipos de sistemas en Tiempo Real como son reservación de vuelos aéreos , reservación de otros servicios y sistemas financieros siendo estos últimos pioneros en este tipo de sistemas. Para la realización de un sistema financiero en tiempo real se quiere de un gran financiamiento porque debe haber elementos como son los feeds o fuentes de información de donde se va a alimentar el sistema, una infraestructura de comunicaciones y telecomunicaciones y otra serie de servicios para proveerse o enviar la información. En términos prácticos un sistema en tiempo real es aquel en el prácticamente no hay distinción de tiempo entre el suceso que ocurre y el punto final a donde se envía la descripción de este suceso. Finsat es un sistema de información financiera en Tiempo Real que tiene diversos proveedores de información financiera y noticiosa, tales como son : la BMV (Bolsa Mexicana de Valores) , Finsat su propia Agencia Noticiosa , Bloomberg (Agencia Noticiosa con sede en NY) , Bridge (Feed de Bolsa Internacional ) , IBES (Calificadora) , esta información es tratada de forma diversa y enviada a los clientes de forma específica. Finsat es un sistema que desarrollo computacional en telecomunicaciones, bases de datos, aplicaciones de servidor y aplicaciones cliente e Internet, sin embargo el enfoque de mi proyecto de limita a la parte de aplicaciones servidor, y es donde se pone en práctica la teoría de bases de datos, análisis de algoritmos, y modelos matemáticos. El objetivo de participar en este proyecto fue realizar dos aplicaciones FinRX32 y FinTCP, ambos son fungen como servicios dentro del ámbito del sistema y que corrieran en servidores NT dentro de una LAN (Local Area Network), y que a su vez canalizaran la información a través de este mismo tipo de red. El FinRx32 es un servicios de análisis de información y almacenamiento a la base de datos. El FinTCP es un servicio de mensajes servidor - cliente Los nombres de estos servicios son sobre la base de la política de terminologías que ya hay dentro del sistema. Aunque cada aplicación tendrá objetivos diferentes también se dará una comunicación entre ellos, manteniendo en cada momento su independencia. Esta independencia dará fortaleza al funcionamiento del servidor y visto de forma global del sistema en su totalidad. La comprensión a detalle de los objetivos y la funcionalidad de estas aplicaciones irá dando a medida del avance en la lectura de este reporte.

Reporte de Proyecto Terminal. 2

I I . Identificación del problema y Determinación de requerimientos.

El problema de aplicaciones con un elevado número de transacciones por minuto es el consumo de recursos de la máquina. El sistema constaba con una aplicación en un servidor que interpretaba información proveniente de algún medio, la grababa a la base de datos y además enviaba mensajes a las máquinas cliente que estaban conectadas al servidor los reportes en recursos fueron del 100% en virtual memory era evidente un memory leak (goteo de memoria), 80% - 100% en Usage CPU, estas cifras fueron alcanzadas en 3 días de operación como máximo, y en un menor lapso de tiempo frecuentemente.

El primer paso pensar en comenzar a determinar que se necesitaba, fue en primera instancia delegar de funciones a la aplicación en función, es decir particionarla en dos servicios fuertemente demandantes en recursos: 1 ) Servicio de análisis de información y almacenamiento de información en la base de datos, y 2) Servicio de envío de Mensajes.

Servicios

Integrados miento en base

Factores decisivos para particionar en dos servicios la aplicación con problemas: 1. Si la parte de acceso a la base datos seguía goteando memoria,

seguramente habría que cerrarla para liberar recursos y volverla a inicializar, por lo que sólo esa detendría su funcionamiento momentáneamente.

2. Independencia en el servicio de envió de mensajes, los usuarios conectados al servidor no se desconectarán de éI, en caso de que el servicio de análisis y almacenamiento se encuentre con status de stop.

3. Facilidad para determinar donde está el problema. 4. Rapidez en el mantenimiento. 5. Estabilidad en el sistema. 6. Perdurabilidad en el funcionamiento de las aplicaciones.

Reporte de Proyecto Terminal. 3

111. Análisis y Diseño del sistema.

Antes de llegar por completo a la parte del análisis y diseño del sistema, es necesario comprender la metodología que se surgió ya que no fue la de tipo estructural que comprende los 7 pasos ya tradicionales, que se mencionarán para cualquier analogía con la metodología que posteriormente se explicará:

A. Metodologia Tradicional.

1. 2. 3. 4. 5. 6. 7.

Identificación de problemas, oportunidades y objetivos. Determinación de los requerimientos de información. Análisis de las necesidades del sistema. Diseño del sistema Recomendado. Desarrollo y documentación del software. Prueba y mantenimiento del sistema. Implantación y evaluación del sistema.

L

B. Metodología lteractive life - cycle (for real time systems).

Para utilizar el proceso iterativo de una aplicación grande es preciso dividir en subpartes más pequeñas. Entonces cada una de esas partes es: 1. Diseñada. 2. Implementada. 3. Probada y Validada.

Usando el método V life cycle. Esto permite la ejecución de seguros problemas a ser descubiertos durante el completo desarrollo del proceso, todo esto podrá ocurrir precisamente antes de liberar el sistema. Esta estrategia es especialmente útil cuando un equipo de programadores está utilizando un ambiente de desarrollo integrado. Porque todos los miembros del equipo están enfocado en una sola y pequeña parte del gran sistema, ellos son capaces de navegar relativamente rápido a través de cualquiera de todos los pasos del desarrollo, esto da a ellos una rápida experiencia con cada una de las herramientas de desarrollo. Esta rápida experiencia es particularmente importante cuando se usa generación de código automático.

El proceso iterativo propugna a encontrar el re - uso del código, permitiendo que miembros del equipo evalúen inmediatamente cuanto código puede reutilizarse. Porque esta evaluación es ejecutada antes, en la planeación del proyecto, esta puede ser una mejor influencia sobre el análisis y del diseño de actividades. Si es necesario, la arquitectura puede ser estructurada lo que permite rehusar el código existente para alguna de las partes. Esas partes pueden ser añadidas a la lista de trabajos a ser hechos por añadidura.

Reporte de Proyecto Terminal. 4

Un desarrollo iterativo orientado a objetos, permite a miembros del equipo seguir mejor el rastro del progreso de su proyecto. Para proporcionar el máximo beneficio. La más crítica de las partes del proyecto deberá ser desarrollada primero. Esto deja pocas sorpresas al final del proyecto. Típicamente, las aplicaciones deberán ajustarse de acuerdo al siguiente patrón:

1) Core functions (El corazón de las funciones) 2) Critical functions (Funciones críticas) 3) Repetitive functions (Funciones repetitivas)

Exactitud de las Aplicaciones. En el desarrollo en tiempo real, uno de los mayores problemas es el

finetunning (fina configuración) del software para arquitectura de la máquina. Parte de la solución es probar por simulación la aplicación en un host similar antes de que se implemente de forma definitiva.

Una buena simulación responde tres preguntas fundamentales: 1) Muestra la aplicación el funcionamiento esperado en un número de casos

nominales? Esta pregunta puede ser rápidamente contestada a través de un rápido prototipo.

2) Se ejecuta de forma confiable la aplicación? Esto se puede responder a través de la verificación de procesos.

3) Satisface la aplicación todos los requerimientos originales? Su respuesta está en la validación de procesos

Generación rápida del prototipo. La Generación rápida del prototipo permite al programador llegar a

familiarizarse con el funcionamiento de la aplicación, y para verificar que esta trabaja como se esperaba en un número limitado de casos nominales. Para acompletar esto el programador debe proporcionar un modelo parcial.

Verificación. La meta de la verificación es determinar si el diseño del modelo funciona

adecuadamente. Algunos de los problemas detectados por el simulador durante la fase de verificación son:

1) Errores de aritmética, tales como apuntar fuera de los límites o la división

2) Código muerto (código que se creo pero no se utiliza). 3) Overflow en estructuras (desbordamiento de pilas, colas,etc.) 4) Deadlock (abrazos mortales sobre algún recurso). 5) Livelock (un livelock puede ocurrir cuando un proceso entra en un ciclo que

entre cero.

no tiene caso base).

Modelo para el Método V life cycle.

Validación. El objetivo de la validación es para probar que la descripción del modelo

cumple completamente con todos los requerimientos de las especificaciones del sistema. Los requerimientos pueden ser expresados en tres diferentes formas: 1 ) stop conditions. 2) Message sequence charts 3) Observers

Stop conditions Las condiciones de parada definen fronteras para el funcionamiento del sistema

con expresiones booleanas que siempre deberán ser verdaderas. Por ejemplo cuantas veces un avión esté debajo de los 1000 pies , una alarma de aviso deberá encenderse siempre. El simulador observa cualquiera violación de estas reglas, y la simulación se termina si detecta alguna violación.

Messagesequence charts Un mensaje de secuencia gráfica muestra un conjunto ordenado transmisión de mensajes entre dos objetos que ocurrirá en cualquiera de los objetos que están intentando llevar a cabo un propósito particular. Esta secuencia de mensajes gráfica define todos los posibles escenarios que el simulador puede observar durante una simple simulación. La secuencia de mensaje gráficos son típicamente usados para describir los escenarios que son esperados durante una operación normal del sistema. Sin embargo, ellos también pueden ser usados para describir secuencia de mensajes que nunca deberán ser observados. El simulador puede entonces observar esa secuencia de mensajes prohibidos durante la simulación, y así utilizar una alerta el programador si alguno de estos ocurre.

Reporte de Proyecto Terminal. 6

Observers En algunos casos, el funcionamiento de un objeto no es gobernando

solamente por el actual estado del sistema, sino también por una secuencia de eventos con prioridad. En orden para determinar si un objeto está funcionando como debe, el simulador debe conocer si es requerida o no la secuencia de eventos que ha ocurrido. Para proporcionar esta información al simulador, estados finitos (llamados observadores) de la máquina deben ser definidos

Rol del simulador durante la validación. Durante la simulación del proceso, el simulador usa condiciones de parada, la

secuencia de mensaje gráfico y los observadores para evaluar el funcionamiento del diseño del modelo.

Existen dos funciones que son ejercitadas durante la simulación. 1) Random simulation mode. 2) Exhaustive simulation mode.

Random simulation mode. La simulación en modo random causa que el explorador de manera aleatoria

verifique el funcionamiento de alguna parte de código sin previo aviso. Esta prueba deberá de comenzar con una semilla inicial que el mismo programador proporcione, la cobertura de esta prueba deberá ser en tiempo real.

Exhaustive simulation mode. La simulación en modo exhaustivo requiere que el explorador verifique todas y

cada una de las parte del código. Cuando el simulador corre en este modo, se revisa todas las propiedades de validación. Si una violación es detectada, el simulador almacena el escenario que se produjo, y se termina la simulación.

Como podemos ver en la figura de abajo si un proceso del modelo no ha pasado por las etapas necesarias no podrá continuar a la siguiente parte del modelo, seguir el modelo proporciona confiabilidad en cada una de las partes que se vayan liberando, escalabilidad y la eficiencia que se busca en las aplicaciones de tiempo real. De modo que cada submodelo se trata como un conjunto total en lo que se refiere a etapa de prueba y liberación. Hasta aquí se ha explicado el modelo utilizado para este proyecto y las razones por las cuales no se implemento el modelo tradicional que trata el sistema como a un todo indivisible.

Una vez descrito el modelo se muestra de forma gráfica el flujo del trabajo en un proyecto.

Reporte de Proyecto Terminal. 7

I , Subpart 1""""" , Subpart * """"""""" -+ Last Part

Modelo Iterative life - cycle.

C. Análisis y diseño de los servicios. El modelo de the iterative life - cycle proporcionó una ágil forma de ir

construyendo un modelo para los servicios del FinRx32 y FinTCP y como primera instancia se determinó que las funciones del FinRx32 deberían ser las siguientes: 1) Análisis de la información proveniente de algún medio. 2) Guardar esta información la Base de Datos. 3) Detectar alarmas de Mercado o de Noticias 4) Notificar al servicio de FinTCP sobre la llegada datos y levantamiento de

alarmas de Mercado o de Noticias.

Análisis de Información en , Información Guardar

Base de Datos

v Base Detectar

Datos b Alarmas de

Cada una de las funciones de FinRx32 arriba mencionadas se sometería a las etapas del V life - cycle con simulación propuesta por el iterative life - cycle.

Reporte de Proyecto Terminal. 8

El servicio del FinTCP debería de ser más independiente por lo que sus funciones se limitaron a: 1) Administración de Monitores de usuarios. 2) Análisis de Notificación proveniente del FinRx32. 3) Envió de Notificaciones a los usuarios conectados al FinTCP.

Análisis de

Usuarios usuarios Notificacion a - Monitores de - Notificación Envió de Administración de

Aquí hay un punto importante, el análisis de la notificación no puede pasar directamente al envió de notificación al usuario, porque precisamente la administración de Monitores se encarga de ver que usuarios están conectado y que monitores abiertos tiene, esta discriminación se hace ya que el envió de paquetes sin control a la red, la sobrecarga innecesariamente.

La relación final entre los servicios del FinRx32 y FinTCP, fue por medio de notificaciones utilizando UDP (Uniform Data Protocol), de forma unidireccional como lo muestra la figura.

m FinRX32 rln Notificación

Finalmente lo último que se tocó como punto de análisis fue decidir cual sería la herramienta para desarrollar las aplicaciones, no había mucho que seleccionar dadas las siguientes características:

1 ) Fuera rápida para desarrollar. 2) Estuviera bajo el estándar de Microsoft, pues correría bajo sistema

operativo Microsoft NT Server y Manejador de Base de Datos Microsoft SQL Server.

3) Utilizara clases, para manejar de manera natural la reutilización de código 4) Conviviera con controles ya existentes.

De esta forma el lenguaje seleccionar fue Microsoft Visual Basic 5.0.

Reporte de Proyecto Terminal. 9

IV.Desarrollo de Aplicaciones (Servicios).

A. FinRX32

l . Funcionalidad. Tiene como finalidad recibir tramas de información de algún medio (Satélite,

Radio o Frame Relay ), desglosar el protocolo, detecta las características de cada paquete y formar sentencias para insertar registros en la base de datos, detectar alarmas y enviar notificaciones al FinTCP. Esta aplicación realiza cientos de accesos a la base de datos por minuto, de ahí lo importante de algoritmo y la estructura de datos interna que maneje para este fin. A continuación se describe de forma más detallada el proceso desde la llegada de información hasta la notificación. Herramienta de Programación y base de datos. Microsoft Visual Basic 5.0, como lenguaje de programación. Microsoft SQL Server 6.5,como Manejador de Base de Datos.

2. Plataforma y Características del Servidor.

Microsoft NT Server versión 4.0 como sistema operativo. La partición donde reside el sistema operativo debe estar como NTFS y deberá

ser instalado como Stand Alone. Service Pack 3.0 posterior. El servidor contará con un mínimo de 64 MB en memoria RAM y 2GB de

espacio mínimo en disco duro libre.

3. Arquitectura. El FinRX32 está divido en módulos específicos. Existe un módulo que recibe

los datagramas que le llegan del medio emisor y los almacena en un stack dinámico utilizando de manera natural la propiedad LIFO (last in first out), de esta manera cuando llega una ráfaga de información en vez de tirarla porque no la puede procesar la almacena y la procesa después. Evidentemente se utiliza un stack para los datos más recientes sean los que primero se procesen dentro del grupo en espera. En otro módulo se encuentras todas las funciones que manejan el proceso de interpretación de datos, análisis de información, verificación de alarmas de mercado y de noticias. El acceso a la Base de datos utiliza tecnología ActiveX, la implementación se hizo por medio de ADO (Activex Data Object) , y por medio del método execute de la conexión activa que realiza la transacción, el fin de utilizar el menor número de conexiones a la Base de Datos que es lo que demanda mucho recurso de memoria por la cantidad de transacciones por minuto hacia la base de datos.

Reporte de Proyecto Terminal. 10

4. Proceso de Recepción de tramas

Radio. La recepción puede ser a través de un radio, de satélite o por medio de la red.

Si el proceso de recepción es a través de un radio este se conecta a puerto serial de la computadora y por medio de un archivo con extensión DLL se comunica a la aplicación FinRX32 para que en ella se procese la información.

Satélite. Si el proceso de recepción es a través de satélite la información llega a un

pace o receptor satelital que el proveedor de la señal satelital establece, este a su vez hay que sintonizarlo en el canal correcto para la recepción de datos y la conexión al servidor se realiza por medio del puerto serial.

Frame Relay. Si el proceso de recepción se hace por medio de Frame Relay el protocolo de

comunicación es por medio de TCP/IP (Transport Protocol / Internet Protocol) y hay que definirle al FinRx32 , una dirección IP Remota desde donde va a recibir y unos dos puertos, uno local que corresponde al servidor y uno remoto que corresponde a la máquina que envía los datos.

Medios De Envio de Datagramas

Señal de Radio

Frame Relay

5. Tratamiento de Datagramas

La información llega en forma de datagramas que es un conjunto de paquetes que a su vez es interpretado. Cada paquete contiene dos elementos básicamente un header y la información propiamente.

Reporte de Proyecto Terminal. 11

El Header está divido como sigue:

Segmento El número de entidad dentro de la base de datos. Aquí cabe aclarar que dentro de la base hay entidades corresponden a una información específica y es por ello es que algunas de ellas se encuentran aisladas, y estas entidades precisamente son llamados segmentos y están numerados de forma bien definida, así el segmento 1 corresponde a la entidad t-ncam-dolar-int, etc, y cuando el header especifica el segmento 1 se sabe que la información del paquete corresponde a la Tabla T-Ncam-Dolar-lnt.

Modo El modo indica la cantidad de campos que viene un registro es decir, si es una retransmisión de dicho registro ya no se envían todos los registros ya que es importante optimizar el uso del canal para no saturarlo, otro ejemplo es si se quiere enviar la corrección de algún campo sólo se enviará ese dato y no todo el registro se manejan siete modos para cada segmento.

Secuencia Es el control de paquetes, este campo contiene información que describe a que parte del paquete entero corresponde es decir cada paquete deberá venir etiquetado paquete1 de 3 , paquete 2 de 3, paquete 3 de 3 , si por alguna razón alguna parte del paquete se pierde en trayecto, las partes del paquete que pudieron llegar se deberán de tirar, ya que de procesarse la los paquetes incompletos pierde integridad y que al final del proceso lo que no se debe de perder es la confiabilidad de los datos.

Longitud Indica la longitud en Bytes del paquete, los paquetes no puede ser demasiado grandes para favorecer el factor velocidad en el medio.

Tipo Indica el tipo de paquete del que se trata.

Estructura de Datagrama.

Información

6. Análisis de la Información Una vez analizado el paquete sobre la información que trae, el siguiente paso

es insertar o actualizar la información en la base de datos, de acuerdo a la operación que se realice se formará una notificación del tipo

id segmentolid-registrolnombre-tablalu/l esta notificación será la que recibirá el FinTCP Existen acciones que no registran notificación al TCP, por ejemplo, las de mantenimiento a la base de datos. Las acciones de mantenimiento son: 1) Inserción de datos Históricos en la base de datos. 2) Borrado de algún registro con información incorrecta. Estas acciones se distinguen porque el paquete ya trae un registro que se llama estado y este tiene un valor específico.

I -

7. Conmutación de Medio. Cuando expira cierto tiempo (puede ser configurable), y no hay recepción de datagramas, el finRx32 tiene definido y configurado un medio secundario alterno, al que se conmuta en este caso, esto tiene como finalidad seguir proveyendo de información a la Base de Datos en caso de que el medio primario se encuentre en estatus de stop. Estando en el medio secundario verificará si el primario se ha restablecido para continuar con su recepción desde el primario, y en caso de no recibir información en el secundario estará en un ciclo constante de switcheo entre medios.

Flujo en re Medios 4

Secun dario

Para garantizar que la información se almacene, en la base de datos conexión a que hay hacia ella se restablece cada 100 segundos.

8. lnterfaz Visual.

Descripción

Sección Servidor de Base de Datos. 0 IP Adress: Dirección IP desde

donde recibe los datagramas. Sección Frames. 0 Correctos: Son los paquetes que

se han procesado correctamente. 0 Segmento: Indica a qué número

de segmento corresponde la información que se procesa.

0 Errores: Indica en que segmento ocurrió el error.

Sección Medio. Indica por cual medio está recibiendo los datagramas. Sección Tasa de Error. 0 Actual: Tasa a la cual está

recibiendo, la información. 0 Perdidos: cuantos paquetes lleva

perdidos. 0 Tasa: Tasa de perdida de datos Sección Acción. 0 Indica que si es una inserción del

Sección BD. 0 Indica el estatus de la conexión a

registro o una actualización.

la base de datos y los segundos después de inicializada.

La pantalla de configuración tiene 3

Pantalla

partes: General, Pto Serial y TCP/IP Sección General. 0 Puerto Primario tipo Indica por que tipo de medio va a ser la recepción de datagramas. Parámetros Generales. 0 Servidor BD: Indica el Servidor de

Base de datos a donde se va a grabar la información

número de puerto por el que va a recibir(TCP/IP).

0 TCPRemoteHost: Muestra la dirección Ip a donde se está conectando.

0 TCP RemotePort : muestra el

Sección Puerto Serial. 0 Puerto: indica el pto de la

computadora que está activo Velocidad: velocidad de recepción de datos

0 Bits de datos: número de bits 0 Bits de Paro: bit de paro

Bits de Paridad: tipo de paridad

Sección Remoto. Contiene la Dirección y puerto remoto al que se está conectando.

Sección Local. 0 Contiene la Dirección y el puerto

local por el que está recibiendo información.

Modo de conexión. Indica el formato de la información

B. FinTCP.

l . Funcionalidad. Los objetivos de este servicio son analizar la notificación que recibe desde el FinRX32, administrar de forma total las conexiones de los usuarios al servidor y precisar que información están viendo en sus máquinas, notificar a los usuarios de la forma más rápida posible la llega de nueva información o de alguna alarma que se haya definido. También utiliza la tecnología DDE (Dinamic Data Exchange), para comunicarse con excel. La parte de administración de usuarios decide que información se le envía a que usuario, y no se puede dar el lujo en enviar información de más, porque pensando en que el servidor como los clientes van a convivir en una red compartida se necesita optimizar el tráfico en la red para no sobrecargarla, ya que si esto llega a pasar aunque la información llegue de forma oportuna al servidor, no de igual forma llegará al cliente que es el punto final.

2. Herramientas de Programación y Base de Datos. Microsoft Visual Basic 5.0, como lenguaje de programación. Microsoft SQL Server 6.5,como Manejador de Base de Datos.

3. Plataforma y Características del Servidor. Estas características son exactamente iguales a las del FinRX32.

4. Arquitectura. Tiene una estructura basada en clases para el la administración de usuarios,

posee cuatro módulos en donde residen funciones publicas diversas para acceso a base de datos y auxiliares en procesos generales. Utiliza la tecnología DA0 3.0 para el acceso a base de datos. Desde el punto gráfico posee dos formas, la primera para configurar el puerto con el que se comunicará con los clientes, este puerto deberá ser el mismo que tengan en sus máquinas que se quieran conectar a él. La estructura de datos para el tratamiento de las notificaciones es la de un stack (pila), la razón es utilizar la propiedad del dato que llega al último es el primero que sale. La comunicación FinTCP - cliente utiliza el protocolo TCP/IP por lo que se utilizan winsock para comunicarse con el usuario, estos sockets los asigna la estructura de datos que los administra. La estructura visual de la administración de usuarios es un treeview que al abrirse despliega número de serie del usuario, estatus de conexión y estatus de conexión DDE. El socket que se maneja para el DDE es diferente al que contiene la información que llega a la aplicación cliente.

Reporte de Proyecto Terminal. 16

5. Proceso de Recepción de Notificación.

La bandera que dispara cualquier evento es la recepción de una notificación por parte del servicio del FinRX32. Esta Notificación es de la forma:

Estructura de Notificación del FinRx32 hacia el FinTCP

7 IdSegmento Id-Registro Tab1

Esta notificación se recibe por medio de UDP, el puerto por el que se recibe debe ser el mismo por el que el FinRX32 envía su notificación. El puerto UDP puede recibir un paquete que contenga más de una notificación, lo que hace es separarlas y almacenarlas en una pila para procesarlas después.

6. Tratamiento de Información y notificación a usuarios.

La una vez desglosado el mensaje de notificación se sabe que segmento de la base de datos ha llegado información ya sea de actualización o inserción, y se revisa en una colección que tiene en memoria a todos los usuarios cual está conectado y cual tiene abierto el segmento que ha llegado, en caso de que la información necesite ser enviada a alguno de los usuarios esta se envía por UDP con un socket previamente especificado. La colección de usuarios se popula haciendo acceso a una tabla en la base de datos donde están registrados todos los usuarios con un número de serie Único para cada uno de ellos.

7. DDE DDE (Dinamic Data Exchange), es una tecnología que está basa en OLE

Y por medio de esta, puede haber comunicación de datos entre diversas aplicaciones, como lo es entre excel y FinTCP, en este caso se envía un notificación con el registro completo de información a la hoja de excel y el usuario podrá ver uno o varios registros en tiempo real, es decir cada vez que cambia en la base de datos también lo hará en su hoja de excel.

8. lnterfaz Visual.

Descripción Sección User Activity.

Muestra un treeview con los usuarios, el color azul indica conexión, y el blanco sin conexión. SN es el número de serie asociado. Los monitores o información que está viendo se indica por la rama Finlan Connected, esto también confirma la conexión hacia el servidor. La conexión hacia el DDE lo indica la Rama que lleva el mismo nombre.

Sección Recepción. Segment: segmento de notificación que se está recibiendo. Table: Describe el nombre de la tabla. Reg ID: Indica el número de registro.

Sección de Activitv. 0 Active Connections: Indica cuantos usuarios

están conectados en total. 0 Open Monitors: Indica cuantos monitores

están abiertos, es la suma de todos los usuarios.

Sección Sending. 0 Sent: Indica que tabla ha sido notificada a

0 Socket ID: a que socket se le envió la

Blocking: Indica el número de bloqueos. Err #,ErrTxt,ErrSock: En caso de error en el envío de mensaje al cliente indica el número de error, texto y socket.

alguno de los usuarios.

notificación.

La configuración del FinTCP es para indicar por que número de puerto va a enviar mensajes a los clientes.

Pantalla

V. Bibliografía.

J. Stankovic, S. H. Son, and C. Nguyen, The Cogency Monitor: An External Interface Architecture for a Distributed Object-Oriented Real-Time Database System,” IEEE Real-Time Technology and Applications Symposium Denver, co.

J. Stankovic and S. H. Son, I’ “Architecture and Obiect Model for Distributed Object-Oriented Real-Time Databases,” IEEE Symposium on Object-Oriented Real-Time Distributed Computing

J. Stankovic, S. H. Son, and J. Liebeherr, “The BeeHive Project: Towards Global Multimedia Database Support for Real-Time Applications,” Second International Workshop on Real-Time Database

Wolfgang A. Halang, “Chair for Real - Time Systems”,Fern University Hangern, Germany.

Artículos:

How to use modeling to implement verifiable, scalable, and efficient real - time application programs by Vicent Encontre.

Using Objects - orient programming tools to build real - time embedded systems by Kim Clohessy.

Kendall y Kendall, “Análisis y Diseño de Sistemas”, Prentice Hall.

Alfred V. Aho, John Hopcroft, Jeffrey D. Ullman, “Estructura de Datos y Algoritmos”, Addison - Wesley.

Microsoft Visual Studio 5.0 Help.

Book on line for Microsoft Visual Basic 5.0

MSDN Library (Microsoft Develop Network).

IPWorks Visual Basic Edition Help.

Microsoft SQL Server 6.5 Help.

Book on line for Microsoft SQL Server 6.5.

20

al

m -

L

b O O w >r O O In

E

e CI C

CI C

e E a z

2 d.

d

c C

o NC-4

U al

O

2

c U m

U

U

d c)

U

C

O O. .- .-

c E e c

W Y

O

c

2 - C

o k O ._

T od

P c W Y

O

'o c

a, C

S O z W o

c

o i;

I 1

+ C - o_ c m -I ._

*-E -o ' ü l

- 0

c .- C - I

L

II

C

C

.b

n m O -1

t

> Z W I -1 -1 3

u)

3 Q C t

O A

? F -

c-

u)

c

U m U

I u)

I

U

n a v) U W

U

m

L

e E v, c

U

II

I1 II o

oa-

c) II m O A

I

o o I, O

N II

a a i ü i ü i ü a a a a a a Q Q Q ~ Q Q Q Q Q Q Q O P P P P S P 9 S P P ~ 0 0 0 0 0 0 0 0 0 0

N

II 7

m W

O v)

II (0 P

m O C

II O A 7 -

N

""Y u ) u ) u ) l n u ) c c c c c 0 0 0 0 0 0 0 0 0 0

O O ' I1 O C O J

ü

N P

' W

" * * C Y u ) u ) u ) u ) u ) u ) C C C C C C 0 0 0 0 0 0 0 0 0 0 0 0

n n n n n ~ m m m m m m 0-0-0P-0-0 0 0 0 0 0 0

"""

r I- l l

O

II m

Ln I-

O

-1 O m m

N N

N (D

II m

d

it N

m N

u) Y

m E C ._ c Q

o II 11 r N

O I I m S - 4 I I

I

F

II

O S m

I1 A

N

""- m m m m m Q P n n Q P P P P P 0 0 0 0 0

"""- n n n n n n n 9 9 P P P P P 0 0 0 0 0 0 0

m m m m m m m

N

u) Y

E u)

O u)

W

._

I

r 11 II a

N

+"e l n l n l n l n c c c c 0 0 0 0 0 0 0 0

n n n n 3 0 0 0 ~ P P P

"" m m m m

""e l n l n l n l n l n c c c c c O O O O O 0 0 0 0 0 ""_ n n n n n 3 0 0 0 0 ~ P P P P m m m m m

z

O O1

5 s

(Y II

o O ._ r

o"

O O O

II .-

W

O O

v) v) W 0

=I

ü. -1' 51 II O O -1

ü

o O a ._ c

c ._ E E 8 i c

c)" l n l n l n c c c O 0 0 0 0 0 i ü i ü i i n n n -000 0 0 0

o O Q ._ c

8 f

O % - N

5 r r r r r r r e r c c c e c ) e

5 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 S iüiüiüiüiüiüiüiüiüiüiüiüiüiüiü

P . 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0

a a l n l n s m l n a a l n l n a a l n l n

m 0 0 0 0 0 0 0 0 0 0 0 0 0 u v

n ~ n n n n n n n n n ~ n ~ n 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0

._

O II m

-I II 6 0

r c ) r r r r r c l n l n u ) l n l n l n l n l n C C C C C C C C 0 0 0 0 0 0 0 0 0 0 0 0 v 0 0 0 iüaiüiüiüaiüiü n n n n n n n n 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0

hl m

r

II

O II

c

I

C C C C l n l n l n l n C C C C O 0 0 0 0 0 0 0

n n n n S P O _ O 0 0 0 0

"" m m m m

L:

r r II

o r II II N m

O II

C

d

m

u)

O a .- c

" " " C l n l n l n l n l n l n l n C C C C C C C 0 0 0 0 0 0 0 L ) 0 0 0 0 0 0 z a a a a a a ~ n n n n n n 9 9 9 0 O P P 3 0 0 0 0 0 0

* " C l n l n l n l n C C C C 0 0 0 0 0 0 0 0

c

m C .- L

iñ

- u

m

iñ .-

ü m m U

m

c

al

2 m - Y

I L

E

c i 4

.. I

E Y" 4

Q a In

X W

c .-

Q a u) .cl C W

C O .- * C S Y U W

al

* al

n ü h m .- L

G ü m

m c C P c P c

al

m - al

y + 2

m .- L

c ü

El V) m W

e e d E

II

c .- a

E e s

2 B

n 3 v) U C W

n C

al O O

m

rn ü O

'f U W

U

o c 2

h L w cn al

&a

U

ü

L