S.F.P. S. E. I .T. D. G . I .T.

CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOLOGICO

cenidet PROTOCOLO DE DlFUSlON TOLERANTE A FALLAS PARA UNA RED DE AREA LOCAL

T E S I S :

QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INGENIERIA ELECTRONICA

ELIAS VARELA PAZ

r

CUERNAVACA, MOR JUNIO DE 1994.

Centro Nacional de Investigación y Desarrollo Tecnológico

ACADEMIA DE LA MAESTRIA DE ELECTRONICA

FORMA R9

ACEPTACION DEL TRABAJO DE TESIS . . . . . . .

Cuernavaca, Mor., 2 ¿Q JVWO \ c''\QqY . . ,

C. Víctor Manuel Alvarado Martinez Jefe de l a Maestría de Electrónica C E N I D E T

,., ..; ,:, ;;ii

Después de .haber revisado el trabajo de t e s i s ti tulado: d e P i S v s i o .. Jlvcs Loc 3 1 ? . f ' -

elaborado por el alumno: \[aye .\% Pl> n

y d i r i g i d o por el C. . C . C a r 1 0 5 (b?am;re+ V ~ \ W . A Z ~ J a 3

el trabajo presentado se ACEPTA ....,iii i i ,

A t e n ' t a m e n t e ,

i, ToleuzGje. a Fa\\= p a v s u a h . ,

, . s

. . ! I : , . . ,

. . . I , < .

C . C . P . : Pres:idente de l a Academia Director 'de Tesis Alumno Tesista . .

' y . .!.

.. , . . . . , :.. . .. . . .

, . . . . . . 2

I < , , , : . '

' ' '. . ' Interior Internado Palrnira S/N C.P 624W Apartado Postal 5-164, C.P. 62050 Cuemavam, Mor. Méxica

- . a - . ma\ i~ 77 A I .. 172) 1 7 7c. 1 1

SPP SISTEMA NACIONAL DE INSTITUTOS TECNOLOGICOS

Centro Nacional de Investigación y Desarrollo Tecnológico

Cuernavaca, Mor., a 2 de j u n i o de 1994.

Ing. E l i a s Varela Paz Candidato a l Grado de Maestro en Ciencias en I ngen ie r í a E lec t r ón i ca P r e s e n t e

Después de haber sometido a . rev is ión su t r a b a j o f i n a l de t e s i s t i t u l a d o :

"PROTOCOLO DE DIFUSION TOLERANTE A FALLAS PARA UNA RED DE AREA LOCAL"

y habiendo cumplido con todas l a s ind icac iones que e l ju rado r e v i s o r de t e s i s l e h izo , se l e comunica que se l e concede au to r i zac i ón para que proceda a l a impresión de l a misma, como r e q u i s i t o para l a obtención de l grado.

Atentamente

3. E. P. P. a. I. 'p. CM.W HkCt&tdJil B f INVEST-

M.C. M a r t - Je fe de l Departamento de Ing. E l

TECHOLOGICO %fMEMlU

c.c.p.- Depto. Se rv i c i os Escolares.

/ rbs

A G R A D E C I M I E N T O S

AL CONACYT Y SEP , que con su determinante apoyo económico, ha fomentado la superación profesional de tantos mexicanos, que como a mí, de otra forma les hubiera sido poco menos que imposible alcanzar esta meta.

AL CENIDET , que con su fraternal ambiente de trabajo y comprensión humana, hicieron menos difícil el cumplimiento de las pesadas jornadas de trabajo académico de la carrera.

AL HE , por el apoyo ofrecido a lo largo de todo el tiempo necesario para la realización de este trabajo.

A la Universidad Autónoma del Estado de Hidalgo, por su actitud paciente para conceder el tiempo y recursos que fueron necesarios durante mi ausencia como elemento de la misma, hasta el momento de mi graduación.

A todos mis compañeros, amigos e investigadores por su amistad y ayuda incondicional.

C O N T E N I D O :

CAPITULO 1.- INTRODUCCION . . . . . . . . . . . . . . . . . . . . Página 4 1.1. ANTECEDENTES- . . . . . . . . . . . . . . . . . . . . . Página 4 1.2. IMPLEMENTACIóN DE LA MEMORIA COMPARTIDA REPLICADA CON BASE

EN UNA RED LOCAL . . . . . . . . . . . . . . . . . . . . Página 7 1.3.- OBJETIVO DE ESTE TRABAJO DE TESIS . . . . . . . . . . . Página 9 1.4.- DESCRIPCION DE LOS CAPITULOS DE LA TESIS. . . . . . . . Página 9

CAPITULO 2.- ALGUNOS PROTOCOLOS DE DIFUSION. . . ; . . , . . . . . Página 10 2.1.- PROTOCOLO DE DIFUCION 1. . . . . . . . . . . . . . . Página 11 2.2.- EL PROTOCOLO DE CHANG Y ~AXEMCHUK. . . . . . . . . . Página 12 2.3.- EL PROTOCOLO TRANS Y TOTAL. . . . . . . . . . . . . Página 13

Página 17 3.1 - PRINCIPIO DEL PDTF. . . . . . . . . . . . . . . . . . Página 17

Página 18 3.2.- TIPOS DE MENSAJE . . . . . . . . . . . . . . . . . . Página 19 3.3.- ESTADOS NODALES . . . . . . . . . . . . . . . . . . . Página 19 3.3.11NICIO . . . . . . . . . . . . . . . . . . . . Página 19 3.3.2 OPERACION NORMAL . . . . . . . . . . . . . . .

3 . 3 . 3 OPERACION NORMAL DEL NODO TOKEN . . . . . ' . . . Página 19 3.3.4 PERDIDA DE UN MENSAJE CUANDO NO SE ES TOKEN . . Página 20 3.3.5 PERDIDA DE UN MENSAJE CUANDO SE ES TOKEN . . . Página 20 3.3.6 CAIDA DE UN NODO . . . . . . . . . . . . . . . Página 20

Página 21 4.1.- PROPÓSITO. . . . . . . . . . . . . . . . . . . . . . Página 21 4.2.- ALCANCES . . . . . . . . . . . . . . . . . . . . . . Página 21 4.3.- FUNCION DE LOS MODULOS . . . . . . . . . . . . Página 21 4.4.- INTERACCION DE LOS MODULOS . . . . . . . . . . . . Página 21 4.5.- LOS SERVICIOS QUE OFRECE EL SISTEMA . . . . . . . . Página 23 4.6.- DESCRIPCION DE LAS VARIABLES USADAS . . . . . . . . . Página 24 4.7.- SERVICIOS DE OTROS SISTEMAS . . . . . . . . . . . . Página 27

4.7.1.- NCB . . . . . . . . . . . . . . . . . . . . . Páaina 27

CAPITULO 3 . - EL PROTOCOLO DE DIFUSION TOLERANTE A FALLAS "PDTF".

CAPITULO 4.- DISEÑO . . . . . . . . . . . . .. . . . . . . . . .

4.7.2.- LLAMADAS A NET BIOS . . . . . . . . . . . . . 4.7.3.- SERVICIOS DE NET BIOS OUE SE USAN EN LAS RUTINAS - -

4.8.- PSEUDOCODIGO . . . . . . . . . . . . . . . 4.8.1 PSEUDOCODIGO GLOBAL . . . . i . . . . 4.8.2 PSEUDOCODIGO DE INICIO . . . . . . . 4.8.3 PSEUDOCODIGO DE RECEPCION . . . . . . 4.8.4 PSEUDOCODIGO DE TRANSMISION . . . . .

4.9.- ESTRUCTURAS DE DATOS . . . . . . . . . . . 4.9.1.- TRAMA DE LOS MENSAJES . . . . . . . 4.9.2.- COLAS . . . . . . . . . . . . . . .

4.9.2.1.-' COLA RECEPfORA DE MENSAJES 4.9.2.2.- COLA DE TRASMISION . . . .

4.9.3.- VARIABLES DE ESTADO. . . . . . . . 4.9.4.- ESTRUCTURA DE EXTREMOS . . . . . . 4.9.5.- ESTRUCTURA DE LIGAS . . . . . . . . 4.9.6.- NETWORK CONTROL BLOCK. . . . . . .

4.10.- SATURACION DE COLAS . . . . . . . . . . 4.11.- ARBOL DE RUTINAS . . . . . . . . . . . . .

4.11.1.- DESCRIPCION DE RUTINAS . . . . . . 4.12.- INTERFAZ DE USUARIO . . . . . . . . . . .

4.12.1.- Inic() . . . . . . . . . . . . . . 4.12.2.- Trans(*Buffer, num) y Query-Tx(). 4.12.3.- Recep(id-f, *Buffer). . . . . . . 4.12.4.- Info(int var) . . . . . . . . . .

Página 1

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

Pagina 28 Página 28 Página 29 Página Página 29 30

Página 30 Página 33 Página 34 Página 34 Página 36 Página 36 Página 40 Página 41 Página 41 Página 42 Página 44 Página 44 Página 46 Página 48 Página 49 Página 49 Página 49 Página 50 Página 50

. . CAPITULO 5 . . PRUEBAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.- PRUEBAS PARA~EL NODO'TOKEN . . . . . . . . . . . . . 5.3.- PRUEBAS GLOBALES . . . . . . . . . . . . . . . . . . . 5.1.- PRUEBAS PARA No TOKEN . . . . . . . . . . . . . . . . . .

CAPITULO 6 . . EVALUACION . . . . . . . . . . . . . . . . . . . . . 6.1.- COMPARACION CON OTROS PROTOCOLOS . . . . . . . . . . 6.2.- TIEMPO DE RESPUESTA . . . . . . . . . . . . . . . . .

CAPITULO 7.- CONCLUSIONES . . . . . . . . . . . . . . . . . . . . CAPITULO 8.- REFERENCIAS . . . . . . . . . . . . . . . . . . . .

Página 52 Página 54 Página 64 Página 71

Página 72 Página 72 Página 73

Página 76

Página 78

a

Página 2

RELACION DE FIGURAS

No . DE FIGURA NOMBRE DE LA FIGURA .PAGINA

1

2

3

4

5

6

7

8

9

10

11

1 2

SISTEMA DE COMPUTO CON MEMORIA COMPARTIDA ..................... 5

RED

CAPAS DEL SISTEMA COMPLETO .................................... 8

MODELO CONCEPTUAL DEL SISTEMA .................................. 8

RELACION ENTRE LA PRECEDENCIA DENTRO DEL ORDEN

DE AREA LOCAL .............................................. 8

PARCIAL Y LOS RECONOCIMIENTOS ................................ 16

CONFIGURACION PUNTO A PUNTO .................................. 10

RELACION DE LOS MODULOS DENTRO DE LA SUBCAPA ADICIONADA ................................................... 22

TRAMA DE LOS MENSAJES A NIVEL DEL PROTOCOLO DE DIF.SION .................................................. 35

ESTRUCTURA DE LA COLA DE RECEPCION ........................... 37

ESTRUCTURA PARA LAS LIGAS DE LISTAS .......................... 38

ESTRUCTURA DE ELEMENTOS EXTREMOS ............................. 4 1

ESTRUCUTRADELIGRMENTOS ..................................... 4 3

.......

CAPITULO 1.- INTRODUCCION

1.1. ANTECEDENTES.

La motivación particular de este trabajo satisface una necesidad contemplada en un proyecto de tecnología de sistemas para la supervisión y control de procesos industriales, aplicado a generación de energía eléctrica, el cual es de gran interés dentro del Instituto de Investigaciones Eléctricas, IIE, de Cuernavaca Morelos.

,:

i Las arquitecturas de estos sistemas de control, están basadas en la inclusi6n de

varias coniputadoras donde se alojan las diferentes funciones; por lo cual se les denomina sistemas distribuidos. i

i En el IIE se han desarrollado sistemas de adquisición de datos para la

supervisión de Centrales Termo-Eléctricas (CTE) ; sin embargo, en las arquitecturas [ usadas únicamente se tiene distribución de las funciones de adquisición de la I información de campo (señales de transductores) empleando para ello varios Módulos de Adquisición (MA) basados en el equipo de la Línea SAC del propio IIE.

1 I En otros proyectos también se han distribuido las funciones de control empleando

el mismo tipo de equipos, teniéndose así Módulos de Control (MC) . Para la implantación de las funciones de presentación de información al usuario y de recepción de sus comandos se emplean terminales de video con teclados dedicados y teclados alfanuméricos esthdar y en algunos sistemas elementos especiales cama el "Ratón" o el "Track ball". Estos dispositivos son Únicamente los mediae de interfaz con el usuario del sistema y normalmente están controlados por una computadora (empleando varios puertos de entrada/salida a la misma), que además controla.todas las funciones del sistema, lleva registro de la información adquirida y de los eventoe ocurridos y genera reportes que pueden ser impresos. La tendencia es también el distribuir las funciones de IHM y control del sistema en varias computadoras más pequeñas a fin de reducir costos e incrementar la modularidad y la fiabilidad del sistema (expresada como una disponibilidad mayor al 99 % ) ; esta es la mot.ivación básica para el sistema que se desea implantar.

1 /

Las funciones básicas de un sistema de control y supervisión de procesos son:

* Conexión al proceso (CAP). * Adquisición de información analógica ( A I A ) . * Adquisición de información binaria (AIB). * Monitor de secuencia de eventos (MSE). * Control analógico (CAN). * Control lógico (CLG). * Historia (HST). * Alaivmas (ALM) . * Enlace Sistema - Usuario (ESU). * Ingeniería de control (ICN).

Página 4

Estas funciones se dividen en sub-funciones [l], entre las cuales se puede establecer el flujo de información entre ellas [ 2 ) . Esto permite proponer la implantación del sistema en forma distribuida en 'los nodos de una red de área local de computadoras [ 3 ] estableciendo el flujo de información entre los nodos de la red, o empleando varias computadoras con una memoria cornparti-da ( 4 1 .

MEMORIA COMPARTIDA i

Una forma de simplificar el flujo de la información entre funciones (y por tanto sus diagramas, diseño e implantación) es el incluir un grupo de estructuras de datos (Base de Datos) donde se almacene y consulte toda la información que fluye; esto se convierte en un cuello de botella para algunas aplicaciones.

Una característica importante de las funciones del sistema de supervisión y control ea que éstas se pueden clasificar en forma general en tres tipos: las generadoras de información (p.e. Adquisición), las consumidoras de información (una vez que la leen es eliminada de la estructura donde se localiza, p.e. la función Alarmas) y las que sólo consultan la información (el resto de las funciones, p.e. Mímicos); por tanto, el empleo de una base de datoa resulta alentador.

La base de datos puede ubicarse en una memoria compartida (Fig. 1); ya sea física o simulada. Existen varias formas de implantar una memoria compartida entre varias computadoras; una es utilizando una memoria física común a todos los procesadores, otra es emularla con base en una red local [ S I , una tercera opción, intermedia entre las anteriores, se presenta en [ 4 ] . En un sistema distribuido basado en'una red local se puede definir una zona de memoria como Memoria Compartida y se utilizaría la difusión de mensajes para la actualización de la información en los distintos nodos (donde se implantan las funciones del sistema), emulando así una Memoria Compartida Replicada.

Página 5

ACUSES DE RECIBO

LJ

PRECEDENCM

FIG. 5 Relación entre la precedencia dentro del orden parcial y los acuses de recibo.

U

Con ello se logrará un requisito para un sistema distribuido tolerante a fallas, que es proporcionar de manera transparente al usuario (que en este caso será el diseñador de las funciones üel sistema de supervisión y control) estructuras cuyo contenido se mantenga replicado (en forma idéntica y simultanea) en todos los nodos de la red; esto es, una Memoria compartida Replicada (MCR).

@ 1.2 IMPLEMENTACIÓN DE LA MEMORIA COMPARTIDA REPLICADA CON BASE

EN UNA RED LOCAL

Se propone el empleo de una red de área local (LAN) con un protocolo estándar ("Ethernet") como base para la implantación de la MCR, ver Fig. 2 .

En particular, el empleo de un protocolo de difusión basado en el estándar 802.3 "Ethernet" se ve como la solución para implantar la MCR; ya que, permite que un mensaje generado desde un nodo sea recibido por todos los nodos de la red "simultáneamente". Sin embargo, en uno o más nodos pueden ocurrir eventos que no permitan la recepción del mensaje (por que no hay espacio para recibirlo o por que se descartó debido a la detección de un error en la transmisión). Esta incertidumbre de la recepción implica el uso de un protocolo de difusión más confiable que los simples "Datagramas" del Ethernet.

Para el sistema que se desea implantar se considerará que una vez que se reciben los mensajes por el nivel de funciones que maneja la MCR, éstos son procesados sin error e inmediatamente. Esto implica que si en todos los nodos se recibe un mensaje simultáneamente, la MC se actualiza síncronamente, al menos para propósitos prácticos, y reduce el problema de sincronización al propio del protocolo de difusión.

El sistema requiere que se desarrolle una capa más sobre el SO y sus servicios de red; que permitirá el uso directo de sus servicios de Memoria Compartida. De esta manera, las aplicaciones que implantarán las funciones serán soportadas por la capa de servicios de manejo de estructuras de datos comunes tipo arreglo (BDTH [5]), además de todos los servicios del SO; una representación se muestra en la Fig. 3 .

Cada una de las 'divisiones en la Fig. 3 representa la interfaz entre capas, la cual se traduce a un conjunto de servicios que ofrece la capa inferior a la del siguiente nivel; por ejemplo, los servicios de suspensión y reactivación de tareas del SO, o el servicio de consulta de un dato de la BDTR. Las tareas de una capa siempre tendrán acceso a servicios de las capas inferiores y no sólo de la inmediata. Esto permite que las tareas de aplicación vean estruct.uras de datos comunes sin importar en que computadora están ubicadas, lográndose así el modelo de la Fig. 1. Una representación integrada de estos conceptos se muestra en la Fig. 4.

Página 7

FIGURA 2 - RED DE AREA LOCAL.

PROGRAMAS DE APLICACION I I 2

Tarea i Tarea j Tarea k .. .. 6

( I 1 V V V

MC MC .......... MC

- SO so BDTR = MC

SISTEMA A DESARROLLAR (BDTR) (MC)

SISTEMA OPERATIVO (SO)

EQUIPO DE COMPUT0,EN RED

FIGURA 3 - CAPAS DEL SISTEMA COMPLETO.

FIGURA 4 - MODELO CONCEPTUAL DEL SISTEMA.

Página 8

1.3.- OBJETIVO DE ESTE TRABAJO DE TESIS

Este trabajo se concreta al diseíio e implantación de un protocolo de difusión, que permita, entre otras aplicaciones, la emulación de una Memoria Compartida Replicada en cada nodo (área de memoria localizada en cada PC de LAN). Para esto se requiere que dicho protocolo de difusión sea tolerante a fallas.

1.4.- DESCRIPCION DE LOS CAPITULOS DE LA TESIS.

En el capítulo 1 se han presentado los antecedentes que originaron la necesidad del trabajo de esta tesis, así como una descripción somera de las Características más importantes que debe tener el mismo, señalando la aplicación inmediata que puede darse a este trabajo dentro de un proyecto mayor.

En el capítulo 2 se lleva a cabo un análisis de algunos protocolos encontrados en la bibliografía para tomar ideas para el desarrollo de un Protocolo de Difusión Tolerante a Fallas, que cumpla con las exigencias mencionadas y que se describe al final del mismo capítulo.

En el capítulo 3 se presenta el protocolo propuesto a un nivel más detallado, en el cual se describen los métodos para dar tratamiento y solución a los estados adoptados por los diferentes elementos de la red. Se describe en s í la operatividad del protocolo, haciendo hincapié en ,los aspectos relacionados con los mecanismos de recuperación.

El capítulo 4 está dedicado al diseiio del software para implantar el protocolo, en el cual se describen con detalle los módulos de que consta, su funcionamiento y la relación que guardan entre s í . Se describen, así mismo, las estructuras de datos en las que se apoya el funcionamiento. También se explica la operatividad de todo el sistema visto como una capa más de eervicio.

En el capítulo 5 se presenta una evaluación del protocolo implantado basada principalmente en las mejoras motivadas por las características de la aplicación.

Página 9

CAPITULO 2 . - ALGUNOS PROTOCOLOS DE DIFUSION.

Dentro de una red de computadoras el flujo de la información se logra mediante transferencia en "bloques" o agrupamientos de caracteres que, desde el punto de vista del transporte, son independientes. Cuando uno de'los nodos de la red efectúa un envío de este tipo, puede ser necesario que el'transmisor se entere del éxito o fracaso de la recepción de ese mensaje, por parte del receptor, por ejemplo en los casos en que se pretenda asegurar la captura de los mensajes, se programa un reenvlo para aumentar la certeza en la recepción. Si se pierde el mensaje otra vez, .la acción correctiva se repite hasta que la recepción tenga éxito o se fracase un cierto número de. veces predeterminado.

FIGURA No. 6 CONFIGURACION PUNTO A PUNTO

Por ejemplo, sea el nodo "A" de la figura NO.'^ un elemento que transmite un mensaje al nodo "B" y que este último no lo recibe. Entonces, si se desea que " A" repita el mensaje cuando "8" no lo reciba, es necesario que "€3" mande otro mensaje de acuse de no recibo (esta vez de "8" hacia "A") para que "A" proceda a repetir la transmisión del mensaje. En caso contrario, "6" mandaría un mensaje de acuse de recibo para que "A" no repita esa transmisión.

Aquí se empieza a notar los requerimientos de un prOtOCOlo de comunicación, que en este caso se relaciona con el sistema más elemental de red: "punto a punto". Sin embargo, cuando se tiene un gran níimero de nodos, los Cuales pueden mandar mensajes hacia todos los demás nodos en difusión, el protocolo es conocido como "Protocolo de Difusión" y el manejo de los mensajes de conEirmación se torna complicado o lento.

De cualquier forma, esos mensajes de confirmación (acuse de recibo o de no recibo) consumen tiempo en el uso de la red, dejando para los mensajes de información un espacio significativamente reducido. De esto se desprende la necesidad de encontrar un método que minimice el uso de la red, dedicado a este tipo de mensajes, para destinar el máximo de tiempo posible a los mensajes de información, sin menguar la confiabilidad que las comunicaciones cobran con el uso de los primeros.

Una forma de reducir el número de mensajes de confirmación es el empleo de mensajes solamente en casos en que la recepción no resulte exitosa, ahorrándose los mensajes de recepción exitosa que se espera sean los más numerosos. A continuación se descrihe un protocolo de estas características.

Página 10

2.1 PROTOCOLO DE DIFUSION 1.

Este protocolo es muy sencillo, se basa en tener un acuse de no recibo de los nodos receptores, que únicamente será transmitido cuando el mensaje relacionado no sea capturado por algún receptor. Para ello a cada mensaje se le asocia un identificador foirmado por el nodo fuente y un número secuencia1 de inensaje. De esta manera, cuando un nodo recibe un mensaje cuyo identificador no coincide con el esperado, el nodo receptor solicita la retransmisión de todos los mensajes entre el último recibido y el que está recibiendo.

Se considera que cuando la aplicación solicita el envío de algún mensaje, este se deposita en una cola circular de donde será tomado para su transmisión. De tal manera que se tendrán dos apuntadores, uno para la inclusión de rnensajes.y otro para la toma de mensajes a transmitir. L o s mensajes más viejos se irán perdiendo cuando esté llena la cola y se incluya un nuevo mensaje, pero únicamente cuando ya hayan sido transmitidos al menos una vez. El nodo .dará prioridad a la recepción de mensajes sobre la transmisión.

La ventaja de este protocolo es que es muy sencillo, aunque se debe llevar un registro del identificador del último mensaje para cada nodo de la red. Sin embargo, cuando 6e entra en una fase de recuperación, su principal desventaja es que no se asegura la misma secuencia de recuperación de los mensajes retransmitidos.

Para disminuir los defectos de este protocolo es necesario un protocolo más completo, el cual asegure la entrega de los mensajes en el mismo orden en todos los nodos, aun en casos de recuperación.

Existen en la literatura varios protocolos de difusión tolerantes a fallas, de los cuales se analizarán los que se proponen en [ 6 ] , 1 7 1 y (81. En seguida se presenta un resumen de estos protocolos'. En esta descripción, se ha traducido la palabra "Positive Acknowledgement" como "Acuse de Recibo" que representa la acción de retornar un mensaje de enterado por efectos de otro mensaje principal ya recibido. Por otro lado, la palabra "Negative Acknowledgement", que representa un aviso de No Enterado, se tradujo como "Acuse de No Recibo".

Página 11

2 . 2 . - EL PROTOCOLO DE CHANG Y MAXEMCHUK.

El protocolo propuesto en [6], divide las funciones de comunicación en dos partes. Primeramente establece la transmisión de mensajes desde todos los nodos hacia uno maestro "Token Site", con acuse de recibo teniéndose varios transmisores y un solo nodo receptor (maestro). Inmediatamente después se complementa el ciclo de comunicación mediante la difusión de mensajes.desde el nodo maestro' a los demás, basándose en mensajes de acuse de no recibo, teniéndose un solo nodo transmisor (maestro) y varios receptores.

,,

Cuando se lleva a cabo la difusión desde el nodo maestro a todos los demás, se debe cumplir la transmisión en la misma secuencia con que fueron saliendo desde su nodo origen. Para esto, se usan códigos identificadores de nodos fuente y destino, así como un número de secuencia correspondiente. De esta forma, se puede conocer el lugar que le corresponde a cada mensaje de cada nodo dentro de todo el flujo de transmisión.

Conforme los mensajes se reciben en los nodos destino, se verifica que el número de secuencia sea el esperado. Si por algún motivo el nímero del mensaje recihido estuviera fuera de secuencia, el nodo receptor transmitiría un mensaje de solicitud de retransmisión al nodo maestro. La retransmisión de mensajes será responsabilidad del maestro, que emprenderá la retransmisión desde el mensaje cuy0 número secuencia1 esperaba el receptor solicitante.

Con el fin de que no caiga la responsabilidad del "maestro" solo en un nodo, dicho cargo se va transfiriendo periódicamente a otros nodos activos que tengan facultades de poder desempenar esta función. Esto se hace de manera periódica o en el momento en que se detecta una anomalía en el desempeño del maestro, cuando la pérdida de sus mensajes se manifieste en una respuesta incorrecta o nula ante un reclamo de retransmisión. La transferencia del "Token" siempre se lleva a cabo mediante un mensaje de acuse de recibo rutinario, es decir, dentro de un mensaje de acuse de recibo se instala la solicitud de cambio de "Token" y subsecuentemente, otro mensaje de acuse de recibo originado por el nuevo nodo maestro, será la respuesta afirmativa de aceptación, en caso de que no haya flujo de mensajes en ese momento. Cuando exista actividad para el "token site" (por haber flujo de mensajes), el funcionamiento normal del nuevo nodo maestro como tal, se interpreta como aceptación del cargo.

Constantemente se mantiene una lista de "L" nodos "candidatos" para hacerse cargo del "token". Esta lista llamada "Token List" la integran los "L" nodos de la red que retengan el total de los mensajes difundidos desde los nodos fuente. El "token site" se va rolando entre L nodos, y manteniendo los mensajes (sin pasarlos a la aplicación) hasta que L + 1 nodos han recibido el token. Esto asegura que todos los mensajes que se han pasado a la aplicación puedan ser recuperados en caso de hasta L fallas; se dice que el protocolo es "L-Resistente". Dicho sea de paso que esto impone un retraso en la recepción de los mensajes por la aplicación.

Página 12

Para ser miembro de la lista, los nodos candidatos deberán cumplir con las condiciones de: ser nodo activo, integrar en la lista la mayoría de nodos, tener posición de turno (el siguiente en la lista deberá ser el usado más antiguamente), contener todos los mensajes que pueden ser pedidos..Para esto, en el momento de dar de alta una nueva lista, deberá pasar por tres pruebas: de mayoría, de secuencia y de resistencia.

Entre los nodos disponibles para tomar el. "token", se designa al siguiente de la lista, e inicia su cargo emprendiendo la retransmisión solicitada, en su caso. De cualquier manera, periódicamente el "token site" deberá'enviar mensajes de acuse de recibo para solicitar reemplazo, aunque no haya mensaje difundido que lo reclame [en este caso se tienen mensajes de acuse de recibo nulos).

2.3.- EL PROTOCOLO TRANS Y TOTAL.

La propuesta hecha en [ 7 ] , se apoya en el análisis de un protocolo de difusión llamado "Trans" de ordenación parcial de los mensajes, para explicar después otro de ordenación total.

El protocolo TRANS usa una combinación de mensajes de acuse de recibo y de no recibo (confirmación positiva y negativa) para tratar de alcanzar la confiabilidad en aplicaciones de difusión, en que los mensajes pueden ser difundidos simultáneamente a todos los nodos o a varios'nodos (multicast) de la red sin tener que acusar recibo por cada mensaje de parte de cada'uno de los receptores. Una característica de este protocolo, consiste en la transmisión de los acuse de recibos por medio de la técnica, que consiste en dar una respuesta intercalada en el siquiente mensaje de la serie que transmite el nodo receptor.

Se apoya también en dividir la red en varias sub-redes de la LAN para aprovechar algunas características de redes mayores ya existentes, aquí no se requiere de un nodo token.

Para disminuir el número de mensajes de acuse de recibo originados por los nodos que opera como se destino, se emplea una estrategia de acuse de recibos difundidos,

explica en el siguiente ejemplo:

- El procesador P difunde un mensaje. - El mensaje de ese procesador es recibi.do por el procesador Q. - El procesador Q incluye un acuse de.recibo de ese mensaje en su transmisión. - El procesador R en recepción del mensaje de Q se entera de que el mensaje de P ya ha sido reconocido (por medio del acuse de recibo) y no hay necesidad de que R reconozca a dicho mensaje. En vez de ello, R transmite un acuse de recibo por el mensaje que acaba de enviar Q.

P cuando recibe el de Q y entonces emite un mensaje hacia P para reclamar la retransmisión correspondiente.

- R se entera que no ha recibido el mensaje procedente de

Página 13

Para establecer el orden parcial, este protocolo se basa en los postulados:

a) Propiedad de entrega eventual "Eventual Delivery Property" cuyo enunciado dice que si cualquier procesador activo ha recibido o difundido un mensaje, entonces dicho mensaje ha sido recibido por todos los procesadores.

b) Propiedad de entrega previa "Prior Reception Property", que establece que si el mensaje C se incluye en el orden parcial, entonces en el momento en que el procesador Pc difunde el mensaje C, él ya ha recibido (directa o indirectamente) todos los mensajes que preceden a C, y ha enviado el acuse de recibo correspondiente.

Por 'otro lado, si definimos Predicado Observable para Entrega "Observable Predicate for Delivery", denotado por OPD(P,A,C), a la situación de que el procesador P puede estar seguro de que el procesador que difundió el mensaje C ha recibido y reconocido, directa o indirectamente, el mensaje A en el momento de la difusión de C. Entonces tenemos la definición del Orden Parcial:

En el orden parcial determinado por el procesador P, el mensaje C sigue al mensaje B

OPD(P,R,H) implica OPD(P,A,C). si y solo si OPD(P,B,C) y, para todos los mensajes A;

Para ilustrar el establecimiento del orden parcial, veamos el siguiente ejemplo: La parte izquierda de la figura 5 representa los acuses de recibido y no recibido ("ACK positivos y negativos) que presentan los mensajes entre s í , los primeros representados por una línea gruesa y los segundos por una línea tachada continua. Por otro lado tenemos en la parte derecha de la misma figura la representación del orden parcial derivado de los acuses de recibo que se ilustran en la parte izquierda.

El establecimiento del orden parcial se deduce a partir de los postulados descritos arriba. viendo la parte derecha, el mensaje C1 no precede al mensaje Al (dentro del orden parcial) porque Al precede a D1 y el procesador Pc no ha recibido aun a Di cuando difundió C1 (según la figura izquierda). Pero C2 si precede a Al porque Pc recibió la retransmisión de D 1 cuando él difundió C2. Análogamente, B2 no precede a C2 porque C2 precede a Al cuyo procesador Pb no ha recibido 82 en el momento de la difusión de B2. En cambio, 82 precede a U2 porque Pb recibió 02. Los postulados mencionados no son explicados a fondo ni demostrados en este artículo.

El propósito del protocolo TOTAL es alcanzar cierto grado de tolerancia a fallas estableciendo un orden total en los mensajes y todos los procesadores activos, asegurando que todos los procesadores reconozcan el mismo orden total.

DEFINICION: un mensaje candidato es aquel mensaje que se encuentra ya localizado dentro del orden parcial y que está a punto de pertenecer al orden total.

Página 14

Como la red se divide en sub-redes, se producen mensajes procedentes de cada subconjunto de nodos, este subconjunto de mensajes es conocido como "subset" (subconjunto) y debe ser considerado como una unidad completa para asignarle un determinado lugar en la secuencia total.

La manera de aceptar un mensaje en el orden total se basa en las votaciones que otros mensajes dentro del orden parcial emitan a favor del subconjunto correspondiente. Estas votaciones son emitidas de acuerdo a las consideraciones siguientes:

a) Un mensaje perteneciente a det-erminado subconjunto de mensajes, puede votar por los otros mensajes de su mismo subconjunto (también poi- s í mismo).

b) Se votará por un mensaje siempre y cuando el mensaje vot.ante esté dentro del número de mensajes votantes requeridos por el criterio de mayoría.

c ) Si el mensaje candidato no,precede a algún mensaje perdido detectado por el nodo votante.

Para incluir a un mensaje en el orden total, se lleva a cabo un proceso de decisión por parte de algún procesador, en base a las votaciones de un número suficientemente grande de mensajes votantes precedentes (criterio de mayoría), dentro del orden parcial.

El número "suficientemente grande" de votos, esta dado por las expresiones siguientes:

RESISTENCIA Nd

1 2 k < n/3

Donde "n" es el número'de elementos votantes, en total. "k" es un número mayor de resistencia, "Nd" es el número suficiente de votos para la inclusión,

Página 15

EJEMPLO: Si un sistema de n = 10 procesadores trabaja con una resistencia de "l", entonces el número requerido de mensajes para ser incluido en el orden total, es:

(n+2)/2 = (10+2)/2 = 6

Esto significa que si el primer mensaje vota por el grupo en el que él mismo se encuentra, para este caso se requieren u n número de cinco mensajes procedentes de cinco diferentes procesadores para que sea incluido como primer elemento y comience la secuencia de orden total.

Con base en los protocolos anteriores y tratando de superar deficiencias de velocidad o reducir la complejidad se sugiere el protocolo de difusión descrito a continuación.

Página 16

CAPITULO 3 . - EL PROTOCOLO DE DIFUCION TOLERANTE A FALLAS "PDTF"

El protocolo definido en [6] selecciona entre los nodos activos de la red uno asignándole un "token" (nodo maestro o nodo token). Este nodo recibe todos los mensajes a los que corresponde con un mensaje de acuse de reciho (varios nodos transmisores y uno receptor); este nodo retransmite el mensaje a todos los'nodos asignándole un número de secuencia global (un nodo transmisor y varios receptores).

Cuando un nodo recibe un mensaje cuyo número secuencia1 no corresponde, envía al nodo token un mensaje de acuse de no recibo; de esta manera, el nodo token es responsable de retransmitir los ,mensajes que perdió el nodo en cuestión. Esa retransmisidn la hace en el miamo,orden con que los recibió. El "token" se va rotando periódicamente entre los nodos, de'la red, pero ai falla el token en turno, se procede a reemplazarlo de sus funciones de "Token". Esta maniobra, como se explicó en su momento, resulta morosa y compiicada.

I 3.1 - PRINCIPIO DEL PDTP.

En el PDTF propuesto, todos los nodos llevan el registro de los mensajes recibidos; de esos nodos, uno'es nodo token y sólo cuando éste falla, otro nodo toma su lugar. Además, como los mensajes se transmiten en difusión, éstos no eon retransmitidos (al destino) por el nodo token. En vez de esto, el nodo fuente le asigna un identificador local a cada mensaje; al recibirlo, el nodo token le asigna un identificador global único (secuencia global). El nodo token difunde un acuse de recibo que incluye ambos identificadores del mensaje, el local y el global. El nodo fuente al recibir el acuse considera que los demás nodos eventualmente recibirán el mensaje. Esto evita la retransmisión del mensaje por el nodo token, como en el protocolo definido en 161.

El nodo fuente n o transmite otro mensaje hasta recibir el acuse de recibo del nodo token al mensaje previamente enviado; más aun, si esto no ocurre en un determinado tiempo deberá retransmitir el mensaje. El proceso se repite hasta M veces y si el acuse no es recibido, se dará por caído al nodo token y se emprenderá una fase de reasignación del nodo toktin. Todos los nodos de la red pueden intervenir como candidatos a nodo token, eligiéndose al que tenga el número de secuencia global mayor.

Página 17

I

'El proceso de reasignación del nodo token inicia con un mensaje especial difundido por cualquier nodo (el primero que detecta la caída del anterior nodo token). Este mensaje contiene el identificador del nodo y el Último número de secuencia global poseído. Los demás nodos al rekibir el mensaje comparan el número de secuencia global recibido con el que ellos tienen para saber su aptitud de competencia, si el suyo resulta superior, enviará un.mensaje análogo que reemplaza al anterior, y lo coloca en ventaja respecto al primer canhidato. De otra manera, si su número de secuencia global resulta ser inferior al del mbnsaje, se reconoce no-apto y entra a una fase de espera para permitir que los otros nodos de mejores facultades lo manifiesten. Esta fase consume algún tiempo porque reclama el procedimiento de reasignación que permite tener en el puesto de token al nodo r de mej.or "estado actual de mensajes"; sin embargo, como se efectúa sólo en casos de nodo token caído, representa .al final un retardo similar que el mencionado en [6]. Ellmanejo de la secuencia global es más sencillo que el utilizado en [7]. Respecto a l!a complejidad, en el PDTF propuesto es menor que en los protocolos estudiados [ 6,7]. ~

3.2.- TIPOS DE MENSAJE I

I

Los tipos de mensaje que se manejarán se identifican con una letra y son los siguientes: I

l a) "D" (Difusión) que cokresponde a los mensajes "normales" de comunicación y que contienen la informacióh de interés para la aplicación.

b) "N" que se refiere a~ un mensaje de acuse de no recibo.

I

c) "P" que se refiere a! un mensaje de acuse de recibo.

d) "I" (Acuse de recibo de Inicialización) que emite el nodo token para manifestar haber dado de alta un nodo en el sistema de red.

l

e) "i" (inicialización) ~enviado,por algún nodo que desea incorporarse al sistema, para que el nodo token 110 dé de alta.

f) "E" (Error) trancmitkdo por el nodo token hacia algún otro nodo que pierda su secuencia lógica de medsajes y no pueda ser recuperada.

9) token en casos de caída o mal funcionamiento del nodo token.

"T" (Destitución de; Token) que es para propiciar la reasignación del nodo

Página 18

3 . 3 . - ESTADOS NODALES ~

Durante el funcionamiento del protocolo, cualquier nodo puede asumir alguno de los siguientes estados: inicio, operación normal, operación normal como nodo token, pérdida de un mensaje cuando no se es token, pérdida.de u n mensaje cuando se es token y caida de un nodo. La descripción formal del protocolo se presenta en la Sec. 4 . 8 Pseudocódigo.

3.3.1 INICIO

~i iniciar la operaciónide la red de un nodo enviará un mensaje tipo i; esperará un cierto tiempo la contestactón del nodo token con el mensaje I. Al recibirla entrará a la red, pero si no la recibe reintentará hasta N veces y si no lo logra asumirá que es un arranque en frío (primero) de la red e iniciará la fase de reasignación del nodo token enviando el mensaje tipo T.

3 . 3 . 2 OPERACION NORMAL

Este estado se refiere a las condiciones normales de comunicación de un nodo que transmite y recibe mensajes. Consi’ote en todas las acciones que implica la transmision de cada mensajes desde un nodo fuente (incluido el nodo token), hacia todos los demás, su correspondiente identificacióii global por conducto del nodo token, que envía el mensaje de acuse de recibo, y la consiguiente validación por todos los nodos, emisor y receptores, que recihen el mensaje de acuse de recibo y por lo mismo pueden pasar el mensaje del nodo fuente a 1a.aplicación. Además de procesar los mensajes tipo D y P, también considera los tipo I y T. Los mensajes tipo E sólo los procesa si van dirigidos al propio nodo y se deben a una solicitud de retransmisión fallida. Los mensajes de otro tipos los desecha. Si s,e recibe un mensaje tipo ‘OD” retransmitido por el nodo token, como respuesta a una solicitud desde otro nodo que perdió mensajes, simplemente se desecha el mensaje. I

3 . 3 . 3 OPERACION NORMAL DEL NODO TOKEN

El nodo token, además de operar como cualquier nodo que emite y recibe mensajes, es responsable de la emisión de los mensajes de acuse de recibo (tipo P ) asignándoles el número de secuencia global. esta función es de mayor prioridad que la emisión de los mensajes de las aplicaciones residentes en el nodo. Cada que recibe un mensaje tipo D (incluidos los generados por este nodo) genera el mensaje tipo P correspondiente. Cuando recibe mensajes tipo N, los cuales incluyen el número de secuencia global del Último mensaje recibido por e; nodo solicitante, deberá retransmitir todos los mensajes tipo D a partir del siguiente número de secuencia global del recibido. En caso de que ya no los conserve, enviará un mensaje tipo E al nodo solicitante indicándole así que no es posible recuperar los mlnsajes. Cuando recibe un mensaje tipo i de parte del nodo solicitante, contesta.con un mensaje tipo I que contiene el identificador del nuevo nodo dado de alta. Este mensaje también lo reciben todos los nodos para llevar registro de nodos activos. El mensaje :tipo T lo procesa como cualquier nodo de la red; esto es, asume que ya no es nodo token y que entrará al proceso de reasignación.

Página 19

3 . 3 . 4 PERDIDA DE UN MENSIAJE CUANDO NO SE ES TOKEN

Como se mencionó, un nodo que no es token detecta la pérdida de mensajes tipo D o tipo P al recibir un mensaje tipo P posterior. Entonces solicitará la retransmisión de mensajes enviando un mensaje tipo N al nodo token incluyendo el número de secuencia global asociado al Último mensaje tipo D recibido. Esperará por los mensajes faltantes, los cuales incluirán además del mensaje propiamente (tipo D) su número de secuencia global. Con ello se evita retransmitir los mensajes tipo P asociados a los tipo D.

I

Puede suceder que tengal mensajes tipo D sin su correspondi.ente mensaje tipo P (se perdieron éstos últimos) y por lo mismo, el mensaje retransmitido incluye ambas informaciones. Si el nodo token ya no tiene la información solicitada en la retransmisión (por que el nodo' perdió demasiados mensajes) responderá con un mensaje tipo E y el nodo solicitante deberá actuar acorde con ello; se considera un inici.0 de nodo.

3.3.5 PERDIDA DE UN MENSRJE'CUANDO SE ES TOKEN

Si el nodo token pierde un mensaje, puede tratarse de un tipo "D" procedente de un nodo en espera del acuse de recibo correspondiente, "i" procedente de un nuevo nodo que'desea entrar a la red, "N" procedente de un nodo que pide retransmisión de mensajes perdidos. En cualquier caso, el nodo que mandó el mensaje esperará un tiempo determinado y si aun así no se obtiene la respuesta esperada, entonces deberá intentar de nuevo, enviando otra vez el hensaje, después de un número " M " de intentos falli.dos se dará por caído el nodo token y deberá procederse a la reasignación del nodo token.

I

3 . 3 . 6 CAIDA DE UN NODO

En este estado se pueden presentar dos casos: El nodo caído es el nodo token, o no es el nodo token.

El primer caso se detecta por cualquier nodo al no recibir respuesta a sus mensajes; entonces éste inicia la fase de reasignación del. nodo token enviando u n mensaje tipo T, donde incluye el número de secuencia global que recibió recientemente. En ese momento otros nodos también pueden detectar la situación y enviar SUS correspondientes mensajes tipo T. Todoa los nodos activos de la red participarán en una competencia por ser el nodo token ya que la recepción de un mensaje tipo T también promueve la transmisión de este tipo de mensaje cuando el número global que tiene el nodo es mayor que el que recibe en el mensaje tipo T.

Cuando cae un nodo que noles token, no tiene implicaciones sobre los demás nodos de la red y oólo repercute en la propia aplicación si lo que falló fue la comunicación con la red.

I Página 20

CAPITULO 4.- DISENO

4.1.- PROPÓSITO.

Este capítulo tiene como propósito mostrar explícitamente el diseno del protocolo de difusi6n propuesto, basado In el usode los servicios de NetBios, para LAN Ethernet.

4 . 2 . - ALCANCES

El protocolo de difusión correspondiente a este diseiio consta fundamentalmente de tres partes o módulos: iinicio, recepción y transmisión. Estos módulos están relacionados de tal forma que permiten, entre todos, cumplir las acciones del protocolo.

En la etapa de inicialización se deben sentar las condiciones de trabajo de LAN, tales como el modo de comunicación en espera "WAIT" o no espera "NO WAIT", el tamaño de los buffers para mensajes de recepción y transmisión, identificador del sitio en cuestión, etc. Todos estos parámetros de trabajo, son manejados por los comandos especializados de Net-Bios para configurar la red encuadrada dentro del esquema descrito en el capítulo anterior.

c~ La herramientas y recursos mediante los que se trabaja, se enlistan a

cont inuaci.ón :

a) Hardware: - P.C., compatibles con IBM. - Tarjetas inteligentes con el protocolo Ethernet. - Manejador de Net-Bios para TCP/IP. - Sistema üperativo~ DOS. - Paquete de programación de lenguaje "C".

b) Software:

4.3.- FUNCION DE LOS MODULOS

El módulo de inicialización es el primero que debe entrar en juego. Se usa para definir las condiciones inici+les de trabajo, identificación numérica de los nodos y asignación de algunas variables de control, así como la .declaración y el vaciado de las estructuras de datos que serárl usadas en los'otros módulos. En seguida, se impulsan las funciones de recepción y transmisión con el fin de mantenerlas en alerta y originar u n servicio integral constante.

4.4 .- INTERACCION DE LOS MODULOS

Los tres módulos, INICIALIZACIóN, RECEPCIÓN Y TPANSMISIÓN, se encuentran relacionados para desempeñar la función global del protocolo. En la figura 7 se muestra un esquema que representa la jrelación que guardan estos módulos (sub-capa adicionada) con las capas de programación inferior y superior.

Página 21

G

. . . .

SEND-BROAD-PA.TAGRAM0

u

RECIBE-BROA1 ”1 VI Qi

@ FUNCIONES DE SERVICIO DE NET-BIOS

.

. . , .

. .

I

10 a nl V

Fig. 7. Relación de los Móldulos dentro de la Subcapa Adicionada

Como. se aprecia en la figura No. 7 , los módulos de recepción y transmisión se valen de dos estructuras de datos tipo cola que'guardan la información recibida: Cola de Recepción, e información por transmitir: Cola de Transmisión.

~

El módulo de transmisióti usa la información contenida en la Cola de Transmisión y en algunos casos también el contenido de la Cola de Recepción como se explicará oportunamente.

También se observa en la misma figura que todo el sistema se apoya directamente sólo de tres servicios de Net-Bios, de tal manera que por debajo de la capa adicionada se encuentra Net-Bios, que es'una interfaz de la capa de Sesión, y más abajo está la capa de transporte. Mientras que hacia arriba se halla la capa de presentación, a la cual son entregados los servicios de nuestra capa.

4.5.- LOS SERVICIOS QUE:OFRECE EL SISTEMA

El conjunto de servic,ios 'del protocolo pueden ser vistos como funciones entregadas por una capa más, adicionada sobre Net-Rios. Dicha capa presenta al usuario los servicios de comunicación en red, mismos que podemos ver en la parte superior de la Figura 7 y que constituyen la interfaz de esta nueva capa. La función "Query-Tx" es para que el usuario conozca el resultado de un llamado de transmisión "Trans()", ver "INTERFAZ DE USUARIO" en la sección 2 . 4 .

El servicio "Ini()*', sIe emplea para entrar al módulo de inicialización que contiene rutinas para establecer las condiciones iniciales del nodo a la hora de darlo de alta, tales como la definic'ión de las estructuras de datos y su inclusión en la red.

Se da también una función llamada "Info()", que proporciona información general del estado en que se encuentra la red y el nodo local, por si en la aplicación se requiere alguno de estos datos.

I Página 23

I

4 .6 DESCRIPCION DE LAS VARIABLES USADAS

I

I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

/ * VARIABLES DE ESTADO ULTIMO * / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

int int int int int int int int int int int int int int int int int int

ID TOKEN; /*Identificador del token*/ CTA TñAS; /*Cuenta de Transmisiones de un msj "O"*/ T RZCONF; /*Bandera de fase de renov. token * / MiiX TRAS; TAM-MSJ; IDE-NET; /*Identifi. de nombre local para Net Bios * / N S G T; /*Secuencia dada por token.Si token local*/ N-S-GiR ; /*Número de Secuencia global actual*/ N-S-G A; ' /*Secuencia glob. de un nisj atrasado * /

ACTüAil?i; /*Si el nodo está en espera de msjs. atrasado*/ NO SEC; :/*No. de secuencia del nodo local*/

/*Para s,aber que el nodo fué inicializado*/ bandera-R; /*Para saber que el ciclo de recepción acabó*/

/*Máximo' valor de n sec-glb que ha llegado*/ /*Límite superior de tiempo para el retardo*/

/ * Número de mensajes por retransmitir*/

/*No.máxkmo de transm. de un msj. tipo D*/ )*No. de bytes válidos en el mensaje * /

NODIINI;

CL.U-NET; cta-t;

num-ret ; cta-i; / * No. de veces que se ha pedido la ini() * /

max-i = 10; /*Máximo No. de intentos para inion/

/ * Encabezado del mensaje e4 curso: * /

char Tipo; /*Indica el tipo de msj. recién llegado * / int No-sec; /*El No.de secuencia parcial del msj. reciente*/ int Tam-ms j ; /*El No. de bytes válidos del msj. * / int N-e-glb; /*Secuencia glohal del rnsj. recién llegado*/ int Id - f; /*Identificndor fuente del msj. reciente*/

Página 24

/ * Estructura\ de las co1as:I */,

int NO-SEC; int N-S-GLB; char MSJ[ 37 ] ; )mensaje [ M ] ;

) cola[i];

/ * Secuencia parcial en el msj*/ 1% Secuencia global en el msj * /

/ * CUERPO DEL MENSAJE * / / * Arreglo de M mensajes * /

#define M 100 / * Variable del tamaño de las colas * / #define Cola-Tx 1 /*Identifieador numérico para la cola de transmisión*/ #define Cola-Rx O /*Identificador numérico para la cola de recepción * / ,#define maxl 100 /*Número de elementos efect,ivos de la cola No. 1 -Recepción-*/ #define max2 100 /*Máximo elementos efectivos de la cola No. 2 - Transmisión-*/

/ * DEFINICIONES DE NOMBRE P A F LISTAS LIGADAS : * /

#define LIBRES-RX 0 #define LLEGXDA 1 / * List/a de mensajes recién llegados [Por procesar) * / #define SINGLE 2 / * Lista de mensajes sin secuencia global * / #define CON-GLB 3 / * Lista de mensajes con secuencia global * / #define CONSUMO 4 / * Lista de mensajes para la aplicación * / #define LIBRESTX O / * Lista de espacios vacíos en la cola de transmisión * / Udef ine TX 1 / * Lista de mensajes para transmitir*/

#define TO 200 / * Milisegundos para el retardo de espera por msj. tipo 'P.*/ #define T1 5*TO / * Milisegundos para retardo de reconst. de token * /

/ * Lis+ de espacios vacíos * /

Página 2 5

/ * Estructura de los extremos, de listas ligadas:*/

struct extremos int ULTIMO; int PRIMERO; / * PARA ,LA COLA DE TRANSM. Y RECEPCION * / lista-r[6], lista-t[2];1

/ * Estructura de las ligaduras para índices de cola:*/

struct index( I int ANT; / * PARA;LIGADURAS DE COLA DE RECEP. Y TRANSM. * / int POST; elem-r[100], elem-t[lOO];

char name[l6]; / * Nombre del sitio local * / char far *dir; / * Dirección del NCB " / char far *BUFI ' l ; / * Buffer para los mensajes de recepción * / char far *BUFF2; / * Buffer para los mensajes de transmisión * /

static void interrupt pos-r ( ) ; / * Post-rutina de recepción * / static void interrupt pDst(); / * Post-rutina de transmisión*/ static void interrupt pos-n(); / * Post - rutina de aL.ta de nombre*/ I

#define NUM-NOM 6 /.* Número de nombre en uso * / #define ADAP O / * :Primer adaptador 1ocal.Pueden haber otro*/ #define OPW 1 / * Modo WAIT * / #define OPNW O / * Modo NO-WAIT * / #define BUPTRM 46 / * ,Tamaño del buffer para transmitir y recibir*/

I typedef char BYTE; /,* Definición pro-portabilidad * / typedef char far *POINTER; / * Apunta al buffer del NCB (Ver abajo)*/ typedef unsigned COUNT; / * Tamaiio del NCU * /

Página 26

I

4 . 7 . - SERVICIOS DE OTROS STSTEMAS

4.7.1 NCB

I Cada uno de los comandos de Net-Rios ejecutado se relaciona con una tabla de datos llamada Network Control Block (NCB), que contiene La información para efectos de comunicaciones en red.

Los campos contenidos en el NCB son:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

TAELA 1

~

NOMBRE DEL CAMPO LONGITUD EN BYTES

COMANDO.. ................................... 1 CODIGO DE RETORNO ........................... 1 NÚMERO DE SESIÓN LOCAL ...................... 1 NÚMERO DEL NOMBRE ........................... 1 DIRECCIÓN DEL BUFFER ......................... 4 LONGITUD DEL BUFFER.! ........................ 2 NOMBRE DEL NODO REMOTO ..................... 16 NOMBRE LOCAL (asociado con el comando) ..... 16 TIEMPO DE 'TOLERANCIA PARA RECIBIR ........... 1 TIEMPO DE TOLERANCIA PARA TRANSMITIR ........ 1 DIRECCIÓN DE LA POS'~-RUTINA ................. 4 NÚMERO DE LANA (ADAPTADOR) .................. 1 BANDEM DE FIN DE COMANUO ................... 1 CAMPO RESERVADO ............................ 14

Este grupo de elementos €orman lo que se conoce como "estructura" en lenguaje "C" y puede ser manejado como tal. Es decir, se puede obtener alguno de los datos llamándolo mediante el escatut'o:

struct Ncb -> (campo requerido)

I Página 27

,De esta manera se dispone de lon parámetros señalados dentro de las funciones definidas en las rutinas de recepción y transmisión, obteniéndose de esta estructura (NCB). Las características de.trabajo que t.iene esta aplicación, no hace necesario el . . uso de la mayoría de estos elementos, limitándose sólo a los de número 1,2,5,6,11 y 12, como st? verá oportunamente.

4.7.2.- LLAMADAS A NET-BIOS

I Existen diversos comandos ofrecidos por Net-Bios, que permiten llevar a afecto las tareas de red,. Los que se van a usar en esta aplicación usan los parámetros: !

* Nombre de la estación local (name) * Núnlero de Nombre (no-num) . * Número de Adaptador de LAN, entre los dos posibles (lana). * Modo de transmisión, * El tamaño del buffer los mensajes (tam). * La dirección del buf;er(BUFF). * La dirección del Network Control B l o c k (NCB).

4 . 7 . 3 . - SERVICIOS DE NET BIOS QUE SE USAN EN LAS RUTINAS , -

I INSERT-NAME(name. ADAP, OPW, &NCBl) USO: Pone un nombre único a la estación local. VALORES REGRESADOS: El iiúinero asignado por Net-Bios, para el nombre dado a la estación local.

I red. I RECEIVE BROAD-DATAGRAM(1DE-NET, ADAP, OPNW, TAM, BUFF1, GNCBl)) uso:

VALORES REGRESADOS: La longitud del dntagrania recibido.

~ s f e comando permite recibir un mensaje procedente de cualquier estación de la

SEND BROAD DATAGRAM(1DE-NET, ADAP, OPNW, TAM, BUFF2, &NCB2) USO:-Este Comando envía un mensaje a todos los nodos que hayan efectuado un comando RECE IVE-BROAD-DATAGRAM . VALORES REGRESADOS: Ninguno.

Página 28

LIMPIA(NCB) Pone a cero todos los valores1 cuantificables y a nulos los no cuantificables de la tabla NCB que s e indique en ei! argumento.

POSTRUTINA.- Se lleva a cabo solamente en los casos de ejecución en.modo No Wait y entra en operación inmediatamente después de terminado el comando. El requisito para usar la post-rutina es pasarle'al NCB la direcc'ión de esta rutina. Su llamado es como sigue:

void interrupt pos-r() ;

4 . 8 PSEUDOCODIGO

4 . 8 . 1 PCEUDOCODIGO GLOBAL

El siguiente pseudocódigd presenta de manera formal el PDTF y sirvió como diseño antes de su codificación. Se udilizan las siguientes definiciones:

I , :. id f ........... Número identificador Fuente no-sec ......... Número seciencia1 del mensaje v-no-sec ....... Número secuencial inmediato anterior v-n-s-glb ...... Número secuencial global inmediato anterior. n-sec-glb ...... Número secuencial global n-s-g-t ........ Número secuencial global del token msj.. .......... Mensaje de Icomunicación en curso n-s-g-a ........ Número secuencia1 global asignado a m s j

-

Entrar en red Llamar Inic(); Mientras número de nodo local sea verdadero

Correr rutinas de t,ransmite();

Llamar rutina de adlicación;

Si hay algo en cola T x

Fin Si Si la condición de atelnción a tarea se cumple

Programa de usuario que contiene Recepo y Trans() Fin Llamar I

Fin Si Fin Mientras

Fin Entrar

I Página 29

1 I - '

4 . 8 . 2 PSEUDOCODIGO DE INICIO

PROCEDIMIENTO DE INICIO:

Dar de alta el sitio 1 Se obtiene "Mi-nombre" LLAMA PROCEDIMTENTO INSERT-NAME 8

Se ejecuta un comando insert-name(name, ADAP, OPW, &NCBl) Fin PROCEDIMIENTO

Fin se Fin dar I

Inicializar Dar de alta las estructuras; Inicializar variables; impulsar las rutinas be recepción y transmisión Mientras del name sea falso

Mientras haya algo en cola Rx Se ejecuta el comando RECEIVE-BROAD DATAGRAM(1DE-NET, ADAP= O ,

OPNW = O, BUFF - TAM = 4 6 , *BUFFI, &NCBl); Fin Mientras Si hay algo en cola Tx

Fin si Fin Mientras

Se ejecuta el comando SEND - BROAD DATAGRAM(1DE-NET, ADAP=l, OPÑW=l,BUF - TAM = 46, &NCB2);

Fin impulsar Fin inicializar I

Fin INICIO

, 4 . 8 . 3 PSEUDOCODIGO DE REC 5EPCION

Si hay mensaje para recibir entonces Obtiene su encabezado de (tipo, id-f, no-sec, n-sglb, msj)

Dif: Si (n-s-glb == -1) (el ma). no tiene n-s-glb) entonces Caso (tipo) I . Si (no se ha recibid4 el; msj (id-f,no-sec)) entonces

Si (token es cierto) entonces n-s-g-t = n-s-9 t + 1 Programa msj(P,'-id f, no sec, n-s-g-t) - _ _ Registra en cola iaf, nosec, n-9-g-t.

Fin si I _ _ Guarda msj en cola con su (id-f, no-sec, O)

Si no (Ya existe men~saje) Si (token es cierto) entonces (el otro perdió msj tipo P)

Obtiene del Relgistro su identif. global en n-sg-a Programa msj (P, id-f, no-sec, n-s-g-a)

Fin si 1 Desecha msj

Fin SL

Página 30

Si no (Ya tiene n-s-glb => retransmisión)

Si (token es cTeTto) entonces

Fin si Programa msj(N, mi-id, O, v-n-a-glb)

Si (n-s-glb es = v-n-sglb + 1) entonces Guarda msj en cola Registra su id-f, no-sec, n-sglb v-n-s-glb = n-sglb Pasa el msj. a la Aplic.

Si (n-s-glb > v-n 6 glb + 1) entonces

token = falso (Dejo de ser token)

Si no

i Fin si Fin si

Fin si Sale caso

P: Si (n-s-glb == v-n-s-gl,b + 1) entonces Si (existe msj. (id-f, no-sec)) entonces

Registra al msj. su (id-f, no-sec, n-s-glb) Si (id-f == mi-id) entonces

Fin sT Pasa msj. a la /aplicación

Ajusta apuntador de cola de mensajes a transmitir cta tras == O (lo da por transmitido)

v-n-s-gib = n-&lb sino (no rdcibió el msj. asociado al P)

Programa msj(N,I mi-id, O, Sn-s-glb) Fin si

Si (n-s-glb > v-n-s-glb) entonces Si no

(no recibió msj. o msjs. anteriores) Programa msj(N, mi-id, O, v-n-s-glb)

Fin si I

Fin si Sale caso I

N: Si (soy token) entonces si (existe msj(n-s-glb) en cola) entonces

Ajusta apuntador de retransmisión al msj. n-s-glb + 1 Ejecuta para todos los mensajes

Fin ejecuta

Programa msj. (E, mi-id, O, n-9-g-t) Pasa msje. “E** a la ,aplicación.

Programa msj’(D, id-f, no-sec, n-s-g-a)

Si no

I Fin si Fin si

Desecho mensaje Si no (Cuando soy cualquier nodo)

Fin si Sale de caso

I Página 31

I -

I: Si (NOD [NI es falso => NO5 IN1 = 1 mi-Td = cta-id

E: Si (id d == mi id) enSonces (id-d es identif. destino) v-nIs-glb =-n-s-glb mi-no-sec = O Pasa msj. (E) a la aplicación (avisa del error)

(inicia su secuenciamiento de msjs . )

Fin si Sale caso

no estoy inicializado) entonces

i: Si (token es ciertoi entonces ' Programa msj(1; mil id, cta-id, n-s-gib, O)

Fin si I

~

Si no soy token Si id-f == mi-id

Cuento la transmisión. de 'i' Fin si I Desecho mensaje 'i' '

Fin si Sale caso

T: Si (puedo ser token) er.ionces Si (token es cierto) entonces

Si (id f no es = mi-id) entonces Si Tn-s-glb es >o= v-n-sglb) entonces

sino

Fin si

token = falso (alguien más tomó el token) n-s-g-t = 'O

Programa msj(T, mi-id, O , v-n-s-glb)

i Fin si

Página 32

Si no

Fin ST Fin si

Fin si Fin si si (temporizador

Fin si Si (cta-tras es >

cta-tras = Fin si

inicia T-reconf

Fin si Default: Sale caso Fin caso

Caso e :

= :

> :

T-reconf vencido).entonces a T1

max-tras') entonces max-tras

_ _ S i (token falso) entonces

(n-s-glb ? v-n-s-glb) Si (id,f no es = mi-id) entonces

Programa msj(T, mi-id, O, v-n-s-glb) Fin si: sale caso si (idLf no es = mi-

sino I

Fin sil, Sale caso id token = id-f sale caso

id-token = id-f

id token = mi-id I

~

id ) entonces

4. e. 4 PSEUDOCODIGO DE T~NSMISION

Si (T-reconf está activo) entonces Si (hay m s j . tipo T por enviar) entonces

Fin si

Si (msj. T tiene mi-id) entonces

Envía m s j . tipo T

Si no

token = cierto n-s-g-t = v-n-s-glb Obtiene el número M de m s j s . recibidos sin n-s-glb asignado Repite M veces

Obtiene su id f y no; sec n - - _ s g t = n-sIg-t + 1 Envía msj(P, mi-id, no-sec, n-s-g-t)

Fin repite

Página 33

. . ..,, , , .. j~ _.,, i ..'..,4 ,... ,. : ..*

. :,

Espera 'PO F i n s i

F in s i F in s i

S i no i d t o k e n = f a l s o

y t r a n s m i s i ó n se r e q u i e r e de r á f a g a d e t r a n s m i s i ó n . E s t o s

I F i n ST S i (cta- tras == O ) e n t o n c e s

S i (hay mensaje e n cola) ent.onces m i n-sec = mi-n-sec + 1 Envia m s j ( t i p o = D , id - f=mi ' id , ' no-sec= mi-n-sec, n-s-glb=O) c t a- t r a s = cta- tras + 1 Espera T O I -

c i e r t o s parámetros que deberán e s t a r d i s p o n i b l e s e n cada son : t i p o , id- f, no-sec, n-s-glb, t a m - msj. ',

Fin s; I

, .

Página 34

. .

, ,

I 4 . 9 ESTRUCTURAS DE DATOS

4.9.1.- TRAMA DE 1.0s MENSAJES I

y---

La trama de mensajes manejada a este nivel es la que se describe en la fig No. 8 en donde:

I tammsj n-s-glb no-sec id f t is0 ms j Cuerpo del mensaje.

Tamaño efectivo del mensaje "msj.' Número de secuencia global de red. Número de secuencia del nodo. Número identificador del nodo fuente. Caracter identificador del tipo de mensaje.

In-sglb ]I no-sec I id - f 1 ~ 1 ~ ~ BYTES: 2 2 2 2 1 37

1

FIG.8 TRAMA DE LOS MENSAJES A NIVEL DEL PROTOCOLO DE DIFUSION.

A continuación se describe cada uno de los elementos de la trama.

a).- tam-msj Se trata de un número que representa la cantidad de bytes de que consta el i

mensaje ''msj'a. I b).- n s glb Este nh&o introducido por el nodo Token a cada mensaje, establece un orden

y no con la que fué recibido; es decir, permite recuperar la secuencia datos en el proceso del cual emanan.

global que permite a cada nodolreceptor tomarlo con la secuencia que fué anitid0 aiginal de Loe

c).- no-sec Cada nodo asigna a sus mensajes un número secuencia1 en el momento de

difundirlos para representar así la secuencia de acontecimientos ocurridos en el punto de adquisición del cual emanan.

d) .- id-f Este número se asigna a cada nodo para distinguirlo de los demás que están en la

e).- tipo Se trata de un caracter para dar a conocer rápidamente el tipo de

contenida en el mensaje en cuestión, pudiendo ser de control o de

red. Se asigna desde el nivel d e red por Net-Bios.

información información.

f).- m s j Este es el contenido verdadero del mensaje que se desea difundir. I

Página 35

Dentro de los mensajes de control se distinguen los tipos siguientes:

4.9.2.- COLAS

* D

* N

* P

* i

* I

* E

* T

(Difusión) mensajes de información, normales.

(Acuse de NO Recibido) para solicitar retransmisión de mensajes atrasados.

(Acuse de Recibopel nodo Token emite un acuse de recibo para que los nodos se enteren de la validez del mensaje referido.

(inicialización) para solicitar la incorporación a la red de un nodo nuevo.

(Acuse de recibo de un mensaje de inicia1izaciÓn)El nodo TOKEN difunde el n-s-glb en curso y su identificador para poner al corriente a un nuevo nodo aceptado en red.

(Error) lo manda el Token para indicar al nodo referido, que su secuencia al soli¿itar retransmisión, es imposible.

(Define Token) mensaje para solicitar cambio de token por parte de un nodo que detecta anomalías en el desempeño de las ' funciones del Token.

I I

I .

Si nos basamos en las limitaciones del Net-Bios dadas por el tamaño de los campos del NCB "NUMERO DE NOMBRE" y "LONGITUD DEL BUFFER", de 8 y 16 bits, el número máximo de nodos (Nombres de Nodo) y el tamaño máximo dedicado al mensaje serían de 255 y 64 KB respectivamente. No obstante, se ha decidido usar un tamaño fijo de mensajes de 46 bytes de datos, que es el tamaño mínimo transmitido por el protocolo Ethernet. Esto con base en que la aplicación se orienta a la emulación de una MCR, donde se requiere enviar mensajes cortos.

4.9.2.1.- COLA RECEPTORA DE MENSAJES

La manera de estructurar1 el espacio destinado para recibir los mensajes desde Ethernet es determinante para hl desempeño total del sistema, desde el punto de vista de la aplicación. Debe ser tal que evite, en lo posible, la copia de mensajes de un área de memoria a otra dentro de la máquina, para evitar consumo de tiempo y memoria innecesario.

I Página 36

I Cola Llena Bandera d e cola llena.

Cola Vacía Banjera de cola vacía.

Número de mensajes en la cola.

Mensaje O Espacio para el mensaje número O.

Mensaje 1 Espacio para el mensaje número 1.

Mensaje 2 Espacio para el mensaje número 2 .

I

para el penúltimo mensaje.

para el último mensaje.

FIG.9 ESTRUCTURA DE LA COLA DE RECEPCION.

La figura NO. 9 ilustra la forma en que esta organiza I zona de memoria para contener los mensajes. Se observan en esta figura una serie de localidades (celdas) en las cuales podrán guardarse los mensajes que se vayan recibiendo o transmitiendo. Estas celdas son de tamaito fijo.

Además de los espacios d;estinados para los mensajes, se tienen tres banderas de cola llena, de cola vacía y de número de mensajes en cola.

I

El tamaño de esta zona eL para contener 100 celdas, pero puede ser cambiado por medio de la redefinición de la estructura "COLA" en el archivo "defin.c", mediante el compilador de "Borlandc" .

Página 37

LIBRES-RX

ant \post

3

4

98

99 99 \ o

LLEGADA

int\post

1 \ 98

I I I

CONGLB

ant\post

4

SIN-GLB

int\poat

Y

CONSUMO . .

ant\post t--

H .... ............. ............... - PRIM 99 1 I 2 ...............- l............- 1

ULT .... 4 ............. 98.! ............. 2 ............... 1 ............ -1 !

FIG.10 ESTRUCTURAS PARA LAS LIGAS DE LISTAS

La administración de esta zona es por medio de listas doblemente ligadas que en el caso de la cola de recepción son: "LIBRES - RX", "LLEGADA", "SIN - GLB", "CON-GLB" Y "CONSUMO".

Inicialmente todos las Celdas están en la lista de LIBRES-RX y en el momento de que llega un mensaje se carga en la lista "LLEGADA", después de que ese mensaje ha sido analizado para conocer su tSpo, secuencia y procedencia, se pasa a la lista de "SIN GLB", en seguida, al ser confirmado Ivalidadol mediante su número slobal. entonces 8e pasará a la lista de "CON!-GLB" y finalmente,. cuando la aplicacih lo .tome será cargado a la lista "CONSUMO". 1

Página 38

Una vez que algún liberarse para dedicar

ya deja de ser Útil para el protocolo, su celda deberá a otros mensajes que puedan ser recibidos, pasándose

a la lista de LIBRES-RX. usados con otros mensajes de recepción.

Estal última lista contendrá espacios disponibles para ser

La estructura de ligaduras, Fig 10, tendrá índices correspondientes uno a uno, con los de la de cola, de tal forma que cada elemento posea su ligadura hacia atrás y otra hacia adelante.

En la FIG.9 se ilustra la manera como se ligan los elementos de las listas "LIBRES-RX" , "LLEGADA", "CON GLB" , "SIN GLB" y "CONSUMO", que corresponden ' respectivamente a los espacios1 de la cola lib;es, los dedicados para datos de llegada, los dedicados para datos con número secuencial global, los de datos sin número secuencial global y finalmente los espacios que pertenecen a los mensajes pasados a la aplicación (consumidos).

Como elemplo, supongamos, ~ T e la cola de recepción se ha distribuido en un momento dado como se ilustra en el siguiente esquema. Se observa en este ejemplo que el elemento "O" de la cola se liga por un lado con el "4" (hacia adelante) y con el "99" por otro (hacia atrás). El "99" es el primer elemento de esta lista y por ello tiene "99" en su "ant"; así como el "4" tiene en su "post" tiene " 4" por ser el Último de la lista "LIBRES RX". Así que cuando cierto elemento se contiene a s í mismo, puede ser interpretado como "inicio de lista" o "fin de lista" según se trate de "ant" o "post" respectivamente.

Análogamente, la lista de LLEGADA comienza con el elemento "1". el siguiente es el "3" y finaliza con el "98". Asimismo se.observa que en la lista de "CON-GLB" existe un solo elemento, el No.2.

En casos de requerir búsquedas se necesita conocer los elementos de cola que en ése momento sean el inicial y final de l a lista de interés. Para conocer en todo momento al elemento inicial y final de cada lista se mantendrán registros actualizados para tal fin. Esto se hace por medio de otra estructura aparte llamada "EXTREMOS" y que tiene un elemento "PRIMERO" y otro "ULTIMO" para cada una de las listas que lo requieran (Fig. No. 11).

De tal manera que podemos observar también que las listas de "SIN GLB" y "CONSUMO" se encuentran vacías, condición que se representa colocando un "-1" en los valores correspondientes de "ULTIMO" y "PRIMERO" para ellas y que se ilustra al pie de la figura recién mencionada. ,

-

I

I Página 39

Con esta estructura de ligaduras se puede dar de baja un elemento de una lista y darlo de alta en otra, sólo con el manejo apropiado de los valores de "post" y "ant" correspondientes de ese elemento, sin tener que mover físicamente los datos contenidos en él. Así también, cuando deja de ser Útil un elemento, por ejemplo de la lista de "LLEGADA", en donde se colocanlmensajes de control frecuentemente inútiles (Como es el caso de acuse de recibos negativos cuando el nodo local NO es token), deberán ser 'desechados". I

La manera de eliminar un,mensaje cualquiera que ya no tiene utilidad, para dejar espacio disponible en la cola, es aplicando un desplazamiento de la celda en cuestión, hacia la lista de "LIBRES RX"; cosa que se logra por medio de una acción de desligado/ligamento manipulando el "ant" y el "post" correspondientes como se explicó en el párrafo anterior. i

Cuando el protocolo genera retransmisiones en respuesta de mensajes tipo N, se hace menester una búsqueda de/ los elementos solicitados, en las listas "CONSUMO" y "CON GLB". Para esto, si el número global buscado es mayor o igual al "PRIMERO" de la lista de "CON GLB", se asume que deberá buscarse en la lista de "CON GLB"; pero si dicho número global es menor, entonces deberá buscarse en la lista de "C%NSUMO" (lista que contiene los elementos más antiguos del proceso).

Los mensajes generados por la recepción que tienen que ser transmitidos, tales como los mensajes a retransmit& o los mensajes de control programados por el protocolo cuando el nodo es token, serád ligados a la cola de transmisión.

I

4 .9 .2 .2 .- COLA DE TRASMISION

La cola de transmisión &tiene todo aquello que se pretende difundir en toda la red, no solamente los mensajes /de control y retransmisión generados por el protocolo, sino también los mensajes procedentes de la aplicación: datos y fracciones de mensajes "texto".

La estructura es básicamente la misma que la cola de recepción, con la virtud de poder colocar mensajes nuevos ,al principio de la cola. Eso con la finalidad de dar prioridad de transmisión a mensales tan urgentes como el tipo "T" (Renovación de nodo Token).

En este caso tenemos sólo I dos listas doblemente ligadas, la de "LIBRES-TX" (constituida de espacios libres) y "TX" (que contiene los mensajes a transmitir propiamente). Pero el orden en que los mensajes son colocados en esta Última, depende de la prioridad que ellos tienen respecto a los demás que ya estén en la lista. Al igual que en el caso de la cola de recepción, cuando se libera un elemento de la cola "TX" es pasado a la lista de "LIBRES-TX" por medio de un proceso de "ligamento" que evita pérdida-de tiempo en borrado del espacio correspondiente.

Como ya se mencionó, la 1 máxima ,prioridad se logra al colocar el mensaje al principio de la lista porque sa,ldrá primero que todos.

Página 40

1

! 1

4.9.3.- VARIABLES DE ESTADO.

Es un agrupamiento de datos que contendrá los valores más recientes e importantes !

que definen al estado Gltimo/del sistema. Estos son:

N S GLB = O ; I

1 ACTUALIZA = o; ARR FRIO = 1; I SOY-TOKEN = o; eieZ-t[o].~osT = 1; 1 elem-tLO].ANT = O;

1

4.9.4. - ESTRUCTURA DE EXTREMOS Esta estructura contiene,los 1 índices de posición para los extremos de cada lista.

"ULTIMO" y "PRIMERO". De esta manera se conoce en todo momento el punto desde el cual debe emprenderse y el extremo en el que termina una búsqueda.

EXTREMOS LISTA

ULTIMO

PRIMERO

I 1- LLEGADA I

1- SIN GLB

PRIMERO

CONSUMO PRIMERO

FIG. No. 11 ESTRUCTURA DE ELEMENTOS EXTREMOS

En el momento de la inicial!ización se deben cargar con "-1" para dar a entender La ausencia de elementos en las listas. Las listas LIBRES son una excepción ya que al ?rincipio esta lista contiene el :máximo de elementos:

I Página 41 .

! / * Inicialización de los extremos: * / ~ ~ ~ ~ ~ - ~ [ L I B R E S - R X ] . U L T I M O I = maxi-i; lista-r[LLEGADA].ULTIMO = -1; lista-r[SIN-GLB].ULTIMO = 1-1; iista_r(CON_GLE].uLTIMO = -1; lista-r[APLIC].ULTIMO = -1;

~ ~ ~ ~ ~ ~ [ T x ] . u L T I M o = -1; '

liSta_t[LIBRES_TX].uLTIMO = 1 max2-1;

/ * Si "PRIMERO" de alguna l'ista es -1, se supone que no existe aun elemento inicial * / I

lista ?=[LIBRES-RX].PRIMERO = O; liStaZr[LLEGAOA].PRIMERO = 1-1; lista-r[SIN-GLB].PRIMERO = -1;

iistaIr[APLIC].PRIMERO = -1; lista r[CON GLB).PRIMER~ = 1-1;

lista-t[TX).PRIMERO = -1; lista - t[LIBRES - TX].PRIMERO ,= O;

4 . 9 . 5 . - ESTRUCTURA DE LIGAS

Esta estructura contiene las ligaduras "post" y *'ant" que establecen la pertenencia o no pertenencia del los diferentes elementos de la cola, a las diferentes listas. Como se explicó oportunamente, existe una relación uno a uno entre los elementos de la cola con los de,la estructura "LIGAS", a tal grado que la disposition en que se encuentre esta Última ;determinará los elementos que pertenecen a cada una de las listas de la cola. Además como hay dos colas, la cola de recepción y la de transmisión, deberá haber también dos estructuras de ligamentos.

1

Página 42

! LXGAS , , ELEMENTO

ANT

POST

ANT

, I

ELEMENTO O , 1

EGEMENTO 1 rFs= I

ELEMENTO M x-i

ELEMENTO M x POST

1

FIG. NO. 12 ESTRUCTURA DE LIGAMENTOS

En el momento de la inicialización, solamente las listas de elementos LIBRES contienen ligamentos; pero en cua'nto se emprenden las acciones de recepción aparecerán elementos ligados a l a s demás listas.

I / * Se inicializa la lista de re,cepción: */ for(Ant = 1; Ant <= maxl-1; Ant++) t I elem r[Ant].ANT = (Ant -1); I elern~r[Ant-l].POST = Ant;

I > 1 / * Se inicializa la lista de transmisión: * /

for(j = 1; j <= max2-1; j++) I I

elem-t[j).~NT = (j -1);

I 1

elem t[j-i].POST = j; I -

, Página 43

4 . 9 . 6 . - NETWORK CONTROL BLOCK.

1 Esta estructura se proporciona por los servicios de Net-Bios. Su explicación está

en la sección llamada "SERVICIOS DE NET-BIOS".

4.10.- SATURACION DE COLAS

Las colas de transmisión y recepción no pueden ser ilimitadas. El tamaiio de éstas se basará en los requerimientos lde la aplicación; en el caso, de la adquisición de datos en tiempo real (preocupación principal de esta tesis) cuya captura y proceÉo deberán efectuarse lo más rápido posible, los mensajes cargados tendrán una corta vida dentro de las colas, por lo mismo no se requiere un tamaño grande para las colas.

Sin embargo la saturaciónl de la cola de recepción de mensajes es algo que se tiene que dar aunque el tamaño de la cola sea muy grande, debido a que las necesidades de recuperación exigen guardar; mensajes antiguos por si algún nodo reclama una retransmisión muy rezagada.

Este asunto'de la saturación de mensajes es un factor determinante del tamaño de la cola que también depende de la aplicación, porque si la vida Útil de los mensajes dentro de las listas es prolod,gada, estos deberán permanecer dentro de la cola, ocupando espacio, durante todo el tiempo en que sean útiles, además debe haber espacio para nuevos mensajes que habrán de llegar. A la inversa, si el proceso de los mensajes desde la aplicación permite deshacerse de ellos rápidamente, se puede "vaciar" el espacio de esos mensajes inútile's y dedicarlo a los nuevos mensajes que lleguen. En conclusión, entre más rápido sean,usados los mensajes por la aplicación, será necesario menor espacio en la cola de recepción.

La forma en que se piensa ,resolver el problema de la saturación es dando una estimación de antigüedad máxima para mensajes que pueden ser eliminados y cuyo espacio puede ser destinado a los nuevos mensajes de la recepción. Es difícil que en la aplicación que nos preocupa se requiera de mensajes que estén 100 posiciones en atraso, dado que se trata de operaciones en tiempo real, ass que cuando se haga viejo el primer mensaje en un atraso de 100, puede ser reemplazado por uno nuevo.

1 Página 44

Como se explicó en la descripción de las listas ligadas, un mensaje puede ser pasado a la aplicación desde el momento en que se encuentra en la lista de "CON-GLB". Cuando ese mensaje es pasado a la aplicacibn deja de tener utilidad deede el punto de vista del nodo local, pero noles eliminado porque puede ser requerido por algún otro nodo que lo pierda (En el caso de que ese nodo local funciofie como Token), pero será pasado a la lista de "CONSUMO"1y permanecerá en su sitio hasta que se haga tan antiguo que pueda ser eliminado. Cuando esto ocurra, habrán 99 mensajes antes que 41 en la lista de "CONSUMO",y en ese momento, si hay un mensaje nuevo que recibir, tomará el espacio de ese mensaje más antd,guo pero quedará cargado en la lista de "LLEGADA". Desde entonces los lugares ocupados por los mensajes más antiguos irán siendo destinados a los mensajes recién llegados, ,cargándolos en la lista de "LLEGADA".

En el caso de la satura!ziÓn de la cola de transmisión, que sucede cuando el espacio destinado a los mensajes para transmitir se agota, deberá advertirse al usuario para que limite el número de sus mensajes por transmitir a una cantidad acorde con el número fijado para la cola de recepción y transmisión ya descrito. Hay que tener en cuenta que en la cola de transmisión se van instalando los mensajes que los algoritmos del protocolo generan, además de los mensajes procedentes de la aplicación en el nodo local. Los mensajes generados por el protocolo pueden ser muy numerosos cuando el nodo local esta operando como Token lporque debe atender a todos los demás nodos con acuses de recibo.

Ya que cualquier nodo puede fungir como token, podría apartarse la mayor cantidad de celdas de la cola de transmisión y dedicarlas a las funciones de token. Esto haria que la cola de transmisión opere a un rendimiento muy reducido, pero si el usuario aplicara esta medida solamente en casos en que su nodo local es Token, el rendimiento aumentaría sustancialmente. Para esto, puede leerse una variable de estado que se llama "N-S-GT" y que es mayor o igual a "1" cuando se es Token y " O" (cero) cuando no. Entonces se puede detener el número de mensajes por transmitir en cuanto la cola de transmisión esté al 50% de su capacidad aproximadamente cuando se es token y a un 90% cuando no se es token. La forma de conocer el nivel de llenado de la cola de transmisión, es consultando la localidad llamada NO MSJS, que representa el número total de mensajes por transmitir que están en la cola TX. Para leer este elemento de la estructura "cola" se debe llamar dicho elemento mediante el operador "punto": cola[Cola - Tx].NO - MSJS usando el compilador de Borlandc.

Considerando el factor de ,antigüedad antes citado, esperamos que un tamaño de cola de un número de 100 mensajes sea suficiente para este caso. De cualquier manera, es comprensible que las estimaciones dadas aquí estén lejos de la realidad cuando se efectúen ensayos de alguna aplicación, así que al ser requerido un espacio mayor o menor para las colas, sólo basta redefinir el tamaño de la estructura "COLAS" para agrandar o reducir su tamaño.

Página 45

4.11.- ARBOL DE RUTINAS

Inic I

I

ini-cola ini'iist ini-recib INSERT - NAME pausa

I ! p0s-r

I I I proceso RECEIVE-BROAD-DATAGñAM ,

I I

I tipos ! encabezado

I I

Dif rec - P rec-N rec-I Err D - Tok ini

Dif

busca meter sacar progm:s j

D-Tok

prog-msj meter sacar

e! r - l - T - l busca meter sacar progms j busca meter sacar progmsj

Página 46

rec-I i n i

meter sacar meter sacar meter sacar progms j

meter sacar

I

, Transmite

I

I I I I I I encabezado progmsj SEND - BROAD-DATAGRAM meter sacar

Recep

I I I busca m e t e saca

1 Trans Query-Tx

' Prog-ms j busca

Página 47

4.11.1.- DESCRIPCION DE RUTINAS

Ink() Inicializa colas, listas y variables e impulsa la recepción.

p0s-r ( ) Post-rutina de recepción. protocolo. Se auto ini,cia con la llegada de un mensaje nuevo.

Contiene el proceso de recepción de mensajes del

I

proceso( ) Esta rutina se encarga de darie tratamiento a cada mensaje según su tipo.

Tipos ( ) En esta rutina, se analiza el tipo de mensaje y se llama la rutina que corresponda a ese tipo.

Encabezado(nurn-cola, ind msj) Lee el encabezado de argún mensaje (el que se define en sus argumentos) y carga las variables de encabezado con esos datos.

RUTINAS DE ATENCION A LOS DISTINTOS TIPOS

DE MENSAJE TIPOS DE MENSAJE

D TOk() iñi()

D P N I E T i

sacar(num-cola, num-lista, elem) Saca el elemento "elem" de la lista "num-lista" de la cola "num-cola". Lo desliga y lo dispone lpara meterlo en otro lugar.

meter(num-cola, lugar, num-lista, elem) Mete el elemento "elem" la cola "num-cola", en la posición "lugar" de la misma cola. Antes de meter un elemento deberá ser sacado de su sitio original.

transmite() Contiene el protocAlo de transmisión. mensajes.

de la lista señalada por el argumento "num-lista" de

Se encarga de la transmisión de

Página 48

pausa(int segundos) Impulsa una Cuenta de tiempo en segundos cuando se detecta un mensaje de tip0 "T", esa cuenta es leída cada ciclo de recepción. En cuanto empieza la Cuenta se prende una bandera de fase de reconfiguración de token "T RECONF". Cuando se ha cumplido la cuenta, se apaga la bandera y puede empezar otra fase igual.

busca(num-cola, num-lista, id F, no-Sec, sent-bua) Busca un mensaje cuyo encabezado sea igual a SUS argumentos y regresa el número del lugar donde se encuentra el mensaje pedido, o "-1" s i no lo encuentra. Cuando "sent bus" es "+1" se efectúa la búsqueda hacia adelante, y

~~ ~ ~

si es "-l", será hacialatrás.

prog-msj(Char Tipo, int IDENT, int SEC, int sec-glb, char*msj) Programa un mensaje para ser transmitido posteriormente, con el encabezado definido por los argumhtos. Este mensaje lo coloca en la lista de transmisión TX según la prioridad que tenga respecto a los mensajes que ya están en esa cola.

4.12.- INTERFAZ DE USUARIO

Los servicios que ofrece el sistema desarrollado son los siguientes:

4.12.1.- Ink()

Este es un servicio del sistema que permite iniciar las condiciones de trabajo para entrar a la red. En este proceso se lleva a efecto la definición del nombre, grupo, modo de transmisión, No. de Network Control Block, No. de nodos en la red, etc. por parte del nodo que la llama y que se requieren para el desempeño normal de las comunicaciones. Aquí se impulsa la rutina de recepción para que la máquina permanezca en un estado de alerta y recepción. La rutina se debe llamar antes de solicitar cualquier servicio de transmisión o recepción de mensajes o cuando se decida re-iniciar el nodo (desde el punto de 4ista de las comunicaciones). El resultado de la llamada ea "O" cuando se tiene éxito, y "-1" si hay error.

4.12.2.- Trans(*Buffer, num) y Query-Tx().

Este servicio permite; al usuario difundir mensajes en forma segura. Se copia el mensaje del arreglo "Buffer" (estructura de datos de la aplicación), a la cola de transmisión. El tamaño del mensaje está dado por num y será de 1 a 37 bytes. El mensaje es enviado cuando lo decida el PDTF;'ya que éste da prioridad a la recepción. Esto es, la llamada Trans(j es en modo no espera (NO WAIT).

Página 49

El uso de esta llamada requiere de la función auxiliar "QueryTxO" para saber si ya se ejecutó la transmisión del mensaje con éxito. La llamada regresa un "O" si el mensaje ha sido difundido; esto 88, el mensaje ya se encuentra en la lista de "CON-GLB" significando que cuando menos I el nodo Token ya lo tiene en su cola. En caso contrario, regresa un "-1".

Si la función "QueryTx" se llama después de "Trans()" en forma repetida hasta que el mensaje en cuestión sea recibido, se tiene un modo de transmisi6n de Espera (Wait). Pero si se llama a "Trans()" y se continGa de inmediato con el curso del programa, para después llamar a la función "QueryTx" antes de realizar cualquier Otro acción de transmisión y asegurarse que el mensaje previo ya ha sido recibido, se tiene un modo de transmisión de "Espera diferida".

4.12.3.- Recep(id-f, *Buffer).

La llamada Recep requiere de los parámetros "Id f" y "Buffer" que corresponden al identificador del nodo del que se desea recibir eimensaje y el arreglo donde se colocará el mensaje respectivamente. Cuando el identificador fuente (Id-f) es "O" se recibirá el siguiente mensaje sin importar BU fuente. La función regresa un número entero positivo indicando $1 número de bytes del mensaje recibido y es copiado al arreglo Buffer, regresa "O" si no hay mensaje y un número negativo si hay error.

La función Recep es en modo "NO espera"; aunque en este caso no se requiere de una llamada para saber si existe un mensaje; ya que la propia función Recep al regresar un "O" indica que no hay mensaje.

4.12.4.- Info(int var)

Esta función permite al usuario obtener el valor de alguna variable del estado actual del sistema, tal como el número de mensajes en la cola de transmisión del nodo local. Esta información puede servirle para enterarse del estado que guarda el sistema hasta ese momento y poder actuar en consecuencia, por ejemplo si se conoce el nivel de llenado que tienen l a s colas, pueden programarse otro6 mensajes a transmitir o detener tal proceso hasta que la cola de transmisión se vacíe lo suficiente para reanudar la transmisión sin riesgos de sobreflujo.

Página 50

~l llamado maneja un argumento, "var", el cual puede ser distinta de cero cuando se desea adquirir el valor de alguna variable en particuiar y cero si se pretende el despliegue de todas las variables que describen e l estado del sietema global a d OOmO las del nodo en particular. El despliegue de estas variables se eniista mediante un número de inciso que sirve para identificar cada variable y es el mismo que se usaría en forma de parámetro si se solicitara el valor de alguna de ellas en particular.

Las funciones de esta sub-capa que se ofrecen al usuario se presentan en forma de comandos manejados desde compilador Borlandc, las cuales se han explicado en ei apartado 4 . 6 de este trabajo. Para usarlas debe tomarse en cuanta que la funci6n de inicialización forzosamente deberá aplicarse antes que las otras para dar de alta las estructuras y permitir el impulso inicial de la recepcibn.

ES necesario incorporar en el directorio de "includes" el archivo "netbios.h" relacionado con todas las funciones de Net-Bios empleadas en este trabajo. Además se requieren los archivos complementarios "ligas.c", "inicia.c", "recibe.c" y "transmite.c" que contienen todas las rutinas integrantes del trabajo en general, las cuales recomiendo se instalen en el mismo archivo de trabajo del programador. Las rutinas pueden ser instaladas como Rutinas Residentes si se desea. Desde luegotambién se requiere instalar las tarjetas de red con el software asociado, incluyendo el archivo "NETBIOS.EXE' que forzosamente trabaja en forma residente.

A manera de prueba se elaboró un programa que usa el Protocolo de Difusi6n Tolerante a Fallas y que muestra la forma de emplear todas las funciones ofrecidas en este trabajo, llevando a, cabo varias tareas sin necesidad de emplear rutinas residentes.

Página 51

CAPITULO 5. - PRUEBAS

Se hicieron pruebas de todos los elementos del protocolo, especialmente de aquellos detalles que pueden,introducir errores de algún tipo, como la recuperación del encabezado de mensajes, la decisión del tipo de mensaje de control a programar (cuando se es Token), el manejo de cada uno de los "tipos" de mensaje, el procedimiento de recuperación mediante acuses de no recibo y la retransmisión de mensajes antiguos aenerada por el nodo token, así como el procedimiento de restablecimiento de nodo token cuando éste cae.

Durante el desarrollo de estas pruebas se descubrieron y corrigieron algunas deficiencias del software, tanto a nivel de programación como estructural, como es el caso de la inserción de un proceso de actualización que el nodo token debe ofrecer a los nuevos nodos dados de alta en la red (esta facilidad no se tenía originalmente). Esta etapa de la evaluación se dio por terminada sólo cuando el software desarrollado pas6 positivamente todo el conjunto de pruebas diseñado.

Para conocer el estado de las colas en cualquier momento del desarrollo de estas pruebas, se elaboró un programa que presenta los mensajes que contiene cada lista, en el mismo orden en que se encuentran dentro de ellas. Por ejemplo, después de llevar a efecto la prueba de recuperación de algunos mensajes conocidos, estos deberán aparecer en la lista de "LLEGADA" de cualquier nodo. De esta forma se puede conocer el resultado de las pruebas en que el ,contenido de alguna de las listas debe sufrir un cambio esperado; y esto es casi en todas las pruebas que se realizaron para evaluar las diferentes etapas del proceso de recepción y transmisión de mensajes.

Para probar el estado de saturación de laa colas se dio a estas un pequeño tamaño ( 2 0 ) mediante el compiladof. de tal forma que con los mensajes de inicialización y unos cuantos mensajes más, generados desde la aplicación y transmitidos desde cualquier nodo, se pueda lograr la saturación de la cola de recepción (Lista "LIBRES R X " ) . En cuyo caso, según se explica en el capítulo 4, deberá echarse mano de los elementos más antiguos de la lista de "CONSUMO", para destinar sus espacios a nuevos mensajes de recepción; debiéndose observar los cambios correspondientes en las listas "CONSUMO" y "LLEGADA" .

Como el programa de recepción esta contenido en la 'post-rutina' de recepción, "pos-r", que no puede ser corrida paso a paso para su verificación (mediante compilador), fue necesariolcorrerlo en un programa "main" provisional y simular algunas condiciones iniciales, para efectuar pruebas de funcionamiento y verificar así las diferentes funciones del protocolo. De esta forma fue posible concebir un plan de pruebas que mostrara, paso a paso, el comportamiento del software ante los diferentes tipos de mensaje, bajo condiciones de trabajo fáciles de propiciar. También se probó el conjunto de programas integrados en su estructura definitiva, instalados en una red de dos nodos, según se explica en los párrafos siguientes.

Página 52

La primera serie de pruebas fueron llevadas a cabo utilizando dos máquinas PC, una de las cuales, el nodo "E", tenía el software de recepción (Protocolo) en un programa "main" provisional y la otra tenla un programa especlal para programar y transmitir la trama de uno o varios mensajes.

Para este plan de pruebas se diseñó un formato general estructurado para Contener la información siguiente:

a) Objetivo pretendido en la prueba.

b) La parte izquierda del formato dedicada a información relacionada con los mensajes transmitidos desde el nodo " A " , como el encabezado y la secuencia planeada.

C) La parte derecha del formato dedicada a información referente al nodo receptor "9" . En el cual queda asentado el conjunto de condiciones bajo las que trabaja el nodo, las acciones esperadas de él.

d) Un espacio final dedicado a los resultados reales obtenidos, así como las observaciones pertinentes al caso.

En las secciónes 5.1 y 5 . 2 siguientes se presentan la mayoría de las pruebas hechas, bajo el formato antes mencionado.

Página 53

5.1.- PRUEBAS PARA NO TOKEN

PRUEBA 1 ===========

OBJETIVO: VERIFICAR QUE UN MENSAJE TIPO 'D' SEA RECIBIDO Y PERMANEZCA EN ESPERA DE SU ACUSE DE RECIBO.

. NODO "B" NODO "A" ....................................................................................... __________-___--__--__------'---------------------------------------------- ACCIONES PROPICIADAS:

Transmisión de mensaj'e: Tipo id-f no-sec .n-s-glb D 1 1 -1 Recibir .......................................................................................

ACCIONES ESPERADAS: I .......................................................................................

- Analiza el tipo de mensaje - Deberá pasarlo de la lista de LLEGADA a la de SIN - GLB.

....................................................................................... RESULTADOS Y OBSERVACIONES:

El mensaje NO apareció en la lista de SIN-GLB como se supone, en espera de recibir un mensaje tipo "P" correspondiente para adquirir su número global.

Al hacer un seguimiento de las acciones del protocolo en la sección relacionada, se descubrió un error en la,asignación del n-s-glb del primer mensaje por recibir. Para solucionarlo, se asignó el valor de' cero "O" a N - S-GLB desde el proceso de inicialización. .................................................................... _ _ _ _ _ _ _ _ _ _ _

Página 54

PRUEBA 2 ========

OBJETIVO: VERIFICAR QUE UN MENSAJE TIPO 'N' SEA RECIBIDO Y ELIMINADO (CASO NO-TOKEN).

ACCIONES ESPERADAS; ....................................................................................... - Analizará el tipo - Eliminará mensaje 'N' pasando la celda de la lista de LLEGADA a la de LIBRES-RX.

LLEGADA a la de LIBRES-RX. - MI-ID = 2 . - NOD-IN1 = 1.

Página 5 5

Esta prueba se diseñó inicialmente con un n-s-glb = 4 > O, en el mensaje "I" transmitido, tal como se observa aqui, porque aun no se contemplaban acciones de actualización para los nodos recién ingresados. Lo que se hacfa entonces era actualizar el N-S-GLB local y proseguir con la recepción de los mensajes siguientes. En este Caso, se apreciaron los valores correctos de MI-ID = 2, NOD IN1 = 1, sin embargo el mensaje "1" anarer ih en la lista de LLEGADA, debido a un error de programación que evitaba la -c------ ~ ~

eiiminación del mensaje recién llegado.

Cuando se incorporó la actualización de nodos recién aceptados, en esta prueba se tuvo que colocar un n-s-glb de valor'cero' (para el mensaje ".I") si no se desea e entrar al algoritmo de actualización, en el cual, el nodo no-token programa un mensaje de acuse de no recibo (tipo N) asumiendo que le faltan los primeros 4 mensajes.

OBJETIVO: VERIFICAR QUE EL MENSAJE TIPO 'i' SEA RECIBIDO, CONTADO Y ELIMINADO.

NODO ' A ' NODO 'B' ....................................................................................... ....................................................................................... ACCIONES PROPICIADAS

Transmisión de mensaje: Tipo id-f no sec nsglb i 3 0 -1

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

....................................................................................... ACCIONES ESPERADAS;

- Se analiza el tipo - Cta i ++, - Se elimina msj tipo 'i', pasando celda de lista

Este mensaje se programa desde la inicialización de cualquier nodo y es enviado "N" veces en espera de un mensaje tipo "I". La prueba no presentó problemas, observándose el valor de Cta i = 1, y el mensaje 'i' en la cola de LIBRES RX. - ....................................................................................... -

Página 56

OBJF.TIV0: VERIFICAR QUE EL MSJ. TIPO 'T' SEA RECIBIDO Y GENERE UN MENSAJE TIPO EN LISTA DE TX.

'T'

RESULTADOS Y OBSERVACIONES

En esta prueba se introdujeron las condiciones iniciales, para los casos de nodo único y no único. En el primer caso, se supone que el nodo ha mandado una serie de mensajes tipo 'i' sin respuesta y programa uno tipo 'T'. Entonces al recibirlo deberá aparecer: NOD-IN1 = 1, MI-ID = 1, CTA-ID = 1 y el mensaje "T" recién llegado en la lista de LIBRES-RX.

Las primeras veces que se corrió esta prueba aparecieron con los mismos valores de la inicialización (valor cero), pero después de corregir la asignación de estos valores dentro del programa (que no estaba) y volver a correr la prueba, aparecieron con sus valores correctos.

En el segundo caso, en el que se supone que una anomalía en el trabajo del Token propició la fase de renovación del mismo mediante este mensaje, deberá aparecer la variable T-RECONP = 1, y aparecerá en la lista TX un mensaje tipo "T" programado por el nodo local (ID-F = MI-ID). con el número de secuencia propio instalado en el mensaje (N-S-GLB = n-s-glb), además el mensaje "T" recién llegado aparecerá en la lista LIBRES-RX. Lo que se observó fue que @1 mensaje apareció tanto en la lista de LIBRES-TX como en la lista TX. Esto debido a que inmediatamente después de eliminarlo, se volvia a programar otro mensaje tipo "T" porque la máquina entraba a un "if" exclusivo del nodo Token (erróneamente), en el que se programa un mensaje tipo "T". Se corrigió la condición "if" errónea. Pero además, debido a que la bandera de fín de retardo ,"cta t", no se había considerado, T-RECONF permaneció con valor "1". A l introducir el programa de temporización, dicha band@ra se restableció al concluir el tiempo (Poniendo a T - RECONF = O) y se eliminó el problema.

Página 57

Por otro lado, aunque al depurar el software para esta prueba corrió adecuadamente, no obstante en pruebas distintas posteriores se descubrió la necesidad de dividir la fase T-RECONF en dos partes, T-RECONF 1, cuando ei'proceso de renovación de token se encuentra dentro del tiempo de retardo dado para que participen todos los nodos de la red, y T-RECONF = 2 , cuando recién se ha dado de alta al nuevo nodo token y existen mensajes tipo "D" en la cola SIN-GLB que requieren ser atendidos con prioridad. .......................................................................................

OBJETIVO: VERIFICAR QUE EL MENSAJE DE TIPO 'E' QUE NO ES PARA EL NODO LOCAL, SE ELIMINA.

NODO ' A ' NODO "8"

ACCIONES PROPICIADAS ~~~~

Transmitir mensaje: SE FORZA POR COMPILADOR: Tipo id-f no sec n-s-glb HI-ID = 2 .

RECEPCION E 4 -1- 90 ....................................................................................... ACCIONES ESPERADAS .......................................................................................

- Analiza el tipo - Eliminará mensaje 'E' pasando celda a lista de LIBRES-RX. .......................................................................................

RESULTADOS Y OBSERVACIONES

Originalmente, en el protocolo no se contemplaba comunicar a los nodos relacionados, acerca de los diferentes tipos de error que detecta el nodo token. Sólamente se tomó en cuenta el caso de error por mensaje tipo "N" con secuencia adelantada. Pero no casos de retransmisión de mensajes ya no existentes (muy antiguos), por pérdidas "en caliente" o cuando algún nodo entra a la red cuando se han transmitido ya algunos mensajes (actualización de nuevos nodos). Antes de introducir estos aspectos en el protocolo, las pruebas originales de mensaje de error habían sido dadas por buenas, pero posteriormente debieron ser corridas nuevamente, en sus diferentes aspectos. Sin embargo 1a.parte receptora del protocolo no se vio afectada y se comportó positivamente.

Página 58

OBJETIVO: VERIFICAR QUE UN MENSAJE TIPO ' D ' QUE ESTA ATRAZADO, SEA ELIMINADO POR CONSIDERARLO RETRANSMISION.

Transmitir mensaje: Tipo id-f no-sec n-s-glb

D 2 1 5

FORZAR BAJO COMPILADOR: N S GLB = 8 , RECEPCION

ACCIONES ESPERADAS

- Analizará el t i p o de msj. - Eliminará msj '*D", pasando la celda a la lista LIBRES-RX por considerarlo retransmisión.

RESULTADOS Y OBSERVACIONES

Página 59

OBJETIVO: VERIFICAR LA RECEPCION DE MENSAJES TIPO 'D' EN RAFAGA, Y LOS CORRESPONDIENTES ACUSES DE RECIBO (MENSAJES TIPO 'P'), PARA ACEPTARLOS COMO MENSAJES RECIBIDOS

Transmitir los mensajes: Tipo id-f no-sec n-s-glb

D 1 2 -1 D 3 1 -1 D 1 3 -1 D 4 2 -1

RECEPCION

P 3 1 4 P 1 2 5

y pasarlo a 12 list: de CON-GLB. - Deberá eliminar los msjs. 'P' pasando celdas a la lista de LIBRES-RX. - Deberá vasar los msis. con seciencia gib.,-de la lista de SINGLB a CON-GLB

RESULTADOS Y OBSERVACIONES

En esta prueba se requieren los mensajes tipo "P" correspondientes a los mensajes tipo "D" para simular que el nodo token mandó el acuse recibo de cada uno de ellos ( l o s "O") y así poderlos aceptar en la lista de CONGLB.

Página 60

En la lista de CONGLB aparecieron los mensajes tipo "D" con números de secuencia global consecutivos, desde el No. 1 hasta el No. 5. En la lista de LIBRES-RX apareció la lista de mensajes "P" programados porque todos fueron correctamente desechados después de su tratamiento.

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

OBJETIVO: VERIFICAR QUE UN MENSAJE TIPO 'D' QUE TIENE n s glb ADELANTADO, GENERA UNA PETICIOÑ DE RETRANSMISION.

- Análisis del tipo de mensaje. - Deberá programar mensaje tipo 'N' con n-s-glb =

(Se aprecia en cola de transmisión " T X " )

N-S-GLB.

....................................................................................... RESULTADOS Y OBSERVACIONES

Esta prueba corrió sin errores, observándose el mensaje tipo "D" en la lista de LIBRES-RX y el mensaje tipo "N" en la lista TX. La trama del mensaje tipo "N" contenía el en el bloque N-s-glb, el valor 2 , según lo esperado.

Página 61

OBJETIVO: VERIFICAR QUE UN MENSAJE TIPO 'I' DA DE ALTA ACTUALIZANDO AL NODO LOCAL Y ASIGNA SU IDENTIFICADOR.

Aquí se presenta el caso de la actualización de un nuevo nodo en el momento en que el sistema ya tiene 2 0 mensajes. El Token genera este mensaje en el cual se informa del identificador (Id-f) y del número de secuencia actual (n-a-glb = 2 0 ) . Anteriormente el nodo que recibía este mensaje sólo actualizaba su N-SGLB = 20 y emprendía su trabajo normal de nuevo nodo.

Esta prueba se diseñó nuevamente para actualizar al nuevo nodo, enviándole los mensajes ya existentes. Para modificar el protocolo original en función a esta necesidad fue requerido cambiar el programa incorporando la nueva condición de actualización (cuando recién se da de alta un nodo), en la que debe hacerse una retransmisión desde el mensaje más antiguo y programar un mensaje de error en caso de que ya no existan algunos mensajes.

Se encontraron errores de programación, principalmente por ubicación incorrecta de elementos de decisión ('if') dentro del listado.

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

Página 62

OBJETIVO: VERIFICAR QUE UN MENSAJE DE ERROR DESDE EL NODO TOKEN, DIRIGIDO AL NODO LOCAL, DARA LUGAR AL DESPLIEGUE DE UN MENSAJE DE ERROR. '

NOTA: AQUI, EL APARTADO ID-F SE USA PARA EL DESTINO.

ACCIONES PROPICIADAS; ................................................................................ Transmitir el mensaje: tipo id-f nb-sec nsglb E 2 -1 -1

FORZAR POR COMPILADOR: MI-ID = 2 , RECEPCION

....................................................................................... ACCIONES ESPERADAS; ____________________________-_---_________------_----------__--------------------------

-Análisis del tipo de mensa je. -Pasar mensaje de error (Desplegar mensaje de error) - Se elimina msje tipo 'E' pasando la celda a la lista LIBRES - RX

--------__________--_--_---_------__--_--_--_-_--__-__--_--_-_- RESULTADOS Y OBSERVACIONES

El tipo de mensaje de error se identifica por medio de un código numérico que aparece en la pantalla después de la palabra "ERROR" (ver archivo DEF1N.C). El nodo token escoge código para ser desplegado dependiendo de las condiciones que presente el nodo errado. El mensaje de error apareció en la lista de LIBRESRX y el código de error en la pantalla del nodo "E".

Cuando a esta prueba se le agregó la función del caso de actualizacidn (después de su inicialización) de nuevos nodos que piden mensajes demasiado antiguos para ser recuperados, se prefirió llevar a cabo la prueba con los dos nodoe funcionando con el software completo (recuérdese que toda esta serie de pruebas se realizaron usando la parte receptora del software cargada en un programa "main" provicional). Bajo estas condiciones, el nodo "A" se dio de alta antes que el "B", para forzarlo a ser nodo token, observándose el resultado de la prueba en las listas del nodo "8" : El mensaje de error apareció en la lista de LIBRES-RX y el código de error en la pantalla de este último nodo.

___________________________________________---_________---------------------_--_____---

Página 63

I

5 . 2 . - PRUEBAS PARA EL NODO TOKEN

OBJETIVO: VERIFICAR QUE EL NODO TOKEN GENERE LOS MENSAJES DE ACUSE DE RECIBO (TIPO P) CORRESPONDIENTES A MENSAJES TIPO 'D'.

Transmitir los mensajes: tipo id-f no-sec n-8-glb D 1 O -1

FORZAR MEDIANTE COMPILADOR ID TOKEN = MI-ID, RECEPCION

Al recibir los mensajes tipo "D" se debe buscar por un mensaje de igual Id-f y No-sec para saber si este mensaje ya ha sido atendido, se elimina o se le da tratamiento, según sea el caso. Al correr la prueba el programa "Busca()" no cambiaba su posición hacia la lista CON-GLB (En donde deben estar los mensajes válidos), quedándose en la lista de LLEGADA; por lo tanto encontraba el mismo mensaje recién llegado y el algoritmo equivocadamente desechaba este mensaje sin atenderlo. El error de programación se encontró en el paso del parámetro "num-lista" del programa "busca()", mal dado.

Página 64

OBJETIVO: VERIFICAR QUE EL TOKEN PROGRAME MENSAJE 'I' EL CUAL CONTENGA EL IDENTIFICADOR DEL NODO

RESULTADOS Y OBSERVACIONES

Esta prueba corrió bien bajo las características descritas en estas pruebas, pero al funcionar la red normalmente (con el software instalado en amboa nodos), se observó que por cada uno de los mensajes tipo "i" (se transmite "N" veces) desde el nodo que solicita ser dado de alta, un mensaje "I" correspondiente se generaba por el nodo Token con el correspondiente incremento de "CTA-ID" (la cuenta de nodos dados de alta). El resultado fue que al inicializar el nodo, este aparecía con un número de identificador muy alto. Se tuvo que introducir un retardo de tiempo entre cada retransmisiOn de mensaje tipo "i" para dar oportunidad al Token de procesarlo y responder con un mensaje "I" que detenga la transmisión de otros mensajes "i" desde el nuevo nodo.

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

Página 65

OBJETIVO: SIMULAR UNA AUTORECEPCION DE MSJ. 'P' PARA VERIFICAR SU ELIMINACION.

Analizará tipos de mensaje Deberá pasar el mensaje tipo' 'D' a la lista SIN-GLB. Generará el msj. tipo "P" (Viéndose en la lista Tx) Al recibir el mensaje 'P' lo tomará como autorrecepción y buscara el 'D' correspond. Pegará el n-s-glb del msj. 'P' y pasará éste a la lista de CON- GLB. Eliminará mensaje 'P' de lista LLEGADA pasándolo a la lista LIBRES-RX.

RESULTADOS Y OBSERVACIONES:

Cuando el nodo Token recibe un mensaje que ya ha sido procesado, se encuentra tanto en la lista de CONGLB como en la lista de "LLEGADA". Al ser encontrado en esta última lista por el programa "busca()", se asume que dicho mensaje procede de un nodo que perdió su mensaje "P" correspondiente e insiste en solicitarlo; de otra manera, debe buscarse el mensaje tipo "D" en la lista de SIN-GLB, asignarle número se secuencia global y pasarlo a la lista de CON-GLB. En el segundo caso, objeto de esta prueba, el Token deberá eliminar el mensaje recién llegado, pasando la celda ocupara por él a la lista de LIBRES RX. Sin embargo el nodo bajo prueba ("E") se comportó como si se tratara del primer caso, apareciendo un mensaje tipo "P" en la lista de "TX" con los identificadores del mensaje "D". El problema se encontró en la toma del valor regresado por el programa "busca()", que debe ser "-1" para el caso de no encontrado. Debido a que se interpretó como "UNSIGNED INT" (con valor mayor o igual a "-1") el Token actuó en consecuencia. .......................................................................................

Página 66

OBJETIVO: VERIFICAR QUE EL TOKEN PROGRAMA UNA RETRANSMISION EN RESPUESTA A UN MENSAJE TIPO 'N'.

Transmisión Tipo id-f D 1 D 3 D 5 D 2 P 1 P 3 P 5 P 2 N 7

de los mensajes: no-sec n-s-glb

2 -1 4 -1 4 -1 5 -1 2 6 4 7 4 8 5 9 10 6

FORZAR POR COMPILADOR: ID TOKEN = MI-ID, RECEPCION.

ACCIONES ESPERADAS:

Después de analizar tipos de msjs: Generará los msjs 'P' de los msjs. ' D ' correspondientes. Al recibir los 'P', los tomará como autorrecepción y asignará glb. a los msjs. 'ü' . (Aparecerán en la lista de CON-GLB). Eliminará los mensajes 'P' y 'D'. Al recibir el mensaje "N", deberá programar el mensaje de RETRANSMI- SION, desde el N-S-GLB = 6. (En la lista de TX, aparecerá). Eliminará msj. tipo "N".

....................................................................................... RESULTADOS Y OBSERVACIONES

Debe simularse una llegada previa de mensajes tipo "Do* con sus correspondientes acuses de recibo (mensajes tipo "P") para que existan algunos mensajes en la lista de CON-GLB. De esta forma, cuando se transmita un mensaje de solicitud de retransmisión (acuse de no recibo, tipo "N") podrá darse la retransmisión a partir del global determinado por el mensaje tipo "N". El único problema que se presentó en esta prueba fue la falta de actualización de una variable llamada o'num-ret'* que indica el número de retransmisiones que se deben realizar. Este error originó que el mensaje de retransmisión contenga un número de retransmisiones por realizar igual a cero y pasó desapercibido hasta que dicha prueba se llevó a efecto con la red (Fuera de simulaciones). .......................................................................................

Página 67

OBJETIVO: VERIFICAR QUE UN MSJ TIPO 'D', REPETIDO, ORIGINA LA REPETICION DE OTRO MENSAJE ~~

TIPO "p"

ACCIONES PROPICIADAS _ _ _ _ _ _ _ _ _ _ _ _ ______________________________r_________---------------------------

Transmitir los mensajes: Tipo id f no sec n-s glb

FORZAR POR COMPILADOR: ID TOKEN = MI-ID = 1,

1- 2 -1 N 3 GLB = 3, D P 1 2 4 RECEPCION. D 1 2 -1 .......................................................................................

ACCIONES ESPERADAS ________________________________________----------------------------------------------- - Análisis del tipo - Generación de msj tipo "P.' - Al recibir el msj 'P' se asigna SGLB y se pasa el msj "D" a la cola CON GLB. - Al recibir el otro msj 'D' es eliminado pasándolo a la lista de LIBRES RX y deberá programar un msJ. tipo "P".

................................................................. - RESULTADOS Y OBSERVACIONES

Un mensaje tipo "D" Único, es dado de alta mediante la asignación de su número de secuencia global. Esto lo hace el nodo Token mediante la difusión de un mensaje tipo "P" que contiene tanto los identificadores del mensaje "D" relacionado, como su número de secuencia global. La prueba corrió adecuadamente, apareciendo el mensaje tipo "P" en la lista "TX" del nodo Token ("B"), con los parámetros correctos.

Página 68

OBJETIVO: VERIFICAR QUE MENSAJES DE TIPO 'I' O 'E' SON ELIMINADOS (AUTORECEPCION)

NODO 'A' NODO ' B ' ....................................................................................... ....................................................................................... ACCIONES PROPICIADAS

Trasmisión de los mensajes: FORZAR POR COMPILADOR: Tipo Id-f n-sec n-s-glb ID-TOKEN = MI-ID = 1,

I 3 -1 5 RECEPCION, - E 4 -1 -1 - ...............................................................................

....................................................................................... ACCIONES ESPERADAS

- Después de analizar tipos: - Eliminar ambos mensajes por tomarlos como autorrecepción

....................................................................................... RESULTADOS Y OBSERVACIONES

Los mensajes de tipo I, E, y P sólo pueden ser generados por el nodo Token y .deben ser eliminados pasando la celda correspondiente a l a lista de LIBRES-RX. La prueba corrió positivamente.

Página 69

RESULTADOS Y OBSERVACIONES

Además de aparecer el mensaje tipo V“ en la lista TX, debe apreciarse el valor de las siguientes variables: T-RECONF = 1, ID TOKEN 1. También se deberá entrar a un ciclo de retardo que permita la participac’ión de todos los nodos de la red sin interrumpir la recepción. Esta Última función se puede verificar tambihn con la variable T-RECONF = 1 que está directamente relacionada. Aunque esta prueba no presentó problemas significativos aquí, en el momento de que se dieron los diversos casos de renovación de token previstos por el protocolo, se presentaron problemas de interferencia por parte de los otros mensajes enlistados. Esta deficiencia del protocolo se corrigió asignando prioridades a los mensajes de transmisión, principalmente, con el fin de que loa mensajes sean atendidos según su importancia, como en el caso del tipo “T” que es de máxima prioridad. ......................................................................................

Página 70

5.3.- PRUEBAS GLOBALES

Una vez que se probó y corrigió el software de recepcidn mediante las simulaciones anteriores, se porocedió a instalarlo en la post-rutina de recepción para emprender pruebas globales junto con la parte de transmisión, instalando el programa completo en las dos máquinas ("A" y " 8 " ) . teniendo una bajo compilador para poder hacer un seguimiento paso a paso de la rutina de transmisión (Esta rutina no se instaló como post-rutina).

I

A l igual que en el caso de las pruebas simuladas de la sección anterior, en esta ocasión se encontraron errores de programación que fueron corregidos hasta que el protocolo completo funcionó adecuadamente. Algunas funciones cuyas pruebas que corrieron correctamente en la simulación, presentaron diversas fallas al trabajar en estas pruebas globales, como es el caso de los mensajes tipo "I" y "T" . En algunos casos por tener errores en la parte transmisora del. protocolo (que no se había probado) y otros debido a nuevas consideraciones de interacción en red que no pudieron ser simulados con la velocidad de la máquina (consultar por ejemplo la prueba simulada No. 13, de la sección anterior). Además se simuló el rompimiento del cable coax'ial para probar el protocolo en las siguientes facetas:

a) Desconectar el cable cuando el nodo token envía varios mensajes y después reconectarlo para ocasionar una pérdida de mensajes. En este caso se encontró que el procedimiento de recuperación de mensajes perdidos respondió eficazmente.

b) Desconectar el cable y enviar mensajes desde el nodo que no es token. En cuyo caso ese nodo se proclamó Token pero el token original persisti6; es decir se dieron dos nodos token aun después de reconectar el cable. Para corregir esta situación se procedió a eliminar uno de los token, forzando una fase de reforma de token bajo las condiciones de duplicidad de mensajes "P", "I" o "E" con diferente ID-F ( Mensajes exclusivos del nodo token).

Página 71

CAPITULO 6 . - EVALUACION

6.1.- COMPARACION CON OTROS PROTOCOLOS

Para evaluar el PDTF desarrollado se considera que el uso del mismo es implantar un esquema de MCR, lo cual implica el envío de mensajes Cortos y frecuentes. Esto originó que el tamaño de los mensajes sea constante y del mínimo permitido por el protocolo CSMA/CD utilizado en la red Ethernet.,Esto va en contra de los resultados descritos en [lo] donde se concluye que los tamaños óptimos de los mensajes (desde el punto de vista del uso de la red) son de 1024, 1530 y 2043.

Además la forma en que se efectúa el relevo del nodo token en [ 6 ] requiere de una lista de "L" miembros de la red elegibles a ser nodos Token que deben pasar por un proceso de elección. El algoritmo asegura que dichos miembros poseen todos los mensajes difundidos, teniéndose una resistencia a "L" nodos fallados. En el protocolo implantado se tiene una resistencia con valor igual al número total de los nodos activos.de la red y no es necesario conocer los nodos activos.

Una ventaja del PDTF respecto a los protocolos tolerantes a fallas consultados [ 6 , 7 ] es la forma breve y sencilla en que se lleva a cabo el relevo del nodo Token.

En el protocolo de [ 6 ] los mensajes son transmitidos íntegramente por el Token hacia los demás nodos y no son pasados a la aplicación hasta que la lieta pase tres pruebas de calidad (que asegura que sus miembros tengan todos los mensajes). Además el nodo Token se va rotando entre todos los elementos de la lista en forma periódica. Esto y el complicado procedimiento de elección de la lista de posibles token representa un retardo bastante grande para ser tolerado en aplicaciones de tiempo real. En cambio, en el PDTF presentado aquí basta que se reciba del nodo Token el mensaje de acuse de recibo para que el mensaje correspondiente pueda ser pasado a la aplicación. Por otro lado, sólo cuando el nodo Token falla ea relevado por aquel nodo que tenga el número de secuencia global más grande (cuente con el mayor número de mensajes reconocidos).

Los protocolos "TRANS" y "TOTAL" definidos en [ 7 ] , están pensados para redes muy complejas, en donde conviene un agrupamiento de todos los nodos de la red en sub-redes y el establecimiento de dos niveles de secuencia: parcial y total. En estos protocolos se presenta un método de secuenciamiento global basado en la precedencia que los mensajes tienen entre si, sin considerar que los mensajes pueden recibirse a destiempo y ocasionar cambios en la precedencia original. En el protocolo presentado en este trabajo, el orden se basa en una numeración secuencia1 global que prospera conforme los mensajes se van generando por las aplicaciones, y la pérdida de mensajes es fácilmente detectada y corregida.

La pérdida del nodo Token es detectada por cualquier nodo que envíe un mensaje y no recibe el acuse de recibo correspondiente en un tj.empo determinado y este nodo inicia la reconfiguración del Nodo Token.

Página 72

En el protocolo desarrollado, el número de mensajes para transmitir una informacidn es de dos: la información del nodo fuente a todos y el acuse de recibo del Nodo Token a todos; el nodo fuente, al recibir el acuse de recibo sabe que su mensaje ha sido registrado al menos en otro nodo (el Nodo Token); los demás nodos, al recibir el acuse de recibo saben si perdieron mensajes previos y sólo en caso afirmativo se requiere de un mensaje de acuse de no recibo y la retransmisión de mensajes de información. En cambio, en el protocolo [ 6 ) , para una difusión,sin pérdida de mensajes, se efectúan tres mensajes; el de información del nodo fuente al Nodo Token, el acuse de recibo del Nodo Token al nodo fuente y el de difusión del mensaje a los demás nodos.

6.2.- TIEMPO DE RESPUESTA

El PDTF servirá de base para la emulación de una MCR. Esto exige la mayor rapidez posible en los accesos a la MCR y por lo tanto es necesario estimar el retardo en el proceso de emitir un mensaje y que sea recibido por la aplicación. Además, téngase presente que los accesos a MC para lectura no tienen interés bajo este contexto porque no implican acciones a través de la red, obteniéndose solamente una información a nivel local.

Para efectos de implantar la MCR, antes de leer un valor de ésta se requiere que no existan mensajes en las colas de transmisión v receDción del DroDio nodo a fin de

~ ~ ~~~ _ _ -~~ asegurar la consistencia de los datos leídos (cadi mensaje generado en cualquier nodo se debe reflejar en un cambio en la MCR).

Desde el momento en que se manda un mensaje hasta que se recibe el acuse de recibo correspondiente (se ejecuta el PDTF), se producen retardos que determinan la eficiencia del PDTF durante la operación normal. Estos retardos se expresan como sigue:

Tretar = TmSj + Tcol

Donde:

Tmsj e5 el tiempo consumido para los algoritmos del PDTF,

Tcol es el tiempo perdido por efectos de colisiones en la red.

llevado a cabo en los nodos, principalmente en el nodo token.

El valor medido de Tmsj cuando no hay colisión en la red fue encontrado experimentalmente dando 0 .4 mSeg. Este retardo de tiempo se midió mediante una red con dos nodos; uno fuente que envió mensaje en modo Espera y el otro operó como Nodo Token Únicamente (genera. los acuses de recibo) esto aseguró la ausencia de colisiones.

Página 73

Para estimar el valor de Tcol debemos tomar en cuanta las Siguientes premisa5 que resultan de las características del PDTF, aplicación y loa recursos utilizados:

a) Para las aplicaciones de MCR, el número de nodos es pequeño,

b) El tamaño de grano para nuestro caso es constante, de 64 bytes

c) La velocidad de transmisión de la red es de 10 Mbytes por seg.

alrededor de 10.

por mensaje.

El tiempo necesario para mandar un mensajes de 64 bytes, a la velocidad anterior es: (64 bytes)(lO Mb/seg) = 64 psegs. Y considerando el ciclo completo para la difusión el retardo.será:

Tgrano = 128 pSeg.

En [ill se presenta un análisis del comportamiento de las redes Ethernet con protocolo CSMA/CD donde se define "a" como:

Tiempo de propagación

Tiempo de transmisión a =

El rendimiento " S " se evalúa en función de "a" y del número de nodos "N" cuando se presentan colisiones (Esta es una función inversa del tiempo promedio de acceso a la red). Para los datos considerados S = 0 . 5 5 ; esto implica que el tiempo promedio de acceso se degrada casi al doble (1-.82 veces).

A s í que el tiempo que se incrementa la transmisión de un mensaje (de 64 bits) por colisiones, e8 en promedio:

Tcol = Tgrano(0.82) = 105 pseg. Por lo tanto Tretar = 0.505 mseg.

El retardo por retransmisión de mensajes "Tretran" está limitado por el tamafio del buffer "M" de mensajes recibidos (en este caso 100) debido a que es el máximo posible que puede tener cada nodo. Como cada mensaje tarda un tiempo "Tmsj" y el peor caso de retransmisión sería de todo el contenido del buffer, el tiempo correspondiente sería de:

Tretran = MTmsj. Que en este caso:

Tretran = iOO(0.4) = 40 mSeg.

Página 74

Esto debido a que durante la fase de retransmisi6n de mensajes el PDTF asegura que sólo el nodo token transmite.

La fase de renovación de nodo token se presentan muy roamente. En Su caso, el tiempo "Ttok" de retardo requerido para ello depende del número de nodos activos en la red y que pueden participar en una subasta para el puesto de Nodo Token, que es el peor caso (desde el punto de vista de retardo). En el peor caso cada uno de ellos enviará su mensaje tipo "T", resultando que el retardo de la fase es de:

Ttok = N*Tretar = 10*(0.505) = 5.05 mseg

Este parámetro servirá para ajustar el temporizador de PDTF que debe esperar cada nodo por la llegada de mensajes tipo T durante el proceso de reasignación de nuevo nodo token.

Página 75

CAPITULO 7.- CONCLUSIONES

El protocolo desarrollado se considera mejor que los consultados en la bibliografía desde los puntos de vista de la complejidad de implantación [ 7 ] y número de mensajes a transmitir durante la operación normal 1611 ein embargo, el tiempo de ciclo de transmisión-recepción en un mensaje del PDTF parece excesivo para la aplicación de MCR en comparación con los retardos correspondientes a un esquema desarrollado por hardware 1121, donde son del orden de 1.6 a 5 pSeg. (El mejor caso de nuestro protocolo es de 400 pSeg).

Por otro lado, el retardo por retransmisión debido a pérdida de mensajes no es crítico ya que 40 mSeg para una recuperación es aceptable en muchos sistemas de tiempo real y el tiempo de reconfiguración debido a la pérdida del Nodo Token es pequeño, lo que nos da una ventaja para el PDTF.

El uso p'ara el cual se pensó el PDTF es la implantación de una MCR. Si bien, para esta aplicación no parece alentador, debido al valor de Tretar, para otro tipo de aplicaciones, donde se requiera la difusión conf iable de información, es altamente alentador; como se propone en [ 9 ] para lograr un estándar de difusión de información aplicado a redes de computadoras usadas en la supervisión de sistemas de generación y distribución de energía eléctrica (SCADA).

Otra aplicación de este protocolo sería para sistemas de tiempo real donde se maneje el concepto de Tiempo Disperso (131; como lo sugieren recientemente Kopetz y Grunsteild [141 al proponer un protocolo accionado periódicamente (time triggered protocol), donde la información se difunde periódicamente y no bajo demanda.

Podría aumentarse la capacidad de recuperación actual de mensajes perdidos, apoyándolo con manejos de archivo en disco (real o virtual) para guardar los mensajes más viejos ,del proceso, de tal manera que la disponibilidad histórica tienda a la totalidad.

Para no asignar el cargo de Token a nodos que han presentado anomalías en su comportamiento, podría ser conveniente llevar algún tipo de estadísticas de la conducta de los nodos durante todo el trabajo, para restar oportunidad a io6 nodos deficientes y así fortalecer la decisión del protocolo en la asignación del cargo de Token, durante la fase de renovación del mismo.

Página 76

En los casos de desconexión física del cable por algún tiempo 't', se daría el fendmeno de la segmentación de la red en dos o más sub-redes, cada una de las cuales tendría su propio nodo Token y su historial de mensajes fluyendo durante el período de tiempo 't' que dure la desconexión. En cuanto la conexión se restablezca, las redes tendrían que ser capaces de detectar la duplicidad de mensajes de control exclusivas del Token, (y así también detectar la duplicidad de nodos Token), emprendiendo la fase de renovación de ese cargo. Tendrían que retransmitir sus mensajes generados durante ese periodo de tiempo para incorporarlos con una nueva secuenciación global. Desde luego que en este caso, la secuencia real con que fueron generados esos mensajes, se perdería.

Si se tratara de aplicaciones donde la ausencia de loa mensajes en algunos nodos puede pasar desapercibida (dentro de cierto margen de tiempo), como en "mensajería", podría no ser muy importante el orden de loa mensajes a lo largo de ese intervalo de tiempo, pero pueden haber aigunas otras aplicaciones, en que el orden resulte vital, como en supervisión y control de procesos.

Podría asignarse la cuenta de tiempo real en vez de los números de secuencia global manejados en este protocolo, como un intento de establecer una secuenciación absoluta y así poder recuperar la posición de cada uno de loa mensajes en el momento del restablecimiento. Aunque persiste el riesgo de que algunos mensajes sean tomados fuera de su secuencia real, como en el caso de que se hayan dado en distintas sub-redes en forma simultanea (o casi simultanea), sin embargo este riesgo decae drásticamente en función de la definición y exactitud de los relojes en las máquinas.

Aunque se ha tenido cuidado en reducir al mínimo el tiempo invertido en el tratamiento de los mensajes, evitando las copias físicas de registro a registro por ejemplo, considero que podría mejorar la velocidad del procesamiento de los mensajes apreciablemente, programando las rutinas en lenguaje ensamblador.

Página 77

I

CAPITULO 8.- REFERENCIAS

1 -

2 -

3 -

4 -

5 -

6 -

7 -

8 -

9 -

10.-

11.-

12.-

13.-

14.-

Varios autores, "Requerimientos Funcionales de un Sisteina de Control Distribuido para Plantas Termo-Eléctricas Normalizadas", Reporte del Proy. 2457, del Depto. de Simulación, DSP, IIE, Versión 2, Feb. 1991. Javier Moreno, Enrique Ruiz y Carlos Ramírez V., "Flujo de Información entre los Nodos del SADRE en Ambiente Distribuido", Reporte Proy 2813, Depto. de Automatización de Procesos, DSC, IIE, Junio 1991. Javier Moreno, Enrique Ruiz y Carlos Ramirez V., "Arquitectura del SADRE en Ambiente Distribuido", Reporte Proy. 2813, Depto. de Automatización de Procesos, DSC, IIE, Mayo 1991. Carlos Ramírez Valenzuela, et al., "Memoria Compartida entre PCs", Memoria de la XI1 Reunión Académica de Ing. Electrónica Electro 91, 21-25 Octubre 1991, ITCh, Chihuahua Chi., pp 67-82. Bill Nitzberg and Virginia Lo, "Distributed Shared Memory: A Survey Of Issues and Algorithms", Computer, August 1991, pp 52-60. Chang, J 6 Maxemchuk, N F, "Reliable Broadcast Protocols", ACM Trans. on Computers, Vol. 2, No 3 , August 1984, pp 251-273. Melliar-smith et al, "Broadcast Protocols for Distributed Systems", IEEE Trans. on Parallel and Dist. systems, Vol. 1, No. 1, Jan. 1990, pp 17-25. Narayan, A. P., "Reliable Multi-Destination transfer of Data in a Local Area Network", Phoenix Conference on Computers and Communications, March 27-30, 1991, IEEE, pp 681-687. P.Emmerich and J. Britton, "Benefits, Problems, and Issues in Open Systems Architectures". (93 WM 163-6 PWRS) IEEE. 1993 Paramesh Vaidyanathan, Scott F. Midkiff Performence Evaluation of Communication Protocols for Distributed Processing Computer Communications Vol. 13 No. 4 Junio 1990. William Stallings, "Local Network Pwerformence". IEEE Communications Magazine, February 1984 - Vol. 22. No.2. Sereno Peñaloza, Oracio "Diseño de una Red de Multiprocesamiento para PCs", Tesis Lic. IPN, ESIME Unidad Culhuacan, 12 julio 93. Hermann Kopetz, "Sparse Time Versus Dense Time in Distributed Real-Time Systems'. 12th Int'l Conf. Distributed computing Systems. IEEE Press, LOS Alamitos, Calif. Order No. 2865, 1992, pp. 460-467. Hermann Kopetz L Gunter Grunsteid, "TTP A Protocol for Fault-Tolerant Real-Time Systems", Computer, Vol 27. Num. 1, January 1994, pp 14-23.

Página 78