Embed Size (px)
Citation preview
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS ESTADO DE MÉXICO
ESTUDIO E IMPLANTACIÓN DE ALGORITMOS DISTRIBUIDOS A REGIONES.
TESIS PARA OPTAR EL GRADO DE MAESTRA E\: CIENCIAS DE LA COMPUTACIÓN
PRESENTA
GABRIELA DE JESÚS MAGALLANES GONZÁLEZ
Asesor: Dr. ROBERTO GÓMEZ CÁRDENAS
Comité de tesis: Dr. Eduardo García García Dr. José de Jesús Vázquez Gómez
Jurado: Dr. Eduardo García García Dr . .los\? de Jesús Vázquez Gómez Dr. Roberto Gómez Cárdenas
Presidente Secretario Vocal
A TIZAP.Á:'\ DE ZARAGOZA, EDO. '.\1ÉX., ENERO DE 2002.
CONTENIDO
1. INTRODUCCIÓN. ESTUDIO E IMPLANTACIÓN DE ALGORITMOS DI STRI B L71 DOS A REGIONES ............................................................................. 4
2. SISTE\1AS DISTRIBliIDOS ........................................................................... 6
2.1 LOS SISTEMAS OPERATIVOS DISTRIBUIDOS Y LOS SISTEMAS OPER . .\. TI\ºOS DE RED ............................................................................................................... 7
2.2 2.2. 1 -, -, -,
2.3 2.3.1 -, , -, __ J,_
-, , , - . ·'. ·'
2.4 2.4. 1 2.4.2
2.4.3
LA CO!\IUNICACIÓN ..................................................................................................... 8 SOCKETS ................................................................................................................... 8 REMOTE PROCEDURE CALL -RPC-..................................................................... 9
CLIEl\TE / SER\'IDOR ................................................................................................. 10 VE!\JTA.JAS Y DESVENTAJAS DE UN SISTEMA CLIENTE i SERVIDOR ...... 11 CLIENTE SERVIDOR Y LOS SISTEMAS ABIERTOS ........................................ 13 ESQUEMA DE COMC'.'JICACIÓN CLIENTE/ SERVIDOR ................................ 13
,\LGORITJ\10S DISTRIBUIDOS ................................................................................. 15 CUALIDADES DE UN ALGORITMO DISTRIBUIDO ......................................... 16 PRINCIPALES TÉCNICAS USADAS EN LOS ALGORITMOS DISTRIBUIDOS 17 ESTRUCTURAS DE CONTROL .................. ...... ... ...... .. ......................................... 17
3. LLAJ\c1ADAS A PROCEDIMIENTOS REMOTOS -RPC-........................ 19
3. 1 USO , .. .\CCESO ............................................................................................................. 20
3.2 EL P . .\SO DE P,\R.Ál\lETROS ...................................................................................... 21
3.3 LOS STUBS (C,\BOS) .................................................................................................... 21 3.31 FL'.1\CIO\:ES XDR ................................................................................................... 22 3.3.2 LOS FILTROS ............. ....................... .. .......................... ............................ .. ............ 24
3.4 ¡,CÓl\10 SE GE'.\ERAN LOS_"STUBS"·(CABOS)'? ................................................... 25 3.4.1 GE1\ERACIÓ1\ AL:T0\1A TIC A ............................................................................. 25 3.4.2 GEl\ERACIÓJ\ DE "STL1Bs·· A TRAVÉS DE FL'J\CIONES DE AL TO J\IVEL. 26 3.4.3 E.JP,1PLO: RUTI:'\A REMOTA EN EL SERVIDOR (ALTO NIVEL) .................. 28 3.4.4 GE1\ERACIÓ1\ DE STLBS A TRAVÉS DE FUNCIONES DE BAJO NIVEL ..... 28 .~.4 =' E.JE\1PLO: L\: CLIE\:TE LLA\!1A AL'?\ SERVIDOR (BAJO l\IVEL) ............... 30
3.5 TOLER . .\.'.\CI . ..\. . .\. F . .\LL . ..\.S ........................................................................................... 32
2
3.5. l CAÍDA DEL SERVIDOR ......................................................................................... 32 3.5.2 CAÍDA DEL CLIENTE ........ .......... ........ ... ............................................................... 33
3.6 SEGURIDAD ................................................................................................................... 34
3.7 UN RPC QUE LLAMA A OTRO RPC ......................................................................... 35
3.8 RPC . .\SÍ'.\CRO:\O .......................................................................................................... 35 3.S. l LOS RPC NO BLOQL'EA:,;TES .............................................................................. 36 3.S.2 C ALLBACK RPC ......................................................................................... ............ 37
3.9 DISE:\A'.\DO C'.\A APl,ICACIÓ:\ DISTRIBUIDA ................................................... 45
.t. LA RECURSIÓl\ COMO l'\' ESTILO DE PROGRAl\1ACIÓ:\' DENTRO DE LOS SISTEl\1AS DISTRIBL'IDOS ............................................................... .48
.t. l DEFINICIÓ'.\ ALGORIT!\10 DE OLA ........................................................................ 49
.t.2 DETECCIÓN DE TER!\11'.\ACIÓN .............................................................................. 50
..i.3 L . .\ OL . .\ RECURSl\'A ................................................................................................... 51 -L3 l DEFJ;\JCIÓ\: DE L'.'\.'\ OLA RECURSIVA ........................................................... 52
-+.3.1.1 Primiti\·a de Concurrencia ..................................................................................... 52 ..i._1.1.2 Sintaxis del RPC .................................................................................................... 53 -+.3.1.3 Esquema General de la Ola Rccursi\'a ......... ........ ....... .......................................... 53 4.3.1.4 La Ola Recursi\·a Secuencial ................................................................................. 54 4.3.1.5 La Ola Recursi\'a sobre una Topología de Árbol ........ .............. ....... ........ ........ ..... 55 4.3.1.(1 La Ola rccursi\a Inundantc .................................................................................... 56
4.3.1.6.1 Especificación de la Ola Recursiva Inundante 57
5. LOS ALGORITl\10S A REGIONES: ESPECIFICACIÓN E '
l\1lPLA~TACION .................................................................................................. 59
5.1
- .., ::,. __
CARACTERÍSTICAS DE LOS ALGORITl\lOS l\1UL TI-OLAS ............................. 59
TER\lINOLOGÍA \' CO:\SIDERACIONES .............................................................. 59
5.3 5.3.1
EL PROBLE!\IA DE ELECCIÓN\' DE COBERTL'R.\ ............................................ 60 LA BAJADA ............................................................................................................. 61
5.3.2 LA ESTRATEGIA DE VISITA .................... .................... ...... .................................. 61 5.3.2.1 Actualización del Padre ...................... ...................................................... ............. 61 5.3.2.2 Los sitios a Visitar ................ ...................... ...................................... ..................... 62 5.3.2.3 Cálculos de los Hijos ................................. .. ................................................... ....... 64 5.3.2.4 Condición de Paro de la Ola ....... ........ ................................................... ................ 64
5.3 .. 1 L.A.. RE\10:\T . .\D.~ .......................................................... ......................................... 65 5._1 .-I LA SL'BIDA .................................................................................................... .......... 66 5.3.5 DEFII\JCJÓ~ DE PARA\1ETROS ............ ................................ ...... ........................ 66
3
5.3.6 LAS VARIABLES ........................................................................ ..................... ....... 67 5.3.6.1 Definición de datos estáticos ................................................................................. 67 5.3.6.2 Definición de datos dinámicos ................................................................... ........... 67 5.3.6.3 La coherencia de los datos ..................................................................................... 68
5.3. 7 PSEUDO-CÓDIGO DEL EJEMPLO ....................................................................... 69
5.4 IMPLANTACIÓN DE UN ALGORITMO MUL TI - OLAS ..................................... 70 5.4.1 EL ALGORITMO DE INTERCAMBIO DE INFORMACIÓN ............................... 72 5.4.2 PARAMETROS DE ENTRADA Y SALIDA PARA LOS PROCEDIMIENTOS REMOTOS ................................................................................................................................ 73 5.-l.3 REClJPERACIÓN DE ERRORES ........................................................................... 73 5.4.4 PRUEBAS DE LA APLICACIÓN DISTRIBUIDA ................................................. 74 5.4.5 EL CÓDIGO DEL ALGORITMO ............................................................................ 74 5.4.(1 NIVEL DE SEGURIDAD ......................................................................................... 76
6. CO"CLUSIO~ES ........................................................................................... 77
ANEXO A. LISTA DE EQUIPOS UTILIZADOS .............................................. 79
B I B LI OG R .. t\.FI A .................................................................................................... 80
l. INTRODUCCIÓN. ESTUDIO E IMPLANTACIÓN DE ALGORITMOS DISTRIBUIDOS A REGIONES
4
Los sistemas distribuidos aparecen a raíz del desarrollo de las redes computacionales y de las computadoras a multiprocesadores. Si bien la aparición de estos dos eventos ha sido crucial en el desarrollo de la informática. la gestión de todos los recursos, tanto en un área como en la otra requiere de conocimientos a tomar en cuenta. Los sistemas distribuidos tienden a reunir todos los conocimientos necesarios en las dos áreas.
Por las características que distinguen a los sistemas distribuidos, se exige para su desarrollo el uso de algoritmos especiales exclusivamente disefiados para estos sistemas. Estos algoritmos reciben el nombre de algoritmos distribuidos. Los algoritmos distribuidos difieren de los algoritmos com encionales en que esos últimos se usan para sistemas de cómputo local, mientras que los primeros están enfocados a ser usados en sistemas distribuidos.
El término cómputo local se refiere a los programas que están confinados a un solo espacio de direcciones. mientras que el té1111ino de cómputo distribuido se refiere a programas que hacen llamadas a otros espacios de direcciones. posiblemente en otra máquina. Es decir, los algoritmos secuenciales y paralelos pueden ser \·istos como recipientes que transfomrnn entradas (datos), proporcionadas al principio. en salidas producidas al final del algoritmo. Los algoritmos distribuidos se ejecutan en procesos de sistemas cuyos elementos de procesamiento se encuentran físicamente separados. y sin·en para garantizar un comportamiento deseado del sistema.
Si definimos al proceso que inicia el cálculo distribuido como iniciador, podemos decir que los algoritmos distribuidos a regiones son aquellos donde existe más de un proceso iniciador, fomrnndo por cada iniciador una región. Nos enfocamos al estudio e implantación de este tipo de algoritmos bajo un esquema de programación llamado Ola recursiva.
Durante el trabajo se realizó un estudio completo sobre los algoritmos distribuidos por regiones. Estudiando la conveniencia de su uso. y bajo que circunstancias se pueden presentar. También se lle\Ó al cabo un análisis fonnal de calculabilidad y complejidad. así como un estudio empírico de los algoritmos a regiones.
Por último. en hase al esquema de programación distribuida tipo ola recursiva se implantó un algoritmo a regiones para analizar su comportamiento.
Para implantar y probar estos casos de estudio se disei'ló e implantó los algoritmos a estudiar en un ambiente de red en los laboratorios ITESl\1 CE\1 en platafomrn U:\"IX y usando como
lenguaje a e.
5
El trabajo se encuentra dividido en 5 capítulos. En el primero de ellos se dan a conocer todas las características de los sistemas y algoritmos distribuidos. En el capítulo dos se explican los
algoritmos tipo ola, haciendo énfasis en la ola recursiva. El capítulo tres se habla todo lo concerniente a la herramienta que se utilizó para implantar el sistema, RPC (llamada a procedimientos remotos). La implantación y análisis de los algoritmos a regiones se lleva al cabo
en el capítulo .cuatro. Por último, en el capítulo seis se presentan las conclusiones y el trabajo a futuro.
6
2. SISTEMAS DISTRIBUIDOS
Es importante hablar de los sistemas distribuidos y los algoritmos asociados a estos sistemas por tratarse de los conceptos en los cuales está basado este trabajo. El objetivo de este capítulo es tener un bosquejo general de los conceptos utilizados para que al describir el proyecto éste resulte de más fácil compresión.
Un sistema distribuido es una colección de interconexiones de computadoras, procesos o procesadores (referidos corno los nodos del sistema distribuido) interconectados entre sí. Para ser considerados como autónomos, los nodos deben contar con control privado. Para ser considerados corno interconectados, los nodos deben ser capaces de intercambiar infomrnción.
Como los procesos (sofü,·are) pueden tomar el rol de nodos de un sistema distribuido, la definición incluye sistemas de software construidos como una colección de procesos de comunicación. En muchos casos, un sistema distribuido contendrá varios procesadores, interconectados por la comunicación por hardware.
Los sistemas distribuidos nacen en un ambiente de cómputo debido a alguna(s) de las siguientes necesidades:
• Intercambio de infom1ación. La necesidad de intercambiar datos entre computadoras diferentes.
• Compartir recursos. una pequei'la escala de cada computadora puede confiarse a servidores dedicados a pro\'eerlos con compi !adores y otras aplicaciones.
• Incrementar confiabilidad a tra\·és de la replicación. Los sistemas distribuidos tienen el potencial de ser más confiables que un equipo stand-alone, porque ellos tienen una tolerancia parcial de fallas. Esto significa que algunos nodos del sistema pueden fallar, mientras los otros funcionan correctamente, y pueden tomar las tareas de los componentes que fallan.
• Incrementar desempefio a través de paralelización. La presencia de multiprocesadores abre la posibilidad de decrementar el tiempo de trabajo intensi\'o a través de la división de trabajo en diferentes procesos.
• Simplificación de disefio a tra\·és de especialización. El disefio de una computadora puede en ocasiones ser simpli ti cado por la división del sistema en módulos. cada parte implanta una funcionalidad y se comunica con otros módulos.
El té1111ino sistema distribuido implica una distribución. sin embargo ¿qué se distribuye? Se puede distribuir el control o los datos. En éste último caso. la distribución puede tomar dos fo1111as. duplicación o particionamiento. Existe una duplicación de un dato x. si este se encuentra duplicado en n ejemplares. Por otro lado. hablamos de particionamiento de datos cuando, estando accesibles desde todos los sitios. los datos son particionados de tal forma que cada una de las
7
particiones se encuentra sobre un sitio dado. Por otro lado la distribución de control tiene sus características ya qne no debe existir una jerarquía estática y no debe existir un proceso líder que en pem1anencia asegure el control.
Los sistemas distribuidos presentan cie11as características que no se deben descuidar: la tolerancia a fallas. la confiabilidad y la consistencia. La tolerancia a fallas permite que el sistema continúe funcionando. tal vez con un menor rendimiento. a pesar de que uno de sus componentes no esté funcionando. La confiabilidad se refiere al hecho de que lo se envíe llegue sin alteraciones, sin pérdidas y en el mismo orden en que se em ió. Por último la consistencia, recordemos que en un sistema distribuido diferentes procesos acceden y actualizan datos concurrentemente. estos cambios no son instantáneos y un cierto conjunto de cambios debe aparecer igual a todos los procesos que integran el sistema distribuido.
Ln sistema distribuido consta de dos elementos básicos: los procesos y las vías de comunicación. Los procesos reciben. manipulan. transfo1111a11 y emiten datos. Las vías de comunicación es el medio sobre el cual circulan los datos. En el caso de los sistemas distribuidos las vías de comunicación se consideran virtuales y presentan propiedades estructurales y comportamentales. Las propiedades estructurales ser refieren al tipo de topología que las vías van a formar, entre más las importantes encontramos: anillo. estrella. árbol y completo. Las propiedades comportamentales se refieren a la hipótesis sobre el comportamiento de las vías de comunicación: transmisión sin duplicación de mensajes y sin alteración de mensajes. considerando una pérdida cuando el tiempo de atención rebasa el tiempo límite.
2.1 LOS SISTEI\1AS OPERATIVOS DISTRIBUIDOS Y LOS SISTEMAS OPERATIVOS DE RED
Existen diferentes sistemas operatirns que pueden ser ejecutados sobre una red computadoras, sin embargo estos sistemas no son sistemas distribuidos.
La proliferación de estaciones de trabajo y de redes locales ha conducido al desarrollo de nuevos conceptos de sistemas operatirns: los sistemas operativos de red y los sistemas operativos distribuidos.
Un sistemJ operativo en red es una colección de computadoras conectadas en una red. y que cuentan con módulos para proporcionar acceso a recursos remotos. En este tipo de sistemas operati,·os cada computadora tiene su propio sistema operativo en red. La única interacción en el sistema es el intercambio de info1111ación entre estaciones a través de algún canal externo de comunicación. Si el usuario requiere algún comando remoto debe ejecutarlo explícitamente en el lugar de que el sistema operativo asigne dinámicamente procesos de CPU. Los usuarios deben conocer el lugar donde se encuentran sus archi,·os. El sistema tiene poca o nula tolerancia a
fallas.
8
Por otro lado, un sistema operativo distribuido es un sistema operativo cuyos componentes están conectados en red. Este sistema es visto lógicamente como un simple sistema operativo que existe para todos los componentes del sistema. Los usuarios no se preocupan por la ubicación de los archivos, ni por la ejecución explícita de procesos remotos. Las decisiones y el control son realizadas globalmente. Los recursos son administrados globalmente usando mecanismos globales y no locales.
La diferencia principal radica en la ubicación del IPC (lnter Process Communication) dentro de la estructura del sistema operati\'o. En los sistemas operati\'os en red esta parte se encuentra entre el administrador de archi\'os y el administrador de dispositi\'OS de Entrada Salida, o entre el administrador de Entrada Salida y el administrador de memoria. En un sistema operativo distribuido el IPC fom,a parte integral del administrador de procesos.
A nivel usuario existen dos diferencias claves: la administración de procesos y la administración de recursos. En un sistema operativo en red si un usuario desea ejecutar un proceso en una máquina remota. debido a que la suya esta muy cargada, este debe de localizar otra máquina y ejecutar el proceso especificando la máquina y el comando. En un sistema distribuido es el mismo sistema el que decide donde ejecutar proceso, y es él mismo el que se encarga de ejecutarlo.
2.2 LA COMUNICACIÓN
La comunicación es un factor primordial dentro de los sistemas distribuidos. Existen dos grandes tendencias para comunicar dos procesos en un ambiente distribuido. Estos son los sockets y el RPC.
2.2.1 SOCKETS
La comunicación se realiza a través de un puerto. Cuando se tienen procesos que comparten el sistema de archi\'os y están en la misma máquina esta puerto puede representarse como una memoria compartida. un pipe. una tifo. etc. Si los procesos se encuentran en máquinas diferentes este puerto adquiere la fom1a de un socket o de una conexión TLI.
Los sockets son puntos de comunicación a tra\·és del cual un proceso puede emitir o recibir infomrnción. es una interfaz entre la capa de aplicación y la de transporte. dentro del modelo OSI. · En el interior de un proceso un socket se identifica por un descriptor, parecido al usado para la identificación de archi\·os.
En general. para que dos procesos puedan comunicarse deben seguir ciertos pasos. Del lado del
9
servidor, este debe de abrir un puerto y esperar por las peticiones de los clientes, del lado del cliente este debe abrir su puerto, escribir una petición y enviársela al servidor. El servidor realiza su servicio y regresa la respuesta al cliente por el mismo medio. Si existe más de un cliente se debe poner especial atención en poder diferenciar las peticiones de los diferentes clientes, teniendo especial cuidado en que un proceso no se haga pasar por otro.
Una opción para garantizar pri\'acidad y proporcionar una interacción adicional durante el procesamiento de la petición es el contar con un canal de comunicación de doble sentido. Contando con este canal privado ya no SL' requiere de un intercambio de identificador de los procesos en cada envío de mensajes.
Una \·ez que el canal fue establecido el scn·idor debe decidir como manejar la petición. Existen tres posibles estrategias servidor-serial. ser\'idor-padre y servidor-thread. En la primera estrategia cuando el servidor recibe una petición se dedica completamente a atender la petición antes que cualquier otra. Si en el instante en que sé esta atendiendo a una petición llega otra, esta última se fonna en una cola de espera para ser atendida hasta que se tem1ine con la primera. En la estrategia del ser\'idor-padre el ser\'idor crea un hijo para que atienda cada petición que llegue, mientras que el servidor se queda escuchando por otras posibles peticiones. Por último la estrategia sef\·idor thread sigue el mismo esquema que la anterior pero con un overhead más bajo. En lugar de realizar un fork para crear un hijo y atender la petición, el servidor crea un thread en su propio espacio de direcciones.
2.2.2 REJ\10TE PROCEDURE CALL-RPC-
La llamada a procedimiento remoto o RPC. por sus siglas en inglés, es una fonna de comunicación entre procesos de reciente utilización y ampliamente aceptado para ocultar o disfrazar la llamada a un proceso que no correría localmente, en el capítulo 3 se describe con más detalle esta técnica.
Dentro del ámbito del cómputo distribuido se incorpora fuertemente la tecnología orientada a objetos. debido a que en el paradigma basado en objetos el estado de un programa ya se encuentra distribuido de manera lógica en diferentes objetos, lo que hace a la distribución fisica de estos objetos en diferentes procesos o computadoras una extensión natural.
La inrncación remota de métodos de Ja\'a es un modelo de objetos distribuidos, diseñado específicamente para el lenguaje .la\'a [ 1 ]. por lo que mantiene la semántica del modelo de objetos locales de Ja\'a. facilitando de esta manera la implantación y el uso de objetos distribuidos. En el modelo de objetos distribuidos de Ja\'a. un objeto remoto es aquel cuyos m¿todos pueden ser inrncados por objetos que se encuentran en una máquina virtual (MV) di fcrentc. Los objetos de este tipo se describen por una o más interfaces remotas que contienen la dctinición de los ml?todos del objeto que es posible invocar remotamente.
La inrncación remota de un método (Remate Method Invocation RMI) es la acción de invocar un
10
método de una interfaz remota de un objeto remoto. La invocación de un método de un objeto remoto tiene exactamente la misma sintaxis de invocación que la de un objeto local.
2.3 CLIENTE/ SERVIDOR
En el sentido más estricto. el tém1ino clientelser\'idor describe un sistema en el que una máquina cliente solicita, a una segunda máquina llamada servidor, que ejecute una tarea específica. El cliente suele ser una compmadora personal común conectada a una LAN, y el servidor es, por lo general. una máquina anfitriona. como un ser\'idor de archivos PC. un servidor de archivos de UNIX. una macrocomputadora o una computadora de rango medio, ver figura 2.1. El programa cliente cumple dos funciones distintas: por un lado gestiona la comunicación con el servidor. solicita un ser\'icio y recibe los datos enviados por aquél. Por otro, maneja la interfaz con el usuario: presentu los datos en el fom1ato adecuado y brinda las herramientas y comandos necesarios para que el usuario pueda utilizar las prestaciones del servidor de fomrn sencilla. El programa ser,idor en cambio. tiene que proporcionar el servicio y encargarse de transmitir la infonnación de fom1a eficiente. No tiene que atender al usuario. De esta fom1a un mismo ser\'idor puede atender a \'arios clientes ul mismo tiempo. Algunas de las principales LAN que cuentan con sen idores especializados que pueden realizar trabajos para clientes son \\'indO\\ s ~T. ]\;etWare de Nowll. VINES de Banyan y LAN Server de IBM entre otras. Todos estos sistemas operati\'OS de red pueden operar y procesar solicitudes de aplicaciones que se ejecutan en clientes, mediante el procesamiento de las solicitudes mismas.
Cliente Cliente
pet leJÓll
r spuesta
Kcmcl Kernel Kernel
Red de Computadoras
Figura 2.1
De fo1111a general. se puede decir que la arquitectura cliente/servidor es un modelo para el dcsarrnllo de sistemus de info1111ación en el que lus transacciones se di\'iden en procesos independientes que cooperan entre sí para intercambiar infonnación. servicios o recursos. Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y ser\'idor al proceso que
11
responde a las solicitudes.
En este modelo las aplicaciones se di\'iden de fom1a que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente sólo se almacena información particular a cada usuano.
Los clientes realizan funciones tales corno: manejo de la interfaz de usuario. captura y validación de los datos de entrada o generación de consultas e infom1es sobre las bases de datos.
Por su parte los sen idores realizan. entre otras. las siguientes funciones: gestión de periféricos compartidos. control de accesos concurrentes a bases de datos compartidas o enlaces de comunicaciones con otras redes de área local ( LAN) o área amplia ( W AN ).
Siempre que un cliente requiere un ser\'icio lo solicita al sen°idor correspondiente y éste le responde proporcionándolo. Nom1almente. pero no necesariamente, el cliente y el servidor están ubicados en distintos procesadores.
Entre las principales características de la arquitectura cliente/servidor se pueden destacar las siguientes:
• El ser\'idor presenta a todos sus clientes una interfaz única y bien definida. • El cliente no necesita conocer la lógica del servidor. sólo su interfaz externa. • El cliente no depende de la ubicación fisica del servidor. ni del tipo de equipo fisico en el
que se encuentra. ni de su sistema operativo. • Los cambios en el ser\'idor implican pocos o ningún cambio en el cliente.
2.3.1 VENTAJAS Y DESVENTAJAS DE t;N SISTEl\1A CLIENTE/ SERVIDOR
Un sistema desarrollado bajo la arquitectura cliente sen·idor presenta \·entajas y desventajas que se deben considerar. [2]
Entre las \'Cntajas del modelo cliente ser\'idor encontramos las de simplicidad y eficiencia. Además. uno de los aspectos que más ha promo\·ido el uso de sistemas Cliente/Servidor es la existencia de platafonnas de hard\\are cada \'ez más baratas. Esta constituye a su vez una de las más palpables \'enlajas de este esquema. la posibilidad de utilizar máquinas considerablemente mús baratas que las requeridas por una solución centralizada, basada en sistemas grandes. Además. se pueden utilizar componentes. tanto de hardware como de software. de varios fabricantes. lo cual contribuye considerablemente a la reducción de costos y fa\'orece la flexibilidad en la implantación y actualización de soluciones.
L'n;i de las\ enlajas del uso del esquema Cliente Sen·idor es que el mantenimiento y el desarrollo Lk aplicaciones es más rápido. pues se pueden emplear las herramientas existentes (por ejemplo hl'tTamientas de bajo ni\ el como los sockets o el RPC). Asimismo. la estructura inherentemente
12
modular facilita la integración de nuevas tecnologías y el crecimiento de la infraestructura computacional. favoreciendo así la escalabilidad de las soluciones. Estos esquemas permiten un mejor aprovechamiento de los sistemas existentes, protegiendo la inversión. Por ejemplo, la compartición de servidores (habitualmente caros) y dispositivos periféricos (como impresoras) entre máquinas clientes pem1ite un mejor rendimiento del conjunto.
Tanto el cliente como el seí\·idor pueden escalarse para ajustarse a las necesidades de las aplicaciones. Los equipos utilizados pueden dimensionarse a partir de las aplicaciones y el tiempo de respuesta que se requiera. La existencia de \'arios equipos proporciona una red más fiable: un fallo en uno de los equipos no significa necesariamente que el sistema deje de funcionar. En una arquitectura como ésta. los clientes y los servidores son independientes los unos de los otros con lo que pueden reno\ arse para aumentar sus funciones y capacidad de fom1a independiente. sin afectar al resto del sistema.
Por otro lado. el esquema Cliente Sen idor tiene algunos inconvenientes, corno el hecho de que se cuenta con muy escasas herramientas para la administración y ajuste del desempeño de los sistemas.
Es importante que los clientes y los ser\'idores utilicen el mismo mecanismo de comunicación (por ejemplo sockets o RPC). Lo anterior implica que se deben tener mecanismos generales que existan en diferentes platafom1as. Se debe considerar que hay que tener estrategias pare el manejo de errores y para mantener la consistencia de los datos, sin dejar de lado la seguridad que en un esquema Cliente/Servidor es otra preocupación importante. Se deben hacer verificaciones en el cliente y en el servidor, es más dificil proporcionar un ele\'ado grado de seguridad en una red de clientes y ser\'idores que en un sistema con un único equipo centralizado. Se puede recurrir a técnicas como el encriptamiento. para la transmisión de infom1ación.
El desempefio es otro de los aspectos a tomar en cuenta en el esquema Cliente/Servidor. Problemas de este estilo pueden presentarse por congestión en la red, dificultad de tráfico de datos, etc. A veces, los problemas de congestión de la red pueden degradar el rendimiento del sistema por debajo de lo que se obtendría con una sola máquina (arquitectura centralizada). Y, por supuesto. existe una alta complejidad tecnológica al tener que integrar una gran variedad de productos. requiere un fuerte redisef10 de todos los elementos involucrados en los sistemas de infonnación (modelos de datos. procesos, interfaces, comunicaciones, almacenamiento de datos, etc.). Además, en la actualidad existen pocas herramientas que ayuden a detem1inar la mejor forma de di\'idir las aplicaciones entre la parte cliente y la parte servidor.
En un esquema de bases de datos distribuidas éste resulta técnicamente muy complejo y en la actualidad hay muy pocas implantaciones que garanticen un funcionamiento totalmente eficiente.
13
2.3.2 CLIENTE SERVIDOR Y LOS SISTEMAS ABIERTOS
Las arquitecturas cliente/servidor se asocian a menudo con los sistemas abiertos, aunque muchas veces no hay una relación directa entre ellos. De hecho, muchos sistemas cliente/servidor se pueden aplicar en entornos propietarios.
En estos entornos, el equipo fisico y el lógico están disefiados para trabajar conjuntamente, por lo que en ocasiones se pueden realizar aplicaciones cliente/servidor de forma más sencilla y fiable que en los entornos que contienen platafornias heterogéneas.
Una des\'entaja es que los entornos propietarios ligan al usuario con un suministrador en concreto. que puede ofrecer ser\'icios caros y limitados. La independencia del suministrador que ofrece los entornos de sistemas abiertos. crea una competencia que origina mayor calidad a un menor precio.
Sin embargo, debido a la filosofia modular de los sistemas cliente/ser\'idor, éstos se utilizan muchas veces en entornos de diferentes suministradores. adecuando cada máquina del sistema a las necesidades de las tareas que realizan. Esta tendencia está fomentando el crecimiento de las interfaces gráficas de usuario, de las bases de datos y del sofnrnre de interconexión.
Debido a esto. se puede afinnar que los entornos cliente/servidor facilitan el movimiento hacia los sistemas abiertos. Utilizando este tipo de entornos. las organizaciones cambian sus v1eJOS equipos por nuevas máquinas que pueden conectar a la red de clientes y servidores.
La interoperatividad es uno de los puntos clave de las herramientas de los suministradores.
2.3.3 ESQUEMA DE COMUNICACIÓN CLIENTE/ SERVIDOR
El protocolo que utiliza es simple, el cliente envía una petición y toma la respuesta. La respuesta que emite el ser\'idor puede ser la inforniación solicitada o un código de error. El envío y recepción de la petición y la respuesta se basa en dos funciones o llamadas: send y receive. En el primero el emisor (ya sea el cliente o el ser,idor). envía el mensaje a un destino especificado dentro de la función. El segundo el receptor esta escuchando la dirección y cuando llega un mensaje lo almacena en una dirección especificada en la función.
Como se puede apreciar para el en\'ÍO de un mensaje es necesario especificar un destinatario. Este destinatario puede tratarse de una máquina. la cual posee un nombre o una dirección numérica. Generalmente esta dirección se especifica en alguna parte del software del programa emisor. Una \ e1 que el mensaje llega a su destino. la máquina receptora debe entregarlo. Si sólo existe un · prnccso no hay problema. se le entrega a este. El problema se presenta cuando existe más de uno. L na de las forn1as de solucionar este problema es en,·iar el mensaje a un proceso y no a una maquina.
14
El problema de dirigir los mensajes a un proceso es como especificar el destinatario. Una de las opciones es que la dirección destino sea una combinación de la máquina a quien va dirigida y del proceso dentro de la máquina. Otra opción es que los procesos tengan identificadores únicos independientes de las máquinas. En este caso se deja a los procesos elegir su propio identificador. El problema se pasa del lado del emisor al tener que identificar cual es el proceso que proporciona un detem1inado sen icio. Existen dos alternativas. la primera es realizar un broadcasting y preguntarle a todo el mundo quien ofrece el sen,icio. ver figura 2.2. La segunda consiste en designar una máquina que sir\"a de sen·idor de nombres, en este caso se le pregunta a la máquina por el ser,idor. \ er figura 2.3.
¡_¡
.\:")
.\:"'
Figura 2.2
.\:)
•• ••
Sen ido r Ul' :\omhn·,
Figura 2.3
¡_¡
15
Una opción es utilizar un número de puerto. El primer paso para establecer una comunicación entre dos computadoras es conocer la dirección, el segundo es conocer el puerto. Por otro lado, desde un punto de vista físico es una ranura que pem1ite conectar físicamente dos computadoras. Desde un punto de vista lógico, se puede considerar como puntos finales de comunicación en los cuales los servidores están escuchando para establecer una conexión. En tém1inos simples se trata de un número a través del cual se va a realizar la comunicación. Haciendo una analogía la dirección equivale al número de teléfono de una compañía y el número de puerto a la extensión de la persona con la que nos queremos comunicar. Algunos números de puertos ya tienen asociados cierto tipo de servicios.
2.4 ALGORITMOS DISTRIBUIDOS
Originalmente. el tém1ino fue usado como referencia para los algoritmos que fueron diseñados para correr en diferentes procesadores "distribuidos" sobre un área geográfica. Pero pasado el tiempo el uso de este tem1ino ha cambiado, ahora incluye algoritmos que corren en una red LAN (Local Area Net\\'ork) y algunos algoritmos para compartir memoria en máquinas mu l ti procesadoras.
Los algoritmos distribuidos son usados en diferentes aplicaciones. incluyendo telecomunicaciones. procesamiento de infom1ación distribuida, cómputo científico o procesos de control en tiempo real. Una parte importante del trabajo de construir un sistema para cualquiera de estas aplicaciones. es el diseño. implantación y el análisis.
Es impo11ante distinguir entre paralelismo y distribución. Por paralelismo se entiende que el algoritmo está compuesto de un cierto número de procesos (o sitios) cooperando a la realización de un fin común. la sincronía en este tipo de algoritmos se da a través de la memoria compartida. Por otro lado, en los sistemas distribuidos la cooperación se hace únicamente por intercambio de mensajes (no hay entonces memoria común). Los mensajes viajan a través de canales que conectan pares de procesos, estos canales se suponen confiables y bidireccionales, las demoras de tránsito de los mensajes son arbitrarias.
En el diseiio de un algoritmo distribuido se hacen algunas consideraciones tales como, la transmisión se efectúa sin duplicación de mensajes. la transmisión se efectúa sin alteración de mensajes. o que no hay pérdida de mensajes.
Otras consideraciones a tomar en cuenta. es el hecho de que entre dos procesos comunicantes el orden de recepción de mensajes es idéntico a su orden de emisión, no hay defasamientos y el tiempo de espera de em·ío de un mensaje es finito (aunque aleatorio). El plazo de despacho es limitado. e\iste un limite superior. más allá del cual estamos seguros que el mensaje es recibido. La mayoría de los algoritmos utilizan todas o algunas de las hipótesis anteriores.
16
Un algoritmo es más interesante si es capaz de resistir a las fallas de los procesos que lo componen. Si un proceso juega un papel importante y falla, puede ser fatal para el algoritmo; pero si todos los procesos juegan el mismo papel, puede ser posible una falla y el algoritmo continuará funcionando en estado "degradado". A mayor simetría los efectos de las fallas son menores y viceversa. a menor simetría los efectos de las fallas son mayores, en la siguiente sección se explica en concepto de simetría. (ver sección 2.4.1 ).
La preocupación con los algoritmos distribuidos no sólo es que cada componente realice lo que tiene que hacer para garantizar el comportamiento deseado; si no que también (al igual que los sistemas paralelos y secuenciales) un gran esfuerzo va dirigido a aspectos tales como la organización para cambiar y acceder a conjuntos de datos, predecir los recursos a utilizar (memoria. ancho de banda. etc.). como probar que la solución propuesta funcionará para todos los escenarios y situaciones así como poder \ isualizar el comportamiento del algoritmo a pesar del escenario.
2.4.1 CUALIDADES DE UN ALGORITl\10 DISTRIBUIDO
Un algoritmo distribuido cuenta con diferentes características que lo diferencian de otros, y que pem1ite hacer una clasificación.
Un algoritmo distribuido cuenta con un grado de repartición o simetría. Se pueden distinguir diferentes niveles de simetría. Se dice que no hay simetría cuando cada proceso ejecuta un código diferente. Un algoritmo es simétrico si los procesos ejecutan el mismo código, con la sola diferencia que cada proceso hace referencia al nombre del proceso que él ejecuta y que todos los nombres son diferentes. según los mensajes recibidos y sus nombres pueden tener comportamientos diferentes. En el caso de una simetría fuerte, todos los procesos ejecutan el mismo código (en el cual su nombre no aparece) según los mensajes recibidos pueden tener comportamientos diferentes. La simetría total se presenta cuando los procesos ejecutan el mismo código. lo que pro\'oca comportamientos idénticos.
Otra característica importante de los algoritmos distribuidos es el tráfico engendrado. Un algoritmo distribuido es más interesante entra más eficientes sea, la eficiencia se mide por el número de mensajes intercambiados. la carga inducida en las vías de comunicación, por el tiempo de espera provocados por los algoritmos.
Por último. un algoritmo puede contar con un estado global o local. Es decir. un algoritmo puede obtenerse a partir de la duplicación de un algoritmo centralizado. al cual se le añaden reglas de administración de variables duplicadas. por lo cual todo proceso se beneficia del conocimiento de un estado global. aunque no toda la infonnación le sea necesaria. Un criterio de e\'aluación debe ser para un proceso del algoritmo. debe tomar decisiones sin utilizar un estado global.
17
2.4.2 PRINCIPALES TÉCNICAS USADAS EN LOS ALGORITMOS DISTRIBUIDOS
Sea cual sea la técnica utilizada, los algoritmos distribuidos utilizan técnicas clásicas que encontramos en las redes, como el acuse de recepción para validar la emisión de un mensaje o la difusión de valores a un conjunto de procesos.
Sin embargo algunas técnicas y/o conceptos propios a los algoritmos distribuidos han aparecido, como la difusión del cálculo, el token circulante o el estampado.
La difusión del cálculo fue propuesto por Dijkstra y Scholten [3] para un algoritmo de tern1inación es utilizado en algunos algoritmos distribuidos donde el objetivo es de realizar un control particular. Los procesos son conectados en forma de árbol mediante sus vías de comunicación. Uno de los procesos se dedicará, inicialmente a la emisión de mensajes. Tiempo después, si dicho proceso recibe un acuse de recibo, se puede afirnrnr que se llevo a cabo una difusión de infomiación (i.e. los mensajes iniciales) a todos los procesos que forman parte del árbol.
El token circulante consiste en circular un privilegio dentro de un conjunto de procesos conectados de acuerdo a una topología de anillo, este privilegio recibe el nombre de ficha o token. El anillo puede definirse estática o dinámicamente, es conceptualmente simple, basado en algoritmos de exclusión mutua y de tem1inación.
El estampado fue creado por Leslie Lamport [ 4]. Es utilizado en algoritmos distribuidos en los cuales las elecciones deben contener detección de interbloqueo y exclusión mutua. En caso de conflicto el proceso seleccionado no debe ser siempre el mismo, ya que se corre el riesgo de crear .. situaciones de hambre". Los sistemas centrales utilizan el mecanismo de acceso a memoria central o al reloj global del sistema. situación que no se presenta en los algoritmos distribuidos. Para pem1itir el establecimiento de un orden total entre todos los eventos que se dan en los procesos que definen el sistema distribuido, Lamport propuso el principio del estampado, conocido también de .. relojes lógicos".
2.-t.3 ESTRUCTURAS DE CONTROL
Ln algoritmo distribuido se basa en el en\'ÍO de mensajes hacia un proceso remoto. Los procesos \'an a actuar dependiendo del mensaje que llegue o que envíen. Es necesario contar con alguna estructura de control para decidir el flujo del programa dada esta comunicación. En los algoritmos estas estructuras de control están representadas por enunciados de los lenguajes comencionales como if-then. \\·hile-do. for-do. repeat-until. Sin embargo en los algoritmos distribuidos no es posible aplicar dichas estructuras.
E\iSk'n diferentes esquemas que sir\Cn como estructuras de control. El esquema de control probabilístico. usa "\'olados electrónicos" y de generadores de números para obtener el componamiento de un proceso. Induce una probabilidad distribuida dentro del conjunto de
18
cálculos de un sistema pseudo aleatorio. Se "lanza una moneda" en cada paso que se ejecuta, el siguiente paso depende del estado actual del proceso y del resultado del lanzamiento de la moneda en el paso anterior.
Los esquemas de control síncronos, utilizan el tiempo. Dentro de la sincronización temporal, el tiempo es absoluto y sirve como medio de ordenamiento de eventos. El uso de un protocolo de sincronización de reloj y de una comunicación por difusión con retardo limitado permite la notificación de los eventos y la toma de decisiones en función del tiempo sobre cada uno de los sitios.
Los esquemas de control asíncronos no utilizan el tiempo, un ejemplo son las iteraciones distribuidas. En un conjunto de procesos trabajando concurrentemente, los cuales están situados en sitios diferentes y se comunican a través de mensajes, cada proceso efectúa un paso en cualquier punto en el tiempo y cada paso se comporta de acuerdo a los datos que recibe.
Otro ejemplo de control asíncrono es la recursión distribuida [5]. Necesita la visita y la realización de tratamientos de todos los procesos de un grupo, y después de los resultados obtenidos. Es importante distinguir entre un algoritmo tipo ola y un recorrido de topología, un recorrido consiste en solo infom,ar a los sitios (difusión sin colecta de errores) [6], mientras que un algoritmo tipo ola se hace un recorrido de "bajada" (flujo) y después de "subida" (reflujo).
19
3. LLAMADAS A PROCEDIMIENTOS REMOTOS -RPC-
El concepto de llamadas a procedimientos remotos es relativamente nuevo. Este fue investigado a mediados de los años 70's por .l. E. \\'hite. Posteriorn1ente White, en conjunto con el equipo Xero\ Corporation. ayudó a desarrollar numerosos sistemas RPC. Xerox estuvo corriendo uno de su sistema RPC, Cedar, en estaciones locales a principios de los ai'los 80's [7].
Dcspu~s. Sl'\' Microsystems uso el conocimiento del RPC. Mucho del trabajo fue llevado a cabo por Bob Lyon quien deja Xero\. SL'\: reali1ó la primera versión de RPC, ONORPC (Open Net ,, ork Computation / Remo te Procedure Cal 1) a mediados de los años 80's. Esta primera ,·ersión fue basada en sockets, conocido como el RPC de SUN, desde entonces ha sido reescrito usando TU resultado en TI-RPC. o Transpone Independiente RPC. SUN RPC es integral con NFS de SUN (Netwonk File System). el cual es ampliamente usado hoy en día.
SL\: no fue el único que cosechó los beneficios de la creación de Xerox otra compañía, Apollo, también trabajo en el RPC. Ellos desarrollaron su propio paquete RPC llamado NCA/RPC (\'el\\ ork Computing Architecturc). Después Hewlett Packard adquirió Apollo en 1989, y \'CA. RPC fue transformada en OSF DCE (Open Software Foundation/Distributed Computing Ell\ iroment).
Para ocultar la diferencia entre llamadas locales y remotas, es posible incluir el RPC en el lenguaje de programación. Todos los detalles de la red se ocultan del programa de aplicación, poniéndolos en procedimientos locales. Estos procedimientos se llaman cabos (stub). El objetivo final consiste en hacer que una llamada de procedimiento remoto no se vea distinta a una llamada a un procedimiento local.
Como todo protocolo implementado en un ambiente cliente/servidor el RPC cuenta con dos panes el código del cliente y el código del servidor.
El RPC no se adapta perfectamente al Modelo de Referencia OSI. Se ha diseñado para ser rápido y, por lo tanto. no contiene una estructura de múltiples capas. La llamada de procedimientos remotos está interesada en aproximadamente los mismos temas que la capa de sesión por lo que consideraremos al RPC como una capa de sesión un tanto especial por tratarse de una capa de sesión sin conexión. [8].
El funcionamiento se puede explicar como sigue: el cliente realiza una llamada local a un procedimiento. Cuando el proceso se da cuenta que se trata de una llamada remota, este cede al control al stub del cliente. Dicho stub construye un mensaje que incluye el nombre del prncedimiento buscado así como los parámetros de entrada y de salida. Este mensaje es pasado al kernel de la máquina donde reside el proceso cliente. El kernel se encarga de enviarlo al kernel de la máquina sen idora. \'Cr figura 3.1.
:\1áquina Cliente
Llamada E111p:.1quetamicnto de p:.námetros
....____ Dese111p:.1que
Resreso
Kernel
Má uina Servidor Stub del Stub del
Cliente Scr\'ldor ":.. :--"'T""""--
/ Mensaje transportado por la red
Figura 3.1
quetamiento de parámetro
Empaqueta
Kernel
20
Del lado del servidor son los mismos pasos salvo que en sentido contrario. Cuando un mensaje llega al kernel de la máquina servidora, este es transmitido al stub del servidor, el cual se encarga de desempaquetar el mensaje, sacar los parámetros, ejecutar y devolver resultados.
Uno de los aspectos más importantes de los RPC es su independencia de arquitectura. Las aplicaciones se puedan ejecutar en sistemas compuestos de máquinas heterogéneas. Para poder solucionar el problema de comunicar dos procesos que residen en arquitecturas diferentes, el RPC utiliza una representación de datos que es independiente de toda arquitectura, XDR ( eXtemal Data Representation).
3.1 eso Y ACCESO
RPC es apropiada para aplicaciones cliente, servidor en las que el cliente genera una petición y
puede esperar la respuesta del ser.·idor antes de continuar con su propio proceso. Dado que muchas implantaciones de RPC no admiten la interacción de par a par. o asíncrona. entre cliente y sen idor. RPC no está indicada en aplicaciones que implican objetos distribuidos o programación orientada a objetos'.
El t'lJUI\ aknte del RPC' en un ambiente onentado a objetos es el R_\1J o Remole \1ethod lnrncation. utilizado en mtcrna~ .:01110 C'ORBA. C'0\1 o J.-\\·_-\_
/
21
Existen en la actualidad herramientas de programador para el desarrollo de aplicaciones RPC en una amplia variedad de entornos, incluyendo Windows (3.1, 95, NT), Macintosh, Unix, OS/2, Netware y YMS.
Las implantaciones RPC son nomrnlmente incompatibles entre sí, salvo excepciones. Los aspectos que pueden afectar al diseño de aplicaciones basadas en RPC son por ejemplo, el soporte del proceso síncrono y/o asíncrono. el soporte de diferentes protocolos de red o el soporte de diferentes sistemas de archivos.
3.2 EL PASO DE PARÁMETROS
A ni\"el local existen dos tipos de paso de parámetros, por valor o por referencia. El primero se utiliza cuando en un procedimiento los parámetros pasados a dicho procedimiento, no se modifican en su valor durante la ejecución del mismo. Por otro lado cuando los parámetros se pasan por referencia éstas variables pueden regresar después de la ejecución con valores diferentes antes de la ejecución.
Existe un tercer tipo llamado copy,restore, en el cual se copia el valor en el stack (como paso por valor) al final de la ejecución local, se copia el valor del resultado que tiene la variable del procedimiento en el stack. El procedimiento que mandó llamar al otro procedimiento copia el valor final. En condiciones nomrnles tiene el mismo efecto que el paso por referencia.
En general el RPC e\"ita el problema prohibiendo el uso de parámetros pasados por referencia. No se hace uso de apuntadores y parámetros que son procedimientos o funciones. Esta solución destruye la transparencia porque las reglas para las llamadas locales y remotas son entonces diferentes.
3.3 LOS STUBS (CABOS)
Los "stubs" son responsables de que la llamada remota sea lo más transparente posible. Hacen de intem1ediarios entre el cliente y los procedimientos de gestión, convirtiendo datos para el uso de las rutinas de la librería ··runtime" de RPC [9].
Esta librería transmite paquetes RPC que contienen rutinas. tablas y datos para apoyar la comunicación entre el cliente y el "stub" del ser,idor.
Las llamadas del cliente se envían a la computadora que contiene los procedimientos públicos, dejando en el "stub" del cliente sólo los privados.
22
El "stub" generado puede tener dos responsabilidades principales, copiar y convertir datos. Los "stubs" más simples sólo tienen un procedimiento para el paso de parámetros y la conversión de datos. Todos los "stubs" ordenan y recuperan datos en y desde el paquete RPC. El "stub" del cliente ordena los parámetros de entrada para enviar el paquete al servidor y recupera los parámetros de salida del paquete de respuesta. El "stub" del servidor recupera los parámetros de entrada del paquete RPC del cliente y los envía al manejador de la interfaz, y ordena los parámetros de salida para enviárselos al cliente. Además, cada "stub" checa el forniato indicado de los datos en el paquete transmitido. Cada sistema em·ía datos en su forniato nativo y el "stub" los corn·ierte a la representación del receptor. Es importante notar que ningún "stub" envía datos en un fonnato estándar de modo tal que si ambos sistemas usan la misma representación de los datos no hay necesidad de convertirlos.
Los .. stubs" pueden ser generados de dos maneras:
1. Manualmente: el disei'lador del RPC ofrece un conjunto de funciones para que el usuario fabrique sus propios "stubs". La ventaja es que son simples de implementar por el disei'lador y es posible controlar parámetros de tipo complejo.
3.3.1
Automáticamente: en este caso hay que utilizar un IDL (Interface Description Language) para definir la interfaz entre el cliente y el servidor. Esta interfaz es una lista de proceso, con el tipo de los parámetros y de los resultados.
FUNCIONES XDR
En Unix se utiliza la técnica de copyirestore basada en XDR. XDR (Externa) Data Representation Standard) es el protocolo utilizado por SUN Microsystems para la encapsulación de los paramentos en el RPC. Consiste en la creación de un flujo XDR. En este flujo un proceso serializará (o codificará) los datos y otro los descodificara. La fornia de describir los datos de XDR es similar a C. Nonnalmente el usuario no necesitara conocer el funcionamiento interno del protocolo XDR.
XDR asume que cada byte consta de 8 bits. La representación de todos los datos se basa en bloques de 4 bytes (31 bits). Para cada tipo de dato existe una función que introducirá o sacará el dato correspondiente del flujo XDR (dependerá del modo en que se ha abierto el flujo). Las funciones serán de la fornia:
xdr_ <tipo>
Y dc-,oherán el tipo hool_t que es TRUE si la operación se realiza correctamente y FALSE si ocurre algún error.
23
Para los tipos de datos simples se dispone de las funciones que los codifican. Las funciones que codifican tipos datos compuestos creados por el usuario, se pueden codificar a partir de las funciones anteriores siguiendo las especificaciones del protocolo. Así la codificación de un registro será la codificación sucesiva de cada uno de los campos.
Las funciones representan un conjunto que convierten datos entre representaciones locales y XDR. Existen dos grupos de funciones, una sirve para la creación y manipulación de streams XDR y la otra proporciona funciones para la conversión y transferencia de datos a streams XDR, a estas últimas se les conoce con el nombre de filtros. La tabla 3 .1, presenta una lista de funciones XDR para tipos simples y la tabla 3.2 una lista de funciones para datos compuestos.
Tipo en C Filtro Tipo xdr I char xdr_char() int short int xdr _ short() int unsigned short int xdr _u_ short() unsigned int
i int xdr_int() int
I unsigned int xdr_u_int() unsigned int ! Jonu ' " xdr_long() int ¡ unsigned long xdr_u_Jong() unsigned int , float xdr_float() float ; double xdr _ double() double void xdr_ void() void
¡ enum xdr_enum() int
Tabla 3.1 Filtros para tipos simples
1 Dato Compuesto Filtro 1
! Arreglo longitud variable con elemento de tamailo arbitrario xdr_array() Arreglo de bytes de tamaño variable xdr _ bytes() Data de longitud fija (sin interpretar) xdr _ opaque()
Referencias a objetos incluyendo apuntadores a NULL xdr _pointer()
, Referencias a objetos xdr _ ref eren ce()
\ Arreglos de caracteres tenninados en NULL xdr _ string() i Unión discriminada, (unión con una enumeración que actúa xdr _ uni on()
1 I d" . . ) : como 1scn111111ante
Arreglo de longitud fija con elementos de tamailo arbitrario xdr _vector() An·eglo de caracteres temiinado en NULL de longitud xdr _ \vrapstring() arbitraria
Tabla 3.2 Filtros para datos compuestos
24
3.3.2 LOS FILTROS
Como se explicó anteriom1ente el RPC utiliza el formato XDR para lograr una independencia de arquitectura. Ahora bien es necesario "traducir" el formato XDR al fom1ato de la máquina sobre la cual se está proporcionando el sen icio o se está mandando llamar al servicio. Esta traducción se lleYa a cabo a traYés de filtros.
Existen filtros ya disei"iados para la traducción de datos de tipo escalar del lenguaje rpcgenlen y filtros para el manejo de streams.
Las rutinas XDR proporcionan una forma de convertir tipos de datos en C y estructuras en representaciones externas tipo bit-string. Cada uno de los filtros definidos es unidireccional es decir traduce de un lado al otro y ,·ice, ersa. cada rutina funciona sobre los datos que se pasan de acuerdo al estado de la infonnación. Por cada tipo existe un procedimiento que toma dos argumentos. La sintaxis general es:
hooU xdrproc( XDR * xdrs. <tipo> argesp)
Donde xdrs es una instancia de un manejador XDR que es la dirección donde la fomia externa de red reside. Si se está codificando a la fornia externa el filtro busca a través del apuntador a argp la estructura del dato a convertir. Si se trata de codificar (descifrar) los datos se toman de xdrs y se depositan en xdrs.
Cada filtro puede realizar tres funciones sobre un stream. Puede codificar, (xdr_encode), decodificar. (xdr_decode) o liberar memoria :xdr_free). La operación es especificada en un campo del manejador XDR que contiene alguna de las constantes anteriores.
La función xdr_ encode solo asigna espacio si *argp es null, estos datos pueden liberarse después con una operación xdr _ free. Provoca que un tipo sea extraído del stream *xdrs y sea depositado en *argesp. La función causa que el tipo en *argesp sea codificado en el stream *xdrs. Por último xdr_free libera memoria. sin embargo hay que tener cuidado al utilizarlo ya que podría generar que un servidor se quede lentamente sin memoria.
Una aplicación más completa requiere del manejo en estructuras "complejas", por lo que es necesario contar con filtros que permitan traducir dichas estructuras.
Es imposible definir un filtro para una estructura de datos que involucre otras estructuras, (i.e. tipo estructura en C o registro en Pascal). Es tarea del usuario desarrollar estas estructuras.
25
3.4 ¿ CÓMO SE GENERAN LOS "STUBS" (CABOS)?
Hay tres niveles de uso del mecanismo de RPC tal como ha sido implantado en UNIX. Cada uno de estos niveles ofrece más o menos transparencia al usuario, es decir, demanda un conocimiento más o menos fino (hasta nulo) del protocolo y de los mecanismos de más bajo nivel, como por ejemplo, los sockets.
Las llamadas de alto nivel pem1iten definir cierto tipo de características al sistema que con la utilería rpcgen no se podría hacer.
La diferencia básica reside en si el programador necesita implantar los stubs del cliente y del ser\'idor. la decisión será tornada de acuerdo a las necesidades del sistema.
3.4.1 GENER.\CIÓN AUTOMÁTICA
Este es el nivel que oculta el max11110 de detalles al usuario. Este es el nivel más fácil de utilización del mecanismo de RPC. Se dispone de un cierto número de funciones estándar que constituyen una biblioteca. Para llamar a las funciones de esta biblioteca solo es necesario especificar el nombre de la maquina "objetivo" y los diferentes parámetros de la llamada.
Evidentemente, a este nivel no es posible desarrollar nuevos servicios RPC (sino es por composición de los ser\'icios existentes).
Para implementar el protocolo RPC se usa una herramienta llamada RPCGEN. La entrada a rpcgen es un lenguaje similar a C en el que se especifican las funciones que se le van a implementar de fom,a remota los parámetros que se le van a pasar, los parámetros que devuelve y los números de programa y versión de que dispondrá. La salida de este programa serán archivos en código C que implementan los stubs de cliente y servidor.
El uso de esta herramienta pem1ite generar llamadas a procedimientos remotos con conocimientos mínimos de los protocolos RPC y XDR.
Una de las primeras opciones es dejar que el sistema genere los stubs del servidor y del cliente. Esto se hace a partir de un archi\'O de especificación con tem1inac1011 x. El archivo de especificación debe contar con el número de programa, los nombres de los procedimientos remotos v el número de versión.
El programa rpcgen \·a a ser el encargado de generar todos los archivos necesarios para implementar el sistema basado en RPC que se tienen que compilar de acuerdo a la relación que guardan los archivos entre ellos. Afortunadamente entre todos los programas generados por 1vcgc11 se genera un archi\·o makefile. el cual simplifica la compilación de los diferentes códigos.
Un archivo .x se muestra a continuación:
/* rand.x *!
!* Especificación de un servicio con 2 funciones */
!* Inicialización de la semilla random y obtener */
/* un número random program RAND _PROG :
version RANO_ VERS 1
*!
\'Oid INITIALIZE_RANDOM(long) = 1; double GET_NEXT_RANDOM(void) = 2;
: = l;
: = Ox31111111;
3.4.2 GENERACJÓ;\; DE "STUBS" A TRAVÉS DE FUNCIONES DE ALTO NIVEL
26
Es el más interesante para el desarrollador. Supone un conocimiento mínimo de los protocolos XDR y RPC y es suficiente para desarrollar la mayoría de las aplicaciones. Descarga totalmente al usuario de la manipulación de los sockets. sobre los que se apoya ( en concreto el protocolo CDP") [10).
La sucesión de operaciones. del lado del cliente. a realizar para definir un servicio de este tipo consiste en:
1. Escoger el número de programa y de versión. 1 Escribir las diferentes funciones sobre el servidor. 3. Solicitar la anotación de las diferentes funciones por el demonio portmap por medio de la
función registerrpc.
Del lado del cliente. la llamada a una función desde una posición remota se realiza por medio de la función callrpc. En la figura 3.1. se puede observar la diferencia entre una llamada de alto nivel y una llamada de ni\'el bajo. Cuando se programa usando stubs de alto nivel solamente se hace uso de pocas funciones para el manejo de llamadas remotas estas funciones se describen a continuación:
En el ser\'idor. la función registerrpc( ). llama al portmapper del servidor, que es un procedimiento listo para proveer éste servicio y pueda ser registrado. Este también alerta al sistema RPC para disparar la rutina que está en espera de peticiones. La sintaxis es la siguiente:
' l DI' l "ser Datagram Prntocol Protocolo estándar TCP IP que permite a un programa de aplicación en una m:iqum:i e11,·1ar un datagrama hacia el programa de apl1cación en otra máquina.
int registerrpc(u_long prognum, versnum, procnum, char * (*procname) (), xdrproc_t inproc, outproc)
27
Una vez que el procedimiento es registrado por el portmap, un cliente proporciona el nombre del servidor, requerido para asociar la conexión remota y la ejecución. El cliente obtiene infomrnción de la conexión remota del portmapper del servidor. Los parámetros prognum, versnum y procnum usados para registrar la versión y número de programa así como el número de procedimientos, son del tipo entero largo.
Cuando el servidor de alto ni\'el obtiene una petición para el prognum. versnum y procnum. este intenta ejecutar el procname ( el nombre del procedimiento. este parámetro es un apuntador a una función que devuelve un apuntador a char). Las funciones inproc() y outproc() son filtros XDR que pasan datos cuando se conecta y desconecta de la red, los filtros XDR fueron descritos anteriom1ente.
Lna \'eZ que el servidor se le\'anta, este se registra a través de la llamada registrerrpc(), entonces pem1anece "dom1ido" hasta que se ejecuta la llamada svc_run(). Esta llamada provoca que el servidor se ponga en espera del procedimiento mencionado en registerrpc(), el formato es:
void svc _run( );.
La función svc _run() actualmente inicia el proceso de espera al final del socket, escuchando para una conexión válida. Una vez aceptado, el proceso lanza el nombre del procedimiento con los argumentos input y dernelve el resultado. svc_run() puede ser usado tanto en UDP/IP o TCP111/IP.
En el cliente lo único que se necesita usar es la función callrpc(), esta función encuentra y ejecuta un servicio UDP en un servidor. La sintaxis de la función:
int callrpc(char *host, u_long prognum, versnum, procnum, char * in, xdrproc_t inproc, char *out, xdrpror _ t outproc)
La función checa el portmap especificado del servidor y lo pone en el canal apropiado de entrada, salida para correr un procedimiento remotamente registrado. in y out son apuntadores a los argumentos del procedimiento remoto y devuelve el valor. Por otro lado, inproc() y outproc() son rutinas XDR que codifican los datos que in provee al servidor con los argumentos solicitados y los datos codificados en out desde donde el servidor lo envía.
Tanto registerrpc() como callrpc() son dise1"1ados solo para que corran UDP, para usar TCP/IP se usan llamadas RPC de nivel bajo.
" TCP TrJnsmiss1on Control Protocol. Protocolo de ni,·el de trnnsporte TCP IP estándJr que proporciona el ser\'icio dl' tlu_¡P co11f1Jbk ful! dupkx El TCP permite que el proceso en una máquina en,·ie un flujo de datos hacia el proceso de otr:i. El TCP está orientado a conexión. antes de transmitir los participantes deben establecer conexión.
28
3.4.3 EJEMPLO: RUTINA REMOTA EN EL SERVIDOR (ALTO NIVEL)
El siguiente código ejemplifica la implantación de la rutina de atención remota en el servidor, en una llamada de alto nivel.
!* Nombre archivo: lisdir svc.c */
1tinclude <rpcirpc.h> #include "Jee.h"
main()
extern bool extern char
xdr_dir(): *lee_dir():
registerrpc(DIRPROG. DIRVERS. LISDIR. Jee_dir. xdr_dir, xdr_dir);
s\·c_run():
3.4.4 GENERACIÓN DE STUBS A TRAVÉS DE FUNCIONES DE BAJO NIVEL
Su utilización es mucho más compleja y supone un buen conocimiento de los mecanismos concernientes a los sockets. Se muestra necesaria para las aplicaciones donde las opciones elegidas en el nin] intem,edio (por ejemplo. utilización del protocolo UDP) son inapropiadas.
En muchas aplicaciones es necesario poder definir un time-out para poder detectar la caída de una máquina. Dicho time-out se debe elegir adecuadamente para que un servicio no de la impresión de que es lento o de que la computadora esta caída. A pesar de todo lo que permite redefinir las llamadas de alto nivel. el time-out no esta dentro de sus opciones. Las llamadas de bajo nivel pem,iten redefinir el time-out de default, el protocolo así como otras cosas más.
La creación de un cliente de bajo nivel requiere mantener una única estructura para cada conexión cliente sen·idor. Algunas de las rutinas toman un manejador como un argumento a especificar en el servidor.
La función clnt_create() crea una estructura del cliente específica para el número de programa servidor y número de versión. El protocolo de transporte el seleccionable tcp o udp. la estructura de la función:
CLIE:\'T *clnt_create (char *host. u_Jong prognum. versnum. char *protocol)
29
La función clnt_destroy, llama a liberar memoria alojada con datos privados de la estructura del manejador del cliente. Si el RPC fue usado para abrir un socket, es necesario cerrarlo. La estructura es:
clnt_destroy(CLIENT *clnt).
La función clnt_control() se usa una ,·ez que la conexión ha sido establecida con c!nt_create(). para modificar las características anticipadas de RPC. Su estructura:
clnt_control (CLIE'.\T *clnt. int request, char *info).
Esta función cambia o recupera las características del cliente incluyendo el valor de timeout y el descriptor del socket.
La función clnt_call() usa los filtros XDR inproc() para codificar los requerimientos desde in y detiene hasta que el envío llega. El filtro XDR outproc() es usado para codificar la salida en out. La estructura es la siguiente:
enum clnt stat clnt call(CLIEJ\T *clnt. u_long procnum, xdrproc_t 111proc, char *in, xdrproc_t outproc. char *out. struct time,al timeout).
Esta función usa el manejador Cliente para llamar al procedimiento remoto, procnum, codifica los argumentos y envía resultados especificados por los procedimientos XDR. Un intervalo timeout es también controlable con el parámetro timeout.
En el sen·idor los procedimientos que se escriben en éste programa no necesitan llamar a la librería RPC. Estos son localizados en el código en el stub del servidor. Como un cliente tiene un manejador de Cliente para cada sen·idor, el servidor recibe un manejador de transporte para el servidor por cada petición RPC.
La función svctcp _ create() crea y de,·uelve un serv1c10 de transporte TCP para un particular socket o crea un socket, la estructura:
SVCXPRT * svctcp_create( int, sock. u_int sendsz. recvsz)
TCP usa buffer de entrada salida. Si el tama110 de sendsz y recvsz es cero se usa un valor de defau lt.
La función svcudp_creak() crea y dernelve un apuntador a UDP. la estructura es:
SVCXPRT * SHudp_create(int sock):
30
El valor de sock puede ser cualquiera de los descriptores de sockets o el valor default RPC_ANY _SOCK. El stub usará svc_register para registrar la rutina de despacho.
En la figura 3.2 que se muestra se presenta un resumen de las llamadas de alto y bajo nivel.
llamada de
alto niv
s "
el ',
as llamad de
bajo ni ve!
¡ '
' (
lado del cliente
callrpc()
clnt_create() clntudp_create() clntcp _ create() clntraw _ create()
clnt_ destroy()
clntcall() clnt_ control() clnt_freeres()
L i b r e r í a
d e
r a n 5
p o r 1 e
lado del servidor
L i registerrpc() b svc_run() r e
,. svc_udp_create() a svc _ tcp _ create()
d svcraw _ crea te() ¿ e
svc _ des troy()
a svc _register() n svc _ unregister() 5 p svc_getargs() o
svc_sendreply(}
e
Figura 3.2
3.4.5 EJEMPLO: UN CLIENTE LLAMA A UN SERVIDOR (BAJO NIVEL)
llamadas de
alto nivel
llamadas de
bajo nivel
La mejor manera de ilustrar como se define un protocolo es a través de un ejemplo. El cliente llama un servicio remoto para obtener el directorio de archivos desde una máquina remota.
* * rdir.c - Directorio remoto
*
=includc <stdio.h> =includc <--11x rpc.h> =includc "rdir.h'" * Declaraciones y definiciones de variables y funciones propias*/
main (int argc, int argv[])
CLIENT *el; char *server; char *dir; leedir_res *resultado; nombrelista ni; i f ( argc ¡ = 3) {
fprintf(stderr, "Uso: o/os directorio servidor \n", argv[O]); exit( 1 );
server = argv [ 1 ] ; dir = argv[2]; /*
* Crea el manejador del cliente usado en el servidor designado en * la línea de comando. Se llama al paquete con el protocolo tcp * cuando se contacta al servidor. */
el= clnt_create(server, DIRPROG, DIRVERS. "tcp"); if (el== NULL) l
/*
/*
* No se pudo establecer comunicación */
clnt_pcreateerror( server ); exít ( 1 );
* Llama al procedimiento leedir en el servidor */
resultado= leedir_l(&dir, el); if (resultado== NULL) {
\ 1
/*
/*
* Un error se produjo mientras se llamo al servidor *!
clnt_perror(cl, server); exit ( 1 );
* Llamada exitosa *' I
if (resultado->¡= O) l '*
* Un error remoto se produjo. *:
31
/*
ermo = resultado->ermo, perror(dir); exit (1 );
* Se imprime directorio. */
for (ni= resultado->leedir_res_u.list; ni ¡= NULL; ni= nl->pNext) { printf( --~,ós\n ",nl->name ):
exit (0);
3.5 TOLERANCIA A FALLAS
32
En [ 11] Tanenbaum nos indica que la tolerancia a fallas es uno de los aspectos importantes dentro de un sistema distribuido es su tolerancia a fallas. El RPC como tal no proporciona un modelo para soportar fallas.
3.5.1 CAÍDA DEL SERVIDOR
Hay al menos tres fom1as de programar el stub de cliente para superar una caída del servidor:
• Quedarse colgado eternamente en espera de una respuesta que jamás llegará. • Al té1111ino de una temporización generar una excepción o informar al cliente del fallo. • Al ténnino de una temporización retransmitir la solicitud.
El primer planteamiento es similar a lo que sucede cuando un programa llama a un procedimiento local que contiene un lazo infinito. No se utilizan temporizadores locales y, por lo tanto, el procedimiento jamás regresa.
El segundo de los planteamientos es similar a lo que sucede cuando un procedimiento provoca un error de protección de memoria o trata de dividir por cero. Si existe un manejador habilitado apropiado. se capturara y él procesará la excepción. Si no, se aniquilara el proceso.
El tercer planteamiento consiste en hacer que el stub del cliente retransmita la solicitud al té1111ino de una temporización. Dado que el sen·idor registrará un nue\'O identificador único en el sistema de base de datos después de una caída. la entidad de transporte en la máquina del servidor rechazarú la retransmisión cuando \·ea el identificador único antiguo, ahora inválido. Si la entidad de transporte dernelve una respuesta de error, el stub de cliente podrá renunciar ( esencialmente el
33
planteamiento anterior), o bien, revincularse y tratar de nuevo. Si el stub de cliente se revincula y repite la llamada, se puede concebir que la operación se llevará a cabo dos veces. De hecho, la ejecución se puede repetir, aun cuando no haya caídas, si se llega a perder la respuesta y pem1itimos que el cabo de cliente haga un nuevo intento.
Que la ejecución repetida sea aceptable o no depende del tipo de operac1on que se esté efectuando. Si la operación se puede repetir sin causar daños diremos que es idempotente. Un ejemplo de una operación idempotente es una lectura a una base de datos, no importa cuantas lecturas se hagan el estado de la base de datos no se ve afectado.
Si todas las operaciones pudieran ajustarse a una fom1a idempotente, entonces el tercer planteamiento seria el mejor de todos. Pero no todas las operaciones son idempotentes, lo cual depende del tipo semántica de los sistemas RPC.
El tipo de semántica más deseable es la conocida como "exactamente una vez", pero es dificil de conseguir. Una fom1a de aproximar esta situación es el manejo de excepciones. Si una llamada regresa nom1almente, significa que no ocurrió ninguna caída y que la operación se ejecutó exactamente una vez. Si el servidor se cae, o se detecta algún otro error importante, la llamada no regresa en absoluto; en su lugar, se genera una excepción y se invoca el manejador apropiado. El programa cliente no tienen que programarse para tratar los errores, pues lo hacen los manejadores de excepciones.
Otro tipo de semántica es "a lo más una vez". Cuando se utiliza esta fonna. el control siempre regresa al que hace la llamada. Si todo se desarrolla de manera correcta, la operación habrá sido ejecutada exactamente una vez. Sin embargo. si se llega a detectar una caída del servidor. el stub del cliente renunciará y devolverá un código de error.
El tercer tipo de semántica para una RPC es la de "al menos una vez". El stub de cliente reintentará una y otra vez, hasta que consiga una respuesta apropiada. Cuando obtenga de nuevo el control. sabrá que la operación se efectuó una o más veces. Para las operaciones idempotentes, esta situación es ideal. Para operaciones no-idempotentes pueden distinguirse varias variantes, posiblemente la de mayor utilidad sea la última de muchas. En esta garantizamos que el resultado que se devuelve es el de la última y no "al de ninguna de las anteriores".
3.5.2 CAÍDA DEL CLIENTE
Llamamos huérfano al sen·idor que continua funcionando tras la caída del cliente que lo inicio. Los huérfanos pueden causar varios problemas: gasto de tiempo de CPU y otros recursos; bloqueo de archi\"Os y otros objetos; posible confusión en RPC lanzadas más tarde. Existen cuatro formas de tratar a los huérfanos. extenninación. expiración. reencarnación y reencarnación moderada.
34
En la extem1inación, cuando una máquina se recupera después de una caída, lleva a cabo una verificación para ver-si tenía algún RPC en proceso en el momento de la caída. Si así fue, le pide a la máquina (o máquinas) del servidor que aniquile cualquier proceso que esté funcionando para su beneficio. Para utilizar el algoritmo de extem1inación es necesario que el stub del cliente registre los RPC antes de lle\·ar a cabo su ejecución. Cuando los RPC terminan, se eliminan sus entradas del registro de RPC pendientes. El registro deberá conservarse (por ejemplo en un disco) de tal fomrn que sobre\'i\'a a las caídas del procesador.
Los huérfanos pueden, por si mismos, realizar llamadas a procedimientos remotos, creando de esta manera nietos huérfanos. Esto obliga a que el algoritmo se plantee de fom1a recursi\'amente con objeto de eliminar la cadena de completa de huérfanos de principio a fin.
En la expiración. no se necesita ningún registro. Cuando se inicia una RPC. al servidor se le da un cierto tiempo para que tem1ine la llamada: si ésta no se completa dentro del inter\'alo original, el stub del serYidor deberá pedirle al cliente por un nuevo intervalo de tiempo. Si la máquina del cliente ha sufrido una caída o se ha reiniciando. este evento se detectará, el temporizador no se reno\·ará y al servidor se le pem1itirá morir. Cuando se utiliza la expiración, todo lo que tiene que hacer el cliente es estar seguro de que el intervalo de tiempo haya transcurrido, desde que ocurrió la última caída, antes de emitir el primer RPC.
La reencarnación se aplica en el caso de que el procedimiento de exterminación fracase en la eliminación de todos los huérfanos. En este método, el tiempo es etiquetado en épocas numeradas secuencialmente. Cuando el cliente en recuperación fracase en el intento de extem1inar a sus huérfanos. difunde el inicio de una nueva época hacia todas las máquinas. Ellas reaccionan mediante la aniquilación de todos sus procesos servidores. Dado que todas las solicitudes y repuestas siempre contienen el número de la época en la que se iniciaron, cualquier repuesta que e\·entualmente regrese. procedente de los huérfanos. lle\'ará un número de época obsoleto y, por consiguiente. será fácilmente detectable.
La reencarnación moderada también se basa en el uso de épocas, pero en lugar de que cada máquina se encargue de aniquilar toda la actividad remota cuando se declare una nueva época, aquí tratará de localizar al cliente que inició al servidor. Sólo se aniquilará al servidor si no se pudiese encontrar al cliente.
En los cuatro métodos se habla de la eliminación de los huérfanos pero han de tenerse en cuenta los problemas que esta eliminación puede pro\·ocar.
3.6 SEGURIDAD
L·na de las grandes preocupaciones dentro de los sistemas distribuidos esta relacionado con el aspecto de seguridad.
35
La seguridad en un RPC es importante por dos razones, el RPC es una forma de ejecución remota que pem1ite que los·programas o comandos sean ejecutados en otros sistemas. Por otro lado el RPC se ha convertido en la base de muchos sistemas cliente/servidor, (p.e. NFS, NIS). Todos los aspectos de seguridad de un sistema computacional tienen que construirse sobre un RPC seguro.
El RPC esta basado en un intercambio de mensajes entre cliente y servidor. Debido a esto se debe cuidar la autenticación del cliente y ser\'idor. la integridad, confidencialidad y originalidad de los mensajes y el control de autorización de acceso del cliente al servidor.
En lo que respecta a autenticación es necesario que las identidades del cliente y ser\'idor sean \Crificadas. También se debe ,erificar que la petición fue verdaderamente generada por el cliente y que es dirigida al sen·idor, que el mensaje de respuesta fue \'erdaderamente generado por el sen 1dur y es dirigido al cliente.
En lo que respecta a los mensajes. se debe estar seguro de que los mensajes de petición/respuesta no han sido modificados (integridad). que el contenido de estos no sea revelado (confidencialidad) y que el mismo mensaje no aparezca dos veces.
Una explicación más detallada de los mecanismos de seguridad puede encontrarse en [ 12] y [ 13].
3.7 L1N RPC QUE LLAMA A OTRO RPC
El RPC es un esquema cliente/sen·idor, y una característica de dicho esquema es que un cliente puede ser servidor y vice\'ersa. Ahora bien el disei'lo de este tipo particular de esquema es dificil con llamadas de alto ni\'el e imposible con tan solo un archi\'o de especificación.
La implementación se lle,·a a cabo bajo un esquema de lo que se conoce como RPC asíncrono. Las características de este esquema pem1iten que un procesos ejecute un RPC sobre varios procesos al mismo tiempo y recibir las respuestas de estos tiempo después. En la siguiente sección se explica más a fondo las características de este esquema de RPC.
L'na de las aplicaciones del esquema anterior es lo que se conoce como la ola recursi\'a. Dicho tema será tratado en el siguiente capítulo.
3.8 RPC ASÍNCRONO
La implantación de las diferentes olas que definieron las diferentes regiones requirió de ciertas particularidades del RPC de Sl::\. La librería RPC de SL\: prowe al usuario de diversas características. Estas características incluyen: RPC asíncronos. de tipo broadcast, RPC en batch. así como también soporte de multi,·ersión para sen·icios. implantación de sus propias rutinas
36
sn run( ) y rutinas para comunicarse con el portmapper. Fueron algunas de estas características las utilizadas en la implantación de las olas.
Generalmente cuando un cliente ejecuta un RPC, este tiene una inmediata respuesta por parte del servidor. El cliente manda una petición RPC y luego espera, ya sea por la respuesta del servidor, o que un tiempo de espera (timeout) tem1ine. Esta característica no es muy conveniente. Hay \ eces en que es preferible una conducta parecida al manejo de mensajes en un solo sentido (one\\·ay message handling) o de un RPC asíncrono.
Se pueden seguir tres esquemas para implementar un RPC asíncrono: RPC no bloqueante (nonblocking RPC). RPC de regreso (callback RPC) y RPCs asíncronos de tipo broadcast. Los RPC no bloqueantes proveen una fomia de manejar mensajes en un solo sentido. de cliente a servidor, pero no ofrece apoyo para la respuesta del servidor al cliente. Los RPC tipo callback pueden ser utilizados tanto para ejecuciones nomiales de RPC como para ejecuciones no bloqueantes; lo anterior con el objetivo de proporcionar un manejo de mensajes en dos direcciones totalmente asíncrono entre el cliente y uno o más ser,idores. Los RPC asíncronos de tipo broadcast nos pem1iten mandar por broadcast una petición RPC pero no ofrece un camino de regreso para respuestas del servidor al cliente.
En las siguientes líneas analizaremos las características de los RPC no bloqueantes y de tipo callback. Se proporcionarán algunos ejemplos con el objetivo de ser más claros.
3.8.1 LOS RPC NO BLOQUEANTES
Los RPC no bloqueantes pueden ser usados en situaciones en las que solo se requiere un esquema simple de paso de mensajes. Si se requiere una respuesta, el cliente debe solicitar dicha respuesta al servidor. o debe hacerlo de otra fom,a por ejemplo con un RPC tipo callback. para obtener el resultado.
Para implementar un RPC no bloqueante es necesario asignar un valor de cero al time-out del RPC. Esto implica asignar valores de cero al argumento de clnt_call() o usar clnt_control() para poner en cero el valor de default del time-out antes de ejecutar cualquier RPC. utilizando el manejador específico del cliente. A continuación se presenta un ejemplo.
struct time\·al timeout
timeout.tv sec = O: timeout-t,· usec = O:
if( clnt_control (clnt_handlep. CLSET_Tl\1EOüT. timeout) ==FALSE) * ClTOr *
37
Debido a que el cliente hace una petición RPC no bloqueante, este no espera ninguna respuesta del servidor, lo que implica que el tipo de datos de respuesta deber ser de tipo void, y el servidor debe ser escrito de tal manera que ninguna respuesta sea generada por la petición. Cuando se escriben procedimientos del servidor a ser usados en conjunción con rpcgen, se puede suprimir el envío de respuesta regresando un valor nulo al apuntador de resultados. En el caso de RPC no bloqueantes, la llamada de un cliente siempre regresa un error de tipo RPC_ TIMEDOUT, el cuál puede ser ignorando.
Otra consecuencia que tienen los RPC no bloqueantes en la semántica de la petición es que la librería RPC no toma responsabilidad por rnlver a procesar una petición de la cual no se ha recibido una respuesta. Esto significa que si el RPC es enviado por un datagrama de transporte no confiable tal como UDP, el mensaje se puede perder sin que el cliente lo sepa. Las aplicaciones que utilicen RPCs no bloqueantes deben estar preparadas para manejar esta situación. Los mensajes enviados que utilicen un transporte orientado a conexión tal como TCP son entregados con seguridad; así uno ya no se preocupa por retransmitir una petición.
Los RPC no bloqueantes efectuados sobre un transporte poco confiable, pueden ser útiles para un sen·icio de actualización. Por ejemplo si se desea enviar mensajes de sincronización cada X segundos. y no preocuparse por las retransmisiones de RPCs, conexiones de transporte ni por los reconocimientos de servicio. Se pueden enviar peticiones de RPC no bloqueantes a las computadoras que uno quiere actualizar. El servicio puede llevar a cabo un seguimiento de las actualizaciones para saber cuando fue la última vez que se recibió una, y de esta forma prevenir que se pierdan actualizaciones. Después de una cantidad máxima de tiempo el servicio puede mandar solicitarle al host una actualización confiable.
3.8.2 CALLBACK RPC
Los RPC de tipo callback son los más potentes del método asíncrono. Nos permiten una completa comunicación RPC asíncrona entre clientes y servidores al pem1itir que cualquier aplicación se comporte como ambos: cliente y servidor. Además, facilita un paradigma punto a punto entre los sistemas que participan. También es posible para un cliente el iniciar peticiones a diferentes sen·idores y luego manejar los callbacks de cada uno asincrónicamente. Esto es muy útil en aplicaciones distribuidas. Un ejemplo de aplicación es el chequeo de errores remotos (depuración remota). en el cual el cliente es un programa de ventanas y el sen·idor consiste en un depurador ejecutándose en una máquina remota. La mayor parte del tiempo el usuario introduce comandos en la ventana de depuración lo cual convierte los comandos del usuario en comandos de depuración y después ejecuta un RPC en el sen·idor (en donde esta corriendo el depurador), diciéndole que ejecute el comando. Cuando el depurador llega a un punto de chequeo (hreakpoint). hay un cambio en los roles. y el depurador necesita ejecutar un RPC en el programa de wntanas para infomiarle al usuario que se ha llegado a un punto de chequeo.
38
Para iniciar una llamada RPC tipo callback, el servidor necesita un número de programa para llamar de vuelta al cliente. El número de programa se selecciona dinámicamente del RPC que se realice en ese momento y su rango varía entre Ox40000000 y Ox5FFFFFFF. El cliente registra el servicio de llamada utilizando un número de programa transitorio, con el programa local portmap (vía ¡mwp _ser()) y registra la rutina de atención (a través de la llamada S\'C _register()). Entonces el número de programa es enviado como parte de la petición RPC al servidor. Cuando el servidor esta listo para ejecutar el RPC callback inicia una petición RPC normal al cliente, utilizando el número de programa recibido. El cliente debe esperar por el callback ya sea de forma explícita, por medio de una llamada s\·c_r1111(), o por medio de una llamada a una rutina que procese peticiones RPC.
En vez de que el cliente le em·íe el número de programa al servidor, también le puede mandar el número de puerto en que fue registrado el servicio. Se puede obtener el número de puerto utilizando la rutina pmap _gerport() . El número de puerto puede ser utilizado por el servidor cuando llama a la rutina creada por el manejador del cliente y de esta fomia ahorrarle un RPC al portmapper del cliente para obtener el número de puerto.
Si el servidor tiene que hacer llamadas al cliente de fomia constante, se sugiere escribir el sen·icio de tal fom1a que incluya tanto al proceso cliente como al servidor en ambas computadoras. El sen·idor y el cliente, en la misma computadora, se podrían comunicar por medio de un mecanismo de comunicación de interprocesos, que podría ser el mecanismo RPC, o cualquiera soportado por la librerica IPC (memoria compartida, semáforos y colas de mensajes).
El siguiente segmento de código es un ejemplo de una rutina que asigna dinámicamente un número de programa de un rango transitorio y luego registra la rutina de atención asociada con el sen·icio callback.
;;:include <stdio.h> tinclude <rpcirpc.h> #include <sys/socket.h>
u-long svc _register _ transient( transp, version, dispatch, protocol) SWXPRT *transp; u _long version; void (*dispatch)(); u_long pro toco!;
!* Principio rango transitorio de búsqueda * ! static u_long prognum = O X 40000000:
* Obtención del numero de programa de la rutina callback *!
\\hile ( pmap_set(prognum, \-ersion, protocoL transp->xp_port) && prognum < Ox50000000) :
prognum ++;
!* protocolo es O - pmap_set registro el numero con el portmapper */
if (prognum < Ox50000000) {
else
if (svc _register(transp, prognum. version. dispatch, O)== FALSE) { svc _ unregister(prognum. version); retum (O);
prognum = Ox40000000 retum(O);
retum (prognum ++ );
/* s,-c_register_transient */
39
La rutina s,·c _registcr_tra11sic11t() toma los siguientes argumentos: un apuntador a un manejador de transporte, la ,-ersión del número de serYicio. la dirección de la rutina de servicio y el protocolo a usar. La rutina entra en un ciclo. llama a pmap _set() para registrar el servicio; si la llamada falla significa que el número de programa está siendo usado por alguien. En este último caso la rutina incrementa el número de programa y trata de ejecutar la llamada de nuevo. Una vez que la llamada tiene éxito, se invoca a s,·c _register() para registrar la rutina. Se puede apreciar que se utiliza el valor de O para el protocolo; este valor le dice a la rutina svc_register() que el programa ya ha sido registrado por el portmapper. La variable prog11u111 ha sido declarada de tipo static para pem1itir llamadas futuras a esta rutina con el fin de empezar la búsqueda de un número de programa a partir de donde se deturn la última llamada. Es necesario hacer hincapié en que la búsqueda por números de programas se detiene al final del rango transitorio, en lugar de regresarse al principio del rango y continuar la búsqueda. Se puede añadir esta característica a la rutina si así se desea.
Si el cliente llama a s,·c_r1111() para esperar por peticiones de RPC, no podrá llevar a cabo ningún otro tipo de procesamiento. Si necesita que el programa cliente continúe trabajando mientras que espera por peticiones RPC. se puede generar otro proceso que llame a svc _ru11() para esperar por peticiones. Otra altematiYa es que escriba su propia rutina s,·c_r1111(). A continuación se presenta un ejemplo de un servidor que utiliza RPC tipo callback.
**************************************************************** Archirn de encabezado: callback.h ****************************************************************!
;:define EXAl\1PLE PROG ;:define EXAMPLE VERS ;:cdeline EXAMPLE PROC
( ( u _long)(Ox20000020)) ((u_long( 1 )) ((u_long( 1 ))
#define EXAMPLE CALL BACK VERS - - -#define EXAMPLE ·C ALL BACK PROC
- - -
((u_long(l )) ((u_long)( 1 ))
#define MAX HOST NAME LEN - - -
tydef strcuct : u_]ong prognum: u_long versnum; u_long procnum; char hostnamc[MAX_HOST _\:A\1E_LE\:]:
: cal! info:
cxtcrn bool t xdr_call_info();
64
!**************************************************************** Rutinas del servidor ****************************************************************!
#includc <stdio.h> #include <rpc rpc.h> l=includc '"callback.h"
struct time\·al timeout = : 25.0}:
main()
S\'CXPRT *transp: rnid dispatch( ):
transp = svcudp_create(RPC_ANYSOCK); if ( transp = = NULL) {
fprintf(stderr, "Error: fallo la llamada a svcudp _ create() \n"); retum( 1 ):
(\·oid) pmap_unset(EXAMPLE_PROG. EXAMPLE_ YERS): if (s\'c_register(transp, EXAMPLE_PROG. EXAMPLE_ VERS, dispatch,
IPPROTO _ UDP) = = FALSE ) { fprintf(stderr ... Error: No fue posible registrar el ser\'icio \n"); S\'C _ destroy( transp ); retum( 1 ):
printl( .. Ser\'idor en modo S\C_run \n"); S\'C _run( ):
40
fprintf(stderr,"Errro: svc_run() no debe regresar \n"); svc_unregister(EXAMPLE_PROG, EXAMPLE_ VERS); svc _ destroy(transp ); return( 1 );
!* main */
void dispatch(rqstp, transp) struct svc_req *rqstp;; SVCXPRT *transp;
cal! info \'Oid
callback info; docallback();
switch (rqstp->rq_proc) { case NULLPROC:
if (svc_sendreply(transp, xdr_ void, O)== FALSE) { fprintf(stderr, "Error en svc_sendreply() NULLPROC \n");
break: case EXAMPLE PROC:
if(s\'c_getargs(transp,xdr_call_info,&callback_info) == FALSE) { svcerr_ decode(transp ); return;
if (svc_sendreply(trasnp, xdr_ void, O)== FALSE) { fprintf(stderr. "Error en S\'C_sendreply() EXAMPLE \n"); return;
.!* simulando un procesamiento intenso*/
printf("Realizando un procesamiento intenso*/ sleep(5); printf("Llamando al cliente de regreso con los resultados \n"); docallback(&callback _ info ); break;
1* dispatch *1
, oid docallback( call _infop) call info *call_infop;
CLIE'.\T *clnt_handlep: enum clnt stat status;
41
clnt_handlep = clnt_create( call_infop->hostname, call_infop->prognum, call_infop->versnum, "udp");
if (clnt_handlep = = NULL) 1 e lnt_pcreateerror( cal!_ in fop->hostname ); retum;
status= clnt_call( clnt_handlep, call_infop->procnum, xdr_rnid. NULL, xdr_void, NULL, timeout):
if(status != RPC_SUCCESS) i clnt_perror( e lnt_handlep, cal l_infop->hostname );
e lnt_ destroy( clnt_handlep ): !* docallback * !
!**************************************************************** Rutinas del cliente ****************************************************************!
#include <stdio.h> trine! ude <rpc/rpc/rpc. h> #include <sys/socket.h> #include "callback.h"
main(argc. arg\") int argc; char **arg\";
SYCXPRT call info int u lonu - ~
rnid
if (argc != 2) {
*transp; callback info; status; svc _register _ transient( ); callback:
fprintf(stderr. "Error en uso: %s hostname \n", argv[O]); retum( 1 );
stmcpy(callback_info.hostname. arg\"[ 1 ], MAX_HOST _NAME_LEN):
if(transp = S\cudp_create(RPC_A:\YSOCK)) = = NULL) { fprintl(stderr, "Error: llamada s\·cudp_create() fallo \n"): retum( 1 ):
42
f callback_info.prognum = svc_register_transient( transp,
EXAMPLE_CALLBACK_ VERS, callback, IPPROTO _ UDP);
if (callb~ck_info.prognum ==O) { fprintf(stderr. '"Error: no se pudo registrar servicio transitorio \n"); svc _ destroy(transp ); retum( 1 );
printf("Usando numero programa transitorio: %Ju \n", callback_info.prognum); callback_info.versnum = EXAMPLE_ C ALLBACK_ VERS; callback_info.procnum = EXAMPLE_ C ALLBACK_PROC;
status= callrpc( callback_info.hostname, EXEMPLE_PROG. EXAMPLE_ VERS, EXAMPLE_PROC, xdr_call_info, &callback_info, xdr_void, (xdrproc_t)O);
if (status != 0) :
fprintf(stderr. "Error: callrpc( ): %s \n ... clnt_ spem10( enum clnt_ stat)status) );
svc _ unregister( cal lback _info.prognum ..
svc _ destroy(transp ); return( 1 );
S\'C run( );
EXAMPLE_CALLBACK_ VERS);
fprintf(stderr. "Error: S\'C_run() no puede regresar \n"); svc _ unregister( cal lback _ info. prognum. = EXAMPLE _ C ALLBACK _ VERS ); svc _ destroy(transp ); ret urn( 1 ) ;
i /* main */
\Oid callback (rqstp. transp) struct S\'C_req *rqstp;; S\"CXPRT *transp;
s\,·itch (rqstp->nL_proc) 1 case NULLPROC:
if(s\c_sendreply(transp. xdr_void. O)== FALSE) i fprintf(stden. "Error en svc_sendreply() NULLPROC \n");
break; case EXAMPLE CALLBACK PROC:
43
,'* callback */
if (svc _getargs(transp, xdr _ void, O) == TRUE) {
printf("Cliente recibio callback de servidor \n"); if(svc_sendreply(trasnp, xdr_void, 0) == FALSE) {
fprintf(stderr, "Error exampleprog \n");
else :
retum;
svcerr _ decode( transp );
retum;
svc _ unregister(rqstp->rq_prog. rqstp->VERS );
S\'C _ destroy( transp ); exit(O);
break;
!****************************************************************
Rutinas XDR ****************************************************************/
;:jnclude <rpc/rpc.h>
#include "callback.h"
boolt xdr_call_info(xdrs, objp)
XDR *xdrs;
cal! info *objp;
char *tmp;
tmp = objp -> hostname; if (xdr_u_long(xdrs, &objp->prognum) ==FALSE) {
retum(F ALSE);
if (xdr_u_long(xdrs. &objp->versnum) ==FALSE) {
retum(F ALSE);
if (xdr_u_log(xdrs. &objp->procnum) ==FALSE) {
retum(FALSE);
retum(xdr_string(xdrs, &tmp. MAX_HOST_NAME_LEN);
* xdr call info *
44
45
La rutina main() del servidor simplemente obtiene un manejador de transporte, registra el ser\'icio, las rutinas ·y llama a svc _run() para esperar por peticiones RPC. La rutina procesa la llamada al procedimiento EXAMPLE_PROC al obtener argumentos y mandar automáticamente una respuesta al cliente. Los argumentos para esta rutina incluyen el nombre del host, el número de programa, el número de \'ersión y el número de procedimiento que identifica la computadora y
el programa remoto que el sen·idor debe llamar de regreso cuando el trabajo sea hecho. Un trabajo intensivo de computación es simulado mandando dormir por 5 segundos al proceso. Finalmente, se llama a la rutina docallhack() para notificarle al cliente que el trabajo se ha reali1ado.
El cliente obtiene un manejador de transporte y registra un servicio transitorio al llamar la rutina .l'l'c_rcgisrcr(). Después hace un RPC al sen idor. Cuando esto es hecho, llama a s,·c_run(} para esperar la llamada del ser\'idor. Típicamente se efectuaría el procesamiento mientras se espera por la llamada. Esto puede se puede hacer creando un proceso que espere la llamada del ser\'idor, o escribiendo una nue\ a versión de la rutina s\'C_1w1(). Nótese que el cliente usa funciones tanto de alto como de bajo nivel.
3.9 DISEÑANDO UNA APLICACIÓ:'1 DISTRIBUIDA
Existen \·arias referencias que hablan del disefio de aplicaciones distribuidas, [14), [15) y [16). Típicamente cuando se diseña una aplicación distribuida, se tienen varias consideraciones, el objetivo de la aplicación, el ni\·e] de seguridad, los tipos de equipos involucrados (heterogeneidad), la identificación de procedimientos remotos, los parámetros de entrada y salida para los procedimientos remotos. la recuperación de los errores y las pruebas para una aplicación distribuida.
Inicialmente se necesita conocer el objeti\'o; cuál es el propósito de la aplicación distribuida La definición de metas es un importante primer paso para cualquier tarea de ingeniería. Una vez que la meta ha sido claramente definida. se especifica la funcionalidad de la aplicación.
Otro paso importante es la autenticación de la aplicación. Se pueden evaluar los tipos de autenticación proporcionados por Librería RPC para detenninar si uno de estos es satisfactorio.
Normalmente, los argumentos y resultados a llamadas remotas de procedimiento son legibles por cualquiera de las comunicaciones por monitoreo entre un cliente y un servidor. Para prevenir esto. se recomienda encriptar los argumentos y resultados antes de mandarlos hacia la red.
La heterogeneidad es importante en el diseño de una aplicación distribuida y, típicamente. entre más po11able sea la aplicación. será mejor. Se debe considerar la independencia de arquitectura de la máquina. la independencia del sistema operatirn y la independencia del transporte de red.
46
La importancia de escribir aplicaciones del software que sean independientes a la computadora y al sistema operativo permite la portabilidad del sistema. El lenguaje C es una buena herramienta para esto. Cuando se escriben aplicaciones distribuidas, otros aspectos que afectan la portabilidad no están relacionados con el lenguaje de programación o el estilo de código utilizado. Solamente porque un programa compila en diferentes ambientes no significa que este trabajará. Es importante asegurar que la especificación del protocolo no tiene dependencias con ningún alcance de salida de la aplicación. Si lo tiene, se necesita incrementar la dificultad asociada portando la aplicación a otra computadora o contar con un manejo interno de problemas.
Idealmente, se quiere que la aplicación sea independiente de la red de transporte usada. Típicamente se adquiere esta independencia guardando cualquier transporte de dependencias aisladas en la misma capa donde la interfaz de RPC está localizada. No se debe dejar transportar dependencias en la aplicación ( ejemplos: tamaño de paquete, tiempos fuera, direcciones). Realzar la independencia implica que el cliente debe ser lo suficientemente hábil para correr independientemente de que versión de ser\'icio está disponible. Por ejemplo si hay tres \'ersiones de la aplicación distribuida, entonces el cliente debe ser capaz de trabajar con cualquier versión del servidor aunque se limiten las características disponibles a los usuarios, dependiendo de que versión del usuario que se está usando. La independencia del vendedor del software, es una importante consideración. Típicamente un vendedor de software publica un protocolo de especificación para una aplicación distribuida para animar a otros vendedores de software para portar la aplicación en su platafonna de hardware.
Lna \·ez completado el disefio de la aplicación probablemente se usen cuadros para realizar el diagrama de los procedimientos que se planea implantar. Cuando se tiene definidos los procedimientos y sus argumentos. se prosigue con la separación de la aplicación. Separar la aplicación es el proceso de decidir cuales procedimientos son locales y cuales son remotos, para continuar con la especificación del protocolo.
La única interacción entre el cliente y el servidor es a través de la salida y la entrada de parámetros para los procedimientos remotos. La definición de esta interacción está en la especificación del protocolo para la aplicación distribuicta. La especificación del protocolo define los procedimientos remotos, incluyendo los tipos de infom1ación de los argumentos y el regreso de nlores. Debe contener toda la infomrnción requerida por alguien para implementar un ser\'idor para esa aplicación. incluyendo comentarios y la suficiente documentación. En general, si un protocolo existe para la función que se desea accionar. es mejor utilizarla que inventar una. Si el protocolo no existe para la función que se deseas accionar, se debe desarrollar una nue\'a solución basada en los protocolos existentes si es posible. No se debe introducir arquitectura del equipo. sistema operativo o dependencias de red de trabajo en la especificación del protocolo. XDR aísla las dependencias más comunes relacionadas con los tipos de datos.
L'na , cz diseiiada la aplicación distribuida. entonces se procede a implantarla. Rpcgen es usada para procesar el protocolo de la especificación del archirn. Rpcgen genera las rutinas XDR.
Lna de las opciones para el disefio e implantación de sistemas distribuidos es el uso del paradigma conocido como llamada de procedimientos remotos, (RPC por sus siglas en inglés). El
47
princ1p10 es simple, la mayor parte de los algoritmos diseñados se basan en el principio de descomposición de un problema en varios módulos, los cuales se pueden invocar el uno al otro
dependiendo del sistema. El uso del envío I recepción de mensajes no permite lo anterior, por lo que en 1988 propusieron un nuevo paradigma que conserva ese principio de llamado de módulos.
En dicho paradigma un proceso invoca un procedimiento, con sus respectivos parámetros, que se encuentra definido dentro de un proceso que reside en una máquina distante. Este último proceso ejecuta localmente el procedimiento llamado, para después enviar los resultados al proceso invocador.
4. LA RECURSIÓN COMO UN ESTILO DE PROGRAMACIÓN DENTRO DE LOS SISTEMAS DISTRIBUIDOS
48
En este capítulo se presenta un esquema para la concepción de algoritmos dentro de los sistemas distribuidos llamado ola recursi\'a [5]. Está basado en la recursión, la herramienta RPC y una primiti\'a concurrente. Se dota de un esquema que le pem1ita desarrollar algoritmos con un alto grado de abstracción. Aparte de mostrar el esquema. este capítulo presenta tres variantes de la ola recurs1\·a.
L'n resultado de la e\·o]ución de los equipos de cómputo son los sistemas distribuidos. Los algoritmos desarrollados dentro de este tipo de sistemas están basados en el envío y recepción de mensajes. Esto provoca que la concepción e implantación de algoritmos dentro de estos sistemas no sea una tarea simple. y obliga al programador a utilizar una técnica diferente a la utilizada en las computadoras secuenciales. El programador de algoritmos distribuidos debe tomar en cuenta di,·ersos factores. como por ejemplo la topología de la red, la sincronización en el em'Ío y recepción de mensajes. Se presenta un nue\'o esquema para la concepción de algoritmos dentro de los sistemas distríbuidos, que se encuentra basado en el concepto de recursión, así como en la herramienta RPC (de sus siglas en ingles: Remole Procedure Cal!). Este esquema proporciona un alto grado de abstracción. Tomando en cuenta que en un ambiente secuencial el programador no se preocupa por la gestión del almacenamiento de registros ni de las direcciones de la computadora.
En el disei'io de los algoritmos distribuidos existen , arios problemas generales para el proceso de redes que aparecen frecuentemente como subtareas. Estas tareas elementales incluyen el broadcasting de la infonnación (ejemplo en inicio o tenninación de un mensaje), alcanzando una sincronización global entre procesos, lanzando la ejecución de algunos eventos en cada proceso, o ejecutando una función la cual en cada proceso espera por una entrada. Estas tareas son siempre desempei1adas por el paso de mensajes de acuerdo a algunas prescripciones, esquemas de dependencias de topología que asegura la participación de todos los procesos. Realmente estas tareas son fundamentales de problemas complicados tal como elección, detección de tem,inación o exclusión mutua puede ser dados en la comunicación entre procesos que ocurra sólo este paso de mensajes. El esquema de paso de mensajes, se le llama algoritmo de ola.
49
4.l DEFINICIÓN ALGORITMO DE OLA
Un algoritmo distribuido usualmente pennite una larga colección de posibles cálculos, debido al no detern1inismo en los procesos tan bien como el subsistema de comunicaciones. Un cómputo es una colección de eventos, parcialmente ordenados por la relación de precedencia causal. Se asume que hay un tipo especial de evento interno llamado evento de decisión, un algoritmo de ola intercambia un número finito de mensajes y entonces ellos toman una decisión, la cual depende de algunos e\·entos en cada proceso.
L'n algoritmo de ola es un algoritmo distribuido que satisface los siguientes tres requerimientos.
1. Tem1inación. Cada cómputo es finito. 2. Decisión. Cada cómputo contiene al menos un evento de decisión. 3. Dependencia. En dada cómputo cada evento de decisión es causalmente precedido por un
en e,·ento en cada proceso.
Un cómputo en un algoritmo de ola es llamado ola. Como una notación adicional, en un cálculo de un algoritmo una distinción es hecha entre iniciadores y no iniciadores, también llamados seguidores. Un proceso es un iniciador si empieza una ejecución de algoritmo local espontáneamente. ejemplo el lanzamiento de alguna condición interna del proceso. Un no iniciador llega a serlo envuelto en el algoritmo solo cuando un mensaje del algoritmo llega y lanza la ejecución de algoritmo de proceso. El primer evento de un iniciador es interno o evento de envío. el primer evento de un no iniciador es un evento de recepción [ 17].
Una variedad de algoritmos de ola existe porque los algoritmos se pueden diferenciar en algunos aspectos. Como un fundamento para el tratamiento de un largo número de algoritmos. Los algoritmos de ola difieren de otros en:
1. Centralización. Un algoritmo es llamado centralizado si tiene exactamente un iniciador en cada cómputo y descentralizado si el algoritmo puede ser iniciado espontáneamente por un subconjunto arbitrario de procesos. Los algoritmos centralizados pueden ser llamados también de fuente simple y los descentralizados multi fuente. La centralización tiene un influencia importante en la complejidad de los algoritmos de ola.
Topología. L'n algoritmo puede ser diseñado por una topología especifica. tal como anillo. árbol, ciclo. etc.
J. Conocimiento Inicial. Un algoritmo puede asumir la disponibilidad de varios tipos de conocimiento inicial en el proceso. Ejemplos de conocimiento prerrequerido incluye lo siguiente:
a) Procc'so de identidad. Cada proceso inicialmente conoce su propio y único nombre.
50
b) Identidad de los vecinos. Cada proceso conoce inicialmente los nombres de sus vecmfls.
4. Número de decisiones. El número de procesos que ejecutan un evento de decisión puede ,·ariar: en algunos algoritmos solo un proceso decide, en otro todos los procesos deciden. En un algoritmo de árbol la decisión es causada por exactamente dos procesos.
5. Complejidad. La complejidad se mide en el número de mensajes intercambiados, el número de bits intercambiados y el tiempo necesitado para un cómputo.
Cuando un algoritmo de ola es usado hay generalmente mas variables y otra infom1ación puede ser incluida en el mensaje. Algunas aplicaciones dependen en la simultaneidad o la propagación secuencial de \'arias olas: en este caso infom1ación de la ola de a quien pertenece el mensaje puede ser incluida en los mensajes. También un proceso puede guardar \'ariables adicionales para administrar la ola u olas acti\'as.
Una importante subclase de algoritmos de ola es fonnado por los algoritmos centralizados de ola teniendo las siguientes propiedades adicionales: El iniciador es un solo proceso que decide; todos los e, entos son ordenados totalmente.
4.2 DETECCIÓN DE TER!\1INACIÓN
Un cómputo de un algoritmo distribuido tcm1ina cuando el algoritmo ha alcanzado una configuración tem1inal: esto es. una configuración en la cual más pasos no son aplicables. Esto no siempre es el caso en una configuración tem1inal cada proceso es un estado tem1inal; que es un estado del proceso en el cual no hay eventos aplicables. La tem1inación es dicha explícita en un proceso si el estado del proceso en la configuración temlinal es un estado terminal del proceso. Tem1inación implícita es también llamada terminación de mensaje porque no mas mensajes son intercambiados cuando una configuración de tem1inal ha sido alcanzada. La terminac_ión explícita es también llamada tem1inación de proceso porque los procesos han tem1inado si un algoritmo explícito temlina.
Es usualmente más fáci I de disei1ar un algoritmo que tem1ina implícitamente que uno que tem1ina explícitamente. Durante el disei10 de un algoritmo todos los aspectos de tem1inación de procesos pueden ser ignorados: la aplicación de un algoritmo requerirá que los procesos tem1inen explícitamente. Solo después de una temlinación explícita puede los resultados de un computo ser considerados como finales y las \'ariables usadas e el proceso. Un deadlock de un algoritmo distribuido resulta en una configuración tern1inaL en este caso el computo puede ser restablecido cuan una configuración tem1inal es temlinada.
Algoritmos de transfom1ación de mensajes tem1inales en procesos de terminación. Los métodos consisten de agregar dos algoritmos que interactúan con el algoritmo de temlinación de mensaje
51
dado. Uno de estos algoritmos observa el computo y detectará el final, este entonces llama el segundo algoritmo, el cual fluye un mensaje de terminación a todos los procesos, causando entonces un estado terminal.
Lo más dificil de la transformación es que el algoritmo detecte la terminación.
4.3 LA OLA RECURSIVA
El esquema de programación propuesto tiene por nombre ola recursiva. Este nombre es debido a las técnicas que utiliza: los algoritmos de tipo ola, y a la recursividad. Los algoritmos de tipo ola fueron presentados por la primera vez en 1982 por Chan Ernest [ 18]. Estos tipos de algoritmos están asociados al concepto de difusión de cálculo, y esta compuesto de dos fases. La primera fase pem1ite una propagación, (broadcasting), de infomrnción a todos los sitios que componen una red; la segunda realiza un recolecta de resultados. Estos resultados pueden ser utilizados como una simple notificación de que la propagación temlino, o puede incluir infomrnción sobre ciertos sitios. Bajo este contexto es fácil comprobar que los dos recorridos efectuados por la ola no son forzosamente los mismos, ( el camino de la propagación puede ser diferente al del regreso). Encontramos diferentes trabajos sobre estos algoritmos [ 19], [20] nosotros presentamos un nuevo tipo de ola que utiliza el RPC (Remate Procedure Call) en combinación con una primitiva concurrente para su propagación, y el concepto de recursión para recuperar la infonnación.
Una ola recursiva es antes que nada un procedimiento el cual, durante su ejecución, efectúan o más ejecuciones paralelas del mismo en otros lugares.
La ejecución de este tipo de procedimiento sobre una red de procesadores genera una topología vi11ual de árbol, con las características siguientes:
• La raíz del árbol es el procesador que realizó la primera ejecución del procedimiento; • Los diferentes nodos del árbol representan procedimientos que esperan la tem1inación de
las llamadas precedentes; • Las hojas del árbol representan ya sea la ejecución activa del procedimiento o un
procedimiento que no hace ninguna llamada.
Tomemos como ejemplo la red representada en la figura 4.1. En la parte (a) el procesador B lanza la primera ejecución sobre los procesadores A y D. Da su vez ejecuta sobre E el cual lo hace sobre H. Lo mismo ocurre con C. F y G.
Figura 4.1: Generación de una topología virtual de árbol a partir de la ejecución de una ola recursiva
52
El procedimiento que define una ola recursiva puede formar parte de un conjunto de procedimientos realizados para un objeti\'o en común. Este conjunto puede englobar una estructura de datos. como el concepto de encapsulación definido en los sistemas orientados a objetos. Esta estructura de datos puede incluir el identificador del procesador activo, los identificadores de los vecinos. así como datos propios al problema a tratar.
Se asume que todas las comunicaciones y sincronizaciones entre las diversas ejecuciones se encuentran regidas por el esquema del RPC. Las líneas de comunicación son seguras, y ningún tipo de falla es considerado. Con el fin de controlar las diferentes ejecuciones del procedimiento sobre un mismo procesador. utilizamos \·ariables comunes a las ejecuciones, cuyo acceso se controla mediante un candado.
4.3.1 DEFINICIÓN DE UNA OLA RECURSIVA
Para definir una ola recursi\'a se necesita una primiti\·a de concurrencia; así como una primitiva para la ejecución de un procedimiento definido en otro procesador, ( es decir el RPC).
4.3.1.1 Primitirn de Concurrencia
Esta primiti\·a nos s1n·e para la generac1on de tareas paralelas. y debe respetar la sintaxis siguiente:
par i in <campo> do < Bloque de Instrucciones>
enddo
53
Esta instrucción activa una "tarea" por cada elemento incluido dentro de <campo>. Esta instrucción es considerada como terminada cuando todos las "tareas" generadas terminan su trabajo.
4.3.1.2 Sintaxis del RPC
Si bien vale la pena explicar mas a detalle el proceso RPC al cual se le dedico un capítulo aquí se menciona brevemente para comprender el algoritmo a describir.
Como se dijo anteriom1ente la ola recursiva necesita de un mecamsmo de RPC. Este debe cumplir con la sintaxis siguiente:
<nombre pcd> (<lista parámetros>) on <idt pres>;
Es decir un procedimiento llamado <nombre pcd> es ejecutado en el procesador indicado por <idt_prcs>. con los parámetros definidos dentro de <lista parámetros>. Esta primitiva y la anterior se encuentran ligadas en el sentido de que <idt_prcs> es considerado como una variable que puede tomar su valor de la variable <campo> definida en la primitiva anterior.
4.3.1.3 Esquema General de la Ola Recursiva
En la figura 4.2 encontramos el esquema general de la ola recursiva.
El esquema se encuentra enumerado para su mejor entendimiento. Los <Bloque de instrucciones> representan cualquier secuencia de instrucciones. En la línea 2 se encuentra la declaración de variables locales. La condición de la línea 5 va a detenninar cuando va a dejar de propagarse la ola1
'. Una vez que la ola se detiene el bloque de instrucciones en la línea 14 se encarga de realizar los últimos cálculos y de enviar los resultados al procesador que activó el procedimiento.
Entre las líneas 7 y 11 se realizan las tareas paralelas. y es el lugar donde se efectúa la propagación de la ola recursiva. En efecto en la línea 9 se ejecuta el RPC en los diferentes procesadores. Los identificadores de los procesadores, a donde es propagada la ola, son tomados de la ,·ariable <campo> de la línea 7.
A continuación presentamos tres variantes de la ola recurs1,·a. En cada una presentamos un ejemplo de aplicación.
'' El cqu1\'alen1e a la condición utilizada para detener la recursión dentro de un procedimiento recursiYo. Cabe resJl!Jr que esta condición es diferente a la condición de terminación del algoritmo.
1 procedure ola recursiva( <parámetros> ) is 2 <Bloque de declaraciones> 3 begin 4
5 6
7 8 9
10 11
<Bloque de instrucciones A> i f <condición> then - Condición para detener la propagación de la ola
<Bloque de instrucciones B> par i in <campo> do
enddo;
<!Bloque de instrucciones C> ola recursi\a(<parámetros>) on i; - Llamado del RPC <Bloque de instrucciones D>
12 <Bloque de instrucciones E> 13 endif; 14 <Bloque de instrucciones F> 15 end ola recursi\'a;
Figura 4.2: Esquema fonnal de la ola recursi\'a.
4.3. 1 .4 La Ola Recursirn Secuencial
54
La fonna más simple de realizar una llamada recursiva de un procedimiento dentro de un sistema distribuido el de llamar/acti\'ar ese mismo procedimiento una sola vez sobre otro procesador. En este caso el árbol de ejecución se reduce a una lista encadenada, donde el primer elemento es el iniciador del calculo.
En algorítmica distribuida la única estructura de control, que se presta a este tipo de cálculos, (aparte de la lista encadenada), es el anillo virtual. Si suponemos que tal estructura existe, y que cada procesador conoce su sucesor y su predecesor, entonces la ola recursiva puede ser implementada muy fácilmente. Por otro lado, no habrá más que una sola ejecución activa del procedimiento: la efectuada por el último procesador de la cadena. El esquema general de la ola rccursi\'a secuencial se encuentra definido en la figura 4.3.
1 procedure ola sec( <parámetros> ) is 2 <Bloque de declaraciones> 3 begin 4
5 6
< Bloque de instrucciones A > if <condición> then
<Bloque de instrucciones B> 7 ola sec( < parámetros >) on sucesor; 8 <Bloque de instrucciones D> 9 endif 1 O <Bloque de instrucciones F >
1 1 end ola sec;
Figura 4.3: Esquema de la ola recursiva secuencial
55
Comparando el esquema de la figura de arriba con el de la figura 4.2 podemos constatar la ausencia de los bloques de instrucciones C y E. En realidad el bloque B y el C están agrupados dentro de B. Lo mismo ocurre con los bloques E y F. Por otro lado no se incluye la primiti\'a par debido a que el RPC no se realiza en paralelo (solo es activado un procedimiento a la vez).
4.3.1.5 La Ola Recursiva sobre una Topología de Árbol
Después de haber analizado el caso de la estructura más simple, veremos como se comporta la ola recursiva sobre un conjunto de procesadores estructurados en una topología de árbol. ( estamos hablando de una estructura \·irtual y no fisica).
La estructura de árbol es bastante utilizada dentro de los algoritmos de control cuando se requiere recolectar un estado global o difundir una infom,ación. Esta forma de actuar requiere un excelente uso de los recursos de comunicación, pero considera que una topología virtual de árbol esta definida durante el cálculo, lo que supone también que la topología fisica es estable.
Para construir tal topología podemos utilizar los algoritmos descritos en [21] o [22].
En este tipo de estructura cada procesador conoce su padre y sus hijos dentro del árbol. solo la raíz no tiene padre siendo esta la que inicia el cálculo. La especificación de este tipo de ola se encuentra en la figura 4.4.
1 procedure ola árbol( <parámetros> ) is 2 < Bloque de declaraciones > 3 begin 4 5 6 7
8 9
10 11 12 13
< Bloque de instrucciones A> if <condición> then
endif
<Bloque de instrucciones B> par i in hijos do
enddo
<Bloque de instrucciones C> ola árbol(<parámetros>) on i; <Bloque de instrucciones D>
<Bloque de instrucciones E >
14 <Bloque de instrucciones F > 15 end ola árbol;
Figura 4.4: Esquema de la ola recursi\'a en una topología de árbol.
4.3.1.6 La Ola recursiva lnundante
56
Las olas recursivas presentadas en las secciones precedentes tienen como característica el que trabajan sobre topologías definidas anteriom1ente. Esto implica la utilización de un algoritmo que construya la topología necesaria, además las topologías de las redes construidas deben de ser lo suficientemente estables para que los algoritmos sean eficientes.
Cuando la topología de la red es susceptible de cambios, (por ejemplo en el caso de sistemas orientados a objetos, donde los objetos son creados y destruidos al mismo tiempo), necesitamos de otro tipo de herramientas. Con el fin de poder construir algoritmos bajo estas circunstancias, presentamos un tipo de ola recursiva que construye dinámicamente su estructura de control. Este tipo de ola construye su propia estructura, utilizando una estrategia conocida con el nombre de inundación. Es por esto que decidimos llamar a este tipo de ola: Ola recursi\'a inundante.
Existen diferentes fomias de controlar una estrategia de inundación de mensajes dentro de una red de computadoras. La diferencia entre cada una de ellas se encuentra en la manera de detener la propagación de los mensajes, es decir la fom1a en que es detenida la propagación de la ola recursi, a. Podemos distinguir tres tipos de estrategias:
1. Limitar el número de llamadas recursi,·as: cada mensaje es ell\"iado al menos n veces. Esta limitación puede ser controlada utilizando un contador el cual es decrementado en cada llamada.
57
2. Activar solo una vez un procedimiento en cada procesador: esto consiste en ejecutar un procedimiento sobre un procesador solamente la primera vez que este es activado. Si otros mensajes de activación llegan después al procesador, estos no serán tomados en cuenta.
3. Acarrear la lista de procesadores visitados: una lista ordenada de procesadores es pasada como parámetro durante la propagación de la ola recursiva. De esta forma, la ola es propagada solo al procesador cuyo identificador no se encuentre en la lista. Mediante esta técnica el número de mensajes es reducido, sin embargo el tamaño de estos aumenta.
Otra solución posible es la combinación de todos estos tipos de mensajes. Esto se puede constatar en la solución de Lamport. Shostak y Pease al problema de los Generales Bizantinos. (ellos utilizan una combinación de la primera y última estrategia). Con el fin de especificar la ola recursi\'a inundante utilizamos la tercera estrategia.
4.3.1.6.1 Especificación de la Ola Recursiva lnundante
A continuación presentamos el esquema general de la ola recursiva inundante. La estructura de control construida por la estrategia de inundación es un árbol. El esquema se encuentra definido en la figura 4.5.
I procedure ola inunda( <parámetros>) is 2 i: id procs; 3 \'ecinos. procs a visitar: setof id procs; 4 <Bloque de declaraciones> 5 begin 6 procs a \·isitar:= vecinos - procs a visitar; 7 < Bloque de instrucciones A> 8 if <condición> then 9 <Bloque de instrucciones B> 10 11 12 13 14
par i in procs a visitar do
enddo
<Bloque de instrucciones C> ola inunda(<parámetros>) on i; <Bloque de instrucciones O>
15 <Bloque de instrucciones E > 16 endif 17 <Bloque de instrucciones F > 18 end ola inunda;
Figure 4.5: Esquema de la ola recursi\'a inundante
58
Notemos que el esquema de este tipo de ola utiliza todos los bloques de instrucciones. Por otro lado la ola termina su propagación después de visitar todos los sitios. Dado que los identificadores de los procesadores visitados anteriormente son pasados como parámetro, la instrucción: procs a visitar:=vecinos - procs a visitar, da como resultado el conjunto vacío lo que ocasiona que la ola detenga su propagación.
59
5. LOS ALGORITMOS A REGIONES: ESPECIFICACIÓN E IMPLANTACIÓN
Existen muchos tipos de algoritmos multi-regiones. A fin de explicar las características de éstos algoritmos y ejemplificar su implantación se eligieron los algoritmos multi-regiones basados en los algoritmos tipo ola descritos en el capítulo anterior.
5.1 CARACTERÍSTICAS DE LOS ALGORITMOS MULTI-OLAS
LnJ o!J recursiva pasa por \·arias etJpas durante su ejecución. estas son. la bajada. la visita y la subida.
Ln algoritmo multi-olas es un algoritmo distribuido en el cual dos o más olas recursivas están en ejecución. Presenta las características siguientes:
• Existe más de un iniciador. • La etapa de subida y bajada de diferentes olas se encuentran mezcladas. • Se cuenta con un árbol de ejecución asociado a cada ola recursiva.
1\o hay que confundir el concepto de multiolas con el de tren de olas [20). la diferencia entre un tren de olas y un algoritmo multi-olas. reside en el momento de la ejecución de la segunda ola. En un tren de olas una nueva ola comienza su ejecución sobre el mismo iniciador una vez que todos los otros procesos tem1inaron con la primera. Si una tercera es necesaria, tendrá que esperar que la segunda tem1ine. Por otro lado, en un algoritmo multi-olas, en cualquier momento del cálculo una nueva ola puede comenzar su ejecución. a partir de cualquier sitio de la red.
5.2 TERJ\11NOLOGÍA Y CONSIDERACIONES
Se considera que la red es conexa y que los identificadores de los procesos son diferentes. No existen dos olas con el mismo identificador (i.e. una ola no tiene más que un solo iniciador). Las líneas de comunicación son fiables y no hay alteración de mensajes. Cada sitio que lanzó una ola. es considerado como un candidato a ser el sitio elegido y la ola toma como identificador el del identificador del sitio que lo lanzó.
60
En estos sistemas varias olas pueden estar presentes durante la ejecuc1on. Cada ola va a propagarse sobre toda la red. Si una ola llega a un sitio ya visitado por otra ola, debe decidir si continua o si detiene su propagación. Esta decisión es tomada en función de la relación de orden de los identificadores de la ola. Si la ola es mejor que la que visitó anteriormente el sitio, esta continua. sino se detiene. Esto nos lleva a definir tres tipos de olas: la ola dominante, una ola en plena propagación y la ola dominada.
La ola dominante o ganadora es una ola que se propaga, hasta llegar a todos los sitios generados. Por construcción de su grafo asociado, se genera un árbol de cobertura, cuyo iniciador es el elegido. Una ola puede ser dominante sobre un sitio y dominada en otro sitio. Dominante y dominada son propiedades locales, ganador es una propiedad global. Independientemente de los iniciadores siempre hay una ola ganadora.
En un principio. todas las olas son olas dominantes, a medida que se encuentran entre ellas las olas dominadas comienzan a aparecer. Al final del cálculo solo existirá la ola ganadora en la red, y ninguna infomiación con respecto a otra ola.
Con el fin de ejemplificar todos los aspectos relacionados con los algoritmos multiolas se atacará el problema de elección y de cobertura.
5.3 EL PROBLEMA DE ELECCIÓN Y DE COBERTURA
Desde el punto de vista de control dentro de los sistemas distribuidos, la elección y la construcción de un árbol de cobertura son problemas fundamentales. En efecto, el árbol de cobertura pem,ite de estructurar el conjunto de procesos que forman el sistema distribuido en una topología de árbol. De esta forma el sistema cuenta con un sistema de control y de ruteo de mensajes dentro del sistema distribuido. Por otro lado, la elección es una forma de proporcionar un privilegio a un sitio. Desde un punto de vista teórico, el algoritmo de elección consiste en pasar de un sistema compuesto de procesos, todos en un mismo estado, a un sistema en el cual un sólo y único proceso se encuentra en el estado elegido. El primer algoritmo conocido de elección es el de LeLann. se han propuesto numerosas soluciones para, aparte de obtener un árbol de cobertura. realizar una elección dentro de un sistema distribuido. En estas soluciones el sitio elegido es la raíz de la topología de árbol.
Para un mejor análisis del funcionamiento del algoritmo se analizarán cada una de las etapas de un algoritmo de tipo ola. En la bajada se propagan las diferentes olas y en la subida se infom1a a los iniciadores si la ola que inicializaron es dominante o dominada. Desde el punto de vista de la construcción de un árbol de cobertura. la bajada define el padre de cada sitio y elige los hijos · posibles: mientras que la subida confim,a si los sitios \·ecinos elegidos pueden convertirse en
hi_ios o no.
61
5.3.1 LA BAJADA
La bajada esta ligada directamente con la propagación de la ola, es decir una vez que la propagación de la ola termina, la bajada también. Esta comienza cuando los sitios iniciadores pasan a un estado despertado. En efecto. al principio. todos los sitios están en el estado dormido, después un cierto número de procesos, los iniciadores, se despiertan y lanzan los RPCs a sus vecmos.
Como se dijo anteriorn1ente los algoritmos a regiones cuentan con más de un iniciador. Entonces puede existir más de una ola ejecutando su fase de bajada. Para poder diferenciarlas, entonces cada ola debe portar un identificador. Lo más simple es que el identificador sea el del sitio que lanzó la ola ,. un número de identificación de secuencias de la ola.
Es posible más de una ola lanzada no tem1ine su propagación, pero al menos una ola debe tenninar. Entonces, las consideraciones siguientes deben tomarse en cuenta:
a) Diferenciar las diferentes olas. b) Asegurarse que al menos una de las olas lanzadas terminará. c) Definir la estrategia de visita y la estrategia de paro de la ola. d) Definir los parámetros de los RPC's (Remate Procedure Call).
5.3.2 LA ESTRATEGIA DE VISITA
La estrategia de visita tiene por objetivo definir los cálculos que debe realizar un proceso cuando la ola llega.
En el caso de los algoritmos multi-olas varias olas atraviesan un mismo sitio durante la construcción del árbol de cobertura. Una vez que una ola llega a un sitio hay dos operaciones a realizar. la actualización del padre y el cálculo de los sitios a los cuales la ola será propagada.
5.3.2. 1 Actualización del Padre
En la actualización del padre los procesos no iniciadores pasan del estado dormido al estado despierto cuando son activados o alcanzados por el primer RPC. Un proceso que esta en el estado dornlido y que recibe un RPC por la primera \·ez, pasa al estado despierto y fom1a parte de la ola (y por consecuencia del árbol) asociada al RPC. Una vez que el proceso fom,a parte de una ola. considera como su padre aquel que le envío el RPC. y como sus posibles hijos a sus vecinos. Cuando un proceso se encuentra en un estado despierto y recibe un RPC relacionado con otra ola, decide a que ola pertenecer en función del identificador. Si el RPC corresponde a una ola dominante. el proceso será parte de esta ola y cambia el identificador de su padre por el del emisor del RPC. el antiguo padre es considerado como un hijo posible. Por consecuencia, por
62
cada ola dominante que llegue a un proceso, puede haber un nuevo padre. Un algoritmo de construcción de un árbol de cobertura se debe asegurar que una vez terminado, cada sitio cuenta con un padre. En la figura 5.1 se presenta un esquema donde se ejemplifica lo anterior.
Padre(x) = b hijos_pot(x) = { a, f, d, e}
5.3.2.2 Los sitios a Visitar
Figura 5.1
Ola 1
Ola 2
Padre(x) = a hijos_pot (x) = {b, f, d, el
lina yez que el sitio ha actualizado a su padre. debe calcular los sitios a donde la ola será propagada. Lo más simple es en,·iar la ola a los sitios vecinos a excepción del padre. Sin embargo si hay más de una ola. habrán ,·arios árboles en la topología. cada uno asociada a una ola. En ese caso. los árboles construidos por las olas dominantes son considerados como subárboles para su propagación. Yer figura 5.2. Inicialmente tenemos todos los nodos interconectados y en estado "donnido ··. una ola llega al sito x y se propaga. después de la propagación algunas ligas entre nodos desaparecen. posteriom1ente otra ola llega al sitio x y se propaga por el camino definido por la ola anterior.
Red antes que algoritmo comience. todos los sitios se encuentran en estado donnido
Red después de la propagación. algunas ligas han desaparecido.
Figura 5.2
63
Una ola llega al sitio x y es propagada
Ola 2
Otra ola llega al sitio x. es propagada a través del camino de la ola anterior
64
Cada sitio administra una variable de tipo conjunto que contiene los sitios a los cuales la ola se debe enviar. Sea E esta variable, en un principio contendrá todos los vecinos del sitio i, entonces:
Donde V 1 • V:, ..... V11 son los identi íicadores de los \·ecinos del sitio i.
A la llegada de la primer ola. el sitio emisor de esta ola (i.e. el padre), es suprimida de E y la ola es propagada al resto de los sitios. que son considerados como posibles hijos del sitio i. Cada vez que un sitio Vi responde que no puede ser hijo del sitio i, es suprimido del conjunto E.
Cuando una ola dominante llega al sitio i. la \'ariable E es modificada. Las operaciones a realizar son:
1 ) Afiadir al antiguo padre. 2) Suprimir al nuevo padre
Lo anterior equi\'ale a considerar al antiguo padre como un posible hijo. Una vez que la variable E es actualizada, la ola es propagada sobre los sitios que son incluidos en la variable E. De esta fom1a no se propaga sobre los sitios ya eliminados.
5.3.2.3 Cálculos de los Hijos
El cálculo de los hijos se hace a partir de la \'ariable E, esta variable contiene los vecinos a los cuales la ola será propagada. Si uno de estos sitios no puede convertirse en hijo, a causa de las condiciones presentadas anteriom1ente, será eliminado de esta variable. Una vez que el sitio pasa al estado consiente, él considera como sus hijos, los sitios contenidos en E.
El código siguiente se va a usar para calcular los hijos de un sitio:
if (ola dominante) then if (vecino no hijo) and (misma ola) entonces
conjunto= conjunto - \'ecino
5.3.2.4 Condición de Paro de la Ola
En este caso. es aquí donde se define cuando se debe detener la propagación de la ola. La ola se propaga por inundación y se detiene si:
1) No hay más sitios a los que em-iar la ola.
65
2) La ola encuentra un sitio que pertenece a la misma ola, o a una ola dominante.
Una vez que la ola se detiene estamos seguros que todos los sitios que ella toca en su propagación se encuentran en estado despierto.
El algoritmo es considerado como terminado cuando todos los sitios conocen al sitio elegido así como su padre y sus hijos en el árbol de cobertura. Esto equivale a decir que todos los sitios están en un estado consciente.
El primer sitio a estar dentro del estado consiente es el iniciador de la ola dominante. Es este el que infonna a los otros sitios que el algoritmo tem1inó e infom1a el identificador del sitio elegido.
Cuando una ola dominante encuentra una ola dominante debe detener su propagación y enviar como resultado una respuesta de perdida. Esta respuesta será pasada de hijo a padre hasta llegar al iniciador de toda la ola dominante. Entonces, si el iniciador de una ola no recibe una respuesta de perdida, significa que no ha encontrado de una ola dominante durante su propagación.
Dado que la red es conexa, podemos estar seguros que una ola va encontrar al menos una ola dominante. Tomando en cuenta que todas las olas cuentan con identificadores diferentes, es seguro que una sola ola dominará a todas las otras.
Entonces la condición de paro de la ola es la siguiente.
if (Ola que llega es mejor) then <Propagar la Ola>
else i f ( Ola que llega es igual) then
else
<El sitio pertenece a una ola dominante> <Detener Ola>
<Es una ola dominada> < Detener la Ola>
5.3.3 LA REJ\10NT ADA
La remontada comienza una \ez que la propagación de la ola ha tenninado, y tem1ina cuando la ola llega al sitio iniciador. El objeti\'o principal de la remontada es infonnar a los padres de los sitios si la ola es dominada o dominante, así como precisar si un sitio puede convertirse en el hijo del que le en\'Ío el RPC. Más adelante mostraremos que las dos infom1aciones están relacionadas y que respondiendo a una podemos concluir la otra.
66
En un primer tiempo vamos a analizar las respuestas a la proposición de convertirse en hijo. Después de que un sitio ha propagado la ola a través de sus vecinos, este puede recibir tres posibles respuestas:
1) El sitio no puede ser un hijo debido a que pertenece a una ola dominante. 2) El sitio no puede ser un hijo porque fom,a parte de la misma ola. 3) Puede convertirse en hijo.
A partir de la respuesta el padre sabe si el RPC que envío corresponde a una ola dominante o a una ola dominada. El hecho de que un sitio no pueda convertirse en el hijo de otro no significa que la ola esta dominada.
5.3.4 LA SUBIDA
La subida comienza una vez que todos los resultados son recibidos. Un sitio puede propagar la ola a través de los mismos sitios varias veces, entonces nos tenemos que asegurar que los resultados recibidos corresponden a la propagación (i.e. bajada) correcta. Esto puede dejarse a la semántica del RPC o a la naturaleza misma de la recursividad, la elección dependerá del ambiente en el cual la ola sea implementada.
Es posible que una o más olas no tem1inen su propagación, pero habrá al menos una bajada completa. Es decir que al menos una ola visitará todos los sitios.
Durante un cálculo una subida puede encontrarse con la bajada de otra ola. Entonces, la subida debe respetar los argumentos siguientes: la subida comienza en las hojas de los árboles de ejecución, las propiedades a probar serán las mismas para todas las olas y establecer la condición de tem1inación para todas las olas.
5.3.5 DEFINICIÓN DE PARÁMETROS
En esta sección se descubren los parámetros a utilizar dentro de cada RPC. Estos son:
l) El identificador de la ola (id_ola).
2) El identificador del sitio que propaga la ola (id_llamada).
3) El conjunto de los hijos potenciales (hijos_pot).
4) Una \'ariable para saber si la ola propagada es ganadora o perdedora (elegido)
El primer parámetro, id _llamada es de entrada; los parámetros hijos _por y elegido son de salida. El parámetro id_ola es de entrada salida.
Entonces P. el conjunto de los parámetros, esta definido como sigue:
67
P = < id_ola, id_llamada, hfios_pot. elegido>
5.3.6 LAS VARIABLES
una de las partes más delicadas es la coherencia de los datos. En efecto el hecho de que la bajada y la subida se encuentren durante un cálculo distribuido obliga a tomar precauciones y a manejar. por ejemplo. secuencias en exclusión mutua asociadas a la manipulación de las variables comunes.
Las mismas técnicas usadas en las olas simples serán utilizadas para asegurarse de la coherencia de las variables.
A continuación se explica cada una de las variables utilizadas en el algoritmo, para tales efectos esta explicación esta divida en:
• Definición de los datos estáticos • Definición de los datos dinámicos • La coherencia de los datos
5.3.6.1 Definición de datos estáticos
Los datos del sitio que no cambian de valor durante el cálculo son los siguientes:
• ego: identificador del sitio actual • hijos: al final del cálculo contiene los hijos reconocidos del árbol • raí:::: identificador del sitio elegido y de la raíz del árbol de cobertura
Los dos últimos son definidos al final del cálculo, entonces podemos definir Dsi, el conjunto de datos estáticos en el proceso i. como sigue:
DSi = <ego. hijos. raí:::>
5.3.6.2 Definición de datos dinámicos
Los datos dinámicos son:
68
• id_arbof: identificador del árbol al cual el sitio actual pertenece, en realidad contiene el identificador del mejor candidato que llego al sitio actual.
• padre: identificador del padre del sitio en el árbol. • conjunto: sirve para administrar todos los mensajes, una vez que el sitio esta dentro de
una ola, esta variable solo contiene los hijos posibles del sitio en el árbol. En un principio contiene todos los vecinos.
• llamados: para evitar problemas de coherencia, en lugar de ejecutar la instrucción par con la variable conjunto como parámetro. se utiliza la variable llamados como parámetro
Es necesario recordar que cada RPC esta acompañado de los parámetros siguientes:
• id_ofa: identificador de la ola que \·iene de ejecutar el procedimiento sobre el sitio. caracteriza una y una sola ejecución del procedimiento.
• id_lfamada: el identificador que ha enviado la llamada del procedimiento distante. • hi/osyot: variable que pem1ite saber si un sitio vecino ya es parte del árbol inducido por
la ola.
El conjunto de los datos dinámicos. DO, esta definido como sigue:
DO=< id_arhof. padre. co11junto >
5.3.6.3 La coherencia de los datos
El conjunto de datos de cada sitio esta definido como sigue:
11
D = DS,LJ¿DD,' ¡ = I
entonces. tomando en cuenta las definiciones anteriores el conjunto de datos será:
D= < ego. /11/os. raí::. id_arhol. padre. co,!/unto >
Se debe poner atención a las dos situaciones posibles:
• El hecho de que varias olas se encuentran atravesando la red. Un sitio puede recibir respuestas que corresponden a olas diferentes.
• La \·ariable conjunto no puede ser modificado durante el curso de la remontada. Si la modificación es hecha al mismo tiempo que alguna otra ola es propagada se podrían presentar problemas de incoherencia.
69
El primer problema se resuelve detectando a que ola corresponde cada respuesta, es decir comparamos el valor de la variable id _arho/ con el valor de id_ ola que es un parámetro por referencia del RPC.
Para e\·itar los problemas expresados en el segundo punto se utilizan dos variables. Una variable realiza la propagación: llamados y la otra. co11j1111to, define los hijos de un sitio. En líneas anteriores ya se explico como se usa esta \·ariable.
5.J.7 PSEUDO-CÓDIGO DEL EJE'.\IPLO
El código se encuentra numerado para una mejor explicación. La descripción de las variables ha sido realizada en las secciones precedentes. por lo que no se incluye una declaración de variables. Al igual que el capítulo precedente se eligió un pseudo-código parecido al lenguaje ADA.
La propagación de la ola se tem1ina por la instrucción número 3. Las últimas líneas muestran la razón por lo cual la ola se detiene: esta pertenece a la misma ola (línea 34) o encontró una ola dominante (línea 37).
La instrucción par de la línea 11. propaga la ola. Las instrucciones entre las líneas 13 y 20 suprimen de la variable conjunto los ncinos que no pueden convertirse en hijos.
La actualización de la variable padre y de la \·ariable conjunto es realizada entre las líneas 5 y 1 O. Las modificaciones siguen los pasos escritos en secciones anteriores.
La condición de tem1ino del algoritmo se encuentra en la línea 25. Una vez que el sitio elegido se encuentra en estado consiente. este manda llamar al procedimiento llamado notific_fin. Este procedimiento se encarga de notificar a todos los sitios que el algoritmo se terminó y de notificar el identificador del sitio elegido.
procedure cobertura(id_ola. id_llamada. hijos. elegido: in, out) is he gin
3 if(id ola<id arbol) 4 begin 5 elegido:== 1; 6 id arbol:== id ola: 7 conjunto:== conjunto+ padre: 8 padre:== id _llamada: 9 conjunto:== conjunto - padre: 1 O llamados:== conjunto: l 1 par i in llamados do 1 :2 cobertura(id_ola. ego. hijos. ganador) on i l.> i f ( ganador = 1 ) then 1-+ if ((hijos= O) and (id_ola == id_arbol)) then
70
15 begin 16 conjunto:= conjunto - i; 17 hijos:= i; 18 endif 19 else 20 elegido:=0; 21 enddo 22 if(elegido = 1) then 23 begin 24 hijos:= conjunto; 25 if ((ego= id_arbol) and (elegido= 1 )) then 26 NOTIFIC_FIN( ego); 27 else 28 if (ego= id_arbol )then 29 elegido:= 1; 30 endif 31 endif 32 else 33 begin 34 if ( id ola= id_arbol) then 35 hijos:= O; 3C, else 37 if(id_ola>id arbol)then 38 elegido:=0; 39 endif 40 end cobertura
5.4 11\IPLANTACIÓN DE UN ALGORITMO MULTI-OLAS
En las secciones anteriores se presentó un ejemplo de diseño de un algoritmo multi-olas. Con el fin de probar el concepto de multiolas se eligió implantar un algoritmo de intercambio de infomrnción.
La red en la cual se implantó el sistema, fue la red de equipos SUN del laboratorio de SUN del ITESM - CEM. apoyándose en otros equipos también SUN instalados en el laboratorio instalado en la planta baja del CCI. Cabe mencionar, que por la facilidad de conexión \'Ía módem. no era necesaria la presencia física en los laboratorios para el desarrollo de este proyecto. En el anexo A se presenta la lista de equipos de ambos laboratorios con su nombre y dirección IP. Los nombres de las máquinas son países del continente americano (México. USA. Guatemala. etc.)
La topología lógica de la red se puede obser,ar en la figura 5.3. Se observa la fomrnción de 3 regiones. por la influencia de 3 nodos iniciadores. Jamaica. México y Ecuador. cada uno de ellos
71
provoca la propagación de una petición hacia otros nodos, en el caso de Ecuador por ejemplo hacia Antigua, Surinam y Guatemala.
Como se mencionó esta topología es lógica y fue diseñada para los fines del proyecto, los equipos están conectados en una red local ethemet y existe.
Uruguay
Bolina 21 Puertorico
Jamaica \:icaragua 24
amas
Can ad a
Brasil
Parauuav ::, -
Barbados
Panama
\' enczuela
Figura 5.3. La topología lógica.
72
5.4.1 EL ALGORITMO DE INTERCAMBIO DE INFORMACIÓN
El intercambio _de infonnación que se utilizó para este sistema es el reporte de procesos corriendo en el nodo, simulando la búsqueda del nodo con menos carga al que se le puedan hacer peticiones posteriores.
Un proceso iniciador solicita a otro nodo los procesos que tiene corriendo, éste a su vez hace la misma petición hacia otros nodos, propagándose bajo una estructura de árbol predetem1inada para cada nodo iniciador. Así por ejemplo Jamaica, que es un nodo iniciador, solicita a sus ''hi/os". Bolivia. Costarica y Brasil, corran la petición denominada "ohte11yrocesos" que obtiene el número procesos que están en ejecución.
Pero a su vez éstos buscan a sus nodos hijos para solicitar ejecuten la misma petición, y de esta manera Bolivia solicita a Uruguay y Belice ejecuten "ohte11yrocesos", estos son nodos hojas así que su labor se limita a ejecutar y devolver el resultado a quien lo invocó en este caso Bolivia. Boli,·ia a su vez selecciona el número menor para reportarlo a su nodo padre, Jamaica que concentra los resultados de todos sus hijos.
Se puede observar que la metodología utilizada es la de ola recursiva, pues como se definió con anterioridad, este método hace propagaciones de un mismo procedimiento en nodos diferentes. En este caso se provoca la ejecución de "ohte11yrocesos" en diferentes nodos.
Se tienen tres nodos iniciadores. Mexico. Jamaica y Ecuador. Estos fom1an un área de influencia o región, pero estas regiones "chocan" al momento de propagarse, y es aquí donde se puntualizó en es este estudio, ¿qué hacer cuando las regiones se intercepten? Se plantearon tres alternativas para cada punto de contacto entre regiones.
La primera alternativa se planteó en el "choque" de la región de Jamaica y la región de México, ambas regiones se expanden y tienen un nodo común: Brasil. Jamaica tiene a Cuba como hijo inmediato, mientras que México lo hace a tra\'és del nodo Cuha (ver figura 5.3). La forma de atacar este "choque" fue a tra\'és de un "apartado" del nodo. Es decir, cuando Jamaica o Cuha intenten propagarse solo uno de los dos lo logrará el que llegué primero, a través de una bandera se sabrá la disponibilidad de Brasil. el nodo que llegue y lo encuentre ocupado se regresará sin resultado. mientras que aquel que lo encontró disponible esperará a que este tem1ine y le dernel\'a el resultado.
Como segunda opción. en un traslape de regiones, se planteó el ignorar si el nodo a acceder está ocupado o influenciado por otra región. solicitándose la propagación. Esta altemati\'a se implantó en las regiones de Ecuador y México (\·er figura 5.3), estas regiones se interceptan en el nodo Ciuarcmalu. Ecuador directamente hacia Guatemala y México \'Ía el nodo Usa, en ambos casos las dos regiones harán su propagación y esperarán a que Guatemala conteste, sin importar si
73
alguno de ellos lo accedió antes como en el caso anterior. Casi siempre los resultados son diferentes pues fueron hechas las peticiones en tiempos distintos y las condiciones son diferentes.
Finalmente el último caso de estudio que se implantó se refiere al aprovechamiento del trabajo hecho por otra región que se propagó previamente. Las regiones de Ecuador y Jamaica se traslapan justamente en el nodo Ecuador que como se observa en la figura 5.3. este caso se planteó haciendo esperar a Jamaica. vía el nodo Costarica, a que la región de Ecuador tem1ine su procesamiento y enviarle su resultado al nodo Jamaica y este a su vez termine con su proceso.
5.4.2 PARÁMETROS DE ENTRADA Y SALIDA PARA LOS PROCEDIMIENTOS REMOTOS
La comunicación entre el cliente y el servidor se hace a través del RPC. Por un lado el cliente invoca al proceso ohten _procesos que recibe como parámetro un apuntador a arreglo de caracteres, y devuelve también un apuntador a un arreglo de caracteres. que después se convierte a un valor numérico que representa el número de procesos corriendo en la máquina a la que se le hizo la petición.
El cliente invoca al proceso remoto a tra\·és de una serie de funciones que, en primer lugar, pem1iten establecer la comunicación y después invocar el proceso a ejecutar en el nodo remoto.
5.4.3 RECUPERACIÓN DE ERRORES
Durante el desarrollo del sistema hubo algunos inconvenientes pues no siempre estuvieron disponibles todos los nodos de la red. Por alguna razón alguno de los nodos no estaba funcionando provocando que el sistema fallara al no lograr la comunicación. Es en estos casos cuando se hacia la sustitución de un nodo por otro, apoyándonos en los equipos SUN del laboratorio de maestría en el CCI.
Se identificaron los nodos que con mayor frecuencia presentaban este problema, generando un nodo respaldo. y sustituyéndolo por el que presenta problemas, esta substitución fue totalmente manual. y después de conocer cuáles eran nodos con mayor incidencia a falla. Así por ejemplo se identificó que la máquina Bahanws no mantenía una conexión constante y con frecuencia se caía fue necesario sustituirla por otro nodo que no presentara este problema y modificar los programas. como el programa fue dise11ado de tal fom1a que cuando un caso así se presentara sólo era necesario modificar el archirn que tiene definido el árbol para cambiar la nueva estructura y si se trataba de un nodo cliente o cliente y sen-idor al mismo tiempo ubicarlo en el programa cliente y hacer la modificación.
74
5.4.4 PRUEBAS DE LA APLICACIÓN DISTRIBUIDA
Las pruebas del sistema se hicieron en fom1a modular, conforme se iban realizando avances al mismo. En primer lugar se probaron en forma local las funciones, las que obtiene el número de procesos y la que ordena los datos. Una vez probadas se procedió a hacer las pruebas de comunicación entre dos nodos, luego un nodo con dos o tres y finalmente una región. Como se puede observar, una región tiene fom,a de árbol donde la raíz es el nodo iniciador. Las pruebas posteriores se enfocaron a \ eri ficar las decisiones en el traslape de las regiones. Es decir identificar si un nodo había sido accedido por la influencia de otra región diferente a la región que lo quiere acceder, esto se hizo mediante la identificación del archivo generado para guardar la infom1ación solicitada si este ya existía el nodo ya había sido accedido de otra forma no.
En la gráfica de la figura 5.4. se observan tres traslapes, en cada uno de ellos se implantó cada una de las posibles situaciones. ignorar y continuar, retroceder sin solicitar infom1ación y finalmente aprovechar lo que la otra región hizo, como se explicó anteriom,ente.
5.4.5 EL CÓDIGO DEL ALGORITJ\10
En el presente trabajo se anexa un disco con los programas utilizados organizados de la siguiente manera:
• red.h, archivo de encabezado que contiene la definición de constantes. • regiones.h, archivo de encabezado que contiene la definición de las regiones, los nombres
de los nodos así como la dirección IP correspondiente. También contiene los arreglos de nodos "hijos .. es decir si por ejemplo en nodo Cuba solicita infom,ación a otros nodos, especificados en el gráfico de la figura 1, existe un arreglo al cual se hace referencia cuando a Cuba hace la propagación de la solicitud, cada nodo que se conecta para propagar tiene su arreglo correspondiente.
• red.e, archivo que contiene las funciones que utilizan los programas principales, el cliente y el servidor.
• region_cliente.c, programa cliente que hace la petición correspondiente al servidor, por ser un programa genérico hace una identificación del nodo que lo esta corriendo para saber quien es el servidor al que se debe conectar.
• region_sernr.c, programa servidor que resuelve la petición hecha por el cliente. a este no le importa que le solicite, no hace identificación del nodo que lo accede, sin embargo al igual que el cliente hace identificación de él mismo para propagar la petición, según la gráfica del sistema.
El sistema consta de dos programas principales. el cliente y el servidor. El cliente inicia el proceso ejecutando las instrucciones pre,·ias al llamado de un procedimiento remoto. en el momento en que éste hace llamada lo hace hacia el nodo servidor correspondiente, donde se il1\ oca al proceso propagador hacia el o los nodos servidores de la petición.
75
Uruguay :r- ·····-........ . _ _..l ..... . ......... .... ........... . . ..... ... .
Bolivia 21
/ ... ·······'
... ,.-·-···········-···· Puerto rico
...........
.. ·····-·········-····-·-... ··· ..
·· .......
.... ... ···
Región 1 ...... . ..
¡ ·, .......... __ __ ..... Región 2 Región 3
Figura 5.4 El traslape de regiones
76
Por otro lado el proceso servidor hace la inicialización propia de su serv1c10, en teoría solo
debería esperar a ser llamado por un proceso cliente para atender la petición, sin embargo el
efecto de ola recursiva se logra toda vez que se recibió la petición éste sea capaz de replicarse
ahora haciendo las funciones del cliente es decir solicitando a otros nodos ejecuten el proceso,
por eso hace la identificación y el llamado al proceso de propagación.
5.4.6 NIVEL DE SEGURIDAD
Por no tratarse de un sistema confidencial o de alto riesgo para el desempeño del ambiente donde
se desarrollo solo se utiliza como seguridad la autenticación dada por UNIX y RPC, que es la
identificación del usuario y la identificación del nodo que hace una petición o quien envía una
respuesta.
Los programas corren y se registran bajo la clave (o login) para el cual fueron creados y su
ejecución solo puede hacerla el dueño los programas.
El programa servidor levanta su servicio y esta listo para resolver las peticiones de los clientes,
para implantar el algoritmo ola el servidor pregunta quien de los nodos que llevan el rol de
sen·idores es que lo esta ejecutando pues existen casos como Cuba, Brasil y Paraguay que a su
,·ez deben propagarse y solicitar a otro servidor la infomiación, haciendo a su vez de clientes.
En el caso del cliente se identifica que nodo esta corriendo, de este depende a quien se le solicite
la información.
77
6. CONCLUSIONES
Mucho tiempo· ha pasado desde que una computadora se programaba basado en tarjetas
perforadas. Las necesidades de hoy en día nos obligan a buscar nuevas formas de explotación de
la computadora. El esquema de programación presentado es un concepto diferente de algoritmo
dentro de los sistemas distribuidos.
Este esquema ha sido probado e implementado presentando un buen desempeño. Los esquemas
de los algoritmos son claros. lisibles y presentan todos la misma estructura.
La principal ventaja que presenta la ola recursiva es el nivel de abstracción que proporciona, así
como la transparencia de todo lo concerniente al manejo de mensajes, y de los inconvenientes
relacionados con la administración del sistema, como por ejemplo la topología de la red de
procesadores. Esta abstracción pem1ite al usuario de concentrarse más en la naturaleza del
problema mismo. que en el manejo de las herramientas para la solución del problema.
Di,·ersos trabajos se han efectuado alrededor de este esquema. Se diseño una metodología
especial para la concepción de algoritmos siguiendo el esquema de la ola recursiva. Esta
metodología presenta la ventaja de que al mismo tiempo que se construye el algoritmo, se sientan
las bases para la prueba del algoritmo multiolas. La recursión en un ambiente centralizado tiene
una reputación de "elegante", pero en muchos casos no es eficiente; el objetivo de la ola recursiva
es demostrar que en un ambiente distribuido la recursión es una herramienta elegante y eficiente.
Después de analizar todos los componentes que fueron necesarios usar para el desarrollo de este
proyecto. se pueden hacer algunas observaciones.
La necesidad de utilizar sistemas distribuidos radica principalmente en la repartición de tareas de
diferentes necesidades tales como la especialización de equipos, la distribución geográfica,
seguridad y contingencia. Pero ¿cuál técnica u opciones se tienen al alcance para realizar este
esfuerzo?
El proyecto da una estrategia de distribución de tareas a través del algoritmo Ola Recursiva y la
metodología de programación RPC, con la variante que se hizo con un enfoque hacia la creación
de regiones. que en este caso se refiere a la agrupación de nodos o equipos, que involucra la
decisión de que alternativa tomar ante el cruce de otra región.
Si bien el algoritmo Ola nos pennite hacer la propagación de un mismo proceso en otros nodos
vecinos. éste no incluye la decisión o decisiones de traslape con otra región que en nuestro caso
fue implantada a traYés de la agrupación de nodos o equipos a los que denominamos regiones.
\:os ,·irnos obligados a agregar al algoritmo una fase de toma de decisiones. Se plantearon tres
78
alternativas que se describieron en este trabajo. Y en cada caso implantado se obtuvo un
resultado, con la consideración del tipo de dato que se estaba consiguiendo.
Pero, este tipo de análisis ¿qué puede aportar? Dado que número de equipos involucrados es
finito y conocido no se observa una ganancia importante el elegir cualquier opción, pero el
sistema puede extrapolar su funcionamiento a un número mayor o desconocido de equipos y las
,·entajas saltan a la vista. Se puede optar por retroceder y no avanzar ante la posibilidad de que el
equipo en ese momento se encuentre ocupado y no pueda contestar en un periodo razonable para
quien solicita un servicio.
La opción de apro\'echar los resultados obtenidos por una petición anterior diferente puede
funcionar en casos como el que no es necesario contar con información actualizada al cien por
cien. Lo anterior podría deberse al hecho de que el resultado que se está arrojando no se haya
obtenido en un lapso "corto" o inmediato anterior a la petición y es probable que la situación
haya cambiado.
La última opción es más completa, pues ordena volver a hacer las peticiones no importando que
éstas hayan sido solicitadas, garantizando la "frescura" de la información.
La opción a seguir será tomada en cada caso cuando la situación se presente y debe de considerar
los factores como tiempo, oportunidad de la infom1ación, así como actualización de datos para
hacer la petición.
Los sistemas y los algoritmos van evolucionando convirtiéndose en más complejos, pero también
más complicados. Tal vez la decisión de que alternativa tomar no recaiga en el programador o
dise11ador del sistema. pueden empezar a incluir herramientas estadísticas que ayuden al mismo a elegir un camino y resulte mucho más óptimo que el dejarlo implantado bajo un esquema de solución. Este esquema está muy limitado. Basado en un estudio hecho de acuerdo a las
circunstancias que en ese momento existían sin contemplar que las condiciones varían y que otros
factores pueden variar el ambiente de ejecución y en consecuencia los resultados.
79
ANEXO A. EISTA DE EQUIPOS UTILIZADOS
NOMBRE DEL EQUIPO DIRECCION IP canada.cem.itesm.mx 148.241.61.1
usa.cem.itesm.mx 148.241.61.2
mexico.cem. itesm .mx 148.241.61.3
guatemala.cem. itesm. mx 148.241.61.4
! belice.cem.itesm.mx 148.241.61.5
honduras.cem. itesm. mx 148.241.61.6
salvador.cem. i tesm. mx 148.241.61. 7
panama.cem.itesm.mx 148.241.61.8
colombia.cem.itesm.mx 148.241.61.9
I venezuela.cem.itesm.mx 148.241.61. 1 O
haiti.cem.itesm.mx 148.241.61.11
cuba.cem.itesm.mx 148.241.61. 12
. peru.cem.itesm.mx 148.241.61.13
ecuador.cem. i tesm .mx 148.241.61.14
brasil .cem.itesm .mx 148.241.61. 15
guyana.cem.itesm.mx 148.241.61. 16
argentina.cem.itesm.mx 148.241.61.17
chile.cem.itesm.mx 148.241.61.18
uruguay.cem.itesm.mx 148.241.61.19
paraguay.cem.itesm.mx 148.241.61 .20
boli \·ia.cem. itesm.mx 148.241.61.21
jamaica.cem.itesm.mx 148.241.61.22
granada.cem.itesrn.rnx 148.241.61.23
nicaragua.cern.itesrn.rnx 148.241.61.24
costarica.cem.itesm.rnx 148.241.61 .25
¡ puertorico.cem.itesm.rnx 148.241.61.26
I surinam.cem.itesrn.mx 148.241 .61.27
antigua.cern.itesm.mx 148.241.61.28
dom i nicana.cern. itesrn. mx 1148.241.61 .29
barbados.cem. itesrn.mx 148.241.61.30
! baharnas.cem. i tesrn. mx 148.241.61.31
rnartinica.cem.itesrn.mx 148.241.61.32
azt lan.cem. itesm .mx 148.241.61.34
80
BIBLIOGR.\FÍA
[ 1] http: 1.ija\'a.sun.com/products/jdk/rn1i/index.html. JavaTM Remote Method Invocation (RMI)
[2] http://habitantes.elsitio.com/a\'ilavit/index2.html. Sistemas Distribuidos.
[3] Dijkstra E. W .. Scholten C. S. - Tern1ination detection for diffusing computations. lnfom1ation Processing Letters, vol 11, no 1 August 1980.
[ 4] Lamport Leslie - Time, Clocks and the Ordering of Events ms a Distributed System. Communications of the ACM, Vol 21, No 7 July 1978.
[5] Gómez Cárdenas Roberto. La recursión como un estilo de programación dentro de los sistemas distribuidos.
[6] Chang Ernest -Echo algorithms: depth parallel operations on general graphs. IEEE Trans. On Soft. Eng. Vol. Se-8 No 4 July 1982.
[7] Birrel A. Nelson B. - Implementing Remote Procedure Calls. ACM Trans. On computing Systems. vol. L No. 3 August 1983.
[8] http://tejo.usal.es/-nines/d.alumnos/rpc/rpc.htm#RPC. Llamada a Procedimientos Remotos.
[9] Bloomer John. Po\\'er Programming with RPC. O'Reilly & Associates, Inc.
[ 1 O] Douglas E. Comer. lntemetworking with TCP/IP Vol. II: ANSI C Version: Design, Implementation, and Internals.
[ 11] Tanenbaum A Sys., Distributed Operating tems. Prentice may, 1995.
[ 12] Bloomer John, Po\\'er Programming with RPC. O'Reilly & Associates, 1995.
[ 13] Cho\\' Randy and Johson Theodore. Distributed Operating & Algorithms. Ed. Addison Wesley. 1997.
[ 14] Couloris George. Dollimore Jean & Kindelberg Tim, Distributed Systems, Concepts and Design. Addison 'Wesley. 2da. Edición, 1994.
[ 15] \1ullender S. Distributed Systems. Ed. Addison Wesley.
[ 1 (i] Tanenbaum A.. P. H. Distributed Systems. principies and paradigms.
81
[ 17) Nancy A. Lynch. Distributed Algorithms (Data Management Series).
[ 18) Chang Ernest. Echo algorithms: depth parallel operations on general graphs IEEE. Trans. On Soft. Eng. Vol. Se-8 No. 4 July 1982.
[19) Tel Gerard. Introduction to Distributed Algorithms. Cambridge Universite Press, 1994.
[20) Raynal M. Helary J. M. Synchronization et controle des systémes et des programmes répartis. Eyrolles, Paris 1998.
[21 J Lavallée Ivan, Lavault Christian. Yet another distributed election and spanning tree algorithm. Rapport de Recherche No. 1024, INRIA. Rocquencourt April 89, France.
[22] Gallager R. G., Humblet P.A., Spira P.M. A distributed algorithm for mínimum spanning trees ACM Trans. On Prog. Lang. Adn Systems Vol 5:66-77, Jan, 1983.
