Estudio e implantación de algoritmos distribuidos a regiones

Texto completo

(1)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. ATIZAP.Á:'\ DE ZARAGOZA, EDO. '.\1ÉX., ENERO DE 2002..

(2) CONTENIDO. 1. INTRODUCCIÓN. ESTUDIO E IMPLANTACIÓN DE ALGORITMOS DI STRI BL71DOS A REGIONES ............................................................................. 4 2.. SISTE\1AS DISTRIBliIDOS ........................................................................... 6. 2.1 LOS SISTEMAS OPERATIVOS DISTRIBUIDOS Y LOS SISTEMAS OPER..\. TI\ºOS DE RED ............................................................................................................... 7 LA CO!\IUNICACIÓN ..................................................................................................... 8 2.2 2.2. 1 SOCKETS ................................................................................................................... 8 -, -, -, REMOTE PROCEDURE CALL -RPC- ..................................................................... 9 CLIEl\TE / SER\'IDOR ................................................................................................. 10. 2.3. 2.3.1. -,. -, J,_ , __. -, , ,. - . ·'. ·'. 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 2.4 CUALIDADES DE UN ALGORITMO DISTRIBUIDO ......................................... 16 2.4. 1 PRINCIPALES TÉCNICAS USADAS EN LOS ALGORITMOS DISTRIBUIDOS 2.4.2. 2.4.3. 3.. 17 ESTRUCTURAS DE CONTROL .................. ...... ... ...... .. ......................................... 17. 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 3.3.2 3.4. 3.4.1 3.4.2 3.4.3 3.4.4 .~.4 =' 3.5. FL'.1\CIO\:ES XDR ................................................................................................... 22 LOS FILTROS ............. ....................... .. .......................... ............................ .. ............ 24 ¡,CÓl\10 SE GE'.\ERAN LOS_"STUBS"·(CABOS)'? ................................................... 25. GE1\ERACIÓ1\ AL:T0\1A TIC A ............................................................................. 25 GEl\ERACIÓJ\ DE "STL1Bs·· A TRAVÉS DE FL'J\CIONES DE AL TO J\IVEL. 26 E.JP,1PLO: RUTI:'\A REMOTA EN EL SERVIDOR (ALTO NIVEL) .................. 28 GE1\ERACIÓ1\ DE STLBS A TRAVÉS DE FUNCIONES DE BAJO NIVEL ..... 28 E.JE\1PLO: L\: CLIE\:TE LLA\!1A AL'?\ SERVIDOR (BAJO l\IVEL) ............... 30 TOLER ..\.'.\CI ...\. ..\. F ..\LL ...\.S ........................................................................................... 32.

(3) 2 3.5. l 3.5.2. CAÍDA DEL SERVIDOR ......................................................................................... 32 CAÍDA DEL CLIENTE ........ .......... ........ ... ............................................................... 33. 3.6. SEGURIDAD ................................................................................................................... 34. 3.7. UN RPC QUE LLAMA A OTRO RPC ......................................................................... 35. RPC ..\SÍ'.\CRO:\O .......................................................................................................... 35 3.8 3.S. l LOS RPC NO BLOQL'EA:,;TES .............................................................................. 36 3.S.2 CALLBACK 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 ................................................................................................... -L3 l DEFJ;\JCIÓ\: DE L'.'\.'\ OLA RECURSIVA ........................................................... -+.3.1.1 Primiti\·a de Concurrencia ..................................................................................... ..i._1.1.2 Sintaxis del RPC .................................................................................................... -+.3.1.3 Esquema General de la Ola Rccursi\'a ......... ........ ....... .......................................... 4.3.1.4 La Ola Recursi\·a Secuencial ................................................................................. 4.3.1.5 La Ola Recursi\'a sobre una Topología de Árbol ........ .............. ....... ........ ........ ..... 4.3.1.(1 La Ola rccursi\a Inundantc ..................................................................................... 51 52 52 53 53 54 55 56. 4.3.1.6.1 Especificación de la Ola Recursiva Inundante 57 5.. LOS ALGORITl\10S A REGIONES: ESPECIFICACIÓN E ' l\ lPLA~TACION .................................................................................................. 59 1. 5.1. CARACTERÍSTICAS DE LOS ALGORITl\lOS l\1UL TI-OLAS ............................. 59. -. TER\lINOLOGÍA \' CO:\SIDERACIONES .............................................................. 59. ::,. __..,. 5.3. EL PROBLE!\IA DE ELECCIÓN\' DE COBERTL'R.\ ............................................ 60 LA BAJADA ............................................................................................................. 61 LA ESTRATEGIA DE VISITA .................... .................... ...... .................................. 61 5.3.2 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 5.3.1.

(4) 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 ..................................... 5.4.1 EL ALGORITMO DE INTERCAMBIO DE INFORMACIÓN ............................... 5.4.2 PARAMETROS DE ENTRADA Y SALIDA PARA LOS PROCEDIMIENTOS REMOTOS ................................................................................................................................ 5.-l.3 REClJPERACIÓN DE ERRORES ........................................................................... 5.4.4 PRUEBAS DE LA APLICACIÓN DISTRIBUIDA ................................................. 5.4.5 EL CÓDIGO DEL ALGORITMO ............................................................................ 5.4.(1 NIVEL DE SEGURIDAD .......................................................................................... 6.. 70 72 73 73 74 74. 76. CO"CLUSIO~ES ........................................................................................... 77. ANEXO A. LISTA DE EQUIPOS UTILIZADOS .............................................. 79. BIBLI OG R. t\.FI A .................................................................................................... 80.

(5) 4. l. INTRODUCCIÓN. ESTUDIO E IMPLANTACIÓN DE ALGORITMOS DISTRIBUIDOS A REGIONES. 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..

(6) 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..

(7) 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.

(8) 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..

(9) 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.

(10) 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.

(11) 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. pet leJÓll. Cliente 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.

(12) 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 ( WAN ). 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: • • • •. 2.3.1. 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.. 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.

(13) 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..

(14) 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..

(15) 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.

(16) 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 lti 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..

(17) 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..

(18) 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.

(19) 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)..

(20) 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..

(21) 20. :\1áquina Cliente. Má uina Servidor Stub del Cliente. Stub del Scr\'ldor. ":.. :--"'T""""--. Llamada. E111p:.1quetamicnto de p:.námetros. quetamiento de parámetro Empaqueta. ....____ Dese111p:.1queResreso. Kernel. Kernel. /. Mensaje transportado por la red. Figura 3.1. 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.-\\·_-\_. /.

(22) 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..

(23) 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. 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.. 3.3.1. 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..

(24) 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. Filtro. Tipo en C I char. short int unsigned short int i int I unsigned int ! Jonu ' " ¡ unsigned long , float ; double void ¡ enum. xdr_char() xdr_ short() xdr_u_ short() xdr_int() xdr_u_int() xdr_long() xdr_u_Jong() xdr_float() xdr_double() xdr_ void() xdr_enum(). Tipo xdr. int int unsigned int int unsigned int int unsigned int float double void int. Tabla 3.1 Filtros para tipos simples 1. 1. Dato Compuesto. ! Arreglo. longitud variable con elemento de tamailo arbitrario Arreglo de bytes de tamaño variable Data de longitud fija (sin interpretar) Referencias a objetos incluyendo apuntadores a NULL , Referencias a objetos \ Arreglos de caracteres tenninados en NULL i Unión discriminada, (unión con una enumeración que actúa . . ) :Icomo d"1scn111111ante Arreglo de longitud fija con elementos de tamailo arbitrario An·eglo de caracteres temiinado en NULL de longitud arbitraria Tabla 3.2 Filtros para datos compuestos. Filtro. xdr_array() xdr_ bytes() xdr_ opaque() xdr_pointer() xdr_ referen ce() xdr_ string() xdr_ uni on() 1. xdr_vector() xdr_ \vrapstring().

(25) 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..

(26) 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..

(27) 26 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; : =. 3.4.2. : = l; Ox31111111;. GENERACJÓ;\; DE "STUBS" A TRAVÉS DE FUNCIONES DE ALTO NIVEL. 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. 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. 1. 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..

(28) 27 int registerrpc(u_long prognum, versnum, procnum, char * (*procname) (), xdrproc_t inproc, outproc) 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 TCP 111 /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..

(29) 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).

(30) 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):.

(31) 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.. lado del cliente llamada s " de alto niv el ',. callrpc(). L i b. L. i b. r. r. e. e. registerrpc() svc_run(). llamadas de alto nivel. r. ¡ '. llamad as de bajo ni ve!. lado del servidor. í. a. clnt_create() clntudp_create() clntcp_ create() clntraw_ create(). d. clnt_destroy(). a. clntcall() clnt_ control() clnt_freeres(). e. ,.. a d ¿. svc_udp_create() svc _ tcp _ create() svcraw_ crea te(). e. svc_ des troy() r. n. a n. 5. 5. p. p. o. o. r. svc _register() svc_ unregister(). llamadas de bajo nivel. svc_getargs() svc_sendreply(}. 1. '. e. (. e. Figura 3.2. 3.4.5. EJEMPLO: UN CLIENTE LLAMA A UN SERVIDOR (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> * Declaraciones y definiciones de variables y funciones propias*/ =includc "rdir.h'".

(32) 31. main (int argc, int argv[]) CLIENT *el; char *server; char *dir; leedir_res *resultado; nombrelista ni; if (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) { /*. * Un error se produjo mientras se llamo al servidor *!. clnt_perror(cl, server); exit ( 1); \. 1. /*. * Llamada exitosa *'I. if (resultado->¡= O) l '*. * Un error remoto se produjo. *:.