UNIVERSIDAD AUTÓNOMA METROPOLITANA- …148.206.53.84/tesiuami/UAM5007.pdf · 3.2.1 Mecanismos IPC...

UNIVERSIDAD AUTÓNOMAMETROPOLITANA- IZTAPALAPA

DIVISIÓN: CIENCIAS BÁSICAS E INGENIERIA

DESARROLLO DEL PROTOCOLO DECAPA SUPERIOR DICOM

GRADO: LICENCIATURA

COMPUTACIÓN

NOMBRE: COLIN MENDEZ LILIA

ASESOR: ALFONSO MARTINEZ MARTINEZ

ABRIL DE 1997

LJ

si.

Vo. Bo.

OR. OCTAVIO R. ARZATE SOLTERO COORDINADOR

INTRODUCCION ..................................................................................................................................... 1

1 . COMUNICACIÓN EN RED .................................................................................................................. 3

1.1 MODELO ISO/OSI .............................................................................................. ................. 3 1.2 MODELO TCP/IP ....... ....................................................................... ................. 5

1.2.1 Direcciones Internet 6 1.2.2 Comparación entre TCP/IP e ISO/OSI ...................................................................................... 7 1.2.3 Protocolos TCp y UDP ............................................................................................................. 8

1.3 MODELO CLIENTE-SERVIDOR .... .................................... ....................................................... 9 1.3.1 Esquema genérico de un y de un cliente ................................................................... 10

2 . INTERFACES DE PROGRAMACI~N EN RED CON TCPAP ............................................................ 12

....................................................................................................... 12 de sockets ...................................................................................... 13

...................................................................................... 13 2.1.1.2 Establecimiento y terminación de la conexión ................................................................................. 13 2.1 . 1 . 3 Mecanismos de transferencia de datos ........................................................................................... 14 2.1 .I . 4 Otras rutinas ofrecidas por BSD ...................................................................................................... 14

2.1.2 Ventajas y desventajas ........................................................................................................... 15 2.2 INTERFASE DE !A CAPA DE TRANSPORTE (TLl'S) ................................................................................ 15

2.2.1 Modo de servicio Orientado a Conexión. ................................................................................. 15 2.2.1.1 Direccionamiento local .................................................................................................................... 15 2.2.1.2 Establecimiento de Conexión .......................................................................................................... 16 2.2.1.3 Transferencia de datos ................................................................................................................... 17 2.2.1.4 Liberacion de conexión ................................................................................................................... 17

2.3 STREAMS PIPES .. ............................... ................................... 18 2.4 PIPES (PIPE Y FIF ....................................................................................................... 19

3 . HERRAMIENTAS PARA LA PROGRAMACIÓN EN RED (TOOLKITS) ............................................ 21

3.1 LLAMADAS A PROCEDIMIENTOS REMOTOS (RPC'S) ............................................................................ 21

..................................................................................................................

. .

3.1.1 Modelo RPC ........................................................................................................................... 21 3.1.2 Las capas RPC ...................................................................................................................... 22 3.1.3 El estándar XDR ..................................................................................................................... 23 3 . f . 4 El cornpilador RPCGEN .......................................................................................................... 23 3.1.5 Asignación de números a programas RPC ............................................................................. 24 3.1.6 Programa para la asignación de puertos (PORTMAP) ............................................................ 24

3.1.8 Ventajas y desventajas de los RPC ............................................................................. 25 3.2 AMBIENTE DE COMUNICACIÓN ADAPTATIVO (ACE) .......................................................................... 26

3.2.1 Mecanismos IPC SAP (Inter-Process Comrnunication/Service Access Point) ........................ 27 3.2.2 Patrones de diseño ............................................................................................................... 28 3.2.3 Patrón Acceptor ....... ............................................................................ 3.2.4 Patrón Connector . ................................................................................................ 30 3.2.5 Reactor ................ .............................................................................. 31

3.1.7 Ejecución de un RPC ....................... ............................................................................. 24

i

4. PLANTEAMIENTO DEL PROBLEMA. ............................................................................................. 33

4.1 MECANISMOS y ELEMENTOS INVOLUCRADOS EN EL FUNCIONAMIENTO DE DULP ..................................... 33 4.1.1 Especificaciones de la lnterfase con el protocolo de Entidades de Aplicacidn DICOM a través de primitivas.. .................................................................................................................................. 34

4.1. I. 1 Servicio A-ASSOCIATE ................................................ 4.1.1.2 Servicio A-RELEASE .............................................................. 4.1. I .3 Servicio A-ABORT ................................................................. 4.1.1.4 Servicio A-P-ABORT .............................................................. 4.1.1 .5 Servicio P-DATA .....................................................................

4.1.2 Especificaciones de lnterfase con TCPAP ............................................................................... 39 4.1.3 Formatos de datos (PDUs) .................................................................................................... 40

4.1.3. I Codificación de PDU's ............................................................................................... 4.1.4 Tiempo de espera (ARTIM) .................................................................................. 4.1.5 Especificaciones del funcionamiento de DULP ........................................................................ 43

4.1.5.1 Establecimiento de una asociación. ............................................................................................... .43 4.1.5.2 Lectura/Escritura de información .................................................................................................... .44 4.1.5.3 Cierre de una asociación. .............................................................................................................. .44 4.1.5.4 Máquina de Estados Finitos DULP (MEFD). ...................................................................

4. I .5.4.1 Estados ....................................... 4.1.5.4.2 Eventos ........................................... ...................... 45 4.1.5.4.3 Acciones ...................................... .......................... 4.1.5.4.4. Funcionamiento de la MEFD ..............................................

5. PROPUESTA DE SOLUCION. ......................................................................................................... 54

5.1 ANÁLISIS Y DISENO ORIENTADO A OBJETOS ......................................................................................... 54 5.2 MODELO DE SOLUCIÓN: UNA PRIMERA APROXIMACIÓN ......................................................................... 56

6. DISENO ............................................................................................................................................. 59

6 . 1 HERRAMIENTAS ................................................ 59 6. I . I Patrones de diseño ................................................................................................................. 59 6.1.2 C++ .................................................. ........................................................................... 61 6.1.3 Clases de Utilería ................................................ 62

6.1.3.1 Cola ............... ..................................................... 62 6.1.3.2 Buffer ............................................................................................................................................. 62

6.2 DISENO DE LA INTERFASE CON EL PROTOCOLO EA DICOM .. ............................................... 63 6.3 DISENO DE LA INTERFASE CON EL PROTOCOLO TCP/IP ........ ....................................................... 64 6.4 DISENO DEL FORMATO DE DATOS (PDU'S) ......................................................................................... 65 6.5 DISENO DE LA MÁQUINA DE ESTADOS FINITOS (MEF) ...................................................................

-

7. RESULTADOS Y CONCLUSIONES .................................................................................................. 70

GLOSARIO ............................................................................................................................................ 71

BIBLIOGRAFIA ..................................................................................................................................... 72

11

INTRODUCCION

La necesidad de almacenamiento y manipulación de imágenes médicas tiene su origen a partir de los años 70’s como consecuencia del nacimiento de la tomografía axial computada como método de diagnóstico a base de imágenes digitales. Esto trajo como consecuencia que en los Últimos años se tenga una gran demanda de medios de almacenamiento más apropiados que no fueran impresiones en papel o placas radiográficas y a su vez métodos de transferencia entre dispositivos manufacturados por distintas compañías.

El hecho de que cada fabricante realizará su propia especificación para el manejo de información, ocasionó que el intercambio de esta sólo se llevara a cabo entre dispositivos de la misma marca y en algunos casos del mismo modelo.

En el laboratorio de Investigación en Computación y Procesamiento Digital de Señales e Imágenes Biomédicas se está trabajando en el diseño y construcción de un sistema PACS (Picture Archiving and Communication Sistems) el cual facilita los servicios de almacenamiento y transferencia de información. Sin embargo para que el sistema pueda tener acceso y a su vez ser accesible a otros de su tipo, se debe utilizar un estándar. El estándar propuesto es DICOM (Digital Imaging and Communications in Medicine).

DICOM define los aspectos que un sistema PACS debe adoptar, teniendo como objetivos lograr compatibilidad con las diferentes modalidades de imágenes médicas, promover la comunicación de imágenes y facilitar la creación y consulta a sistemas de diagnóstico locales o remotos.

Este estándar especifica comunicación en red, proponiendo protocolos montados sobre TCPíIP y los propuestos por ISOíOSI; además de la posibilidad de conexión punto a punto.

En este proyecto se realizó el desarrollo para el protocolo de capa superior DICOM utilizando la opción de comunicación sobre TCPíIP como base. A este protocolo se le llama DULP de las siglas “DICOM Upper Layer Protocol”.

El punto de inicio fue realizar un análisis sobre el modelo OS1 y el modelo TCPíIP con el fin de establecer diferencias entre estos. Posteriormente se hace una comparación entre los protocolos UDP y TCP pertenecientes a esta familia, para complementar la información.

Consideramos importante revisar también las diferentes interfaces de programación soportadas por el protocolo TCPAP (sockets, TLl’s, Fifos, Streams Pipes) con el fin de conceptualizar claramente el manejo de la comunicación con la capa de transporte sobre la cual sería montado el protocolo de capa superior DICOM. A su vez encontramos que no era necesario trabajar la interfase a bajo nivel, por lo que se realizó una revisión de herramientas que abstraen funciones de interfaces como sockets o TLi’s, tales como RPC’s y ACE (Adaptive Communication Environment). Esta Última fue seleccionada para resolver el problema de interfase a nivel transporte de DULP, porque está diseñado bajo el modelo Orientado a Objetos y ofrece un amplio conjunto de categorías de clases que desarrollan las tareas de

DESARROLLO DEL PROTOCOLO DE CAPA SUPERIOR DICOM 1

comunicación, lo cual favoreció el desarrollo del protocolo y un acoplamiento natural, ya que en un principio se planteó la idea de realizar el desarrollo utilizando este modelo.

En una siguiente etapa del desarrollo, se hizo el planteamiento del problema tomando como base la especificación de DULP. En esta parte se establecen los elementos que se ven involucrados con el funcionamiento del protocolo, las especificaciones de interfase con el protocolo de Entidades de Aplicación (EA) DICOM y con el protocolo de transporte TCPIIP. También se considera la especificación de los formatos de datos (PDU’s) , del temporizador para medir el tiempo de espera (ARTIM) y las especificaciones de funcionamiento de DULP a través de su máquina de estados finitos.

De acuerdo al planteamiento del problema, se realizó un análisis para encontrar un modelo de solución, utilizando Análisis y Diseño Orientado a Objetos.

Como infraestructura para este proyecto se tuvieron a disposición estaciones de trabajo con el sistema operativo UNlX y herramientas soportadas por el modelo Orientado a Objetos, para diseñar y construir el modelo de solución previamente definido.

Por último hacemos algunos comentarios acerca de las experiencias obtenidas durante el desarrollo del proyecto, considerando la metodología y las herramientas utilizadas.


1. COMUNICACIÓN EN RED

1.1 Modelo ISO/OSI

Siempre que se habla de una red de computadoras hay que distinguir entre protocolos y servicios de la red. En realidad, un estudio exhaustivo de las redes debe empezar por el modelo de referencia OS1 (Open Systems Interconnection, desarrollado por IS0 en 1977). Este es un modelo que estructura en siete capas los diferentes elementos que intervienen en las comunicaciones. Cada una de las capas ofrece una serie de servicios a la capa superior y utiliza los servicios que le brinda la capa inferior. Los servicios de una capa pueden verse como una interfase de comunicación con la misma. Los protocolos, por su parte, definen la forma que van a tener las tramas de bits que intercambian las distintas capas y cómo se va a llevar a cabo esa comunicación. El objetivo que se persigue al separar protocolos de servicios es aislar los aspectos tecnológicos de los aspectos de uso de una red. Así, se procura definir servicios lo menos cambiantes posibles con el objeto de que los usuarios no tengan que estar modificando sus aplicaciones continuamente. Por otro lado, las mejoras en las tecnologías de las redes van a repercutir en diseño de protocolos que garanticen una transmisión más fiable, segura y rápida. Esto va a complicar los protocolos pero, no los servicios.

La figura 1.1 muestra los principales conceptos del modelo OSI. Las entidades que soportan el protocolo de nivel N se denominan corresponsales o entidades pares. Por convención, la frontera vertical entre dos niveles adyacentes se llama interfase y se construye como un conjunto de puntos de acceso a servicio o SAP (Service Access Points) por donde se intercambian primitivas de servicio. Las siete capas que propone el modelo OS1 son descritas a continuación:

1. Capa física: se encarga de la transmisión de bits a lo largo de un canal de comunicación.

2. Capa de enlace de datos: La tarea principal de la capa de enlace consiste en transformar el medio de transmisión, que va ser ruidoso, en una línea sin errores, y por lo tanto fiable, para la capa de red (capa inmediatamente superior a esta en la jerarquía).

3. Capa de red: se ocupa de la obtención de paquetes procedentes de la fuente y de encaminarlos por la red y las sub-redes hasta alcanzar su destino.

4. Capa de transporte: la función principal de la capa de transporte consiste en aceptar los datos de la capa de sesión, dividirlos, siempre que sea necesario, en unidades más pequeñas, pasarlos por la capa de red y asegurar que todos ellos lleguen correctamente al otro extremo.


5. Capa de sesión: permite que los usuarios de diferentes computadoras puedan establecer sesiones de trabajo en computadoras remotas. Un ejemplo de sesión consiste en accesar a un sistema remoto en tiempo compartido y conectarnos a trabajar con el, tal y como hacemos con nuestro sistema local (rlogin o telnet). Otro ejemplo puede ser transferir archivos entre dos computadoras (rcp bajo UNIX).

7c

6

5

4

3

2

I

6. Capa de presentación: se ocupa de los aspectos de sintaxis y semántica de la información que se transmite. Un ejemplo típico de servicio de la capa de presentación es la codificación de los datos de acuerdo con unas normas. La información que una computadora envía a otra ocupa unidades tales como caracteres, números enteros o números de punto flotante, y puede que en una red haya computadoras que representen estas unidades de diferente forma. Por ejemplo, una computadora envía un nombre codificado en caracteres ASCII mientras que la computadora que lo recibe codifica los caracteres en EBCDIC; la capa de presentación se va encargar de realizar los cambios necesarios de ASCII a EBCDIC para que el nombre recibido sea inteligible y no una secuencia de símbolos sin significado.

Primitivas

Punto de acceso al servicio

Tl

\

7. Capa de aplicación: la capa de aplicación contiene una variedad de protocolos que se necesitan frecuentemente. Un problema típico a resolver en esta capa es la compatibilidad de las distintas terminales que hay en el mercado, con objeto de que los programas de aplicación no tengan que preocuparse de las características hardware de los mismos. El sistema de ventanas X-WINDOWS es un ejemplo de solución a este problema.

Figura I. I. Estructura en capas del modelo OS1 para comunicaciones entre computadoras.


1.2 Modelo TCP/IP

En 1968 la Agencia de Proyectos de Investigación del Departamento de Defensa de los Estados Unidos (ARPA) contrató a la empresa de consultoría de Bolt Bernak & Newman para desarrollar una red de computadoras (ARPANET), que uniera a los centros donde tenía proyectos financiados. Para 1971 la agencia asumió la dirección del proyecto. De los primeros trabajos que se completaron, se instaló un protocolo, el programa de control de red que evolucionaría hasta convertirse dos años mas tarde, en el Protocolo de Control de Transmisión y el Protocolo Internet (TCPAP).

TCPAP es un 'conjunto de protocolos desarrollados para permitir la operación entre computadoras para compartir recursos en una red. Este modelo puede describirse por la interacción de tres agentes: procesos, computadoras con conexión a red (hosts) y redes. Los procesos son la entidades fundamentales de la comunicación y se ejecutan en las computadoras que pueden soportar varios procesos simultáneos. La comunicación de procesos se lleva a través de redes a las que se conectan las computadoras.

El modelo TCPAP organiza a sus protocolos en cuatro niveles, los cuales se explican a continuación.

Nivel acceso a red: este nivel comprende aquellos protocolos que gestionan el uso de los servicios en red y residen en una computadora o su equivalente lógico.

Nivel internet: el nivel internet soporta los procedimientos que permiten el tránsito de datos a traves de múltiples redes. Así, éste debe proporcionar una función de ruteo.

Nivel de transporte: este nivel contiene los protocolos con capacidad para enviar datos entre dos procesos en diferentes computadoras. Puede ofrecer una conexión lógica entre entidades de alto nivel. Otros posibles servicios incluyen control de errores, flujo y la capacidad de manejar señales de control no asociadas con una conexión lógica de datos. Son necesarios dos tipos de protocolos generales en este nivel, teniendo cada uno de ellos diferentes requerimientos de servicio:

1. Un protocolo de datos orientados a conexión (TCP). Caracterizado por la necesidad de una entrega confiable de datos.

2. Un protocolo para datagramas (UDP). que sólo ofrece servicios básicos y puede ser apropiado para algún trafico, particularmente aplicaciones que no se orientan a conexión.

Nivel proceso/aplicación: comprende protocolos para compartir recursos (computadora a computadora, por ejemplo) y garantizar acceso remoto (terminal a computadora).

La figura 1.2 representa el modelo de la arquitectura TCPAP y varios de sus protocolos más importantes.

~


I FTp I TELNET SMTP Xwin Rexcc Do- TFTP RPC

I I SNMP

TCP UDP

IP e ICMP Protocolos Gateway

Figura 7.2. Arquitectura TCPAP

ARP, RAW Proxy ARP

I .2.1 Direcciones Internet

La forma de construir direcciones depende de los protocolos que se empleen en la capa de transporte y de red. La dirección distingue de forma inequívoca a cada nodo o computadora y es utilizada para encaminar los datos desde el nodo origen al nodo destino.

En Internet el patrón de identificadores es clasificado en nombres, direcciones o rutas.

nombre: identifica cual es el objeto. dirección: en donde se encuentra. ruta: determina como obtenerlo.

Cada patrón de TCPAP de Internet asigna Únicamente 32-bits de dirección Internet que son usados en la comunicación con el patrón. Las direcciones IP se escriben como cuatro enteros decimales separados con puntos decimales, en donde cada entero tiene el valor de un octeto de la dirección IP.

Ejemplo: 1000000 00001010 00000010 00011110 representa: 128. 1 o. 2. 30

Conceptualmente cada dirección es un par (netid, hostid), donde netid identifica a la red de trabajo, y hostid identifica a la computadora en la red. En la practica, cada dirección IP puede agruparse en una de las tres clases siguientes:

O Clase A: utiliza el primer octeto para identificar a la red y los restantes tres octetos para identificar la computadora.

O Clase B: esta clase emplea los dos primeros octetos para hacer la identificación de la red y los restantes octetos para el número asociado a la computadora. Esta clase permite un total de 64516 computadoras integradas a cada red.


0 Clase C: utiliza los tres primeros octetos para el número de red y el ultimo octeto lo emplee en la identificación de la computadora. Esta ultima clase solo permite 254 computadoras conectadas a cada red.

1.2.2 Comparación entre TCP/IP e ISO/OSI

Se espera que el modelo OS1 conduzca, en un futuro, el desarrollo internacional en materia de protocolos, sin embargo junto a este se encuentra el modelo TCP/IP probado en la práctica y que ha sido de hecho el modelo de las comunicaciones entre computadoras. Ambos persiguen objetivos semejantes y se basan en el concepto de protocolo. No obstante existen diferencias filosóficas y prácticas importantes entre ellos.

Entre estos modelos existen cuatro diferencias fundamentales:

0 El concepto de jerarquía contra el de nivel. 0 La importancia que cada modelo concede a la interconexión de redes. 0 La utilidad de servicios no orientados a conexión. 0 El enfoque para funciones de administración.

El modelo TCPAP reconoce que el trabajo de la comunicación es muy complejo y diverso para que se realice por una sola unidad. En consecuencia, éste se divide en módulos o entidades cooperantes que soportan en conjunto un servicio distribuido. Una buena práctica de sistemas dicta que esas entidades serán agrupadas jerárquicamente.

El modelo OS1 se basa en los mismos razonamientos, pero además reconoce que existen entidades de la misma jerarquía con características en común que se pueden agrupar en un mismo nivel o capa.

En lo que concierne a las relaciones entre niveles, que se presentan en OSI, puede mencionarse que:

0 La entidad de nivel N puede intercambiar datos usando los servicios de la entidad del nivel N-I. Otra forma de decir esto es que la entidad del nivel N-I, debe estar implicada en cada transferencia de datos de la entidad del nivel N.

0 La entidad del nivel N-I da servicio a la entidad N intercambiando unidades de datos que, contienen información de control del nivel N-I y datos de la entidad N.

Por otro lado, en el modelo TCPAP, se permiten las siguientes operaciones:

0 Una entidad puede utilizar directamente los servicios de otra jerárquicamente mas baja, aún sin ser adyacentes.

0 Puede utilizar caracteres de escape para colocar caracteres de control dentro de una cadena de datos.


0 Los datos y la información de control no comparten la misma unidad de datos. Con esto se ofrecen diferentes servicios para cada tipo de conexión.

0 Se puede manejar la información desde una jerarquía inferior para realizar un control en las jerarquías superiores.

0 Se permite la cooperación de múltiples entidades de la misma jerarquía.

Una diferencia histórica entre el modelo TCP/IP y OS1 es la importancia que el primero concede a la interconexión. Esta ocurre cuando dos sistemas de comunicación no están unidos a la misma red. Así los datos transferidos deben atravesar al menos dos redes que además, pueden ser de tipos distintos.

En el modelo TCP/IP tienen igual importancia los servicios sin conexión y los servicios orientados a conexión, mientras que el modelo OS1 está expresado solamente en términos de estos últimos.

1.2.3 Protocolos TCP y UDP

Dentro del modelo TCP/IP se definen los protocolos TCP y UDP. El protocolo TCP permite establecer una comunicación orientada a conexión (circuito virtual). Para establecer este tipo de comunicación se realizan los siguientes pasos :

1. Un nodo realiza la petición de comunicación con otro nodo en la red. 2. Se inicia la búsqueda de nodos libres que permitan enlazar a los dos nodos que desean

3. Una vez definida la ruta de comunicación entre los dos nodos, se procede al envío tener la comunicación (establecer el circuito virtual).

secuencial de los datos.

La conexión será permanente mientras la comunicación entre los nodos siga activa.

Por otro lado el protocolo UDP brinda la oportunidad de establecer una comunicación no orientada a conexión (datagrama), en este caso la conexión no es permanente. La transmisión por los datagramas es a nivel de paquetes, donde cada paquete puede seguir una ruta distinta y no se garantiza una recepción secuencial de la información.


A continuación se hace una comparación entre estos dos protocolos:

TCP No existe restricción sobre la o

longitud de los datos enviados. Envío secuencial de los datos. o

Dado que la comunicación es o

permanente, los mensajes alcanzan su destino.

Proporciona al usuario un canal o

fiable y full-duplex.

UDP La información es fragmentada en paquetes de longitud fija. No se garantiza una recepción secuencial de la información. No existe garantía de que los mensajes siempre alcancen su destino, lo Único que asegura es que los mensajes van a viajar por la red sin fraccionarse. No ofrece la opción de comunicación full-duplex.

1.3 Modelo Cliente-Servidor

El modelo cliente-servidor es el modelo estándar de ejecución de aplicaciones en una red. Un servidores un proceso que se está ejecutando en un nodo de la red y que gestiona el acceso a un determinado recurso. Un diente es un proceso que se ejecuta en el mismo o diferente nodo y que realiza peticiones de servicio al servidor. Las peticiones están originadas por la necesidad de acceder al recurso que gestiona el servidor.

El servidor está pasivamente esperando peticiones de servicio. Cuando se produce una petición, el servidor despierta y atiende al cliente. Cuando el servicio concluye, el servidor vuelve al estado de espera. De acuerdo con la forma de prestar el servicio, podemos considerar dos tipos de servidores:

0 Servidores interactivos. El servidor no sólo recoge la petición de servicio, sino que el mismo se encarga de atenderla. Esta forma de trabajo presenta un inconveniente: si el servidor es lento en atender a los clientes y hay una demanda de servicio muy elevada, se van a originar tiempos de espera muy grandes.

0 Servidores concurrentes. El servidor recoge cada una de las peticiones de servicio y crea otros procesos o hilos de control para que se encarguen de atenderlas. Este tipo de servidores sólo es aplicable en sistemas multiproceso, como es UNIX. La ventaja que tiene este tipo de servicio es que el servidor puede recoger peticiones a muy alta velocidad, porque está descargado de la tarea de atención al cliente. En aquellas aplicaciones donde los tiempos de servicio son variables, es recomendable implantar servidores del tipo concurrente.


1.3.1 Esquema genérico de un servidor y de un cliente

La forma genérica que van a tener los diagramas de flujo de control, tanto de los procesos servidores como de los clientes, se pueden ver en la figura 1.3.

Las acciones que debe llevar a cabo el programa servidor son las siguientes:

1. Activarse e informar a la red tanto de la dirección a la que responderá como de su disposición para aceptar peticiones de servicio.

2. Esperar a que un cliente le pida servicio en la dirección y puerto (TCPAP) que él tiene declarado.

3. Cuando recibe una petición de servicio, si es un servidor interactivo, atenderá al cliente. Los servidores interactivos se suelen implementar cuando la respuesta que necesita el cliente es sencilla e implica poco tiempo de proceso. Si el servidor es concurrente, creará un proceso para que le dé servicio al cliente.

4. Volver al punto dos para espera nuevas peticiones de servicio.

Proceso Servidar Proceso cliente

I

Figura 1.3. Estructura de los programas servidores y clientes.


El programa cliente por su parte, llevará a cabo las siguientes acciones:

1. Abrir el canal de comunicación y conectarse a la dirección de red atendida por el servidor

2. Enviar al servidor un mensaje de petición de servicio y esperar hasta recibir la respuesta. 3. Cerrar el canal de comunicaciones y terminar la ejecución.

Naturalmente, esta dirección debe ser conocida por el cliente.


2. INTERFACES DE PROGRAMACIÓN EN RED CON TCPIIP

La capa de transporte es importante porque provee la transparencia en la transferencia de datos utilizados por aplicaciones y por las capas superiores; por tanto la interfase del servicio de transporte permite a las aplicaciones y a las capas superiores el ser implementadas sin que se tenga un gran conocimiento de las capas inferiores; dos programas que se comuniquen haciendo uso de las interfaces que son soportadas sobre la capa de transporte (sockets, TLI’s, entre otros) no tendrán que preocuparse por aspectos como:

Canal físico de comunicación, tipo de transmisión, tipo de modulación, correspondiente a la capa física. Forma de codificar las señales. Nodos de la red por los que tiene que pasar las tramas de bits y gestión de las redes involucradas. Formar paquetes a partir de la información a transmitir y buscar una ruta que una el nodo origen con el destino.

A continuación son analizadas algunas de las interfaces para la programación en red con TCPAP.

2.1 Sockets

La interfase con la red que ofrece el sistema 4.3 BSD para comunicación a través de TCPAP corresponde al nivel 4 (capa de transporte) del modelo ISOiOSI.

AI establecer una comunicación mediante sockets, es necesario conocer la familia o dominio de la conexión y el tipo de conexión.

Una familia agrupa a los sockets que comparten características comunes tales como protocolos, convenios para formar direcciones de red, etc.

El tipo de conexión indica el tipo de circuito que se va a establecer el cual puede ser virtual (orientado a conexión) o datagrama (no orientado a conexión).

Entre las familias de sockets podemos encontrar dos, que son las más comunes en los sistemas 4.3 BSD:

AF-UNIX: la cual se utiliza para la comunicación de procesos que se están ejecutando en una misma computadora. Esta familia soporta la comunicación a través de datagramas (SOCK-DGRAM) y orientado a conexión (SOCK-STREAM).

AF-INET: esta familia utiliza protocolos de comunicación para llevar a cabo la comunicación de procesos que se estén ejecutando en computadoras distintas o en

DESARROLLO DEL PROTOCOLO DE CAPA SUPERIOR DlCOM 12

una misma. La comunicación a traves de datagramas se realiza por medio del protocolo UDP (SOCK-DGRAM); y la comunicación orientada a conexión utiliza el protocolo TCP (SOCK-STREAM). Ambos protocolos son montados sobre IP.

RUTINA socket()

2.1.1 Llamadas para el manejo de sockets

DESCRIPCI~N La llamada para abrir un canal bidireccional de

La interfase con sockets ofrece varias rutinas para el establecimiento, manejo y cierre de una conexión. Este sistema de llamadas puede clasificarse de acuerdo a ciertas categorías generales.

2.1.1.1 Manejo de contexto local

La interfase con sockets proporciona las siguientes rutinas para el manejo de la información del contexto local:

bind()

getsockname() Y getpeername() Close()

comunicación es socket, esta llamada devuelve un descriptor de archivo válido. Es utilizada para asociar un descriptor de socket a una dirección de red determinada Determinan la dirección local o remota, respectivamente, de un socket conectado.

Cierra el socket en sus dos sentidos (servidor-cliente y cliente-servidor), dejando el descriptor asociado al socket disponible para un uso posterior.

2.1 .1.2 Establecimiento y terminación de la conexión

La interfase con sockets proporciona las siguientes rutinas para el establecimiento y terminación de la conexión:


RUTINA connect()

DESCRIPCI~N Un cliente típicamente utiliza la llamada a connect para establecer una conexión con el servidor.

2.1 .I .3 Mecanismos de transferencia de datos

Lis ten ()

Accept()

Shutdown()

La interfase con sockets proporciona las siguientes rutinas para enviar y recibir datos: I RUTINA I DESCRIPCI~N

Un servidor hace uso de listen para indicar que espera en forma pasiva las peticiones de conexión por parte de los clientes. Un servidor utiliza accept para crear un nuevo punto de comunicación para brindar servicio a un cliente. Es empleada para terminar la comunicación entre el servidor y el cliente en una determinada dirección. Es decir puede cerrar la comunicación cliente-servidor, servidor-cliente o ambos.

read() write() Send() recv()

Sendto() recvf rom 0

2.1 . I .4 Otras rutinas ofrecidas por BSD

Con estas llamadas se recibe y envía un buffer de datos, respectivamente, a través de un descriptor particular. Es similar a readíwrite, pero además cuentan con un parámetro extra que controla ciertas operaciones especificas (como el manejo de datos con carácter de urgentes). Utilizadas para intercambiar datos cuando la conexión no es orientada a conexión

RUTINA DESCRIPCI~N htonl(), htons(), Estas rutinas son empleadas para transformar el orden de ntohl(), ntohs() los bytes que se manejan en la red (big endian, little

endianl. IGethostnameO

GetservbynameO Select() Fcntl() ioctl()


Determina el nombre oficial que tiene un nodo dentro de la red. Identifica servicios a través de su número de puerto. Permite demultiplexar un conjunto de descriptores abiertos. Habilitan Entradas/Salidas (E/S) asíncronas, E/S non- blocking a demás de la entrega de mensajes urgentes sobre los sockets.

2.1.2 Ventajas y desventajas

Ofrece la oportunidad de enviar datos con mayor prioridad sobre otros. Dispone de una modalidad llamada sockets crudos (SOCK-RAW), los cuales pueden ser soportados sobre otro protocolo diferente a TCP o UDP, es decir que permite el manejo de protocolos de mas bajo nivel o de nivel superior. Otra de sus principales ventajas es que no existe limitante en cuanto al tamaño de datos a ser enviados.

Algunos de los problemas que se presentan en su manejo corresponde al uso del descriptor que emplean para identificar a un socket que ha sido creado, pues este también puede identificar a un archivo, lo que en un momento dado puede causar confusión y por lo tanto errores. Además los nombres no siguen un estándar, por lo que resulta difícil distinguir la relación entre las distintas funciones empleadas por los sockets.

2.2 lnterfase de la Capa de Transporte (TLl’s)

Los TLl’s son una interfase de programación de la capa de transporte definidos por la ATT V4R5 de UNlX de ISO. Estos forman parte de XTI (X/Open Transport Interfase), y están implementados en base a una librería que hace uso de los mecanismos de entradalsalida de los STREAMS, dicha librería incluye un conjunto de funciones que soportan los servicios de esta interfase para procesos usuarios.

2.2.1 Modo de servicio Orientado a Conexión:

Este modo de conexión permite la transmisión de datos de manera secuencia1 cuando se establece una conexión, y está caracterizado por cuatro fases:

I. Direccionamiento local. 2. Establecimiento de la conexión. 3. Transferencia de datos. 4. Liberación de la conexión.

2.2.1 .I Direccionamiento local

Esta fase define operaciones locales entre un usuario de transporte y un proveedor de transporte. Un canal de comunicación entre el usuario y el proveedor de transporte es Único y es llamado terminal de transporte.

Una operación local necesaria para cada usuario es la que establece una identidad con el proveedor de transporte. Cada usuario es identificado por una dirección de transporte; a su vez esta dirección esta asociada con cada terminal, por tanto si un usuario pide una conexión con otro debe especificar la dirección del usuario con el que desea conectarse .


La siguiente tabla muestra las rutinas empleadas para el direccionamiento local de la interfase de la capa de transporte.

RUTINA t-alloc( )

t bind( ) t close() t error() t-free( )

DESCRIPCI~N Asigna memoria a la interface para las estructuras de datos. Asigna una dirección de transporte a una terminal. Cierra una terminal de transporte. Imprime un mensaje de error. Libera la memoria asignada a las estructuras usando

RUTINA

t-getinfo( ) t getstate() t look() t-oPen( 1

t-optmgmt( )

t sync() t-unbind()

2.2.1.2 Establecimiento de Conexión

DESCRIPCI~N Retorna un conjunto de parametros asociados con un proveedor de transporte en particular. Retorna el estado de una terminal de transporte. Retorna que terminal de transporte es la actual. Establece una terminal conectándola a un proveedor de transporte. Especifica opciones del protocolo con el proveedor de transporte. Sincroniza una terminal con el proveedor. Desasocia una dirección de transporte de una term ina I.

Esta fase permite a dos usuarios crear una conexión o circuito virtual entre ellos, esto puede describirse por medio de el modelo cliente/servidor, en donde tanto el cliente como el servidor cuentan con su respectivo proveedor de transporte.

Típicamente el servidor da a conocer sus servicios a un grupo de usuarios, y espera hasta que recibe una petición de alguno de ellos. Cuando un cliente requiere de un servicio, intenta conectarse al servidor usando la dirección de transporte que tiene asignada dicho servidor, posteriormente se verifica si la petición del cliente es aceptada, si esto sucede se establece la conexión de transporte.

Lo mas interesante del procedimiento del establecimiento de la conexión es que hace distinción entre clientes y servidores. La interface de la capa de transporte concede un amplio conjunto de procedimientos en esta fase para cada tipo de usuario de transporte.

Esta interfase permite dos acciones durante el establecimiento de la conexión que no necesariamente son soportadas por todos los proveedores de transporte: la habilidad de transferir datos entre el cliente y el servidor cuando se esta estableciendo la conexión, y la


negociación de las opciones de protocolo ( es decir, el cliente puede especificar las opciones del protocolo que el proveedor de transporte y/o el otro usuario soportaran).

RUTINA t-accept( ) t-connect( )

La siguiente tabla muestra las rutinas para establecer una conexión de transporte.

DESCRIPCI~N Acepta una petición de conexión de transporte. Establece una conexión con el usuario de transporte a un destino emecífico.

t-listen( )

t-revconnect( )

Espera por una indicación de petición de conexión de algún otro usuario. Completa el establecimiento de la conexión si t connect( ) fue llamado en modo asíncrono.

2.2.1.3 Transferencia de datos

RUTINA t-rcv( 1

t snd()

Esta fase permite la transferencia de datos en ambas direcciones cuando se establece una conexión. Se garantiza que todos los datos enviados por un usuario llegarán al otro usuario de la terminal en el mismo orden en como fueron enviados.

DESCRIPCI~N Recupera los datos que arribaron de una conexión de transporte. Envía datos.

La interfase de la capa de transporte no hace diferencias entre el cliente y el servidor en este punto. Cada usuario puede enviar y recibir datos o terminar la conexión.

Dos clases de datos pueden ser transferidos en una conexión de transporte: datos normales y datos expeditos. Los datos expeditos están típicamente asociados con información urgente. Su semántica esta sujeta a la interpretación del proveedor de transporte, sin embargo no todos los protocolos de transporte soportan la notación de este clase de datos.

La siguiente tabla muestra las rutinas para la transferencia de datos.

2.2.1.4 Liberación de conexión

Esta fase permite liberar una conexión establecida. Cuando se decide terminar con la sesión se hace una petición al proveedor para que libere la conexión de transporte. Dos son los tipos de liberación que permite la interfase de capa de transporte. La primera se da

17 DESARROLLO DEL PROTOCOLO DE CAPA SUPERIOR DICOM

abortando la conexión en la cual directamente el proveedor de transporte libera automáticamente la conexión, y la otra es por medio de la petición de liberación de la conexión.

RUTINA t-rcvdis( )

t-rcvrel( )

t-snddis( )

t sndrel()

La siguiente tabla muestra las rutinas de liberación de la conexión.

DESCRIPCI~N Retorna una indicación del aborto de una conexión, incluyendo código de la razón y datos del usuario. Retorna una indicación de que otro usuario de transporte ha solicitado la liberación de la conexión. Aborta una conexión o rechaza una petición de conexión. Solicita la liberación de la conexión.

2.3 Streams Pipes

Son una extensión a el mecanismo original pipe de UNIX. Anteriormente la generación pipe de UNIX proporcionaba un solo stream unidireccional de bytes desde una terminal escritora a una terminal lectora. Los Streams pipes soportan deliberación bidireccional de byte streams y mensajes entre procesos y/o hilos de control, ejecutándose sobre la misma computadora. Por omisión, un stream pipe provee solo un canal de datos entre sus dos terminales. Además, si múltiples transmisores escriben a el pipe, todos los mensajes son colocados dentro del mismo canal de comunicación. Esta es una desventaja debido a que es difícil demultiplexar datos desde muchos clientes sobre un solo canal.

Un stream proporciona una ruta bidireccional de datos entre un proceso y un usuario, así como un manejador en el kernel. Los datos escritos por el proceso usuario viajan hacia abajo hacia el manejador, y los datos recibidos por el manejador del hardware viajan hacia arriba para ser recibidos por el usuario.

Un stream simple esta constituido de un stream principal y un manejador, como se muestra en la siguiente figura 2.1.


Usuario 1 Kernel

Datos Datos

Figura 2.1. Stream simple.

El stream principal consiste de un conjunto de rutinas que proporcionan una interfase entre las aplicaciones en el espacio de los usuarios y el resto del espacio de los stream en el kernel.

Cuando una aplicación hace una llamada al sistema con un descriptor de streams, la rutina del stream principal es invocada, teniendo como resultado una copia de los datos, generación de mensajes, o creación de un control de operaciones.

El stream principal es solo uno de los componentes del stream que puede copiar datos entre el espacio del usuario y el espacio del kernel. Todos los demás componentes efectúan solamente transferencia de datos.

El segundo elemento de este proceso es el manejador, encontrándose al final del stream. Este lleva el control periférico de la transferencia de datos entre el kernel y el proceso.

2.4 Pipes (Pipe y FIFO)

Existen dos tipos de pipes: los pipes anónimos y los llamados pipe o FIFO.

Una llamada al sistema pipe crea un pipe anónimo pero con dos stream principales apuntándose uno con otro como se muestra en la figura 2.2.

~


Usuario Kernel

Stream Stream Principal Principal

Figura 2.2. Stream pipe.

Sin embargo los pipes fueron implementados inicialmente usando streams pero únicamente transferían datos en una sola dirección.

Los llamados pipe o FIFO son creados por medio de la llamada a mknod(), y puede ser accesado por medio de la llamada a open(). Los pipe están conformados por un stream principal con una cola de escritura apuntando a una cola de lectura. Los datos escritos en el FIFO son recuperados leyéndolos del final del mismo FIFO. Este tipo de stream se muestra en la figura 2.3.

Usuario I Kernel

Figura 2.3. Stream FIFO.

~


3. HERRAMIENTAS PARA LA PROGRAMACIÓN EN RED (Toolkits)

3.1 Llamadas a Procedimientos Remotos (RPC's)

Los RPC's son un paradigma de comunicación de alto nivel ideado por Sun Microsystems que permiten al programador escribir aplicaciones de red usando llamadas a procedimientos que esconden los detalles básicos de la red.

Los RPC's implementan un sistema cliente/servidor sin requerir que el usuario conozca las bases de la red.

En este contexto, un servidor, es una computadora donde son implementados algunos servicios de red. Un servicio, es una colección de uno o más programas remotos. Un programa remoto implementa uno o más procedimientos remotos. Un cliente de la red es una pieza de software que inicializa llamadas a procedimientos remotos para los servicios.

El cliente envía un mensaje a el proceso servidor y espera un mensaje de respuesta. El mensaje de llamada contiene los parámetros del procedimiento y el mensaje de respuesta contiene el resultado del procedimiento. El cliente extrae el resultado del mensaje de respuesta y continúa ejecutándose.

En el servidor, un proceso está latente esperando la llegada de un mensaje de llarnada, cuando éste llega, el proceso servidor extrae los parámetros del procedimiento, calcula los resultados, envía el mensaje de respuesta y sigue esperando para la llegada del siguiente mensaje de llarnada.

3.1.1 Modelo RPC

El modelo RPC es similar a el modelo que utiliza llamadas a procedimientos locales. Con el modelo local, el usuario coloca los argumentos de un procedimiento en una localidad especifica y transfiere el control al procedimiento. Cuando el usuario eventualmente recupera el control, este extrae los resultados del procedimiento y continua la ejecución.

El modelo RPC opera en una forma similar, excepto que el control fluye entre los dos procesos: el procesos cliente y el proceso servidor. Esto es, el proceso cliente envía un mensaje a el proceso servidor y espera un mensaje de respuesta. El mensaje de llamada contiene los parámetros del proceso, y el mensaje de respuesta contiene los resultados del procedimiento. Cuando el mensaje de respuesta regresa, el cliente extrae los resultados de el procedimiento y reinicia la ejecución. El proceso servidor siempre está latente y esperando la llegada de un mensaje de llamada, cuando este llega, extrae los parámetros del


procedimiento, calcula los resultados, envía el mensaje de respuesta y sigue esperando la llegada de el siguiente mensaje de llamada. La figura 3.1 muestra el modelo RPC:

Máq

Programa cliente

Continua ció n del programa

raA Red MáquinaB I

I I

I callrpcfl ,

I lnvocaciói I servicio I I I ‘ petición I co m pl etad ~ returno I

I

I

I

I

Llamada ai servicio

Ejecución de servicio

retu r no

Figura 3. I. Modelo RPC.

3.1.2 Las capas RPC

El modelo RPC esta dividido en 3 capas:

Capa Superior; Es transparente para el sistema operativo, la computadora y la red en la cual se este ejecutando. Los usuarios de esta capa pueden hacer una llamada a una rutina dentro de sus programas sin estar enterados del uso de RPC’s para la ejecución de ésta.

Capa Media: Son propiamente los RPC’s y consiste de rutinas usadas por mas aplicaciones. En esta capa, el usuario simplemente hace llamadas a procedimientos remotos para ejecutarlas en otras computadoras, sin considerar detalles acerca del socket de interfase, el sistema UNlX y otros mecanismos de bajo nivel. Las llamadas RPC son hechas con las rutinas registerrpc0, callrpc() y svc-run(). Las dos primeras son fundamentales, pues registerrpco obtiene el número de identificación de procedimiento, y callrpc() ejecuta la llamada al procedimiento remoto.

Capa inferior: En este nivel el programador puede hacer aplicaciones más sofisticadas pues tiene el control sobre los detalles, es decir, puede manipular la interfase de transporte utilizada para la transmisión de mensajes RPC. Esta capa debe ser evitada, si es posible.


3.1.3 El estándar XDR

Q.h

Toda arquitectura de computadora provee su propia definición de representación de datos. Algunas computadoras guardan el byte menos significativo de un entero en la dirección más baja de memoria. otras guardan el byte más significativo en la dirección más baja, y otras no guardan los bytes contiguamente en la memoria.

Declaración de constantes y tipos usados en el código generado para el cliente v el servidor.

Los programadores quienes escriben programas para una sola computadora no necesitan pensar acerca de la representación de datos, debido a que una computadora solo permite una representación. Cuando un programador declara una variable, el cornpilador usa la representación de datos nativa de la computadora.

Q-xdr.c Q-c1nt.c Q-svc.c

Los programadores que crean software cliente/servidor deben considerar la representación de datos, pues, ambas computadoras deben acordar la representación exacta de todos los datos enviados a través de los canales de comunicación entre ellas. Si la representación de datos nativa de dos computadoras es diferente, los datos enviados por el programa sobre una computadora a otro programa sobre otra computadora deben ser convertidos.

Llamadas a procedimientos XDR usadas en el cliente y el servidor. Procedi mien to cliente. Procedimiento servidor.

RPC asume la existencia de XDR, que es un conjunto de librerías estándar que permiten a un programador de C, describir estructuras de datos arbitrarias. XDR es usado para la transferencia de datos entre computadoras de diferente arquitectura. Por ejemplo, un programa puede usar XDR para crear información portable, traduciendo su representación local a una representación XDR, y algún programa corriéndose sobre otra computadora puede leer la información traduciendo la representación XDR a su formato local equivalente.

3.1.4 El compilador RPCGEN

Este compilador ayuda a automatizar el proceso de escribir aplicaciones RPC. Rpcgen acepta programas remotos definidos en lenguaje RPC y produce archivos de salida en lenguaje C. Esta salida consiste de un fragmento de las rutinas del cliente, un esqueleto del servidor, rutinas XDR para parámetros y resultados, un archivo de cabecera que contiene definiciones comunes, y fragmentos de rutinas de ANSI C.

Rpcgen lee un archivo de entrada que contiene la especificación de un programa remoto. Este produce cuatro archivos de salida, cada uno contiene código fuente. Rpcgen deriva los nombres para los archivos de salida de el nombre de archivo de entrada. Si el archivo de especificación tiene nombre Q.x, todos los archivos de salida deberán empezar con Q. En la siguiente tabla se muestran los archivos de salida y se describe su contenido:


3.1.5 Asignación de números a programas RPC

Un mensaje de llamada RPC tiene 3 campos con los cuales Únicamente se identifica el procedimiento a ser llamado. Estos campos son:

0 El número de versión del programa remoto 0 El número de procedimiento remoto 0 El número de programa remoto

El número de versión identifica cual versión de el protocolo RPC esta usando el cliente. El número de procedimiento identifica el procedimiento a ser llamado. Los números de programa son administrados por una autoridad central (tal como Sun Microsystems). Una vez que se tiene el número de programa, entonces se puede implementar el programa remoto.

3.1.6 Programa para la asignación de puertos (PORTMAP)

El asignador de puertos (portmap) es un servidor que convierte números de programas RPC a números de puertos IP. Este debe ser ejecutado en orden para hacer llamadas RPC. Cuando un servidor es inicializado, este le dice a portmap el número de puerto. Cuando un cliente quiere hacer una llamada RPC a un número de programa dado, este primero debe avisar a portmap sobre el servidor, para determinar el número de puerto donde los paquetes RPC deberán ser enviados.

3.1.7 Ejecución de un RPC

Los pasos que toman lugar cuando se ejecuta un RPC son generalmente los siguientes:

1. El cliente llama a un procedimiento local, llamado el “client stub” (esquema cliente). El propósito de este stub, es el de empaquetar los argumentos para el procedimiento remoto, posiblemente ponerlos dentro de algún formato estandar y entonces construir uno o más mensajes de red. AI agrupamiento de los argumentos del cliente dentro de mensajes de red se le llama “marshaling”.

2. Estos mensajes de red son enviados al sistema remoto mediante el client stub. Esto requiere una llamada al sistema dentro del kernel local.

3. Los mensajes de red son transferidos al sistema remoto.

4. Un procedimiento “server stub” (esquema servidor), espera sobre el sistema remoto por las peticiones del cliente. Este desempaqueta los argumentos de los mensajes de red y posiblemente los convierte.


5.

6.

7.

0.

9.

El servidor stub ejecuta llamadas a procedimientos locales para invocar a la función servidor actual, pasándole los argumentos que este recibe en los mensajes de red desde el client stub.

Cuando el procedimiento servidor finaliza, este regresa al servidor stub, regresando también algunos valores.

El servidor stub convierte los valores si es necesario, y los empaqueta dentro de uno o más mensajes de red para enviarlos de regreso al cliente stub.

Los mensajes obtenidos se transfieren de regreso a través de la red hacia el cliente stub.

El cliente stub lee los mensajes de red desde el kernel local.

lO.Después, posiblemente se tengan que convertir los valores obtenidos, el cliente stub finalmente regresa a la función cliente.

La figura 3.2 ilustra los pasos listados anteriormente.

Proceso chnte Proceso servidor r - - - - - - 1 r - - - - - - 1

I I I I

l I Rutinasdel I

, cliente I I sendclr 1 I I I I

I I Llamada a procedl

.b + I - 1 I I I Esquema I I Esquema I I cliente I I servidor i

I I I L A L -I

Rutinasdd I

1. A ' (6) (3 I (101 1 I lacal={l) I

A * I

(75 (4) Uamada al cisterm= (2 ) (9)

- 1 -1 I I I Rutinas& ,

red red I

I I (8) I R u t k d e I I I

I

Kernel local L'- - - - - 2

Kernelbcal . de red L - - - - - - ,

Figura 3.2. Esquema de ejecuci6n de un RPC.

3.1.8 Ventajas y desventajas de los RPC's

Entre las ventajas de utilizar RPC's se listan las siguientes:

I. Los RPC's pueden implementarse sobre ambos protocolos de transporte: TCPAP y UDPIIP.


2. La velocidad con que se transmite la información es mayor que cuando se utilizan sockets o TLI’s.

3. Rpcgen ayuda a los programadores a construir automáticamente programas distribuidos, es decir, que los procedimientos de un programa se encuentran localizados en diferentes computadoras.

4. Por medio de XDR se ofrece portabilidad entre diferentes sistemas aún siendo computadoras con distinta arquitectura.

Las desventajas son las siguientes:

1. Las librerías de RPC implementan una estrategia de retransmisión muy simple, y por tanto,

2. Cuando un procedimiento remoto no se ejecuta la aplicación no detecta esa falla. no confiable.

3.2 Ambiente de Comunicación Adaptativo (ACE) [l]

El ambiente de comunicación adaptivo (ACE) implementa un conjunto de patrones de diseño que simplifica el desarrollo de software de comunicación. ACE proporciona un amplio conjunto de categorías de clases que son utilizadas para el desarrollo de tareas del software de comunicación (tales como: demultiplexado de eventos, establecimiento de conexión, ruteo, configuraciones dinámicas de servicios de aplicación y control de concurrencia).

El principal objetivo de ACE es simplificar el uso de los mecanismos del Sistema Operativo (OS), explícitamente en el ligado dinámico, demultiplexado de los puertos de comunicación y concurrencia. Además ACE automáticamente configura y reconfigura el software de comunicación, ligando dinámicamente los servicios con sus aplicaciones en tiempo de ejecución, y ejecuta estos servicios en uno o más procesos o hilos de control.

ACE emplea una variedad de mecanismos avanzados del OS (como son ligado dinámico y multi-hilos de control), técnicas de diseño orientado a objetos (encapsulamiento, clasificación jerárquica, y composición) y un lenguaje característico C++ (tipos parametrizados, herencia y asignación dinámica) dándole ciertas cualidades al software (robustez, facilidad de uso, portabilidad, reusabilidad y extensibilídad) sin que esto signifique degradar el desarrollo de las aplicaciones.

Las técnicas de la programación orientada a objetos y el lenguaje C++ permiten la reusabilidad y extensibilidad de los componentes utilizados en el desarrollo del software de comunicación. La herramienta ACE esta diseñada usando una arquitectura de capas, que ofrecen encapsulamiento a nivel inferior y muestran en el nivel superior, categorías de clases y marcos de trabajo (frameworks).

A nivel inferior ACE provee encapsulamiento para abstraer los sistemas de concurrencia, comunicación de interprocesos (IPC) y mecanismos de memoria virtual.

A su vez provee de una colección de componentes de nivel superior, los cuales colaboran para producir arquitectura reutilizable.


Permite la portabilidad hacia otras plataformas tales como: 0 Sun OS 4.x y 5.x 0 Plataformas de SO como SGI, HP-UX, Linux, SCO Unix, OSFíI, AIX y Windows NT.

3.2.1 Mecanismos IPC SAP (Inter-Process Communication/Service Access Point)

IPC SAP proporciona servicios a través de puntos de acceso a diferentes interfaces de programación estándar tales como BSD sockets, TLI del sistema V de UNIX, SVR4 STREAM pipes, UNIX FlFOs y pipes de Windows NT. Estas interfaces de programación protegen a los desarrolladores y a las aplicaciones de fallas de no-portabilidad de los mecanismos IPC locales y remotos.

Los mecanismos IPC incluyen protocolos orientados a conexión y no orientados a conexión tales como TCPAP, UDPAP y IPXíSPX disponibles en sistemas operativos modernos tales como UNlX (en sus diferentes versiones), Windows NT y OS/2.

IPC SAP utiliza técnicas orientadas a objetos a través del lenguaje C++ para proporcionar un gran conjunto de componentes que simplifican el desarrollo del software de com un icaci ón .

Como se muestra en la figura 3.3, IPC SAP esta diseñado como un conjunto de categorías de clases que incluyen SOCK SAP el cual encapsula la interfase socket, TLI SAP, el cual encapsula la interfase TLI, SPIPE SAP la cual encapsula la interfase UNlX SUR4 STREAM pipe, y FIFO SAP la cual encapsula la interfase UNlX FIFO.

m IPC SAP

U

Figura 3.3. La clase IPC SAP'

Cada categoría de clases esta organizada en una jerarquía de herencias en donde cada subclase proporciona una interfase bien definida para un subconjunto de mecanismos IPC existentes.

Se utiliza la notación de Booch para análisis y diseño orientado a objetos. 1

27 DESARROLLO DEL PROTOCOLO DE CAPA SUPERIOR DlCOM

IPC SAP esta diseñado para proporcionar exactitud, portabilidad, reusabilidad y facilidad para entender y usar software de comunicación, mientras se mantiene un alto nivel de ejecución.

3.2.2 Patrones de diseño [2]

La solución a problemas específicos dentro de la programación orientada a objetos pretende ser una solución reutilizable, por medio del uso de patrones para aumentar la flexibilidad; en donde los diseñadores al familiarizarse con los patrones pueden aplicar estos para diseñar soluciones a problemas sin tener que desarrollar toda la solución, apoyándose para esto en los patrones de diseño.

Los Patrones de diseño proveen técnicas que facilitan el desarrollo de nuevos sistemas, además ayuda a elegir entre distintas alternativas de diseño que produzcan un sistema reutilizable y anula aquellas alternativas que limitan la reutilización.

Cada patrón describe un problema así como la esencia de la solución del mismo. En general un patrón consta de 4 elementos esenciales:

I. Nombre del Patrón, usado para describir el problema de diseño, sus soluciones y consecuencias en una o dos palabras.

2. Problema, describe cuando puede aplicarse el patrón en cuestión. Aquí se explica el problema y su contexto.

3. Solución, describe los elementos que conforman el diseño, sus relaciones, responsabilidades y colaboraciones. La solución no describe en particular un diseño concreto o implantación, porque un patrón es tomado como un templete que puede ser aplicado en distintas situaciones.

4. Consecuencias, son los resultados de aplicar el patrón, aquí existe la crítica para evaluar las alternativas de diseño y a su vez el costo y beneficio de usar el patrón.

Por tanto el patrones de diseño, es la descripción de objetos de comunicación y clases para resolver un problema de diseño en general para un contexto particular.

Puede clasificarse a los patrones de diseño en base a dos criterios:

El primero es el propósito que refleja un patrón determinado, este puede ser:


0 Creacional: que corresponde al proceso de creación de objetos. Este ayuda a crear sistemas independientes del como están siendo creados, compuestos y representados sus objetos.

0 Estructura/: los patrones estructurales tratan con la composición de clases u objetos para formar grandes estructuras.

0 Comportamiento: estos patrones determinan la manera por la cual las clases u objetos interactuan y delegan responsabilidades.

El segundo criterio es el llamado alcance, el cual especifica si el patrón puede ser aplicado principalmente a clases o a objetos.

Los patrones de clase tratan con las relaciones entre clases y sus subclases. Estas relaciones están establecidas a través de herencia.

Los patrones de objeto tratan con relaciones entre objetos,

En ACE se hace uso de un ciertos conjunto de patrones de diseño que permiten simplificar el desarrollo de software de comunicación, parte de este conjunto de patrones de diseño son explicados brevemente a continuación.

3.2.3 Patrón Acceptor [3]

Juega el papel pasivo de la comunicación. Una computadora, una vez inicializado el punto de comunicación, espera en forma pasiva hasta que alguna otra máquina realice una petición de conexión con el.

Objetivo El Acceptor, cumple con la parte pasiva. La idea fundamental de este patrón es separar

las actividades desarrolladas para la inicialización pasiva del servicio, de las actividades llevadas a cabo una vez inicializado el servicio.

Aplicación

El patrón Acceptor es de utilidad cuando la aplicación orientada a conexión presenta las siguientes características:

El comportamiento de un servicio distribuido no depende de los pasos requeridos para inicializar un servicio pasivo.

La petición de conexión de los diferentes sistemas deben llegar concurrentemente, y la conexión sobre uno de ellos no es eficiente.


Soluciones que brinda el patrón Acceptor

El uso de este patrón permite dar solución a cuestiones de:

0 Como utilizar el código de inicialización existente para cada nuevo servicio. 0 Como habilitar estrategias flexibles para ejecutar servicios en forma concurrente (a traves

de hilos de control simples o múltiples procesos, sin importar como fue establecida la comunicación).

0 Como hacer el código de establecimiento de conexión portable a través de las distintas plataformas que contienen diferentes interfaces de programación.

0 Como asegurar que un manejador de U S en modo-pasivo no sea utilizado accidentalmente para lectura o escritura de datos.

3.2.4 Patrón Connector [4]

El patrón Connector desarrolla el papel activo iniciando una conexión a la dirección en donde se encuentra la entidad en el papel pasivo.

Objetivo

del servicio de las tareas desarrolladas una vez que el servicio fue inicializado. El patrón Connector desarrolla el papel activo. Su intención es separar la inicialización

Aplicación

El patrón Connector tiene uso cuando la aplicación orientada a conexión presenta alguna de las siguientes características:

El desarrollo de un servicio en la red no depende de los pasos requeridos para la inicialización del mismo.

Una aplicación debe establecer un gran número de conexiones con sistemas conectados a redes de gran tamaño.

Soluciones que brinda el patrón Connector

Este patrón permite dar solución a problemas de:

Como reutilizar el código para el establecimiento de una conexión para cada nuevo servicio: el patrón Connector permite que las características del servicio sean desarrolladas independientemente de los mecanismos utilizados para inicializar la comunicación. Esto permite reutilizar el código empleado para el establecimiento de una conexión.


0 Como hacer código portable entre las diferentes plataformas que contienen diferentes interfaces de programación: esto es particularmente importante para conexiones asíncronas en las que se utilizan interfaces de programación de bajo nivel (como son sockets y TLI's).

0 Como activar el establecimiento de conexiones con un gran número de sistemas en forma eficiente: el patrón Connector puede inicializar y completar múltiples conexiones.

3.2.5 Reactor [5]

Objetivo El objetivo de este patrón es soportar el demultiplexado y atender múltiples

manejadores de eventos, los cuales se presentan concurrentemente mediante múltiples eventos. El patrón Reactor facilita el desarrollo de aplicaciones flexibles usando componentes reutilizables. En particular, el patrón ayuda a desacoplar los mecanismos independientes de la aplicación, de la funcionalidad específica de la aplicación.

Los mecanismos independientes de aplicación son componentes reutilizables que demultiplexan eventos y atienden manejadores de eventos pre-registrados. La funcionalidad específica de la aplicación es ejecutada mediante métodos definidos por el usuario en los manejadores de eventos. En resumen, el patrón Reactor facilita la extensibilidad de la aplicación.

Aplicación Se debe usar el patrón Reactor cuando:

1. Uno o más eventos deban llegar concurrentemente de diferentes fuentes.

2. Un manejador de eventos posea las siguientes características:

0 Intercambia mensajes de tamaño fijo o variable con sus pares, sin requerir bloqueo de E/S. 0 Procese cada mensaje recibido en un periodo de tiempo relativamente corto.

3. El uso de múltiples hilos de control para implantar demultiplexado de eventos, origine alguno de los siguientes problemas:

0 No Factibilidad: Debido a la falta de múltiples hilos de control soportados sobre una plataforma de sistema operativo.

0 No Deseable: Debido a una ejecución pobre sobre un único procesador o debido a la necesidad de cubrir esquemas de control de concurrencia complejos.

Redundancia: Debido a el uso de múltiples hilos de control en un alto nivel dentro de una arquitectura de aplicación.

4. - La funcionalidad, portabilidad y extensibilidad de los manejadores de eventos específicos de la aplicación beneficiarán mediante el desacoplamiento de los mecanismos

DESARROLLO DEL PROTOCOLO DE CAPA SUPERIOR DICOM 3 1

independientes de las aplicaciones que ejecutan demultiplexado de eventos y despacho de manejadores de eventos.

Ventajas del Patrón Reactor

Este desacopla los mecanismos independientes de la aplicación de la funcionalidad específica de la aplicación. Los mecanismos independientes de la aplicación deben ser componentes reutilizables. Ellos conocen como demultiplexar eventos y atender los métodos apropiados definidos por Event Handler. En contraste, la funcionalidad específica de la aplicación conoce como ejecutar un tipo particular de servicio.

Ayuda a proporcionar la modularidad, reusabilidad y configuración de software de aplicación que maneja eventos.

Proporciona portabilidad, pues permite que su interface pueda ser rehusada independientemente de las llamadas al sistema que ejecuten demultiplexado de eventos.

Desventajas del Patrón Reactor:

Sus manejadores de eventos no están seguros mientras ellos se están ejecutando. Además, los manejadores de eventos generalmente no deben ejecutar bloqueo de E/S. Cada uno de ellos debe ejecutar operaciones de larga duración. Para ejecutar este tipo de operaciones es necesario producir un proceso o un hilo de control por separado. Esta separación de procesos o hilos debe completarse en paralelo dentro del ciclo principal del Reactor.

El patrón Reactor puede ser difícil de depurar debido a que su control de flujo oscila entre el código de demultiplexado del nivel mas bajo y las llamadas a métodos del nivel más alto sobre los manejadores de eventos de la aplicación.


4. Planteamiento del problema.

El Colegio Americano de Radiología (ACR) y La Asociación Nacional de Manufactura Eléctrica (NEMA), se unen para desarrollar un estándar de protocolos, para manejo de imágenes médicas y su comunicación en medicina, dando como resultado el estándar DICOM 3.0.

Para soportar la comunicación en red, DICOM propone 3 opciones: en la primera propone el uso de conexión punto a punto, en la segunda el uso de los protocolos TCP/IP y en la tercera el uso de protocolos ISO/OSI. Para el caso de TCP/IP se propone el Protocolo de Capa Superior Dicom Ó por sus siglas en inglés DULP (DICOM Upper Layer Protocol), el cuál es necesario para soportar la comunicación entre aplicaciones DICOM en un ambiente de red.

Las aplicaciones DICOM están definidas a través de Entidades de Aplicación (EA) DICOM que son asociadas con actividades del mundo real. De esta forma las EA’S utilizan los servicios de red especificados para establecer comunicación entre ellas.

Como todo protocolo, DULP especifica las reglas y formatos de datos que definen la manera en que se llevará a cabo la comunicación con su capa superior e inferior a través de una Máquina de Estados Finitos, en la cual es especifican 28 acciones, 19 eventos y 13 estados que conforman el protocolo.

Por otra parte, DULP define también el formato que van a tener las tramas de bits que intercambiará con otras capas. Estas tramas de bits son llamados PDU’s (Protocol Data Unit), los cuales están formados por la información de control del protocolo y datos del usuario.

Nuestro Proyecto de Investigación está enfocado al desarrollo de DULP, por lo cual, a continuación explicaremos con más detalle las partes que conforman a DULP y su comportamiento.

4.1 Mecanismos y Elementos involucrados en el funcionamiento de DULP.

DULP se comunica con dos protocolos representados por la capa superior e inferior a él, y son:

Protocolo de la capa de transporte ( TCP) y 0 El protocolo de entidades de aplicación DICOM. como se muestra en figura 4.1.


DULP

Para que la comunicación entre estos protocolos se lleve a cabo, DULP especifica dos mecanismos de interfase para usar los servicios de TCP/IP y ofrecer sus servicios a la capa de EA’s a traves de primitivas.

DULP se hace responsable de garantizar el establecimiento de asociaciones en forma apropiada entre EA’s, para lo cual tiene asociados varios elementos como son los PDU’s, ARTIM y la Máquina de Estados Finitos.

4.1.1 Especificaciones de la lnterfase con el protocolo de Entidades de Aplicación DlCOM a través de primitivas

Como se mencionó anteriormente, DICOM propone 3 formas para comunicar sus aplicaciones en red, utilizando TCP/IP, ISO/OSI y conexión punto a punto. Sin embargo especifica que dichas aplicaciones vean una sola interfase para comunicarse, independientemente de la opción de comunicación escogida. Para esto, DICOM especifica los servicios de capa superior OS1 para EA’s DICOM.

Como ya sabemos, en un modelo de comunicación en capas, cada una de las capas usa los servicios proporcionados por su capa inferior inmediata. Estos servicios describen el resultado de la operación del protocolo sin necesidad de conocer en detalle las especificaciones del mismo. Un protocolo especifica la comunicación horizontal (virtual) entre dos computadoras a través de la red, mientras que un servicio describe una relación vertical dentro del sistema.

En este caso, las EA’s hacen uso de 5 servicios DULP a traves de 4 primitivas: Las primitivas son:

a) Petición. b) Indicación. c) Respuesta. d) Confirmación.

Estas primitivas atraviesan las capas en lo que es llamado Punto de acceso al servicio Ó SAP’S ( Service Access Point).

Existe una relación directa entre las primitivas en dos EA, lo cual se refleja en sus nombres, esto se muestra en la figura 4.2:


Entidad de aplicación en el sistema A

SERVICIO A ASSOCIATE A RELEASE A ABORT A-P-ABORT

Entidad de aplicación en el sistema E

TIPO Confirmado Confirmado No confirmado lnicializado por el proveedor de servicios de la capa

I Primitiva de

Primitiva de indicacibn

Primitiva de respuesta

SAP en el sistema A sistema B

Primitiva de cunfitrnaciin

P DATA

Fig. 4.2 Descripcibn de servicios a través de primitivas

superior No confirmado

Una primitiva de petición enviada a DULP del sistema A, induce a una primitiva de indicación en el sistema B. Si una primitiva de indicación en el sistema B necesita una respuesta, una primitiva de respuesta debe ser enviada hacia el DULP de éste sistema a través de su SAP correspondiente. Esta primitiva de respuesta debe inducir a una primitiva de confirmación en el sistema A.

Los servicios de Capa Superior OS1 para EA DICOM especificados, son listados en la tabla 4.1, en donde se observa el tipo de cada servicio:

Tabla. 4. I Servicios de Capa Superior OSI.

En seguida se describen los servicios de Capa Superior OSI.

4. I . I . 1 Servicio A-ASSOCIATE

El establecimiento de una asociación entre dos EA’S debe ser realizada a traves del servicio A-ASSOCIATE asociado a primitivas de petición, indicación, respuesta y confirmación. El inicializador de este servicio es llamado “Solicitante” (Requestor) y el usuario el cual recibe la indicación del servicio AASSOCIATE es llamado el “Proveedor”, el cual deberá confirmar el servicio (Ver fig. 4.3).


El servicio AASSOCIATE debe contener una lista de parámetros, de los cuales algunos son de uso obligatorio para las EA’S DICOM, y otros tienen valores fijos y pueden no ser utilizados.

Una EA que desea establecer una asociación deberá transmitir una primitiva de petición para el servicio A-ASSOCIATE. La EA invocada, es identificada por medio de los parámetros del servicio asociado a la primitiva de petición.

El solicitante (Entidad que hace la petición) espera una confirmación por lo que no puede enviar otra primitiva, excepto la de petición asociada al servicio AABORT. El DULP utilizado por la entidad proveedora , deberá enviar una primitiva de indicación a esta.

La EA proveedora debe aceptar o rechazar la asociación enviando una primitiva de respuesta. El DULP de la EA solicitante deberá enviar una primitiva de confirmación.

Si el proveedor acepta la asociación, ésta estará disponible para usarse. Si se rechaza la aplicación, la asociación no deberá establecerse.

Solicitante (requesdor) Prrrveedor (acceptor)

Primitiva de peticibn I

I Primitiva de indicación DüLPdc I DLiLPde A-ASSOCIATE

Primitiva de respuesta A-ASSOCI ATE

-

Primitiva de confirmacih AASSOCI ATE

Fig. 4.3 Servicio A-ASSOCIATE.

4.1 .I .2 Servicio A-RELEASE

La liberación de una asociación entre dos EA deberá ser ejecutada a través del servicio A-RELEASE asociado a las primitivas de petición, indicación, respuesta y confirmación. En este caso se tiene un “solicitante” y el usuario quien recibe la indicación del servicio A-RELEASE es el “proveedor” , el cual deberá confirmar el servicio.

Una aplicación que desea liberar la asociación deberá enviar una primitiva de petición a su DULP correspondiente. Este solicitante no deberá transmitir ninguna otra primitiva hasta que reciba una primitiva de confirmación.


El DULP utilizado por la EA proveedora (Fig. 4.4) enviará una primitiva de indicación a esta, la cuál, solo podrá enviar una primitiva de respuesta asociada al servicio en cuestión, una primitiva de petición asociada al servicio A-ABORT, o una primitiva de petición asociada al servicio P-DATA.

Para completar el servicio, la EA proveedora deberá contestar la primitiva de indicación mediante la transmisión de una primitiva de respuesta, convirtiéndose en una primitiva de confirmación hacia el solicitante.

Un solicitante en cualquier EA puede interrumpir el servicio A-RELEASE mediante la transmisión de una primitiva de petición asociada al servicio A-ABORT. Cuando el proveedor recibe una indicación A-ABORT, la asociación es liberada con la posible pérdida de la información que se encuentra transitando por la red.

La siguiente figura muestra el procedimiento de una liberación normal en una asociación.

solicitante (requestor) Prwieednr (aceepdor)

Primitiva de peticián I

Primitiva de indicacih A-RELEASE Primitiva de respuesta A-RELEASE

I

. PAP)

Primitiva de

A-RELEASE confirmacibn GAP)

Fig. 4.4 Servicio A-RELEASE.

Puede suscitarse una colisión en este servicio cuando dos solicitantes en distintas EA ‘s envían simultáneamente una primitiva asociada al servicio A-RELEASE. En este caso, tanto la EA solicitante como la EA proveedora reciben una primitiva de indicación no esperada. Entonces, deberá ocurrir lo siguiente para completar la liberación normal de la asociación:

1. El solicitante de la asociación enviará una primitiva de respuesta. 2. La EA proveedora esperará una primitiva de indicación de su DULP correspondiente. 3. El solicitante del servicio recibirá una primitiva de confirmación.

La asociación deberá liberarse cuando los dos usuarios del servicio han recibido una primitiva de confirmación.


4.1 .I .3 Servicio A-ABORT

El servicio AABORT debe ser usado por el solicitante en alguna de las EA para causar la liberación de una asociación en forma anormal. Este deberá ser un servicio no confirmado, es decir, el aborto de la asociación sólo debe llevarse a cabo a traves de las primitivas de petición e indicación asociadas al servicio A-ABORT (Ver fig. 4.5).

Cuando este servicio es usado, la asociación deberá ser liberada anormalmente junto con la liberación anormal de la conexión de transporte. La EA que desea liberar la asociación anormalmente deberá transmitir una primitiva de petición. El DULP de la EA proveedora, le deberá transmitir la primitiva de indicación a esta.

El propio DULP (de ambas partes) podrá causar la liberación anormal de la asociación debido a errores internos. En este caso, deberá enviar una primitiva de indicación a cada de las EA’S involucradas en la asociación.

Solicitante (reqwsbor)

PWnitiva de

Prweedor (acceptor)

DULPde , DULPdp laEA I laEA Solicitante I Prouerdoi I Primitiva de indicación

A-AEORT

Fig. 4.5 Servícío A-ABORT

4.1 .I .4 Servicio A-P-ABORT

Este servicio debe ser usado por DULP, para indicar la liberación anormal de la asociación a causa de problemas en los servicios en la capa de presentación, o en las capas de más bajo nivel. Este servicio debe utilizar sólo la primitiva de indicación (Ver fig. 4.6).

Cuando DULP detecta un error interno, la primitiva de indicación asociada a este servicio deberá enviarse a ambas EA.%. La asociación deberá ser liberada anormalmente.


Solicitante (requestmar) Plweedor (acceptor)

I

Primitiva de k d i c a c i h indicacibn AP-ABORT A P A B O R T

Fig. 4.6 Servicio A- P-A BO R T

4.1 .I .5 Servicio P-DATA

Este servicio deberá ser usado por las EA’s para intercambiar información (por ejemplo, mensajes DICOM). Una asociación permite un intercambio bidireccional simultáneo de primitivas de petición e indicación asociadas al servicio P-DATA.

Cuando la asociación se ha establecido satisfactoriamente, entonces se podrá iniciar la transferencia de datos entre las EA’s. La EA que solicitó la asociación deberá transmitir una primitiva de petición. El DULP de la EA proveedora deberá transmitir la primitiva de indicación a esta. Como éste servicio es bidireccional entonces la EA proveedora podrá iniciar el mismo procedimiento.

Sokitante (mquestor) Pnmreedar (acceptor)

Primitiva de

PAP> I GAP)

Fig. 4.7 Servicio P-DATA.

4.1.2 Especificaciones de lnterfase con TCP/IP

DULP especifica la interface con TCPíIP con el fin de que este pueda ser utilizado en ambientes de red.

Existe una relación uno a uno entre una conexión de transporte TCP y una asociación de capa superior, la cual se describe en las siguientes reglas:


a) Cada asociación de capa superior deberá ser soportada Únicamente por una conexión de transporte TCP.

b) Cada conexión de transporte TCP deberá soportar Únicamente una asociación de capa superior.

Para establecer una conexión TCP, un puerto TCP debe ser usado para servir como selector de transporte. Una entidad de capa superior DICOM es identificada sobre un sistema dado sobre la red por un número de puerto Único dentro del alcance de éste sistema. El puerto asignado a DICOM es el 104.

La comunicación entre los protocolos DULP y TCP se lleva a cabo a través de tres etapas las cuales son:

1. Apertura de una conexión de transporte TCP. 2. Transferencia de datos sobre una conexión TCP. 3. Cierre de la conexión de transporte TCP.

1. Apertura de una conexión de transporte TCP. Cuando una asociación va a ser establecida por una EA DICOM, una primitiva de petición de conexión de transporte debe ser transmitida a los servicios de transporte de TCP. Una vez que la conexión de transporte es confirmada satisfactoriamente (se recibe una primitiva de confirmación), un PDU se formará con la información correspondiente y deberá ser enviado sobre la conexión de transporte establecida.

2. Transferencia de datos sobre una conexión TCP. Una vez que la conexión de transporte TCP se ha establecido satisfactoriamente, entonces se inicia el intercambio de PDU’s como lo especifica la máquina de estados finitos DULP.

3. Cierre de la conexión de transporte TCP. Una conexión de transporte es cerrada bajo ciertas situaciones, de las cuales las mas comunes son las siguientes:

a) Cuando se recibe un PDU de liberación. b) Cuando una conexión de transporte ha sido establecida por una EA y un PDU de

c) Cuando se recibe un PDU de aborto. d) Cuando ocurre alguna falla en la red.

petición de asociación no se recibió antes de que el temporizador se detuviera.

Las posibles interfaces con TCP/IP fueron mencionadas en los capítulos 2 y 3 de éste reporte.

4.1.3 Formatos de datos (PDU’s)

Los PDU’s (Protocol Data Units) son los formatos de mensajes intercambiados entre entidades de aplicación, utilizando DULP. Un PDU consiste de información de control del


protocolo e información de usuario, y están constituidos por campos fijos obligatorios seguidos por campos variables los cuales contienen uno o más elementos (llamados items) y sub- elementos (llamados sub-items).

Tipo de Longitud PDU del

PDIJ

DULP maneja siete unidades de datos distintas, las cuales son:

( Campo variable ) Contiene una o mas elementos de Presentacion

de valores de dato? (PDV) mostrados abajo

1. P-DATA-TF 2. A-ABORT 3. A-ASSOCIATE-RQ 4. A-ASSOCIATE-AC 5. A-ASSOCIATE-RJ 6. A-RELEASE-RQ 7. A-RELEASE-RP

LongtM del

elemento

Para tener una idea más clara de lo que son los PDU’s, se presenta a continuación la estructura de cada uno de ellos con los nombres y tamaños (en bytes) de los campos que los forman (Ver figuras 4.8 a 4.10).

IDdelCon PDV tex-iode Mensaje DICOM presentdc Comando o conjunto de dato3

Estructura del PDU P-DATA-TF

Fig. 4.8

Estructura de los PDU’s A-ASSOCIATE-RJ, A-RELEASE-RQ, A-RELEASE-RP y A-ABORT

1 1 4 1 1 1 1

Fig. 4.9 Nota: Los campos marcados por un asterisco (*) deberán ser usados o reservados dependiendo del PDU especificado.


Estructura de los PDU’s A-ASSOCIATE-RQ y A-ASSOCIATE-AC

L q i d del

Elementc

1 1 4 2 2 16 16 32

c i

Nombre de SutáXis abstracta

Elemento Contexto de Aplicación:

hombre del Contexto de aplicacian

1 1 2 C= 64

L ~ i t U C del

Elementc

(solo uno)

Nombre de Sintaxis de tmnsferencix

Elemento Contexto de Presentación:

Longitud del

Elementc

l d

1 1 2 1

ibíaxma loiigitud recibida ( solo Uno)

Elemento Sintáxis Abstracta:

1 1 2 <.= 64

Elemento Sintixis de transferencia:

1 1 2 c= 64

Elemento información de usuario:

1 1 2

I i

Elemento Máxima longitud:

1 1 2 4

Fig. 4. I O


4.1.3.1 Codificación de PDU's

La codificación de los PDU's deberá ser definida como sigue:

a) Cada tipo de PDU deberá consistir de uno o más bytes numeradas secuencialmente con el

b) Cada byte dentro del PDU deberá consistir de 8 bits numerados del 7 al O, donde el bit O es

c) Cuando bytes consecutivos estén usados para representar una cadena de caracteres, los

d) Cuando bytes consecutivos son usados para representar números binarios, el número de

e) El número de byte más bajo es localizado primero en el servicio de transporte de flujo de

byte 1 siendo el número de byte más bajo.

el bit de orden más bajo.

números de bytes más bajo representan el primer carácter.

byte mas bajo tendrá el valor más significativo (Formato Big Endian).

datos.

4.1.4 Tiempo de espera (ARTIM)

El temporizador de DULP (ARTIM - Association RequesüReject/Release/ Timer), es el encargado de administrar el tiempo límite de espera para las peticiones, rechazos y liberaciones de las asociaciones sobre una entidad de capa superior DICOM.

Cuando una EA DICOM proveedora recibe una indicación de conexión de transporte para una asociación, esta debe esperar la llegada de un PDU A-ASSOCIATE-RQ, entonces ARTIM debe ser activado. Si el tiempo límite de espera transcurre y no se ha recibido el PDU, entonces la conexión de transporte deberá cerrarse.

Cuando un PDU AASSOCIATE-RJ, A-RELEASE-RP o un A-ABORT es enviado para cerrar la asociación, ARTIM es activado. Si el tiempo límite de espera transcurre y no se recibe una indicación de cierre de conexión, entonces la conexión de transporte deberá cerrarse.

4.1.5 Especificaciones del funcionamiento de DULP.

DULP tiene tres funciones principales, las cuales son:

1. Establecer asociaciones. 2. Lectura/Escritura de información. 3. Cerrar asociaciones.

4.1 5 .1 Establecimiento de una asociación.

Una asociación es establecida mediante la siguiente secuencia:


1) El cliente inicia la asociación escogiendo un protocolo de red y llama a un servidor en una dirección conocida.

2) El servidor examina la llamada del cliente y determina si le es posible comunicarse con el, enviándole una respuesta.

3) El cliente examina la respuesta para determinar si esta es apropiada.

El cliente transmite una unidad de información de protocolo (PDU) de petición de asociación como parte de la inicialización . Este PDU contiene un número de campos fijos y otros variables los cuales definen el tipo de asociación que el cliente desea. El servidor examina el PDU de petición y responde con un PDU de aceptación o con un PDU de rechazo.

Una vez que la asociación es establecida, el cliente y el servidor se comunican como pareja. El manejador de la conversación es determinado por el tipo de asociación que fue establecida. El estándar DICOM permite que cada aplicación envíe mensajes sobre la asociación establecida.

4.1 5 2 Lectura/Escritura de información.

Cuando una asociación se ha establecido satisfactoriamente, entonces se podrá iniciar el intercambio de PDU’s entre las EA’S involucradas en la asociación.

La información que será transmitida entre las EA deberá ser fragmentada. Cada fragmento es guardado dentro de un PDV (Presentation Data Value Item - Elemento de presentación de valores de datos), los cuales son incluidos dentro de un PDU P-DATA-TF en forma de lista.

4.1 S .3 Cierre de una asociación.

Hay varios mecanismos para cerrar una asociación:

1. La aplicación que inicia la asociación pide que la asociación sea liberada satisfactoriamente mediante la transmisión de un PDU de liberación.

2. Alguna de las aplicaciones piden que la asociación sea liberada inmediatamente mediante la transmisión de un PDU de aborto entonces la conexión en red también es liberada.

3. Alguna de las aplicaciones termina anormalmente la conexión en red.

4.1 -5.4 Máquina de Estados Finitos DULP (MEFD).

Como se ha mencionado anteriormente, esta máquina de estados finitos se forma de 13 estados los cuales están relacionados con 19 eventos y 28.


4.1.5.4.1 Estados

1.

2.

3.

4.

5.

Los estados de la máquina DULP se dividen en cinco grupos principales los cuales son:

No asociación: Dentro de este grupo se encuentra el Estado I, también llamado estado ocioso.

Establecimiento de la asociación: Dentro de este grupo se encuentran los estados 2, 3, 4 y 5.

Transferencia de información: En este grupo solo se encuentra el estado 6.

Liberación de la asociación: Este grupo lo conforman los estado 7, 8, 9, 10, 11 y 12.

Espera del cierre de la conexión de transporte: Estado 13.

4.1 -5.4.2 Eventos

Los eventos de la MEFD son 19 y pueden ser generados por alguna de las 3 fuentes siguientes:

a) Por la capa superior de EA’S. b) Por TCPAP. c) PorARTIM.

Entre los eventos que pueden ser generados por la capa superior de EA’S, se encuentran los que emiten alguna primitiva. TCPAP genera los eventos involucrados con la emisión de algún tipo de PDU, así como los eventos que tiene que ver con la conexión de transporte local. Por Último, ARTIM genera los eventos relacionados con el tiempo límite de espera.

4.1.5.4.3 Acciones

Están divididas en cuatro grupos y son los siguientes:

1) Acciones relacionadas con el establecimiento de la asociación. 2) Acciones relacionadas con la transferencia de datos. 3) Acciones relacionadas con la liberación de una asociación. 4) Acciones relacionadas con el aborto de una asociación.


4.1 S.4.4. Funcionamiento de la MEFD

Posible evento a recibir Acción I Clave Definición Clave Definición Est.Sig.

E-1 Petición A-ASSOCIATE (usuario local) AE-1 Emitir primitiva de petición de conectar Est 4

E-5 indicación de conexión de transporte AE-5 Emitir primitiva de respuesta de conexión de Est 2 transporte al Servicio de transporte local.

transporte, activar temporizador ARTIM.

- (servicio de transporte local)

El funcionamiento de la MEFD, lo presentaremos a través de las siguientes tablas, en donde cada una de ellas representa un estado de la máquina. En cada tabla se indican los eventos que se pueden presentar en el estado en cuestión y las acciones que se tendrán que ejecutar cuando se susciten dichos eventos. Se indica también el estado siguiente al que tendrá que pasar la máquina después de que se ejecute cierta acción.

Tabla 4.2 Estado 1. Estado ocioso

Tabla 4.3 Estado 2. Apertura de la conexión de transporte (esperando A-ASSOCIATE-RQ PDU)

Clave E-3

E-4

E-1 O

E-1 2

E-I 3

E-1 9

E-6

E-1 6

E-I 8

E-1 7

Posible evento a recibir Definición

A-ASSOCIATE-AC PDU (recibido de la conexión de transporte).

A-ASSOCIATE-RJ PDU (recibido de la conexión de transporte)

P-DATA-TF PDU

A-RELEASE-RQ PDU (recibida de la conexión de transporte abierta).

A-RELEASE-RJ PDÜ (recibido de la conexión de transporte).

PDU recibido irreconocible o invalid0

A-ASSOCIATE-RQ PDU (recibido de la conexión de transporte)

A-ABORT PDU (recibido de la conexión de transporte abierta). Expira ternporizador ARTIM (Asociación rechazaddliberación del ternporizador). Indicación de cierre de conexión de transporte (servicio de transporte local).

Clave AA-I

AA-I

AA-I

AA-1

AA-1

AA-I

AE-6

AA-2

AA-2

AA-5

Acción Definición

Mandar A-ABORT PDU (origen usuario de servicio) y activar (o reiniciar si ya esta inicializado) ternporiiador ARTIM Mandar A-ABORT PDU (origen usuario de servicio) y activar (o reiniciar si ya esta inicializado) temporizador ARTIM Mandar A-ABORT PDU (origen usuario de servicio) y activar (o reiniciar si ya esta inicializado) ternporizador ARTIM Mandar A-ABORT PDU (origen usuario de servicio) v activar ío reiniciar si va esta inicializádó) ternporizador ARTIM I

Mandar A-ABORT PDU íoriaen usuario de . - servicio) y activar (o reiniciar si ya esta inicializado) temporizador ARTIM Mandar A-ABORT PDU (origen usuario de servicio) y activar (o reiniciar si ya esta inicializado) ternporizador ARTIM Detener temporizador ARTIM y si A- ASSOCIATE-RQ es aceptado por el proveedor de servicios: - emitir primitiva de indicación de A- ASSOCIATE en otro caso - emitir A-ASSOCIATE-RJ PDU y activar ternporizador ARTIM Detener temporizador ARTIM si esta activo. Cerrar conexión de transporte. Detener ternporizador ARTIM si esta activo. Cerrar conexión de transporte. Detener ternporizador ARTIM.

Est.Sig. Est 13

Est 13

Est 13

Est 13

Est 13

Est 13

Est 3

Est 13

Est 1

Est 1


Tabla 4.4 Estado 3. Esperando primitiva de respuesta A-ASSOCIATE local (desde el usuario local).

Acción Clave I Definición AA-1 I Mandar A-ABORT PDU (origen usuario de

Posible evento a recibir

E-15 1 Primitiva de petición A-ABORT Clave I Definición Est.Sig.

Est 13


A-ASSOCIATE-RJ (recibido de la conexión de transporte ).

AA8

AE8

AA8

AA8

AA8

AA8

AE-7

de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar ASSOCIATE-RJ Activa ARTIM.

Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener ternporkador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar A-ASSOCIATE-AC PDU. Est 6

Est 13

Est 13

Est 13

Est13

Est13

Est 1

Primitiva de respuesta A-ASSOCIATE rechazo

E-6 A-ASSOCIATE-RQ PDU (recibida de la conexión de transporte ).

E-12

E-13

E-19

E-7

E-16

A-RELEASE-RQ PDU (recibido de la conexión de transporte abierta).

A-RELEASE-RP PDU (recibido de la conexión de transporte abierta).


Primitiva respuesta A-ASSOCIATE (aceptación). A-ABORT PDU (recibido de la conexión de transporte abierta).

I servicio) y activar (o reiniciar si ya esta I

conexión de transporte. Emitir primitiva de indicación A-P-ABORT.

I inicializado) temporizador ARTIM AA8 I Mandar A-ABORT PDU (origen proveedor I Est 13

Est 1

I de servicio) emitir indicación A-P-ABORT, I

E-17

1 y detener temporizador ARTIM. AA8 I Mandar A-ABORT PDU (origen proveedor I Est 13

Indicación de cierre de conexión de transporte (servicio de transporte local).

Posible evento a recibir Acción Clave Definición Clave Definición Est.Sig.

E-2 Confirmación de conexión de transporte AE-2 Mandar A-ASSOCIATE-RQ PDU. Est 5

E-15 Primitiva de petición A-ABORT. AA-2 Detener ternporizador ARTIM si esta Est 1

E-17 Indicación de cierre de conexión de AA-4 Emitir primitiva de indicación A-P-ABORT. Est 1

(servicio de transporte local).

activo. Cerrar conexión de transporte.

L transporte (servicio de transporte local).

AA-3

AA-4

Si (usuario de servicio inicia el aborto) - emitir indicación A-ABORT y cerrar

conexión de transporte. Otro caso (proveedor de servicio inicia el aborto)

- emitir indicación A-P-ABORT y cerrar

Est 1


Tabla 4.6 Estado 5. Esperando A-ASSOCIATE-AC o A-ASSOCIATE-RJ PDU.

Posible evento a recibir Acción Clave Definición Clave Definición

E-3 A-ASSOCIATE-AC PDU (recibido de la AE-3 Emitir primitiva de confirmación A-

E 4 A-ASSOCIATE-RJ PDU (recibido de la AE-4 Emitir primitiva de confirmación (rechazo) y conexión de transporte). ASSOCIATE (aceptación)

Est.Sig. Est6

Est 1

E-1 6

I conexión de transporte. I Otro caso (proveedor de servicio inicia el

conexión de transporte). A.ABORT PDU (recibido de la conexión de transporte abierta).

cerrar conexión de transporte. Si (usuario de sewicio inicia el aborto) AA-3 Est 1

- emitir indicación A-ABORT y cerrar

1 ab?h indicación A-P-ABORT v cerrar I I I conexión de transporte. I

E-19 PDU recibido irreconocible o invalido AA-8 Mandar A-ABORT PDU (origen proveedor Est 13 de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM.

Tabla 4.7 Estado 6. Asociación establecida y listo para transferencia de datos.

conexión de transporte). e servicio) emitir indicación A-P-ABORT ,


E-I 6

E-I 7

conexión de transporte abierta). A.ABORT PDU (recibido de la conexión de transporte abierta).

AA-3 Si (usuario de servicio inicia el aborto) - emitir indicación A-ABORT y cerrar


- emitir indicación A-P-ABORT y cerrar conexión de transporte.

Indicación de cierre de conexión de AA-4 Emitir primitiva de indicación A-P-ABORT transporte (servicio de transporte local).

Est 1

Est 1

Tabla 4.8 Estado 7. Esperando A-RELEASE-RP PDU.

Acción Clave I Definición AA-I 1 Mandar A-ABORT PDU (origen usuario de

Clave E-I 5

E-3

E-4

E-6

E-I 9

E-1 O E-I 2

E-I 3

E-I 6

E-I 7

Est.Sig . Est 13


Primitiva de petición A-ABORT Definición

AA-8

AA-8

AA-8


A-ASSOCIATE-RJ PDU (recibido de la conexión de transporte).

A-ASSOCIATE-RQ PDU (recibido de la conexión de transporte).

servicio) y activar (o reiniciar si ya esta inicializado) temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT ,

Est 13

Est 13

Est 13


AR-6 AR-8

AR-3

AA-3

P-DATA-TF PDU A-RELEASE-RQ PDU (recibido de la

de servicio) emitir indicacion Á-P-ABORT , y detener temporizador ARTIM. Emitir indicación P-DATA Est 7 Emitir indicación de A-RELEASE (colisión liberada)

- si association-requestor Est 9 - si no Est 10

Emitir primitiva de confirmación A- Est 1 RELEASE, y cerrar conexión de transporte Si (usuario de Servicio inicia el aborto)

- emitir indicación A-ABORT y cerrar conexión de transporte. Otro caso (proveedor de servicio inicia el aborto)


Est 1

conexión de transporte abierta)

AA-4

A-RELEASE-RP PDU (recibido de la conexión de transporte abierta). A.ABORT PDU (recibido de la conexión de transporte abierta).

conexión de transporte. Emitir primitiva de indicación A-P-ABORT Est 1 Indicación de cierre de conexión de

transporte (servicio de transporte local).

I y detener ternporizador ARTIM. I A A 8 I Mandar A-ABORT PDU (origen proveedor I Est 13


Tabla 4.9 Estado 8. Esperando primitiva de respuesta A-RELEASE (desde el usuario local).


Clave E-15

E-3

E 4

E-6

E-I O

E-12

E-13

E-19

E-I 4

E-9

E-16

E-I 7 AA-4 Emitir primitiva de indicación A-P-ABORT



Primitiva de petición A-ABORT Clave Definición E-I 5

Definicián

Acción Clave Definición EstSig. AA-1 Mandar A-ABORT PDU (origen usuario de Est 13

servicio) y activar (o reiniciar si ya esta

'rimitiva de oetición A-ABORT

E-3

Acción Clave I Definición AA-1 I Mandar A-ABORT PDU (origen usuario de

A-ASSOCIATE-AC PDU (recibido de la AA-8 conexión de transporte).

A.ABORT PDU (recibido de la conexión de transporte abierta).

inicializado) ternporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT ,

AA-3

Est 13

Si (usuario de servicio inicia el aborto) - emitir indicación A-ABORT y cerrar



conexión de transporte).


de servicio) emitir indicación A-P-ABORT , y detener ternporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT ,

AA-8

EstSig. Est 13

Est 13

Est 13

Est 13

Est 13

Est 13

Est 13

Est 13

Est 13

Est 8

Est 1

Est 1

Tabla 4.1 O Estado 9. Colisión liberada del lado del solicitante; esperando respuesta A-RELEASE (desde el usuario local).

I y detener temporizador ARTIM. I E-4 I A-ASSOCIATE-RJ PDU (recibido de la I AA43 I Mandar A-ABORT PDU (origen proveedor I Est 13 i Est 13

I y detener ternporizador ARTIM. I E-10 I P-DATA-TF PDU I A A 8 I Mandar A-ABORT PDU (origen proveedor I Est 13


E-I 2

E-I 3

E-I 9

E-I 4 E-1 6

E-1 7

de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM.

A-RELEASE-RQ PDU (recibido de la AA-8 Mandar A-ABORT PDU (origen proveedor conexión de transporte abierta). de servicio) emitir indicación A-P-ABORT ,

y detener temporizador ARTIM. A-RELEASE-RP PDU (recibido de la AA-8 Mandar A-ABORT PDU (origen proveedor conexión de transporte abierta). de servicio) emitir indicación A-P-ABORT ,

y detener temporizador ARTIM. PDU recibido irreconocible o invalido Mandar A-ABORT PDU (origen proveedor


Primitiva de respuesta A-RELEASE AR-9 Mandar A-RELEASE-RP PDU . A.ABORT PDU (recibido de la conexión de AA-3 transDorte abierta). - emitir indicación A-ABORT y cerrar

AA-8

Si (usuario de servicio inicia el aborto)

Est 13

Est 13

Est 13

Est 11

Est 1




Emitir primitiva de indicación A-P-ABORT AA-4

Tabla 4.1 1 Estado I O . Colisión liberada del lado del proveedor; esperando A-RELEASE-RP PDU.

Acción Clave 1 Definición AA-I I Mandar A-ABORT PDU (origen usuario de

Clave E-I 5

E-3

EstSig. Est 13

E-4

E-6

E-I O

E-I 2

E-1 9

E-I 3

E-I 6

E-I7

AA-8

AA-8

AA-8



servicio) y activar (o reiniciar si ya esta inicializado) temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT ,


A-ASSOCIATE-RJ PDU (recibido de la conexión de transporte).


P-DATA-TF PDU AA-8

A-RELEASE-RQ PDU (recibido de la

y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT ,

Est 13

conexión de transporte abierta)

AA-8 PDU recibido irreconocible o invalido

de servicio) emitir indicacion A-PiABORT , y detener temporizador ARTIM. Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT ,

Est 13

Est 13

A-RELEASE-RP PDU (recibido de la conexión de transporte abierta). A-ABORT PDU (recibido de la conexión de transporte abierta).

AA-3

AA-4 Indicación de cierre de conexión de transporte (servicio de transporte local).

RE LEAS E. Si (usuario de servicio inicia el aborto)

conexión de

Otro caso (proveedor de servicio inicia el aborto)

- emitir indicación A-P-ABORT y cerrar conexión de transporte. Emitir primitiva de indicación A-P-ABORT

- emitir indicación A-ABORT y cerrar

transporte.

Est 13

Est 13

Est 13

I y detener temporizador ARTIM. AA-8 I Mandar A-ABORT PDU (origen proveedor I

I y detener temporizador ARTIM. I AR-10 I Emitir primitiva de confirmación A- I Est 12

Est 1

Est 1

DESARROLLO DEL PROTOCOLO DE CAPA SUPERIOR DICOM 5 1

Posible evento a recibir Acción Clave Definición Clave Definición E-I5 Primitiva de petición A-ABORT AA-1 Mandar A-ABORT PDU (origen usuario de

servicio) y activar (o reiniciar si ya esta inicializado) temporizador ARTIM.

E-3 A-ASSOCIATE-AC PDU (recibido de la AA-8 Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT , conexión de transporte).

I . . I I y detener temporizador ARTIM. 1

E 4 I A-ASSOCIATE-RJ PDU (recibido de la I AA8 I Mandar A-ABORT PDU (origen proveedor I Est 13

Est.Sig. Est 13

Est 13

I I conexión de transporte). . I I de servicio) emitir indicación A-P-ABORT , I .~


y detener temporizador ARTIM.

de servicio) emitir indicación A-P-ABORT , AA-8 Mandar A-ABORT PDU (origen proveedor Est 13

E-I O y detener ternporizador ARTIM.

de servicio) emitir indicación A-P-ABORT , P-DATA-TF PDU A A 8 Mandar A-ABORT PDU (origen proveedor Est 13

E-I2 y detener iemporizador ARTIM.

de servicio) emitir indicación A-P-ABORT , A-RELEASE-RQ PDU (recibido de la AA-8 Mandar A-ABORT PDU (origen proveedor Est 13 conexión de transwrte abierta).

E-19

Tabla 4.13 Estado 12. Colisión liberada del lado del proveedor; esperando primitiva de respuesta


de servicio) emitir indicación A-P-ABORT , PDU recibido irreconocible o invalid0 AA43 Mandar A-ABORT PDU (origen proveedor Est 13

i-RELEASE ídesde el usuario locall.

E-13

E-I6

Clave E-I 5

E-3

E-4


RELEASE, y cerrar conexión de transporte. Si (usuario de servicio inicia el aborto)

A-RELEASE-RP PDU (recibido de la AR-3 Emitir primitiva de confirmación A- Est 1 conexión de transporte abierta). A.ABORT PDU (recibido de la conexión de Est 1 AA-3

E-6

E-I O

E-I 2

E-1 3

E-17

transporte abierta). emitir indicación A-ABORT y 'cerrar conexión de transporte. Otro caso (proveedor de servicio inicia el aborto)


Indicación de cierre de conexión de AA-4 Emitir primitiva de indicación A-P-ABORT Est 1 transporte (servicio de transporte local).

I y detener temporizador ARTIM. I A-ASSOCIATE-RJ PDU (recibido de la I A A 8 I Mandar A-ABORT PDU (origen proveedor I Est 13




conexión de transporte). I I de servicio) emitir indicacion A-P:ABORT , I I

Acción Clave Definición Est .Sig . AA-I Mandar A-ABORT PDU (origen usuario de Est 13

servicio) y activar (o reiniciar si ya esta inicializado) temporizador ARTIM.



I y detener temporizador ARTIM. I P-DATA-TF PDU I AA8 I Mandar A-ABORT PDU (origen proveedor I Est 13



A-RELEASE-RQ PDU (recibido de la conexión de transporte abierta).

A-RELEASE-RP PDU (recibido de la conexión de transporte abierta).


de servicio) emitir indicación A-P-ABORT , y detener ternporkador ARTIM.



AA8 Mandar A-ABORT PDU (origen proveedor Est 13

AA8 Mandar A-ABORT PDU (origen proveedor Est 13

E-I 9

E-I 4

E-I 6

E-I 7

Posible evento a recibir Clave I Definición

E-3 I A-ASSOCIATE-AC PDU (recibido de la

PDU recibido irreconocible o invalido

Acción Clave I Definición Est.Sig. AA-6 I Ignorar PDU Est 13

Primitiva de respuesta A-RELEASE

conexión de transporte).

A-ABORT PDU (recibido de la conexión de transporte abierta).

I


conexión de transporte). P-DATA-TF PDU A-RELEASE-RQ PDU (recibido de la

AA8

AR-4

AA-3

AA-4

1

AA-6 Ignorar PDU Est 13 AA-6 lanorar PDU Est 13

Mandar A-ABORT PDU (origen proveedor de servicio) emitir indicación A-P-ABORT ,

E-I3

E-6

y detener temporizador ARTIM. Emitir A-RELEASE-RP PDU y activar

conexión de transporte abierta). A-RELEASE-RP PDU (recibido de la AA-6 conexión de transporte abierta). A-ASSOCIATE-RQ PDU (recibido de la AA-7

temporizador ARTIM. Si (usuario de servicio inicia el aborto)

- emitir indicación A-ABORT y cerrar conexión de transporte. Otro caso (proveedor de servicio inicia el aborto)

- emitir indicación A-P-ABORT y cerrar conexión de transporte. Emitir primitiva de indicación A-P-ABORT

- Ignorar PDU

Mandar A-ABORT PDU

Est 13

Est 13

Est 13

Est 13

Est 1

conexión de transporte). PDU recibido irreconocible o invalido A.ABORT PDU (recibido de la conexión de

Est 1

AA-7 Mandar A-ABORT PDU Est 13 AA-2 Detener ternporkador ARTIM si esta Est 1

Tabla 4.14 Estado 13. Esperando indicación de cierre de transporte (ya no existente asociación).

IT

p E-I 6

I transporte abierta). I E-18 I Expira ternporizador ARTIM (Asociación I AA-2

activo. Cerrar conexión de transporte. Detener temporizador ARTIM si esta I Est 1


5. Propuesta de solución.

5.1 Análisis y diseño orientado a objetos[l I ]

Para la creación de software de calidad deben tomarse en cuenta las fases tradicionales de análisis y diseño de sistemas también conocidas como rnacroproceso las cuales son:

I . Conceptualización: persigue establecer los requisitos esenciales para el sistema.

2. Análisis: proporciona una descripción del problema, esta debe ser completa, consistente, legible y revisable. En el análisis se busca modelar el mundo real.

3. DiseFío: su propósito es crear una arquitectura para la implantación que va a desarrollarse.

4. Evolución: su propósito es aumentar y cambiar la implantación mediante refinamiento sucesivo.

5. Mantenimiento: esta fase es la continuación de la fase anterior en donde se analizan cambios específicos y se eliminan errores persistentes.

Todos los sistemas con éxito orientados a objetos cuentan con las cualidades de tener integridad conceptual que es uno de los puntos más importantes a considerar en el diseño de un sistema, es decir tener una estructura interna transparente es esencial para construir un sistema comprensible, que pueda extenderse y reorganizarse.

Esta cualidad es llamada arquitectura la cual tiene los atributos de estar construida en capas de abstracción bien definidas, existiendo una clara separación de intereses entre la interfase y la implantación de cada capa.

Otra cualidad es la de tener un ciclo de vida incrementable e iterativo, es iterativo en el sentido de que conlleva al refinamiento sucesivo de una arquitectura y es incrementable en el sentido de que cada pasada por un ciclo análisisídiseñoíevolución lleva a refinar gradualmente las decisiones que deben tomarse para el perfeccionamiento del sistema.

Dentro del análisis y diseño orientado a objetos debe aplicarse el proceso de desarrollo llamado microproceso[l 1, el cual tiende a seguir las siguientes actividades:


o Identificación de clases y objetos: el propósito de identificar las clases y objetos es el de establecer los límites del problema que se maneja, esta actividad es el primer paso al proyectar una descomposición orientada a objetos del sistema que se desarrolla.

Como parte del análisis se aplica este paso para descubrir aquellas abstracciones que forman el dominio del problema.

Como parte del diseño, se aplica este paso para insertar nuevas abstracciones que forman parte de los elementos de la solución.

Inicialmente alguno de los objetos y clases identificados pueden estar equivocados, ya que a medida que se aprende más del problema se cambiaran probablemente los límites de ciertas abstracciones, responsabilidades, etc.

O Identificación de la semántica de las clases y objetos: el propósito de esta identificación es la de establecer el comportamiento y atributos de cada abstracción que se identifico en la fase anterior.

Como parte del análisis se aplica este paso para asignar las responsabilidades para definir comportamientos del sistema.

Como parte del diseño se aplica este paso para conseguir una clara separación de funciones entre las partes de la solución.

O Identificación de las relaciones entre clases y objetos: su propósito es consolidar los límites del problema. Además formaliza la separación tanto conceptual como física de objetos entre abstracciones.

Como parte del análisis se especifican las asociaciones entre clases y objetos. La expresión de la existencia de una asociación identifica alguna dependencia Semántica entre dos abstracciones.

Como parte del diseño se especifican las colaboraciones, así como el agrupamiento de las clases. Dentro de este paso se obtienen diagramas de clases y objetos, la utilidad principal de estos es que ayudan a visualizar y razonar sobre las relaciones entre objetos y clases.

0 Implantación de clases y objetos: su propósito es el de proporcionar un refinamiento de las abstracciones existentes, además el de crear representaciones tangibles de las abstracciones en apoyo del refinamiento sucesivo.

Durante esta etapa es importante la selección de las estructuras y algoritmos que suministraran la Semántica de las abstracciones obtenidas.


Un punto importante dentro de la misma es la de considerar el uso de herencia, clases parametrizadas, clases abstractas, instanciación, polimorfismo, agregación, etc. y tomar en cuenta los pros y contras de utilizarlas en la implantación; ya que las implantaciones complejas y difíciles o no eficientes solo indican que la abstracción tiene carencias o que no se ha elegido una representación correcta.

5.2 Modelo de solución: Una primera aproximación

De acuerdo a la metodología de análisis y diseño orientado a objetos y al planteamiento del problema, se encontraron como una primera aproximación los siguientes objetos que se obtendrían de una jerarquía de clases:

1) DULP. 2) Maneador de eventos. 3) Maneador de estados. 4) Maneador de acciones. 5) PDU’s. 6) ARTIM. 7) Primitivas.

Todos estos objetos deberían interactuar como se muestra en la figura 5.1:

/ I I I \ \

PROTOCOLO DE EA‘S

DULP

\ \ \ . .

r

TCP / IP

Fig. 5.1. Componentes de DULP.


1) DULP: Como se observa en la figura 5.1, Prácticamente todos los objetos están agregados al objeto DULP, por lo tanto en la interfase con las otras capas la comunicación se daría a través de él.

2) Manejador de eventos: Encargado de detectar los eventos que provengan ya sea de la capa de ACE, de la capa de EA’S o de ARTIM, a traves de las primitivas respectivas. Además tendría que comunicarse con el manejador de estados para indicarle que evento se presentó.

Durante el análisis de los eventos, no dimos cuenta de lo siguiente:

+ 8 eventos involucran la recepción de algún PDU. + 7 eventos involucran primitivas provenientes de las EA’S. + 1 evento proviene de ARTIM. + 3 eventos involucran avisos de la conexión de transporte local.

3) Manejador de Estados: Encargado de controlar los 13 estados de la máquina de estados finitos, indicando siempre el estado actual. Deberá comunicarse con el manejador de acciones, indicándole que acciones deberá ejecutar.

4) Manejador de Acciones: Es el objeto encargado de ejecutar las acciones que le sean solicitadas por el manejador de estados.

En esta parte se decidió, como primera aproximación, que las acciones serán divididas en 4 grupos (como se mencionó en la parte 4.1.2.4.3 de este capítulo), los cuales cada uno estaría representado por una clase la cual heredaría directamente de una clase base llamada “Acciones”.

n ACCIONES

Fig. 5.2. Representación de las acciones.


5) PDU’s: Es el objeto que se encargaría de recibir o formar los PDU’s que llegan o se transmiten a través de la conexión de transporte.

Se determinó que para los PDU’s también se tendría una jerarquía de clases, la cual se muestra en la figura 5.3.

Fig. 5.3. Representacibn de PDU’s.

Esto es, cada uno de los tipos de PDU’s estará representado por una clase, la cual heredaría directamente de la clase base PDU.

6) ARTIM: Es el objeto que representa al temporizador de DULP. Puesto que es el encargado de controlar los tiempos de espera para las peticiones, liberaciones y abortos de las asociaciones; deberá comunicarse con el manejador de eventos y con el manejador de acciones.

7) Primitivas: Se tendrán dos objetos primitivas: las primitivas para la capa de aplicación, que serán las encargadas de comunicar a DULP con el protocolo de las EA’S, esto es, DULP ofrecerá sus servicios a la capa de arriba a traves de las primitivas de aplicación, y las primitivas para la capa de transporte, mediante las cuales, DULP usará los servicios que le ofrece TCP.

En lo referente a la interfase de DULP con TCP, se decidió utilizar ACE por las ventajas que este ofrece, pues como ya se ha mencionado (ver sec. 3.2), ACE implementa un conjunto de patrones de diseño que simplifican el desarrollo de software de comunicación.

Entre los patrones de ACE que se utilizarán para la interfase entre DULP y TCP están el patrón Acceptor, el patrón Connector y el patrón Reactor (sec. 3.2.3, 3.2.4, y 3.2.5 respectivamente), es decir, tendremos un objeto Acceptor, un objeto Connector que utilizan al objeto Reactor, para establecer la funcionalidad de comunicación entre DULP y TCPíIP.


6. DISEÑO

6.1 Herramientas

6.1.1 Patrones de diseño[2]

Dentro de las soluciones a problemas de diseño de software orientado a objetos se encuentran los patrones de diseño.

Un patrón básicamente describe un problema, su solución, en que casos puede aplicarse esta solución y muestra sus consecuencias.

La solución es un arreglo general de objetos y clases que resuelven el problema, adecuandose esta, e implementándola para resolver el problema en un contexto en particular.

Es obvio que un patrón es una solución general a un problema común; además es una técnica que puede ser adaptada y reusada.

Básicamente en este proyecto se hará uso de los siguientes patrones de diseño:

a) Composite[Z]: este patrón se utiliza cuando se tienen objetos compuestos en estructura de árbol. El patrón composite trata por igual a objetos simples y a objetos compuestos.

Este es un patrón de objeto estructural el cual describe como construir una jerarquía de clases para dos tipos de objetos los cuales son simples y compuestos.

Los objetos compuestos pueden estructurarse de objetos simples y de otros objetos compuestos, los cuales a su vez pueden tener una estructura compleja arbitraria, como se muestra en la figura 6.1.


6 (&I (*j Simple Simple Simple

Figura 6, I. Estructura de un objeto compuesto.

b) Iteratofl21: también llamado cursor. Este es un patrón de comportamiento. Proporciona una manera de accesar a los elementos de un objeto agregado secuencialmente sin exponer su estructura o composición interna. De hecho el acceso y recorrido puede ser muy variado, dependiendo de la manera en que se quiera o necesite accesar a ellos.

La clase iterator, define una interfase para accesar los elementos de la lista. Un objeto iterator es responsable de obtener el elemento en cuestión.

c) Mediator[2]: Define un objeto que encapsula la forma en que un conjunto de objetos interactuan. Ofrece un bajo acoplamiento, teniendo de cada objeto que interactua solo su referencia.

Un mediador es responsable de controlar y coordinar la interacción de un grupo de objetos. Los objetos solo conocen al mediador y con esto se reduce el numero de interconexiones.

Este patrón es utilizado principalmente cuando se quiere comunicar un conjunto de objetos de maneras bien definidas pero complejas.

El mediador reemplaza las relaciones de muchos a muchos con relaciones de uno a muchos, entre el mediador y los objetos que interactuan. Además una relación de este tipo es más fácil de mantener y extender.


AL

I

Estructura del patrbn Mediator

6.1.2 C++

C++ es simplemente un lenguaje de programación orientado a objetos. La programación orientada a objetos es una nueva forma de enfocar el trabajo de la programación, toma las mejores ideas de la programación estructurada y las combina con nuevos y poderosos conceptos, que permiten descomponer fácilmente un problema en subgrupos de partes relacionadas. Así, puede traducir estos subgrupos en unidades autocontenidas llamadas objetos.

Todos los lenguajes de programación orientada a objetos tienen tres elementos en común: objetos, polimorfismo y herencia.

Objetos. Un objeto es simplemente una entidad lógica que contiene datos y un código que

manipula estos datos. El enlazado de código y datos de esta forma se denomina encapsulamiento.

Polimorfismo.

permite usar un nombre para varios propósitos relacionados pero ligeramente diferentes. Esto es algo muy importante dentro de la programación orientada a objetos, ya que

El fin del polimorfismo es permitir el uso de un nombre para especificar una clase de acción general. En C++ el polimorfismo se soporta en tiempo de ejecución y en tiempo de compilación.

La sobrecarga de operadores y de funciones son ejemplos de polimorfismo en tiempo de compilación, mientras que las clases derivadas y funciones virtuales son ejemplos de polimorfismo en tiempo de ejecución.

Herencia. Es el proceso por el cual un objeto puede adquirir las propiedades de otro objeto, esto

es importante porque soporta el concepto de jerarquía de clases. Usando jerarquías solo se necesita definir las cualidades que hacen Único a un objeto dentro de su clase.


La herencia es el mecanismo que hace posible que un objeto sea un ejemplo específico dentro de una clase más general.

6.1.3 Clases de Utilería

Una clase de utilería puede representar una colección de subprogramas libres o una clase.

Las clases de utilería usadas en el proyecto serán:

6.1.3.1 Cola

Se implementó una clase llamada cola la cual esta parametrizada para poder insertar en ella datos de diversos tipos.

A su vez se implementó una clase llamada cola-iter la cual hereda de la clase cola, con esta clase se obtiene transparencia en cuanto al uso de la clase cola, para las operaciones de inserción y borrado de la misma.

Se tomó la decisión de hacer uso de esta clase de utilería porque el comportamiento de este TDA (tipo de dato abstracto) cumple exactamente con las características que se necesitan para el desarrollo de algunas partes del proyecto.

El comportamiento radica en que el primer elemento que uno inserta en la cola es también el primer elemento en salir de ella.

6.1.3.2 Buffer

Se implemento una clase llamada buffer, la cual se encarga de almacenar dentro de un arreglo de caracteres la información que se le va indicando.

Esta clase tiene sobrecargado el operador += , el cual puede manejar de igual manera la asignación de un carácter o de una cadena de caracteres.

Cuenta a su vez con una función que recibe como parámetro un apuntador a caracteres sin signo y la longitud del mismo, ya que no pueden guardarse por medio del operador += para el caso de cadena de caracteres, para resolver esto hace uso del operador += pero para el caso un solo carácter en donde va guardando dentro del buffer carácter por carácter que se recibió por medio del apuntador.

Otro operador que fue sobrecargado fue [ ] para que el acceso a los elementos del buffer fuera de manera directa, ya sea para asignación o para consulta.


Un objeto del tipo buffer es responsable de saber su longitud en todo momento, esto se logra por medio de un contador, el cual registra ei tamaño del buffer y se incrementa si la longitud del buffer aumenta.

Se utiliza esta clase debido a que la información que se envía por red debe estar contenida en un arreglo de caracteres, además de que al mandarse por red debe enviarse también el tamaño de dicho arreglo, conociendo este tamaño por medio del contador del buffer.

6.2 Diseño de la interíase con el protocolo EA DlCOM

Como anteriormente se explico la interfase se lleva a cabo mediante el uso de primitivas. El diseño de estas fue tomando en cuenta la siguiente abstracción:

Una primitiva esta relacionada con un servicio y a su vez un servicio con una primitiva, por lo tanto obtuvimos una clase llamada primitiva y otra clase abstracta llamada servicio las cuales están asociadas, la figura 6.2 muestra lo anterior.

Figura 6.2

Dentro de la clase servicio están considerados cualquiera de los tipos de servicio existentes para la capa superior, también mencionados con anterioridad.

Por tanto una primitiva tendrá consigo un identificador que representara el tipo de primitiva que se manejará, así como de una referencia del servicio que está siendo solicitado.

Un objeto de tipo primitiva tiene las responsabilidades de verificar lo siguiente: Si la primitiva es válida de acuerdo al tipo de servicio solicitado.


0 Si el servicio contiene los campos de tipo mandatorio que se especifican en el estándar de DICOM.

Por otro lado los servicio se representan por una jerarquía de clases por herencia, para tener una clase general llamada servicio por medio de la cual se pueden obtener cualquiera de los servicios que se necesiten.

Esta clase es responsable de verificar que los datos que componen al servicio son válidos, tiene al igual que la primitiva un identificador para saber el tipo de servicio del que se trata, a su vez tiene una referencia de la primitiva; estableciéndose una relación de asociación entre ambas clases.

Dentro de los datos o información que conforman algunos de los servicios se tienen uno o mas contextos de presentación, el cual fue representado con una clase que lleva el mismo nombre, esta clase a parte de contar con campos fijos cuenta también con una o mas sintaxis de transferencia.

Para el manejo de los contextos de presentación y sintaxis de transferencia se hizo uso de una clase de utilería llamada cola, en la cual se inserta la información dentro de la cola indicada, es decir si el servicio cuenta con dos contextos de presentación y cada uno de estos tiene a su vez tres sintaxis de transferencia, cada contexto de presentación se inserta en un nodo de la cola de contextos de presentación el cual a su vez contiene una cola de sintaxis de transferencia con tres nodos, en donde en cada nodo se inserta una sintaxis de transferencia.

En otros servicios se tiene una cola de PDV's los cuales se tratan de igual forma que los contextos de presentación y las sintaxis de transferencia, es decir se insertan dentro de la cola cada uno de los PDV's recibidos.

Para la fase de verificación por parte de la primitiva en relación a los datos que componen el servicio es necesario recorrer las colas, para obtener la información contenida en ellas, para esto se implanto el patrón iterator con el cual se recorren las colas siempre de inicio de las mismas al final.

6.3 Diseño de la interfase con el protocolo TCPAP

La interfase con TCP se llevará a cabo con primitivas de transporte, estas serán manejadas por medio del Toolkit de ACE.

Básicamente para el diseño de estas primitivas se tienen las siguientes clases:

Conexión de transporte del solicitante. Propiamente esta clase hereda de la clase Connector de ACE [4 1. Conexión de transporte del proveedor. Hereda de la clase Acceptor de ACE 131, la cual inicia los servicios.

Principalmente estas primitivas servirán para el envío de indicaciones para lograr el establecimiento de la conexión entre el solicitante y el proveedor.


Por tanto el funcionamiento de la primitiva para dicho establecimiento es el siguiente:

Primeramente DULP recibe por parte del solicitante una petición de asociación por lo cual DULP envía la primitiva de petición de conexión de transporte al proveedor. El proveedor recibe esta primitiva como una primitiva de indicación de conexión, posteriormente el proveedor decide si la conexión se acepta o no, y envía una primitiva de respuesta al solicitante. DULP recibe dicha respuesta como una primitiva de confirmación y se lo hace saber al solicitante.

Es importante resaltar que cada vez que el proveedor recibe una solicitud de conexión, anticipadamente se ha generado un objeto DULP; es decir, que por cada conexión se generara dicho objeto. Esto se logra mediante la estrategia de concurrencia que ofrece el Acceptor de ACE. De hecho, dichas clases ofrecen las primitivas necesarias para llevar a cabo la interfase con TCP.

6.4 Diseño del formato de datos (PDU‘s)

El formato de datos que se utilizo fueron los PDU‘s, los cuales se implementaron tomando como base al patrón Composite [2] teniendo los PDU’s la siguiente estructura mostrada en la figura 6.3.

Figura 6.3. Jerarquía de clases para PDU’s.

Se tiene una clase abstracta llamada PDU-FORMAT de la cual heredan todas las subclases. Dentro de esta clase se encuentran todos aquellos atributos en común que contienen los elementos que conforman al PDU, como son un identificador que representa el tipo de elemento, la longitud que tiene dicho elemento y su nombre.

La jerarquía de clases expuesta en la figura anterior muestra que un PDU puede ser un PDU simple o un compuesto el cual a su vez puede tener un item compuesto o un PDU compuesto.


Si tiene un item compuesto este se conforma por items simples y sub-items. Si lo que tiene es un PDU compuesto este puede tener una estructura compleja arbitraria.

De acuerdo a la herencia representada en la figura, las clases PDU-COMPUESTO e ITEM-COMPUESTO heredan de la clase COMPUESTO la cual a su vez hereda de la clase PDU-FORMAT.

Dentro de la clase COMPUESTO existe una cola en la cual se insertan cada uno de los objetos simples o compuestos que componen el PDU.

Por tanto si el PDU es un PDU compuesto, dentro de su cola se insertan los elementos que lo conforman, los cuales pueden ser items compuestos; si este es el caso entonces tendrá en su cola a estos items y dentro de ellos otra cola en donde se insertaran los elementos que conforman al item.

Para las colas utilizadas en la implantación de estos PDU’s nos apoyamos en la clase de utiiería llamada cola, ya descrita con anterioridad.

Cada objeto PDU es responsable de calcular su longitud así como de convertir su información al formato BIGENDIAN.

AI igual que las primitivas, el manejo de las colas en los PDU’s se realizó por medio del patrón iterator 121.

Una vez que el PDU está completo, está información debe almacenarse en un arreglo de caracteres, el cual viajara por red; conteniendo este arreglo todos y cada uno de los elementos que forman el PDU.

Este arreglo se implemento usando la clase de utileria llamada buffer, el cual se llena conforme se iteran las colas del PDU generado, pero siempre siguiendo el orden definido por el estándar de DICOM.

6.5 Diseño de la Máquina de Estados Finitos (MEF)

Para la implantación de la MEF se usará la técnica de construcción de máquina de estados orientadas a objetos [I 31. Dicha técnica usa subclases, composición, delegación, y genericidad; permitiendo crear de una máquina de estados simple una más compleja.

En nuestra máquina solo se usarán subclases y delegación, básicamente se compone de los siguientes elementos:

a) Una clase abstracta ESTADO. Que propiamente es una máquina de estados menos compleja, dentro de esta máquina pueden observarse los siguientes estados de primera generación, como se muestra en la figura 6.3.


Figura 6.3 Máquina de estados finitos simplificada.

Donde cada estado de primera generación tiene asociados ciertos estados, por ejemplo (Fig.6.4), para el establecimiento de la asociación se tiene:

Figura 6.4. Estados derivados de un estado de primera generacibn.

Es decir, los estados 2 al 5 heredan de la clase ESTABLECIMIENTO DE LA ASOCIACION.


b) Mapa de Estados. Cada estado tiene asociado un mapa de estados el cual contiene todas las posibles transiciones que pueden darse para ese estado dependiendo del evento que se recibe.

Para la máquina de estados se plantea lo siguiente (Fig. 6.5):

Fígura 6.5. Mapa de estados.

El mapa de estado es el encargado de instanciar el estado siguiente de acuerdo con el estado actual y el evento recibido, es decir, dentro del mapa se encuentra la acción a ejecutar y se sabe cual es el estado siguiente.

c) Protocolo. Este contendrá un ESTADO ACTUAL que es una instancia de ESTADO, un objeto ARTIM y podrá recibir tanto primitivas de aplicación como primitivas de transporte.

Por tanto, la máquina de estados dentro del protocolo funciona de la siguiente manera:

Primeramente DULP recibe una primitiva ya sea de aplicación o de transporte, encargándose a su vez de determinar cual fue el evento que se suscitó. Posteriormente le da a conocer dicho evento a ESTADO ACTUAL el cual tiene asociado un mapa de estados. A su vez el mapa de estados de acuerdo al estado actual y al evento se encarga de eliminar al estado activo, instancia el nuevo estado el cual será el nuevo estado actual y le da a dicho estado la acción que debe ejecutar.

Cuando es instanciado el nuevo estado, la clase ESTADO es responsable de crear el nuevo estado y de ejecutar la acción que le fue indicada.

Cuando DULP recibe otra primitiva, el proceso anterior se ejecutara nuevamente.


La figura 6.6 muestra los componentes de la MEF.

figura 6.6. Protocolo con su máquina de estados finitos.

Es importante mencionar que los estados asociados a un mismo estado de primera generación tienen el mismo mapa de estados, por esta razón se concluye que hay cinco estados de primera generación y un mapa de estados asociado a ellos; para los trece estados que componen a la máquina existen cinco mapas de estado.


7. RESULTADOS Y CONCLUSIONES

De suma importancia resulto el hecho de conocer y aplicar todas y cada una de las fases del macroproceso así como del microproceso para el desarrollo de este proyecto, ya que en vanas de estas fases hubo la necesidad de retomarlac y hacer cambios, así como refinamientos; para que al final se llegara al modelo propuesto como solución.

Fue un factor relevante el uso del diseño orientado a objetos, ya que permitió proyectar una descomposición del problema en varias partes las cuales por tanto eran más fáciles de resolver. Obviamente como parte del diseño también fue necesario hacer modificaciones en cuanto a la identificación de clases y objetos, relaciones y por ende implantación, por supuesto estas modificaciones se realizaban con fundamentos, logrando con ellas una mejor solución a nuestro problema.

La aplicación de patrones de diseño fue fundamental, ya que las soluciones a las partes que conforman el proyecto se resolvieron en gran medida al uso de estos, de hecho tuvo que analizarse de la gran diversidad de patrones existentes aquellos que resolvían el problema de manera general y posteriormente los adecuamos e implementamos de manera que resolvieran en forma especifica el problema.


GLOSARIO

Clase abstracta: Clase base que hereda otras clases y que tiene por lo menos una función virtual pura.

Clase base: Clase que hereda su estado y comportamiento a sus clases hijas.

Conexión punto a punto: Conexión directa en un sistema de telecomunicaciones entre dos puntos fijos remotos.

DULP (DICOM Upper Layer Protocol) : Protocolo de Capa superior DICOM, el cual es necesario para soportar la comunicación entre aplicaciones DICOM en una ambiente de red.

Estado ocioso: Estado 1 de la MEFD, el cual se encuentra en espera de alguna petición de asociación.

Macroproceso: Marco de referencia que controla al rnicroproceso el cual define una serie de productos medibles y actividades para gestionar el riesgo.

Microproceso: Representa actividades diarias del equipo de desarrollo,

Patrón de diseño: Solución general a un problema común de diseño de software, por medio de un arreglo general de clases que lo resuelven.

PDU (Protocol Data Unit): Es la unidad de datos del protocolo, es decir, por medio de ellos se hace el intercambio de información entre las entidades de aplicación.

Proveedor (Acceptor): Es el usuario el cual recibe alguna indicación de servicio.

Sobre carga de funciones: Cuando dos o mas funciones pueden compartir el mismo nombre, pero su declaración de parámetros es distinta.

Solicitante (Requestor) : Es el que inicializa alguno de los servicios ofrecidos por la capa inferior inmediata.


Bl BLlOG RAFIA

Schmidt, D. C; “The ADAPTIVE Communication Environment: An Objet-Oriented Network Programming Toolkit for Developing Comunication Software”; In Proceedings of the 12th Annual Sun User Group Conference, San José, CA, 1993.

Gamma, E., Helm, R., Johnson, R., y Vlissides, J; Design Patterns: Elements of reutilizable Object- Oriented Software; Addison-Wesley, 1995.

Schmidt, D. C.;“Aceptor: A Design Pattern for Actively Initializing Network Services,” C+ + Report .., 1996

Schmidt, D. C., J;. “Connector: A Design Pattern for Actively Initializing Network Services,” C++ Report, 1996.

Schmidt, D. C.; “The Reactor: An Object-Oriented Interfase for Even-Driven üNiX U 0 Multiplexing (parte 1 de 2),” C++ Report, vol. 5,1993.

Schmidt, D. C. ; “The Object-Oriented Design and Implementation of the Reactor: A C++ Wrapper for UNIX I/O Multiplexing (parte2 de 2),” C++ Report, vol. 5,1993.

Schmidt, D. C.; “IPC-SAP: An Objet-Oriented Interfase to Interprocces Comunicaction Services,” C+ + Report, vol. 4,1992.

Douglas E. C. ; Internet working whit TCPIIP: principles, protocols, and architecture, vol I . Englewood Cliffs, New Jersey; Prentice Ha11,1995.

Douglas E. C. and Stevens D. ;Internet working whit TCP/lP: client-server programing and applications, vol 111. Upper Saddle River, New Jersey.;Prentice Hall, 1996.

Stephen A. R. ; UNLk’ System V: Network Programing;Addicon-Wesley Professional Computing Series, 1995.

B w h G.;Object Oriented Analysis and Design with Aplications (2nd Edition). Redwood City, California.;Addison-Wesley, 1993.


[ 1 I] Booch G.;Object Solutions: Managing the Object-oriented Project. Menio Park, California; Addison- Wesley, 1996.

[ 121 Schmidt, C.; “Pattern Languages of Program Design ”; Addison-Wesley, 1995.

[ 13 1 Sane A. , Campbell R.; “Object-Oriented State Machines: Subclassing, Composition, Delegation, and Genericiíy” ; OOPSLA 95.


UNIVERSIDAD AUTÓNOMA METROPOLITANA- …148.206.53.84/tesiuami/UAM5007.pdf · 3.2.1 Mecanismos IPC...

Documents

Transcript of UNIVERSIDAD AUTÓNOMA METROPOLITANA- …148.206.53.84/tesiuami/UAM5007.pdf · 3.2.1 Mecanismos IPC...