1. Unidad 2 - La Comunicacin en los Sistemas Distribuidos2.1 comunicacion sod2.1 Llamada a procedimiento remoto (RPC) En el anterior epgrafe hemos estudiado un modelo de interaccin entre los procesos de un sistema distribuido que es el modelo cliente-servidor. Para implementarlo, el sistema dispone de dos llamadas al sistema, send y receive, que las aplicaciones utilizan de forma conveniente. Estas primitivas, a pesar de constituir la base de la construccin de los sistemas distribuidos, pertenecen a un nivel demasiado bajo como para programar de forma eficiente aplicaciones distribuidas. 2.1.1 La operacin RPC bsica La llamada a procedimiento remoto constituye un mecanismo que integra el concepto cliente-servidor con la programacin convencional basada en llamadas a procedimientos. La idea surgi en 1984 y consiste en que el cliente se comunica con el servidor mediante una llamada ordinaria a un procedimiento. Esta llamada se denomina a procedimiento remoto porque el procedimiento invocado se encuentra en otro espacio de direccionamiento, en la misma o en distinta mquina que el cliente. La informacin se transporta en los parmetros de la llamada y el resultado es devuelto en el retorno de la llamada. El cliente no tiene que utilizar las primitivas send y receive como en el modelo cliente-servidor puro, de modo que la programacin de aplicacio-nes distribuidas se hace ms sencilla.2.1.2 El paso de parmetros La funcin del cabo cliente es empaquetar los parmetros en un mensaje y enviarlo al cabo servidor. Este examina el cdigo del procedimiento en una sentencia tipo switch e invoca el procedimiento de forma local. El resultado es de nuevo empaquetado en un mensaje y enviado al cabo cliente. Esta interaccin, que parece directa, no es tan simple como aparenta ser. Mientras las arquitecturas del cliente y del servidor sean iguales no se presenta ningn problema especial. En un entorno distribuido, sin embargo, cada arquitectura tiene su propia representacin de nmeros, caracteres, etc. Por ejemplo, los mainframe IBM utilizan el cdigo EBCDIC para los caracteres en lugar del cdigo ASCII, como el IBM PC. Problemas similares ocurren con la representacin de coma flotante o los enteros negativos (complemento a 1 o complemento a 2). Otro problema surge con la forma de almacenar un entero. La arquitectura PC mantiene una representacin little endian, a saber, el byte menos significativo en el byte ms bajo de memoria. La arquitectura SPARC utiliza un almacenamiento big endian, es decir, el byte ms significativo en el byte ms bajo de la memoria. Un 486 operando en modo protegido representa un entero con cuatro bytes, de modo que el 5 lo representa como 0005. Un mecanismo adicional de paso de parmetros es denominado de copia-restauracin. Consiste en realizar una copia del parmetro en la pila. Si esta copia parmetro es modificada en el procedimiento, se restaura su nuevo valor a la variable original. Algunos compiladores de Ada utilizan este mecanismo en parmetros in out, si bien ello no est especificado en la definicin del lenguaje. La estrategia de copia con restauracin puede ser utilizada para pasar punteros a procedimientos remotos. Supongamos la invocacin del procedimiento remoto cuenta = read(df, buf, nbytes);La implementacin ms directa consiste en copiar al buffer del mensaje local un vector de nbytes caracteres en lugar de buf, que es la referencia al vector. El mensaje es entonces enviado al cabo servidor. Ahora el buffer del mensaje se encuentra en el espacio de direccionamiento de este ltimo, invocar la rutina de servicio read con la referencia al 2. vector recibido en el mensaje, es decir de forma convencional por referencia. Ahora el mensaje es devuelto con su contenido actualizado a la rutina cabo del cliente, que restaura el vector del mensaje a su vector original. Para optimizar este mecanismo eludimos en el cabo cliente la copia del vector al mensaje en caso de lectura. En el caso de la escritura, prescindiremos de restaurarlo. Como vemos, es posible pasar punteros a procedimientos remotos siempre que sean referencias a estructuras sencillas como vectores. No obstante, no podemos enviar a procedimientos remotos referencias a estructuras de datos complejas como listas o rboles. 2.1.3 Especificacin de interfase El servidor RPC puede ser considerado como un mdulo u objeto que implementa unas operacio-nes sobre datos ocultos. El servidor da a conocer estas operaciones a los clientes mediante lo que se denomina su interface, constituida por las declaraciones de los mtodos que soporta. Como sabemos, el objetivo del mecanismo RPC es lograr que un programa tenga acceso a los servicios de uno de estos mdulos, aunque residan en otro espacio de direccionamiento, posiblemente remoto. La figura 2.8 muestra los componentes de una implementacin RPC. La mitad rayada constituye el software adicional de empaquetamiento y desempaquetamiento de parmetros y primitivas de comunicacin que debe ser ocultado al programador. Por brillante que sea la idea de la interaccin cliente-servidor a travs de RPC, si el programador debe encarar la construccin de los cabos, el progreso de los sistemas distribuidos se ver comprometido por la falta de uso en la prctica. Es preciso que la generacin de cabos en el cliente y el servidor se realice de forma automtica. Pues bien, la interfaz del servidor se utiliza como la base de esta generacin automtica de cabos. El primer paso es definir el interfaz, es decir, el conjunto de los prototipos de los procedimientos de servicio, mediante un lenguaje determinado, denominado lenguaje de interfase. La figura 2.8, a) muestra un ejemplo de servidor. La figura 2.8, b) su definicin de interfaz. Un compilador especial toma como entrada el fichero escrito en el lenguaje de interfase y como salida genera el cdigo objeto de los procedimientos que constituyen el cabo cliente, por una parte, y el cabo servidor, por la otra. El programa cliente se enlaza con estos procedimientos objeto para generar el ejecutable. En cuanto al servidor, los procedimientos de servicio, escritos por el programador, se compilan previamente a lenguaje objeto y, a continuacin, se enlazan con los procedimientos cabo, entre los que figura el procedimiento principal del servidor RPC. 1. include void main(void) {struct mensaje m1, m2; /* Mensajes entrante y saliente */int r; while(1){ receive(FILE_SERVER, &m1); /* El servidor se bloquea esperando un mensaje */ switch(m1.opcode) { case CREATE: r = do_create(&m1, &m2); break; case READ: r = do_read(&m1, &m2); break; case WRITE:r = do_write(&m1, &m2); break; case DELETE: r = do_delete(&m1, &m2); break; case DELETE: r = E_BAD_OP; break; } m2.result = r; send(m1.source, &m2);} 3. } a) 1. include specification of file_server, version 3.1 long read(in char name[MAX_PATH], out char buf[BUF_SIZE], in long bytes, in long position); long write(in char name[MAX_PATH], in char buf[BUF_SIZE], in long bytes, in long position); int create(in char[MAX_PATH], in int mode); int delete(in char[MAX_PATH]);end; b)2.1.4 Enlace dinmicoNo es conveniente que un servicio est ligado a una mquina. A veces las mquinas no estn operativas, de modo que los servicios se mueven a otra mquina. El cliente est interesado en el servicio, no en qu mquina ejecuta el servidor. Para solicitar un servicio, un cliente podra enviar un mensaje en una sentencia como la siguiente send(33.33.33.33@20, &mens);en el cdigo fuente que implementa la llamada RPC. Esta solucin es inflexible, puesto que, si dentro de la mquina 33.33.33.33 el servidor pasa a escuchar en otro puerto distinto del 20, el cliente debe ser recompilado. Lo mismo ocurre si el servidor cambia de mquina. En contraste, el cliente debera invocar el servicio por su nombre, sin hacer referencia a direccin alguna. La figura 2.8 b) muestra la especificacin formal del servidor de ficheros 2.8 a). En la especificacin formal del servidor intervienen el nombre del servidor y su nmero de versin. Ambos datos identifican un servidor. Un servidor con el mismo nombre y la misma versin, no obstante, pueden estar replicados en dos o ms mquinas a fin de mejorar el servicio o propor-cionar tolerancia a fallos. El cliente debe solicitar un servicio invocando su nombre y versin, sin citar direccin alguna. El nmero de versin es conveniente a fin de que un servidor que evoluciona conserve su nombre. Un servidor puede evolucionar ofertando nuevos servicios, cancelando otros y modificando otros. A pesar de esta evolucin, es preciso que clientes antiguos, desconocedores de los cambios, sigan obteniendo el mismo tipo de servicio. Es preciso compren-der, no obstante, que un servidor con el mismo nombre pero con nmero de versin distinto es un servidor diferente. Las ventajas de identificar al servidor por su nombre son evidentes, pero, cmo el cliente localiza al servidor? Quin le proporciona su direccin? Este es un problema al que algunos sistemas RPC, entre ellos Sun RPC, dan respuesta mediante lo que se llama el enlace dinmico, que no es sino averiguar la direccin del servidor en tiempo de ejecucin. El enlace dinmico est basado en un tercer proceso denominado el enlazador. Cuando el servidor arranca, en su cdigo de inicializacin previo al bucle principal, enva un mensaje al enlazador a fin de registrarse como un proceso que presta un servicio. El enlazador es, al fin y al cabo, un registrador de servicios, un servidor de nombres. El servidor entrega su nombre, su nmero de versin y su direccin. Se dice que el servidor exporta su interfaz. No sera extrao que dos programadores diesen el mismo nombre a dos servidores distintos, de modo que, a pesar de que no aparezca, cada servidor RPC tiene asociado, adems del nombre y la versin, un identificador numrico, generalmente de 32 bits, que tambin entrega en la operacin de registro. Dos servidores distintos deben tener identificadores distintos (se entiende aqu servidor como programa, no como proceso). Si bien sera raro, es posible que dos programadores que terminan dos 4. servidores RPC, coincidan en darles el mismo identificador. Lo que ocurra cuando ambos traten de registrarse depende de cada implementacin particular del software RPC, pero es lgico pensar que el enlazador rechazara la segunda peticin de registro. 2.1.5 Semntica RPC en presencia de fallosEl objetivo de la llamada a procedimiento remoto es conseguir la ejecucin de procedimientos en otras mquinas sin cambiar la forma en que se invoca el procedimiento en el cdigo fuente. Salvo algunas excepciones como que un procedimiento remoto no puede usar variables globales, el objetivo ha sido alcanzado plenamente. Mientras no se produzcan errores la transparencia de la llamada remota est conseguida, ya que el programador no necesita saber que la llamada que realiza es a un procedimiento remoto. Los problemas llegan cuando bien cliente o bien servidor dejan de operar correctamente, ya que las diferencias entre llamadas locales y remotas no son fciles de enmascarar. Vamos a considerar cinco situaciones de fallo: 1. El cliente no es capaz de localizar al servidor. 2. El mensaje del cliente al servidor se pierde. 3. El mensaje de rplica de servidor a cliente se pierde. 4. El servidor se cae tras recibir el mensaje del cliente. 5. El cliente se cae tras recibir la rplica. El cliente no puede localizar al servidor Puede haber varias causas. Una es que el servidor se cae. Otra es que el servidor se actualiza y un cliente antiguo invoca una versin del servidor que ya no ejecuta. Una solucin es que la llamada devuelva 1 como cdigo de error. Sin embargo, 1 puede ser un resultado vlido como en la llamada RPC de suma. Otro intento de solucin es escribir un manejador de excepcin (seales en C) para los errores producidos en las llamadas RPC. Sin embargo, esta solucin acaba con la transparencia respecto a las llamadas locales. Lo mejor es recibir el resultado en parmetros de salida de la llamada RPC y que esta devuelva 0 en caso de ejecucin con xito y un cdigo de error en otro caso. La peticin del cliente se pierde Este caso tiene un tratamiento sencillo. El ncleo del cliente arranca un temporizador cuando enva el mensaje al servidor. Si al cabo de un plazo no ha llegado rplica o reconocimiento del servidor, el cliente da el mensaje por perdido y lo reenva. Si todos los reenvos se pierden, el kernel del cliente considera que el servidor no est activo y devuelve un error al cabo cliente, que lo pasa a la aplicacin. Estamos en el caso anterior. La rplica del servidor se pierde Este problema es ms complejo. Cuando en el caso anterior venci el plazo sin que llegase la respuesta del servidor, asumimos que se haba perdido el mensaje enviado por el cliente. Pero existe la posibilidad de que el mensaje perdido fuese la rplica. De cualquier forma, establecimos que lo que haba que hacer era el reenvo del mensaje. En el primer caso, el servidor recibe el mensaje reenviado por primera vez. Todo vuelve a funcionar correctamente. En el segundo caso el servidor recibe el mensaje por segunda vez. Sirve la peticin dos veces, como si en el programa cliente hubisemos invocado la llamada una segunda vez. En algunos casos, la repeticin de una operacin en el servidor no causa ningn dao. Por ejemplo, el leer los 20 primeros bytes de un fichero. Las peticiones que tienen esta propiedad se dicen que son idempotentes. Otras veces, la re-peticin s ocasiona perjuicios, como puede ser el aadir 20 bytes a ese fichero o retirar de una cuenta bancaria 500 millones de pesetas. La solucin a este problema pasa por numerar las peticiones. Las retransmisiones llevan el mismo nmero de secuencia que la transmisin original. Entonces el kernel del servidor detecta que la rplica se ha perdido y la reenva, sin operar sobre el servidor. Una versin distinta de esta solucin es introducir en la cabecera de la peticin un bit de retransmisin. El servidor se cae La figura 2.10 a) muestra la secuencia de eventos producidos en un servidor en el servicio de una peticin. El sistema operativo del servidor recibe el paquete entrante con el mensaje, que entrega al cabo para que invoque la ejecucin del procedimiento que sirve la peticin. A continuacin, el cabo pasa la rplica al sistema operativo que lo enva en un paquete al cliente. Ahora bien, tras haberse ejecutado el procedimiento de servicio, el servidor puede sufrir una cada que impide la emisin de la rplica al cliente. Es el caso b) de la figura. Por el contrario, la cada puede producirse tras la recepcin del paquete, pero previamente a la ejecucin del procedimiento de servicio. Es el caso c). 5. Las consecuencias de los casos b) y c) es diferente. Supongamos que la operacin remota es escribir un texto en la impresora. El servidor primero carga el texto en la memoria interna de la impresora y despus escribe en un registro de la misma para iniciar la impresin. El servidor puede caerse antes de establecer el bit o despus de establecer el bit. En el primer caso, la operacin no ser realizada. En el segundo caso, s, ya que la impresora contina su trabajo con independencia de que el servidor est activo o no lo est. Podemos pensar que este caso tiene la misma complejidad que la prdida de la rplica, examina-da en el caso anterior. No es as. La prdida de la rplica supone un reenvo de la solicitud de impresin. El ncleo del servidor se dar cuenta de que el mensaje tiene un nmero de secuencia repetido y enviar de nuevo la rplica si repetir la impresin. En contraste, la cada del servidor supone la prdida del registro de los nmeros de secuencia de mensajes del cliente. Por esta razn, tras un rearranque, el servidor no puede saber si la re-peticin de impresin ha sido servida con anterioridad, de modo que volver a ser servida. Si la cada se produjo en el caso c) la impresin no se hizo, de modo que reiniciar la operacin es lo correcto. Sin embargo, si la cada se produjo en el caso b) reiniciar la operacin supone repetirla. Lo peor del caso b) es que ni cliente ni servidor sabrn nunca si la operacin se realiz con anterioridad o no. 2.1.6 Implementacin de software RPCEl xito o el fracaso de un sistema operativo distribuido radica en sus prestaciones. Si un sistema es lento, no tiene xito. Las prestaciones de un sistema operativo distribuido radican en gran parte en la velocidad de las comunicaciones, y esta velocidad depende fundamentalmente de la implementacin del protocolo de comunicacin ms que en sus principios abstractos. En esta seccin vamos a discutir la implementacin de software RPC. Protocolos RPC En los sistemas comerciales actuales, el software RPC est implementado como una biblioteca de funciones que el programa de usuario invoca. Tanto el cabo cliente como el cabo servidor no son sino un conjunto de llamadas a funciones de la biblioteca RPC. Veamos el ejemplo de Sun RPC. El siguiente mandato UNIX es el que se utiliza para compilar el programa cliente rdate de la figura 2.9.# cc -o rdate rdate.c date_clnt.c -lrpclibdonde se aprecia el enlace de la biblioteca de Sun RPC, rpclib. El mandato para generar el servidor RPC es similar. La aplicacin de usuario rdate invoca funciones RPC del cabo que, a su vez, invocan las llamadas al sistema de comunicaciones del sistema operativo para enviar los mensajes al servidor RPC. As, el software RPC puede entenderse como un nivel de servicio entre cliente o servidor y el sistema operativo, tal como ilustra la figura 2.11. Generalmente, las llamadas al sistema de comunicaciones de los sistemas UNIX estn implementadas mediante la pila de protocolos TCP/IP, que forman parte del ncleo de UNIX. IP es el protocolo de nivel de red (nivel tres en la pila OSI). TCP es uno de los protocolos de transporte de la pila TCP/IPTCP es un protocolo del nivel de transporte (nivel cuatro en la pila OSI), orientado a conexin. La comunicacin entre dos procesos mediante conexin se basa en establecer un circuito virtual entre ambas mquinas antes del hacer envo alguno. El establecimiento de una conexin es costoso en tiempo y recursos, pero garantiza la fiabilidad total de la comunicacin. 2.2 Comunicacin de gruposLa comunicacin RPC tiene dos partes, una, el cliente, dos, el servidor. Hay situaciones en que este modelo no es el idneo en un sistema con un conjunto de servidores de ficheros replicados a fin de proporcionar tolerancia a fallos. Un programa cliente que hace una escritura a disco debe hacer llegar la peticin simultneamente a todos los servidores y no a uno de ellos nicamente. El problema puede solucionarse invocando tantas llamadas RPC como servidores existentes. Existe, sin embargo, otro paradigma de comunicacin disponible para los sistemas distribuidos que es la comunicacin de grupos, ms apropiado en casos como este. 2.2.1 Introduccin a la comunicacin de grupos 6. La caracterstica principal de un grupo de procesos es que cuando se enva un mensaje al grupo, todos sus componentes lo reciben. Por otra parte, los grupos son dinmicos. Los grupos nacen y mueren y en cada grupo terminan algunos procesos y se incorporan otros. Por lo tanto es necesario un mecanismo de gestin de grupos. Un proceso puede pertenecer a ms de un grupo y abandonar un grupo para unirse a otro. Un grupo es una abstraccin cuyo propsito es evitar, en las llamadas de comunicacin con grupos de procesos, parmetros molestos como el nmero de elementos en el grupo o la localizacin de cada proceso del grupo y proporcionar primitivas ms potentes y transparentes, como el ejemplo anterior de envo de un mensaje a un conjunto de servidores de ficheros. El cliente no debera saber cuantos servidores estn disponibles en cada momento ni en qu mquinas concretas han sido arrancados. La implementacin de grupos depende mucho del hardware de comunicacin disponible. En algunas redes, como ethernet, existen unas direcciones especiales en las que pueden escuchar ms de una mquina. Para ello es necesario configurar el adaptador de red ethernet en cada mquina. Un nico marco o enviado a esta direccin es ledo por todas las mquinas que escuchan en ella. Estas direcciones se denominan multicasting. Si el nivel de enlace de la red soporta multicasting, como es el caso de ethernet, la implementacin de grupos es sencilla. Basta asignar a cada grupo una direccin multicasting diferente. Existen redes que si bien no admiten multicasting, s admiten difusin. Marcos ethernet con la direccin de destino 111111 son recibidos por todas las mquinas de la red. La difusin puede ser utilizada para implementar grupos, pero es menos eficiente, porque el marco se enva a todas las mquinas, tanto las que pertenecen al grupo como las que no. De todas formas, el envo al grupo de procesos requiere de un solo paquete. Si el nivel de enlace no proporciona multicasting ni difusin, an es posible la implementacin de grupos. Para ello, el emisor debe enviar un paquete particular a cada miembro del grupo. Por supuesto, esta es la implementacin menos eficiente. 2.2.2 Aspectos de diseo La comunicacin de grupos comparte muchos aspectos de la comunicacin estndar de paso de mensajes, tales como primitivas con buffer o sin buffer, bloqueantes o no bloqueantes, etc. No obstante, existen ms posibilidades adicionales a elegir en la comunicacin de grupos. En esta seccin examinamos algunos de estos aspectos particulares en la comunicacin de grupos. 2.2.2.1 Grupos cerrados frente a grupos abiertos Los protocolos que soportan comunicacin de grupos pueden dividirse en dos categoras. Una es la de los grupos cerrados. En ellos slo los miembros del grupo pueden enviarse mensajes entre s. Procesos que no pertenecen al grupo no pueden enviar mensajes al grupo como tal, si bien, por supuesto, s pueden enviar mensajes particulares a cada miembro del grupo a ttulo particular. Otros protocolos soportan grupos abiertos. Un proceso que no pertenece a un grupo puede enviar mensajes a este grupo. Los grupos cerrados son utilizados tpicamente en procesa-miento en paralelo, donde los procesos tienen su propio cometido y no interactan con el mundo exterior. Los grupos abiertos son apropiados para problemas como el de los servidores replica-dos, donde un cliente enva una peticin al grupo. Los miembros del grupo tambin necesitan hacer uso de la comunicacin en grupo y no slo un proceso externo, por ejemplo para decidir quin debe ejecutar una peticin dada. 2.2.2.2 Grupos de iguales frente a grupos jerrquicos En algunos grupos un proceso es el jefe o coordinador y el resto trabajan para l. En otros, todos los procesos tienen la misma categora y las decisiones se toman de forma colectiva. En el primer caso, cuando uno de los trabajadores o un cliente externo solicita una peticin, esta es enviada al coordinador, que decide cul de los trabajadores es el ms apropiado para servirla. Cada una de estas organizaciones tiene sus ventajas y sus inconvenientes. Los grupos pares no tienen un nico punto de fallo. Si un trabajador deja de existir, la carga se reparte en el resto. Sin embargo, incurren en el retraso que supone el ponerse de acuerdo para decidir quin sirve una peticin. Los grupos jerrquicos tienen las propiedades opuestas. 2.2.2.3 Pertenencia a grupos 7. Se necesita un mtodo para crear, destruir y modificar los grupos. Una solucin es introducir un proceso denominado el servidor de grupos. El servidor de grupos mantiene tablas con los grupos existentes y sus integrantes. Esta solucin es eficiente y fcil de implementar. El problema es que el servidor de grupos es una tcnica centralizadora y, como tal, constituye un nico punto de fallo. La opcin opuesta es la gestin distribuida. Un nuevo proceso que se incorpora al grupo puede enviar un mensaje al grupo y todos los procesos toman nota de su existencia. Cuando un proceso del grupo termina, enva un mensaje de adis. Surge un problema cuando un proceso del grupo termina inesperadamente. El resto del grupo tiene que descubrirlo experimentalmente, ya que el proceso nunca responde a nada. Cuando todos los miembros lo han constatado, se le da de baja. 2.2.2.4 Direccionamiento de grupos Para dirigir un mensaje a un grupo, el grupo debe tener una direccin. Si el nivel de enlace de la red -en adelante, la red- soporta multicasting, se puede implementar una direccin de grupo como una direccin multicasting. Si la red soporta difusin, pero no multicasting, el mensaje debe ser recibido por todos los ncleos y extraer de l la direccin del grupo. Si ninguno de los procesos de la mquina es miembro del grupo, el mensaje es descartado. En otro caso, es pasado a todos los procesos que pertenecen al grupo. Si la red no soporta ni difusin ni multicasting, el ncleo de la mquina emisora tendr que tener una lista de los procesos que pertenecen al grupo y enviar un mensaje a cada uno de los componentes del grupo. 2.2.2.5 Primitivas send y receive No es conveniente que los procesos de usuario puedan utilizar las primitivas send y recei-ve por separado. Segn Tanenbaum, send y receive se corresponden en programacin distribuida con la construccin go to en programacin convencional. Su utilizacin provoca ms trastornos que utilidad. Si RPC es la primitiva de comunicacin usada por los procesos de usuario, la comunicacin de grupo debiera poder construirse mediante RPC. El problema es tratar con una llamada a procedimiento que devuelve tantos valores como procesos tiene un grupo. No parece posible, de modo que una aproximacin comn es volver a las primitivas send y receive en los procesos de usuario. Si se permite send y receive a los procesos de usuario, se pueden aprovechar estas primitivas para realizar la comunicacin de grupo. En el caso de la comunicacin convencional cliente servidor, el primer parmetro de send es un nmero de puerto en la red y el segundo parmetro es el mensaje. Se puede utilizar send para la comunicacin de grupos empleando como primer parmetro la direccin de un grupo de procesos en lugar de un puerto determinado. As unifica-mos la comunicacin punto a punto y la comunicacin de grupos en una primitiva nica. La implementacin de send que haga el ncleo o la rutina de biblioteca puede ser una de las tres citadas en el apartado de direccionamiento de grupos. send puede ser con buffer o sin buffer, bloqueante o no bloqueante, fiable o no fiable, etc, igual que en la comunicacin punto a punto. La comunicacin de grupo no cambia las cosas. Enviar a un grupo obliga al ncleo del sistema que enva a hacer una comunicacin multicasting a todos los miembros del grupo, pero qu es recibir de un grupo? Puede entenderse que todos los miembros del grupo van a enviar una rplica diferente y por lo tanto un envo a un grupo debera continuar en el programa de usuario con tantas operaciones receive como miembros tuviese el grupo. Ello, no obstante, significa una prdida de transparencia, ya que un proceso externo no debe conocer la estructura interna de un grupo. 2.2.2.6 Atomicidad de la difusin Una de las caractersticas de la comunicacin de grupos es que un mensaje enviado a un grupo debe ser recibido por todos los miembros del grupo o por ninguno de ellos. A esta propiedad se la denomina la atomicidad de la difusin o simplemente la atomicidad. La atomicidad facilita en gran medida la programacin de sistemas distribuidos. Supongamos, por ejemplo, una base de datos distribuida. Una base de datos distribuida puede tener una relacin cuyos atributos estn repartidos en mquinas dispersas geogrficamente. El acceso a una tupla significa enviar un mensaje a 8. todas las mquinas. Supongamos la creacin de una tupla de estas caractersticas. Si uno de los mensajes se pierde, la base de datos queda en un estado inconsistente. La tupla debe crearse en su totalidad o no crearse y la aplicacin ser informada del xito o del fracaso de la operacin entera, no slo un xito parcial. Implementar la atomicidad de la difusin no es tan simple como parece. Por ejemplo, uno de los adaptadores de red tal vez acaba de recibir un paquete y antes de que est preparado para recibir uno nuevo, llega el paquete de difusin, que no puede ser aceptado y simplemente se pierde. Todas las mquinas del grupo han recibido el paquete excepto una, lo que arruina la difusin completa. Para cerciorarse de que todo ha ido bien, el emisor de la difusin debe esperar las confirmaciones de los miembros del grupo. Si una falta, deber repetir la difusin o reenviar el mensaje en particular. Puede ocurrir que antes de repetir la difusin o hacer el reenvo, el emisor de la difusin se caiga. En esta situacin, el cliente debe rearrancar, pero nunca sabr cuntos son los mensajes que realmente han sido enviados y cuntos los que han fallado. Algunos miembros del grupo han recibido el mensaje y otros no. Una situacin inaceptable e incorregible? No, queda alguna esperanza. Existe un algoritmo que demuestra que la atomicidad es posible. El emisor realiza la difusin, inicializa temporizadores y realiza los reenvos necesarios. Cuando un miembro del grupo recibe un mensaje nuevo, enva el mensaje a todos los miembros del grupo -de nuevo utilizando temporizadores y retransmisiones si son necesarias-. Si el mensaje no es nuevo, simplemente es descartado. No importa cuantas mquinas caigan en el proceso de envos y reenvos, lo importante es que de los procesos supervivientes en el grupo todos han recibido el mensaje. 2.2.2.7 Ordenacin de mensajes Para que la comunicacin en grupo sea fcil de usar y comprender requiere de dos propieda-des. La primera es la atomicidad, examinada ms arriba y la segunda es el orden de los mensajes. Supongamos cinco mquinas, cada una con un proceso. Los procesos 0, 1, 3 y 4 pertenecen a un grupo de procesos. Supongamos que los procesos 0 y 4 deciden enviar un mensaje al resto de los procesos del grupo. Supongamos que el proceso 0 lo ha decidido un instante de tiempo antes. La propiedad de orden temporal global exige que cada miembro del grupo reciba primero el mensaje del proceso 0 y despus el mensaje del proceso 4. Una red local que soporte difusin garantiza el orden temporal global. Todos los mensajes del proceso 0 llegan al resto del grupo ya que el paquete con direccin difusin es recibido por todos los adaptadores de red de forma simultnea. Slo despus, cuando el mensaje ha sido enviado y deja libre el canal el proceso 4 puede emitir su paquete de difusin. Una red sin difusin no garantiza el orden temporal global, que debe implementar la difusin enviando cuatro mensajes consecutivos que pueden entrelazarse con los del proceso 4. As, el proceso 1 puede recibir primero el mensaje del proceso 0 y despus el del 4 y el proceso 3 puede recibir primero el mensaje del proceso 4 y despus el del proceso 0. 2.2.2.8 Grupos solapados En el apartado anterior vimos el problema de la ordenacin temporal global aplicada a un grupo dado. Dos procesos del mismo grupo enviaban simultneamente un mensaje al grupo. Hemos mencionado previamente que un proceso puede pertenecer a ms de un grupo, de manera que los grupos pueden solaparse. Este solapamiento produce un nuevo tipo de inconsistencia temporal. La figura 2.14 muestra el problema planteado. Los procesos A y D, en distinto grupo, envan simultneamente un mensaje a su propio grupo. Como en el caso anterior supongamos que la red no proporciona difusin y esta se implementa mediante unicasting. El envo simultneo es consitente si B y C reciben primero el mensaje del grupo 1 y despus el mensaje del grupo 2 (o viceversa). Unicasting no puede garantizar esto, de modo que es posible el escenario de la figura 2.14. B recibe el mensaje dirigido al grupo 1 y despus el mensaje al grupo 2. C, por el contrario, primero recibe el mensaje dirigido al grupo 2 y despus el mensaje al grupo 1. Fig. 2.14 Cuatro procesos y cuatro mensajes. B y C toman los mensajes de A y D en diferente orden. Una comunicacin de grupo que garantiza que esto no ocurre se dice que tiene la propiedad de orden temporal entre grupos solapados. La implementacin del orden temporal entre grupos solapados es costosa y difcil de implementar, de modo que algunos sistemas distribuidos la implementan y otros no, actualmente la mayora de ellos. 9. 2.2.2.9 EscalabilidadMuchos algoritmos de comunicacin de grupos funcionan bien siempre que los grupos sean pequeos y haya pocos grupos, pero qu ocurre cuando cada grupo tiene muchos procesos y hay miles de grupos? Y qu ocurre cuando los grupos se extienden geogrficamente entre continen-tes? Para ellos es preciso sobrepasar los estrechos lmites de la red local e introducir encaminado-res y muchas redes locales. La presencia de encaminadores afecta a las propiedades de la comunicacin del sistema operativo distribuido, ya que estn basadas en la suposicin de ausencia de encaminadores. Un encaminador es bsicamente una mquina que pertenece a dos o ms redes. Su propsito es unir dos o ms redes locales distantes geogrficamente, de distinto nivel de enlace o ambas cosas a la vez, permitiendo que todas ellas compartan un mismo protocolo de nivel de red. En la definicin de grupo nada impide que los procesos que forman el grupo se encuentren en una misma Inter-red pero en distintas redes locales. Cuando la comunicacin de grupo se realiza mediante unicasting la presencia de gateways no es problemtica. Cada mensaje enviado por el proceso emisor llega al proceso destinatario siguiendo los cauces convencionales del algoritmo utilizado por el protocolo de red. Consideremos un sistema operativo distribuido en el que las redes locales que abarca soportan multicasting, como ethernet. 3.1 Sincronizacin de relojes Los algoritmos distribuidos tienen las siguientes propiedades:1. La informacin relevante est repartida entre mltiples mquinas 2. Los procesos toman decisiones basados nicamente en informacin local 3. Es preciso evitar un nico punto de fallo 4. No existe un reloj comn Los primeros tres aspectos dicen que es inaceptable recoger toda la informacin en un nico punto. El ltimo aspecto es que ahora nos interesa. En un sistema centralizado, el tiempo se solicita mediante una llamada al sistema, como la llamada UNIX time. Si un proceso A solicita el tiempo y poco despus lo solicita el proceso B, B obtiene un tiempo posterior al de A, ya que ambos consultan el mismo reloj. En un sistema distribuido, en que A y B corren en mquinas distintas y consultan distintos relojes, si el reloj de A es ligeramente ms lento que el de B, A puede conseguir un tiempo posterior al de B a pesar de habero solicitado antes. 3.1.1 Relojes lgicos Leslie Lamport, en 1978 ([Les78]), mostr que la sincronizacin de relojes para producir un patrn de tiempo comn a ms de una mquina es posible y present un algoritmo para lograrlo. Lamport afirm que no es necesario disponer de un registro comn absoluto del tiempo cuando los procesos no interactan y, cuando lo hacen, tampoco es necesario en la mayora de las aplicaciones. Para muchos casos, lo imporante es que los procesos que interactan se pongan de acuerdo en el tiempo en que los eventos ocurren. En el ejemplo de make, lo importante es que pepo.c sea ms antiguo que pepo.o, no el instante preciso de creacin de ambos. As, para ciertas clases de algoritmos, lo que importa es la consistencia interna de los relojes, no la exactitud particular de cada uno de ellos. Para estos algoritmos, es conveniente hablar de relojes lgicos. Cuando el objetivo es mantener todos los relojes dentro de un margen error dado respecto al tiempo absoluto, es conveniente hablar de relojes fsicos.Lamport defini la relacin ocurre-antes, a m b, leda a ocurre antes que b, y significa que a ocurre antes que b y todos los procesos estn de acuerdo en ello. Lamport defini esta relacin como sigue:1. Si los eventos a y b ocurren en el mismo proceso y a ocurre antes que b, entonces a b. 2. Si a es el evento que consiste en el envo de un mensaje a otro proceso y b es el evento que consiste en la recepcin del mensaje en otro proceso, entonces a b. 3. Si a e b y b c, entonces b e c. 10. 3.1.2 Relojes fsicosEl da solar es el tiempo que transcurre desde que el sol alcanza su punto ms alto en el horizonte hasta que vuelve a alcanzarlo. Un da tiene 24 horas, de modo que definimos el segundo solar como 1/(24*60*60) = 1/86400 de un da solar. En 1940 se descubri que la duracin del da no era constante. Estudios actuales sobre coral antiguo han llevado a los gelogos a pensar que hace 300 millones de aos haba 400 das en un ao. No es que el ao fuera ms largo. Es que los das eran ms cortos. La tierra rotaba sobre s misma ms rpido que en la actualidad. Adems de esta tendencia a largo plazo, la tierra experimenta perturbaciones espordicas en su tiempo de rotacin debido a las turbulencias de su ncleo de hierro. Estas oscilaciones llevaron a los astrnomos a determinar la duracin del segundo como la media de un gran nmero de ellas. Dividida esta cantidad por 86400 obtenemos el segundo solar medio.Con la invencin del reloj atmico en 1948, la medida del tiempo pas de ser responsabilidad de los astrnomos a ser responsabilidad de los fsicos. Definieron el segundo atmico como el tiempo que tarda el istopo 133 del cesio en realizar 9192631770 transiciones. Este nmero de transiciones fue escogido, por supuesto, porque son las que igualaban la duracin del segundo solar medio el da que el segundo atmico fue introducido. El segundo atmico es ms preciso que el segundo solar, pero no es absolutamente preciso. En el mundo existen actualmente unos 50 laboratorios que disponen de un reloj de 133Cs. Cada uno de ellos registra el nmero de ticks acumulados desde las cero horas del primero de enero de 1958. En Pars existe una organizacin que se llama la Oficina Internacional de la Hora que promedia los ticks de estos 50 laboratorios. Al resultado lo divide por 9192631770 para obtener el Tiempo Atmico Internacional (TAI). El TAI es extrordinariamente estable y est a disposicin de cualquiera que lo solicite. Sin embargo, como el periodo de rotacin de la tierra est aumentando continuamente, el segundo solar aumenta en la misma medida. As, un da solar, que son 86400 segundos solares, tiene ahora 86400.003 segundos TAI.Usar el tiempo TAI es ms exacto, pero llegar un momento que el medioda no ser a las 12, sino a las doce y cuarto. Los segundos TAI duran menos que los segundos solares. Para ello, cuando un reloj solar ha perdido 0.8 segundos respecto al tiempo TAI, por ejemplo, el tiempo es de 4.0 TAI y de 3.2 solar, se extingue ese segundo solar para que pase directamente de 3.2 a 4.0 y mantener la sincrona con el tiempo TAI. Esto da una medida del tiempo con intervalos irregulares, llamado el Tiempo Universal Coordinado (UTC), que es la base actual del registro del tiempo. Ha reemplazado al antiguo estndar de la medida del tiempo, el GMT (Greenwich Meridian Time), que es tiempo solar.Para proporcionar el tiempo UTC, una institucin de Estados Unidos, el Instituto Nacional del Tiempo Estndar (NIST), mantiene una estacin de radio de onda corta que radia un pulso cada vez que comienza un segundo UTC. La precisin de esta estacin es de un milisegundo, pero el ruido atmosfrico eleva este error en la prctica a 10 milisegundos. En Inglaterra y otros pases existen estaciones similares. Tambin satlites proporcionan el tiempo UTC, y lo hacen con una precisin de 0.5 milisegundos, veinte veces mayor que las estaciones de radio de onda corta. El costo de este servicio vara, segn su exactitud, entre 100.000 pts y varios millones de pesetas segn su precisin. Hay un medio ms barato, que es obtenerlo del NIST por telfono. Este es el mtodo ms inexacto, ya que hay que corregir el retraso de la seal en la lnea y el modem.Concluyendo, podemos decir que el tiempo absoluto puede ser proporcionado al computador, pero a un precio alto y siempre con un margen de error no despreciable. Mas informacin: http://www.cstv.to.cnr.it/toi/uk/utctime.html 11. 3.1.3 Algoritmos de sincronizacin de relojesLa medida del tiempo en las mquinas se lleva a cabo mediante un oscilador de cristal. Un chip denominado temporizador recibe la seal peridica del oscilador e interrumpe la UCP cada cierto nmero de oscilaciones, previamente programado. Valores tpicos oscilan entre 50 y 100 interrupciones por segundo a la UCP. Por preciso que sea un oscilador a cristal, siempre existe un margen de error que conlleva la discrepancia de la medida del tiempo de dos mquinas diferentes. En una red local, por ejemplo, ninguna mquina tiene el mismo registro del tiempo. Para disminuir la discrepancia entre relojes, se puede tener acceso a una estacin de onda corta de las ya citadas. El caso general, sin embargo, es que este servicio no est disponible, y el problema que se plantea es, dado un conjunto de mquinas, mantener sus relojes lo ms cercanos que sea posible mediante software.Se han propuesto para ello muchos algoritmos, todos ellos con el mismo principio, que ahora describimos. Se supone que cada mquina dispone de un temporizador que interrumpe a la UCP H veces por segundo. El ncleo dispone de una variable que es incrementada en la unidad por la rutina de interrupcin del reloj. Esta variable registra el nmero de ticks recibidos desde la puesta en marcha del sistema, por ejemplo. Esta variable se considera el reloj del sistema y vamos a denominar el valor que almacena como C. Cuando el tiempo es t, el tiempo registrado por la mquina p es Cp(t). Idealmente Cp(t) debiera ser igual a t, para todo p y todo t. En otras palabras, dC/dt debiera ser idealmente 1. Tericamente, un temporizador con H=60 interrumpe al reloj sesenta veces por segundo. En una hora interrumpe 60*60*60 = 216000 veces. En la prctica, se puede contar este nmero de interrupciones y descubrir que no son exactamente esas, sino que el dato vara entre 215998 y 216002 ticks en una hora, lo que representa un error relativo de aproximadamente 105. La precisin de un temporizador viene dada por su tasa de deriva mxima 0, de modo que sise dice que el reloj opera dentro de sus especificaciones.Dos relojes iguales dentro de sus especificaciones pueden generar una direferencia mxima en su medida del tiempo cuando la deriva toma en ellos el valor mximo y de signo opuesto. As, partiendo ambos de cero, en un intervalo , el reloj uno toma un valor de y el reloj dos un valor de 0, obteniendo una diferencia mxima en la medida de 0. Si los diseadores del sistema desean que nunca dos relojes muestren diferencias mayores a una constante 0, 0, de modo que 0, lo que significa que los relojes deben ser sincronizados cada 0 segundos. A continuacin vamos a ver algunos algoritmos que llevan a cabo esta resincronizacin. 3.1.3.1 El algoritmo de CristianEste algoritmo requiere que una de las mquinas disponga de un receptor de onda corta y el objetivo es lograr que todas las dems operen sincronizadas con ella. A esta mquina la vamos a llamar un servidor de tiempo. Peridicamente, y siempre antes de segundos, cada una de las mquinas enva un mensaje al servidor de tiempo solicitando el tiempo CUTC, que es servido tan rpido como es posible como indica la figura 3.5 XX falta XX. El algoritmo tiene dos problemas, uno ms leve y otro ms serio. El ms serio es que un reloj nunca puede ser retrasado. Si el reloj de la mquina que solicita el tiempo es rpido, el tiempo CUTC recogido es menor y su reloj debe ser atrasado. Esto no se puede permitir porque muchas aplicaciones, como make, confan en la secuencia temporal de eventos en el sistema como la base de su operacin. A un evento que ocurre despus de otro, como la generacin de un fichero objeto, no se le puede asignar un tiempo de creacin o ltima modificacin inferior al del programa fuente. 12. La modificacin del reloj debe realizarse gradualmente. Una forma de hacerlo es la siguiente. Supongamos que el temporizador interrumpe la UCP cien veces por segundo, lo que significa que un tick de reloj es un intervalo de tiempo de diez milisegundos. La rutina de interrupcin incrementa un contador en el ncleo, el reloj, en una unidad, lo que equivale a sumar al tiempo diez milisegundos. Para retrasar el reloj un segundo se puede dejar de incrementar el contador una de cada cien interrupciones -por ejemplo, la dcima-, lo que significa que cada segundo retrasamos el reloj diez milisegundos. Para retrasarlo un segundo necesitamos cien segundos. Para adelantar el reloj se puede utilizar esta misma tcnica. Al cabo de 100 segundos, habremos adelantado el reloj un segundo. Tambin se puede adelantar el reloj de una sla vez aadiendo 100 ticks al reloj, ya que el adelantamiento del tiempo no causa problemas.El problema secundario es que desde que una mquina solicita el tiempo CUTC, la rplica del servidor de tiempo tarda en llegar una cantidad de tiempo no despreciable y, lo que es peor, que vara con la congestin de la red. El algoritmo de Cristian aborda este problema intentando medirlo. El cliente registra el tiempo local T0 en que enva el mensaje y el tiempo T1 en el que llega y estima que la rplica tard en llegar (T1-T0)/2. Este tiempo que es local y, por ser pequeo, relativo exacto aunque el reloj se haya alejado sensiblemente del tiempo UTC. (T1-T0)/2 se suma al CUTC que trae el mensaje y el resulado es el CUTC que finalmente el cliente adopta. Para mejorar la exactitud se puede realizar un muestreo entre distintos tiempos de retorno de la peticin de tiempo y realizar una media. Se aconseja descartar los valores que superan un umbral dado para evitar introducir en la estimacin rplicas obtenidas en momentos de congestin. 3.1.3.2 El algoritmo de Berkeley Es el adoptado por UNIX BSD. Frente al algoritmo de Cristian, basado en un servidor pasivo que responde a las peticiones de clientes, el algoritmo de Berkeley toma una aproximacin activa. Es til cuando no se dispone del tiempo UTC, va un receptor de onda u otro. Un demonio UNIX peridicamente realiza un escrutinio de las mquinas, aquella en la que reside incluida, a fin de obtener el valor de sus relojes. Realiza una media de todos ellos y la comunica a todas la mquinas para que avancen o retrasen sus relojes. 3.1.3.3 Algoritmos de promediadoLos algoritmos anteriores tienen la desventaja de su aproximacin centralizada y, por lo tanto, tienen un nico punto de fallo. Presentamos a continuacin un algoritmo descentralizado. Las mquinas dividen el tiempo en intervalos de longitud R, de modo que el comienzo del i-simo intervalo comienza en el instante T0+iR se prolonga hasta el instante T0+(i+1)R, donde T0 es un instante pasado previamente acordado. Cuando comienza uno de estos intervalos, cada mquina realiza una difusin del tiempo segn su reloj. Debido a la deriba particular de cada reloj, dos difusiones no ocurren simultneamente. Despus de la difusin de su tiempo, cada mquina establece un temporizador y espera el mensaje correspondiente al broadcast del resto de las mquinas en un intervalo S. Cuando han llegado todos los mesajes, un algoritmo de promediado proporciona el nuevo tiempo. El algoritmo ms simple es realizar la media aritmtica de los tiempos. Una variacin es descartar previamente los valores extremos a fin de protegernos frente a relojes defectuosos. Otra variacin es estimar el tiempo de propagacin de cada mensaje para aadirlo al tiempo que el mensaje transporta. Esta estimacin puede llevarse a cabo a partir de un conocimiento previo de la topologa de la red o realizando mediciones del tiempo de retorno de algunos mensajes de prueba. 3.1.4 El empleo de la sincronizacin de relojes 13. Hasta hace poco tiempo no se ha presentado la necesidad de sincronizar los relojes de mquinas en una red de rea ancha. Ahora es posible sincronizar relojes distribuidos a lo largo de toda la Internet en mrgenes de precisin de unos pocos milisegundos respecto al tiempo UTC. La disponibilidad de algoritmos de bajo costo para mantener la sincronizacin de relojes ha incitado el desarrollo de algoritmos distribuidos que explotan esta circunstancia disminuyendo el nmero de mensajes implicados en las versiones que no la explotan. A continuacin ilustramos el empleo de la sincronizacin de relojes en el problema de la consistencia de la cach de un sistema de ficheros distribuidos. La referencia [Lis93] contiene ms ejemplos.Un ejemplo de la utilidad de algoritmos basados en el uso de relojes sincronizados est relacionado con la consistencia de la cache de disco en un sistema de ficheros distribuido. Razones de prestaciones exigen una cach en el cliente. Dos clientes operando sobre un mismo fichero mantienen cada uno de ellos una copia del fichero en su propia mquina. La inconsistencia de las cachs surge cuando uno de los clientes trata de escribir en el fichero. Tradicionalmente, cuando un cliente deseaba escribir un fichero de su cach solicitaba permiso al servidor. Inmediatamente, el servidor est obligado a solicitar permiso al proceso o procesos que estn leyendo del fichero para que dejen de hacerlo (y lo descarten de la cach), y esperar a que todos los permisos lleguen antes de conceder el permiso de escritura, lo que introduce una fuerte sobrecarga en tiempo y ancho de banda en la red.La introduccin de los relojes sincronizados agiliza este tipo de protocolos de los sistemas de ficheros distribuidos. La idea bsica es que cuando un cliente solicita un fichero, el servidor le otorga una concesin en la que detalla el tiempo de expiracin de la misma E. Como cliente y servidor tienen los tiempos sincronizados, el plazo es el mismo en ambos. Mientras dura la concesin, el cliente tiene la garanta de que opera sobre el fichero de forma consistente. Un cliente no necesita comunicar al servidor que ha terminado la operacin de lectura. Si un cliente solicita la escritura de un fichero, el servidor debe pedir a los clientes lectores la terminacin prematura de la concesin. Qu ocurre cuando no hay respuesta por parte del cliente lector? El servidor no sabe si el cliente simplemente se ha cado. En este caso, el servidor no obtiene respuesta, lo que planteara un problema en el algoritmo tradicional. Con los relojes sincronizados, simplemente espera a que cumpla el plazo de la concesin del fichero. 3.2Exclusin mutuaCuando dos o ms procesos comparten una estructura de datos, su lectura o actualizacin no debe ser simultnea. Para evitar la simultneidad de acceso, y con ello la incosistencia de la estructura, el cdigo de acceso y actualizacin de la misma se denomina regin crtica y su ejecucin es protegida mediante construcciones como semforos, monitores, etc. En esta seccin examinamos algunos ejemplos de cmo construir regiones crticas en sistemas distribuidos. 3.2.1 Un algoritmo centralizadoLa forma ms directa de conseguir la exclusin mutua en un sistema distribuido es simular al mecanismo de los sistemas centralizados. Se requiere de un proceso que acta como coordinador. Este registra las regiones crticas de los procesos. Cuando un proceso desea entrar en una regin crtica enva un mensaje al coordinador con el nmero de la regin crtica. Si ningn otro proceso est ejecutando la regin crtica, el coordinador enva una rplica al proceso con la concesin de entrada, tal y como muestra la figura 3.5. Cuando la rplica llega, el proceso entra en la regin crtica. 14. Fig. 3.5 a) Solicitud y concesin de entrada en regin crtica. b) La concesin se retrasa hasta mientras la regin crtica est en uso. c) Concesin tras ser liberada Supongamos que el proceso 3 de la figura desea entrar en la misma regin crtica antes de que el proceso 2 salga. La peticin llega al coordinador, que sabiendo que el proceso 2 est dentro, no enva rplica alguna al proceso 3, que permanece bloqueado esperndola -tambin se puede implementar la denegacin mediante un mensaje-, pero lo registra en la cola de la regin como solicitante. Cuando el proceso 2 sale de la regin crtica lo comunica al coordinador mediante un mensaje de liberacin. El coordinador procesa el mensaje determinando si existe en la cola de la regin recin liberada algn proceso esperando. En nuestro caso, efectivamente lo hay. Es el proceso 3, que por fin recibe el mensaje de concesin de entrada.Este algoritmo garantiza la exclusin mutua. Primero, el coordinador slo permite entrar en la misma a un proceso. Segundo, es justo, ya que las peticiones son atendidas en el orden en que llegan. Tercero, ningn proceso espera indefinidamente por la entrada. El esquema es fcil de implementar y es eficiente, ya que requiere tres mensajes para usar una regin crtica. El defecto principal del algoritmo, como todos los algoritmos centralizados es la existencia de un nico punto de fallo.3.2.2El algoritmo distribuido de Ricart y AgrawalaRicart y Agrawala presentaron en 1981 un algoritmo de exclusin mutua distribuido. Consideramos un conjunto de N procesos con una esctructura sencilla en la que alternan los clculos fuera de la regin crtica y dentro de la regin crtica. Las condiciones del algoritmo son las siguientes:1. Los procesos se comunican mediante mensajes de capacidad no nula. 2. Los mensajes pueden llegar a un proceso en cualquier punto de la ejecucin, bien dentro o bien fuera de la regin crtica. De cualquier modo una interrupcin, excepcin, manejador de seal, etc, se encarga de procesar la llegada del mensaje. 3. Se asume que la comunicacin es fiable y los mensajes entre dos procesos son entregados en el orden en el que fueron enviados. 4. Es preciso una relacin de orden total entre los eventos de todo el sistema. Consideramos que para que un proceso entre en la regin crtica deben tener el permiso todos y cada uno del resto de los procesos, permiso que solicita enviando un mensaje a todos ellos, va multicasting, difusin o uno a uno. El mensaje acarrea una etiqueta temporal que es el valor del reloj lgico local correspondiente a su envo. Cuando un proceso recibe un mensaje de solicitud de permiso, la accin que toma el proceso receptor es la siguiente:1. Si el receptor no est en su regin crtica y no desea entrar en ella, se dice que est en situacin de permiso concedido (CONCEDIDO) y enva inmediatamente un mensaje de rplica al proceso que solit el permiso. 2. Si el receptor est ejecutando en su regin crtica, se dice que tiene el permiso (OTORGADO), no enva rplica al emisor y encola la peticin. Como vemos, si un proceso no contesta significa que no concede el permiso de entrada. 3. Si el receptor desea tambin entrar en la regin crtica, pero an no lo ha conseguido se dice que est en estado de solicitud (SOLICITANDO), compara el reloj del mensaje entrante con el del mensaje que ha enviado al resto de los procesos para solicitar el permiso. El ms bajo gana. Si gana el emisor del mensaje entrante, el receptor enva a este la rplica. Si gana el receptor, encola el mensaje y no enva rplica. Inicializacin: estado:=CONCEDIDO; 15. Para obtener el permiso:estado:=SOLICITANDO;multicast de solicitud de permiso al resto;T:=Reloj lgico del mensaje de peticin;Wait until(Nmero de rplicas recibidas=n-1);estado:=OTORGADO;Cuando se recibe una peticin en pj:if(estado=OTORGADO or (estado=SOLICITANDO and C.pj < C.pi) )thenEncola la peticin de pi sin replicarelseReplica inmediatamente a pifiPara conceder el permiso tras abandonar la regin crtica:estado=CONCEDIDO;Replica a todos las peticiones en la cola;Fig. 3.6 El algoritmo de Ricart y Agrawala En conjunto, el algoritmo es ms lento, ms complicado y menos robusto que el algoritmo centralizado, de modo que porqu molestarse estudindolo? Porque demuestra que un algoritmo distribuido, sin un control central, es posible, lo que estimula el estudio de soluciones distribuidas ms avanzadas.3.2.3 El algoritmo en anillo Esta basado en una disposicin de los n procesos que estn interesados en utilizar la regin crtica en un anillo lgico. Se concede la entrada en la regin crtica al proceso que obtiene el denominado testigo. El testigo es un mensaje que se pasa de proceso en proceso en un sentido nico recorriendo el anillo. Cada proceso tiene la direccin del proceso al que pasa el testigo. Cuando un proceso recibe el testigo, si no est interesado en la regin crtica, pasa es testigo a su vecino. Si necesita entrar en la regin crtica, espera bloqueado la llegada del testigo, que es retenido y no es entregado al vecino sino cuando abandona la regin crtica.Para obtener el testigo, como mximo se emplean n-1 mensajes. Una desventaja es que los mensajes se envan continuamente aun en el caso de que ningn proceso reclame el testigo. Otra es que este algoritmo tiene n puntos de fallo, si bien la recuperacin es ms fcil que en los casos anteriores. Si cada vez que se recibe el testigo se enva un mensaje de confirmacin, es sencillo detectar la cada de un proceso y retirarlo del anillo.3.3Algoritmos de eleccinUna eleccin es un procedimiento cuya funcin es elegir un proceso en un grupo a fin de que este desempee un papel determinado, como puede ser centralizar peticiones de entrada en una regin crtica, a modo de coordinador. Vamos a considerar que los procesos implicados en la eleccin son idnticos, sin que ninguno de ellos tenga una caracterstica destacable como para ser el coordinador idneo. Cada proceso tiene un identificador nico como puede ser su direccin de red. En general, los algoritmos de 16. eleccin intentan localizar al proceso con el identificador ms alto para hacerlo coordinador. Para enviar los mensajes, los procesos necesitan conocer las direcciones de red de todo el grupo de procesos en busca de coordinador, de modo que la eleccin ya estara hecha de antemano. El problema es que los procesos desconocen cules de ellos estn an activos y cules no. El requisito que debe cumplir una eleccin de coordinador es que esta sea nica. Los algoritmos difieren unos de otros en el modo de conseguirlo.El algoritmo del matn Este algoritmo data de 1982 y es debido a Garca-Molina. Cuando un proceso se apercibe de que el coordinador no responde a sus mensajes, inicia una convocatoria de eleccin. Una eleccin se desarrolla como sigue: 1. P enva un mensaje de tipo ELECCION a todos los procesos con identificadores ms altos. 2. Si ninguno de ellos responde, P gana la eleccin y se convierte en el coordinador. 3. En cuanto P recibe el mensaje de respuesta de alguno de ellos, renuncia a ser el coordinador y su trabajo ha terminado. Cada uno de estos procesos, tras enviar el mensaje, convocan una eleccin En cualquier momento, un proceso puede recibir un mensaje ELECTION de uno de los procesos con identificador inferior. La rutina que sirve el mensaje enva un mensaje de confirmacin y toma el control iniciando una eleccin, a menos que ya est celebrando una. Llega un momento en que todos los procesos renuncian y uno de ellos se convierte en el nuevo coordinador, hecho que anuncia al resto de los procesos mediante el envo de un mensaje. Si un proceso que inicialmente estaba cado se recupera, inicia una eleccin. Si es el de identificador ms alto, ganar la eleccin y asumir el papel de coordinador. Siempre gana el proceso de identifica-dor ms grande, de ah el nombre del algoritmo. En la figura 3.7 vemos el desarrollo de una eleccin en un grupo de ocho procesos numerados del 0 al 7, siendo este ltimo el coordinador que, en un momento dado, deja de estar operativo. El proceso 4 es el primero en darse cuenta de que el coordinador no responde y convoca una eleccin, enviando un mensaje de tipo ELECCION a los procesos 5, 6 y 7, los dos primeros confirmando el mensaje. En cuanto el proceso 4 recibe la confirmacin del proceso 5 da su trabajo por terminado. Sabe que l no ser el coordinador, sino uno de los superiores que han confirmado. Los procesos 5 y 6 convocan elecciones de forma ms o menos simultnea. El proceso cinco recibe confirmacin del 6 y renuncia. El proceso 6 no recibe confirmacin alguna, de modo que se erige en ganador, algo que anuncia al resto envindoles un mensaje COORDINADOR. El proceso 4, que estaba esperando el resultado de la eleccin -aunque ya lo casi lo conoca- reanuda su trabajo, esta vez con un nuevo coordinador. 3.4 Transacciones atmicas El paradigma cliente-servidor proporciona una buena forma de estructurar el sistema y de desarrollar aplicaciones, pero necesita del concepto de transaccin para controlar secuencias complejas de interacciones entre el cliente y el servidor. Sin transacciones no se puede conseguir que los sistemas distribuidos funcionen en las aplicaciones tpicas de la vida real. Los conceptos de transacciones fueron concebidos para poder abordar la complejidad de las aplicaciones on-line en sistemas de un nico procesador. Estos conceptos, ya veteranos, son hoy da incluso ms crticos en la implementa-cin con xito de sistemas masivamente distribuidos, que operan y fallan en formas mucho ms complejas. Los sistemas de proceso de trasacciones fueron pioneros en conceptos de computacin distribuida y computacin tolerante a fallos. Ellos introdujeron los datos distribuidos en aras de la fiabilidad, disponibilidad y prestaciones. Ellos desarrollaron el almacenamiento tolerante a fallos y el proceso tolerante a fallos a fin de garantizar la disponibilidad de datos y aplicaciones. Y fueron ellos quienes desarrollaron el modelo cliente-servidor y las llamadas a procedimiento remoto para la computacin distribuida. Y, lo ms importante, las propiedades ACID de las transacciones han emergido como los conceptos unificadores de la computacin distribuida ([Gra93]). Como puede apreciarse, no es posible obviar el tpico de las transacciones atmicas en un curso sobre sistemas distribuidos. En esta seccin nos ocupamos de ellas, tratando algunos de sus mltiples aspectos. 17. 3.4.1 Introduccin a las transacciones atmicasPensemos en una primitiva de sincronizacin como un semforo. Subir o bajar un semforno es una operacin de muy bajo nivel que obliga al programador a tratar los detalles de la exclusin mutua, la gestin de la regin crtica, la recuperacin en caso de fallo, etc, cuando opera sobre datos compartidos. Lo que nos gustara en un entorno de datos compartidos y con componentes suscepti-bles de fallo es disponer de primitivas de manipulacin de datos de ms alto nivel que permitan al programador: 1. Concentrarse en el problema, ignorando que los datos son accedidos de forma concurrente 2. Ignorar que un fallo puede dejar los datos en un estado inconsistente. Estas primitivas se utilizan ampliamente en los sistemas distribuidos (su finalidad es compartir datos y recursos y tienen ms posibilidades de fallo) y se llaman transacciones atmicas. El uso de las transacciones se remonta a los aos 60 cuando los datos se almacenaban en cintas magnticas. Una base de datos resida en una cinta. que se llamaba el fichero maestro. Las actualizaciones residan en una o ms cintas (por ejemplo las ventas diarias o semanales) llamadas ficheros de movimientos. Maestro y movimientos se montaban en el computador para producir un nuevo fichero maestro, que sera utilizado al da o a la semana siguiente con nuevos ficheros de movimientos. La ventaja de este mtodo -no reconocida suficientemente en aquellos aos- es que si el programa que llevaba a cabo las actualizaciones fallaba, se produca una cada en la alimentacin elctirica, etc y el proceso de actualizacin se interrumpa, siempre se poda descartar la nueva cinta que haba quedado a medias y volver sobre el maestro y las actualizaciones para generar de nuevo el fichero maestro. As, una actualizacin del maestro proceda correctamente hasta el final o no se modificaba en absoluto. Esta propiedad era una transaccin atmica sobre el objeto fichero maestro. Consideremos ahora una aplicacin bancaria que realiza una retirada de una cantidad de una cuenta y el ingreso correspondiente en otra cuenta distinta. Si el computador falla despus de la retirada y antes del ingreso, el dinero se desvanece. Puede que ambas cuentas residan en distintas mquinas y el fallo se deba a una prdida de la conexin telefnica entre ambas operaciones. Sera necesario agrupar ambas operaciones en una transaccin atmica como en el ejemplo de la cinta magntica que garantizase que la operacin se realiza completamente o no se realiza. La clave reside en volver al estado inicial de las cuentas si es que se ha producido un fallo en mitad del proceso. Esta habilidad es proporcionada por las transacciones atmicas. 3.4.2 Servicios transaccionales Conviene examinar la aplicacin bancaria anterior en el contexto del modelo cliente-servidor. Cuando decimos que un servidor porporciona operaciones atmicas significa que el efecto de desarrollar una operacin en beneficio del cliente: Est libre de interferencia de las operaciones realizadas en beneficio de otros clientes Bien la operacin concluye completamente o no tiene efecto alguno si el servidor falla.Una transaccin entre un cliente y un servidor es una secuencia de interacciones. El servidor bancario proporciona las operaciones Depsito, Retirada, Balance, Total Sucursal?. sobre una serie de objetos, en este caso cuentas: Depsito(Cuenta, Cantidad) Deposita la cantidad Cantidad en la cuenta CuentaRetirada(Cuenta, Cantidad) Retira la cantidad Cantidad de la cuenta Cuenta 18. Balance(Cuenta) CantidadDevuelve el balance de la cuenta CuentaTotal Sucursal e TotalDevuelve la suma de todos los balancesConsideremos un cliente que quiere realizar una serie de operaciones sobre las cuentas A, B, C. La primera operacin transfiere 100 pesetas de A a B. La segunda transfiere 200 pesetas de C a B: Transaccin: T: Retirada(A, 100); Depsito(B, 100); Retirada(C, 200); Depsito(B, 200); End Transaccin?(T) Como vemos, desde el punto de vista del cliente, una transaccin es una secuencia de operaciones que se realizan en un slo paso, llevando al servidor de un estado consistente a otro. El cliente no es consciente de que otros clientes pueden realizar operaciones sobre las cuentas A y B. A un servidor de este tipo se le conoce como servidor transaccional o que provee de un servicio transaccional. En un servicio transaccional, el cliente, cuando inicia una transaccin con el servidor, emite la peticin Abrir Transaccin? y el servidor le devuelve un indentificador de transaccin. Este indentificador ser usado en las operaciones siguientes. El cliente notifica al servidor el final de la secuencia de operaciones mediante la primitiva Cierra Transaccin?. Abrir Transaccin n Trans Arranca en el servidor una nueva transaccin y devuelve un nico identificador de transaccin o TID, que ser usado como parmetro en el resto de las operaciones de la transaccinCerrar Transaccin?(Trans) r (Compromiso, Aborto) Termina la transaccin. Si devuelve un compromiso, indica que la transaccin se ha comprometido (se ha realizado en su totalidad). Si devuelve un valor de Aborto, la transac-cin no se ha realizado.Abortar Transaccin?(Trans)Aborta la transaccinLa transaccin puede abortar por varias razones. Entre ellas la naturaleza misma de la transaccin y su desarrollo, conflictos con otra transaccin o el fallo de procesos o mquinas. La transaccin puede ser abortada, tanto por el cliente como por el servidor. Cuando el servidor decide unilateralmente abortar la transaccin en curso, la operacin en curso devuelve un cdigo de error como SERVER_ABORT. Veamos cual es el comportamiento de cliente y servidor en presencia de fallos: Fallo en el servidor Si un servidor transaccional falla inesperadamente, cuando vuelve a arrancar, aborta toda transaccin no comprometida utilizando un procedimiento de recuperacin para restaurar los valores de los items de datos provisionales a los valores definitivos producidos por la transaccin comprometida ms recientemente previa al fallo. Replica al cliente la operacin solicitada con un valor SERVER_ABORT. Otra posibilidad es que el cliente d un plazo de respuesta al servidor para cada operacin emitida. Si el servidor se recupera dentro del plazo, contina con la transaccin en curso en lugar de abortarla. Fallo en el cliente Si un cliente falla inesperadamente en el desarrollo de una transaccin, el servidor puede dar un plazo de expiracin a la transaccin. Si una nueva operacin de la transaccin no llega en ese plazo el servidor aborta la transaccin e inicia el procedimiento de recuperacin. 19. 3.4.3 Propiedades de las transacciones atmicas Las transacciones tienen cuatro propiedades fundamentales que se conocen por el acrnimo ACID: Atomicidad, Consistencia, serializabilidad o aislamiento (Isolation) y Durabilidad. 3.4.3.1 Atomicidad La atomicidad garantiza que la transaccin procede hasta que se completa o no se realiza en absoluto. Si se completa, esto ocurre en una accin indivisible e instantnea. Mientras una transaccin est en progreso, otros procesos, estn o no estn implicados en transacciones, no pueden ver los estados intermedios. Por ejemplo, supongamos una transaccin que se ocupa de aadir octetos a un fichero de 10 octetos. Mientras la transaccin esta en curso, otro proceso debe ver un fichero de slo 10 bytes. Cuando la transaccin se compromete, el fichero instantnemente aparece con su nuevo tamao. Un sistema de ficheros que garantiza este comportamiento es un sistema de ficheros transaccional. La mayora de los sistemas de ficheros no son transaccionales. 3.4.3.2 Consistencia La propiedad de la consistencia obliga cumplir ciertos invariantes de los datos del servidor. Por ejemplo, como resultado de una transferencia interna, una sucursal bancaria debe mantener el mismo dinero en su saldo que antes de que la transaccin se realice. La consistencia de los datos puede ser violada por el cliente si las operaciones que emite no son consistentes y por el servidor si no dispone de un adecuado mecanismo de control de concurrencia. Si las operaciones de forman una transaccin T que emite un cliente son consistentes, el servidor garantiza que la consistencia de los datos que T comparte con otra transaccin U no va ser violada por la concurrencia de las operaciones de U. 3.4.3.3 Serializabilidad La tercera propiedad dice que las transacciones deben ser aisladas. Aislada significa transacciones concurrentes en un servidor no interfieren las unas con las otras. Una forma de lograr el aislamiento es anular la concurrencia del servidor de modo que ejecute las transacciones de forma estrictamente secuencial, una tras otra. El objetivo de un servidor, sin embargo es maximizar sus prestaciones, algo que pasa por la atencin concurrente al mayor nmero de transacciones posible. Esto significa que si un servidor est atendiendo a dos o ms transacciones simultneamente que operan sobre datos compartidos por los clientes -un fichero, por ejemplo-, el servidor transaccional debe garantizar que el resultado final de estos datos es aquel que produce una realizacin estrictamente secuencial de las transacciones. Esta realizacin, no obstante, es decidida arbitrariamente por el servidor. Supongamos que un servidor transaccional mantiene una variable x que es accedida por tres clientes. Las transacciones de los clientes en un momento dado son las siguientes: Proceso 1: Abrir Transaccin; x := 0; x := x + 1; Cerrar Transaccin;Proceso 2:Abrir Transaccin; x := 0; x := x + 2; Cerrar Transaccin; Proceso 3: Abrir Transaccin; x := 0; x := x + 3; Cerrar Transaccin; Las peticiones de las distintas transacciones llegan al servidor entrelazadas. A cada secuencia de ejecucin de las peticiones por parte del servidor se le llama entrelazado o planificacin. Si el servidor es transaccional, no todas las planificaciones son vlidas. En la tabla que sigue vemos tres planificaciones posibles, donde el tiempo transcurre hacia la derecha:Planificacin 1x := 0; x := x + 1; x := 0; x := x + 2; x := 0;x := x + 3; legal Planificacin 2x := 0; x := 0; x := x + 1; x := x + 2; x := 0; x := x + 3; legal 20. Planificacin 3 x := 0; x := 0;x := x + 1;x := 0; x := x + 2;x := x + 3; ilegal tiempoEn la planificacin 1 las transacciones son ejecutadas de forma estrictamente secuencial, y el valor final es 3. Decimos que esta planificacin ha sido serializada. La planificacin 2 no es serializada, pero es legal por que, al final, x toma un valor que podra haber sido alcanzado por una planificacin estrictamente secuencial. La planificacin 3 es ilegal, ya que x termina con un valor de 5, valor que imposible alcanzar con una planificacin serializada.Equivalencia serial Si un entrelazado de dos o ms transacciones tiene el mismo efecto sobre los datos que alguna ejecucin serializada de dichas transacciones decimos que el entrelazado es serialmente equivalente. La planificacin 2 de la figura es serialmente equivalente.3.4.3.4 DurabilidadUna transaccin debe ser durable. Esta propiedad establece que si un servidor compromete una transaccin -por ejemplo con una rplica a una primitiva Cerrar Transaccin(Trans)que devuelva el valor Compromiso-, no importa lo que ocurra, los cambios son ya permanentes. Ningn fallo despus del compromiso puede desacer los resultados o causar su desaparicin, con la consiguiente confusin posterior en el cliente.2.3 Bibliografa [Cou95] Coulouris A. et al.,Distributed Systems,2nd. Edition. Addison-Wesley, 1995.[Tan95] Tanenbaum, A.,Distributed Operating Systems,Prentice-Hall, 1995.[Cou94] Coulouris, G., Distributed Systems, Concepts and Design, Second Edition, Addison-Wesley, 1994.[Gra93] Gray, J., Reuter, A., Transaction Processing, Concepts and Techniques, Morgan Kaufmann Publishers, 1993. [Lam78] Lamport, L., Time, Clocks, and the Ordering of Events in a Distributed System, Communications of the ACM, Number 7, Volume 21, July, 1978. [Lis93] Liskov, B., Practical uses of syncronized clocks in distributed systems, Distributed Computing, No. 6, pp. 211219, 1993.2.1.1. Comunicacin con los clientes-Servidor (Socket)Origen de los socket tuvo lugar en una variante del sistema operativo Unix conocida como BSD Unix. En la universidad de Berkeley, en los inicios del Internet, pronto se hizo evidente que los programadores necesitaran un medio sencillo y eficaz para escribir programas capaces de intercomunicarse entre s. Esta necesidad dio origen a la primera especificacin e implementacin de sockets. Cliente-Servidor es el modelo que actualmente domina el mbito de comunicacin, ya que descentraliza los procesos y los recursos. Es un Sistema donde el cliente es una aplicacin, en un equipo, que solicita un determinado servicio y existe un software, en otro equipo, que lo proporciona. 21. Los servicios pueden ser; a)Ejecucin de un programa. b)Acceso a una Base2.1.2 comunicacion con rpcRCP (REMOTE PROCEDURE CALL)El mecanismo general para las aplicaciones cliente-servidor se proporciona por el paquete Remote Procedure Call (RPC). RPC fue desarrollado por Sun Microsystems y es una coleccin de herramientas y funciones de biblioteca. Aplicaciones importantes construidas sobre RPC son NIS, Sistema de Informacin de Red y NFS, Sistema de Ficheros de Red. Un servidor RPC consiste en una coleccin de procedimientos que un cliente puede solicitar por el envo de una peticin RPC al servidor junto con los parmetros del procedimiento. El servidor invocar el procedimiento indicado en nombre del cliente, entregando el valor de retorno, si hay alguno. Para ser independiente de la mquina, todos los datos intercambiados entre el cliente y el servidor se convierten al formato External Data Representation (XDR) por el emisor, y son reconvertidosa la representacin local por el receptor. RPC confa en sockets estandard UDP y TCP para transportar los datos en formato XDR hacia el host remoto. Sun amablemente a puesto RPC en el dominio pblico; se describe en una serie de RFCs.La comunicacin entre servidores RPC y clientes es un tanto peculiar. Un servidor RPC ofrece una o ms colecciones de procedimientos; cada conjunto se llama un programa y es idenficado de forma nica por un nmero de programa. Una lista que relaciona nombres de servicio con nmeros de programa se mantiene usualmente en /etc/rpc. En esta figura, la llamada remota toma 10 pasos, en el primero de los cuales el programa cliente (o procedimiento) llama al procedimiento stub enlazado en su propio espacio de direcciones. Los parmetros pueden pasarse de la manera usual y hasta aqu el cliente no nota nada inusual en esta llamada ya que es una llamada local normal. El stub cliente rene luego los parmetros y los empaqueta en un mensaje. Esta operacin se conoce como reunin de argumentos (parameter marshalling). Despus que se ha construido el mensaje, se lo pasa a la capa de transporte para su transmisin (paso 2). En un sistema LAN con un servicio sin conexiones, la entidad de transporte probablemente slo le agrega al mensaje un encabezamiento y lo coloca en la subred sin mayor trabajo (paso 3). En una WAN, la transmisin real puede ser ms complicada. Cuando el mensaje llega al servidor, la entidad de transporte lo pasa al stub del servidor (paso 4), que desempaqueta los parmetros. El stub servidor llama luego al procedimiento servidor (paso 5), pasndole los parmetros de manera estndar. El procedimiento servidor no tiene forma de saber que est siendo activado remotamente, debido a que se lo llama desde un procedimiento local que cumple con todas las reglas estndares. nicamente el stub sabe que est ocurriendo algo particular. Despus que ha completado su trabajo, el procedimiento servidor retorna (paso 6) de la misma forma en que retornan otros procedimientos cuando terminan y, desde luego, puede retornar un resultado a un llamador. El stub servidor empaqueta luego el resultado en un mensaje y lo entrega a la interfaz con transporte (paso 7), posiblemente mediante una llamada al sistema, al igual que en el paso 2. Despus que la respuesta retorna a la mquina cliente (paso 8), la misma se entrega al stub cliente (paso 9) que desempaqueta las respuestas. Finalmente, el stub cliente retorna a su llamador, el procedimiento cliente y cualquier valor devuelto por el servidor en el paso 6, se entrega al cliente en el paso 10. El propsito de todo el mecanismo de la Fig.1 es darle al cliente (procedimiento cliente) la ilusin de que est haciendo una llamada a un procedimiento local. Dado el xito de la ilusin, ya que el cliente no puede saber que el 22. servidor es remoto, se dice que el mecanismo es transparente. Sin embargo, una inspeccin ms de cerca revela algunas dificultades en alcanzar la total transparencia. 2.1.3 comunicacion en grupo La comunicacin se clasifica deacuerdo al numero de usuarios alos que se le a enviado el mensaje.-BROADCAST O DIFUSION FORZADA un nodo emite todos los escuchan y solo contesta a quien va dirigido el mensaje -MULTICAST se entrega el msj a todos los anfitriones HOST que estn compuestos de ciertas caractersticas. -UNICAST o POINTCAST un nodo emite y otro recibe, solo escucha aquel a quien se dirigi el msj. Una clasificacin adicional es la realizada en base a grupos -LISTAS DE DESTINARIOS se tiene una lista de aquellos alos que se les enviara el mensaje. -IDENTIFICADOR DE GRUPO se forman grupos y el msj es dirigido solo a los miembros de ese grupo. -PREDICADOR DE PERTENENCIA se enva y otro recibe, solo escucha aquel a quien se dirigi el mensaje. 2.1.4 tolerancia a fallos La difusin de los sistemas distribuidos incrementa la demanda de sistemas que esencialmente nunca fallen [25, Tanenbaum].Los sistemas tolerantes a fallos requerirn cada vez ms una considerable redundancia en hardware, comunicaciones, software, datos, etc. La rplica de archivos sera un requisito esencial. Tambin debera contemplarse la posibilidad de que los sistemas funcionen an con la carencia de parte de los datos. Los tiempos de fallo aceptables por los usuarios sern cada vez menores.2.2 sincronizacion sistemas distribuidosEn sistemas con una nica CPU las regiones crticas, la exclusin mutua y otros problemas de sincronizacin son resueltos generalmente utilizando mtodos como semforos y monitores. Estos mtodos no se ajustan para ser usados en sistemas distribuidos ya que invariablemente se basan en la existencia de una memoria compartida.No es posible reunir toda la informacin sobre el sistema en un punto y que luego algn proceso la examine y tome las decisiones.En general los algoritmos distribuidos tienen las siguientes propiedades:1)- la informacin relevante est repartida entre muchas mquinas 2)- los procesos toman decisiones basadas solamente en la informacin local disponible 3) - debera poder evitarse un solo punto que falle en el sistema 4)- no existe un reloj comn u otro tiempo global exacto 23. Si para asignar un recurso de E/S un proceso debe recolectar informacin de todos los procesos para tomar la decisin esto implica una gran carga para este proceso y su cada afectara en mucho al sistema. Idealmente, un sistema distribuido debera ser ms confiable que las mquinas individuales. Alcanzar la sincronizacin sin la centralizacin requiere hacer cosas en forma distinta a los sistemas operativos tradicionales. 2.2.1 relojes fisicos El algoritmo de Lamport proporciona un orden de eventos sin ambigedades, pero [25, Tanenbaum]:Los valores de tiempo asignados a los eventos no tienen porqu ser cercanos a los tiempos reales en los que ocurren. En ciertos sistemas (ej.: sistemas de tiempo real ), es importante la hora real del reloj: Se precisan relojes fsicos externos (ms de uno). Se deben sincronizar: Con los relojes del mundo real. Entre s. La medicin del tiempo real con alta precisin no es sencilla. Desde antiguo el tiempo se ha medido astronmicamente.Se considera el da solar al intervalo entre dos trnsitos consecutivos del sol, donde el trnsito del sol es el evento en que el sol alcanza su punto aparentemente ms alto en el cielo. El segundo solar se define como 1 / 86.400 de un da solar. Como el perodo de rotacin de la tierra no es constante, se considera el segundo solar promedio de un gran nmero de das. Los fsicos definieron al segundo como el tiempo que tarda el tomo de cesio 133 para hacer 9.192.631.770 transiciones: Se tom este nmero para que el segundo atmico coincida con el segundo solar promedio de 1958. La Oficina Internacional de la Hora en Pars (BIH) recibe las indicaciones de cerca de 50 relojes atmicos en el mundo y calcula el tiempo atmico internacional (TAI). Como consecuencia de que el da solar promedio (DSP) es cada vez mayor, un da TAI es 3 mseg menor que un DSP: La BIH introduce segundos de salto para hacer las correcciones necesarias para que permanezcan en fase: El sistema de tiempo basado en los segundos TAI. El movimiento aparente del sol. Surge el tiempo coordenado universal (UTC). El Instituto Nacional del Tiempo Estndar (NIST) de EE. UU. y de otros pases: Operan estaciones de radio de onda corta o satlites de comunicaciones. Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5 mseg, etc.). Se deben conocer con precisin la posicin relativa del emisor y del receptor: Se debe compensar el retraso de propagacin de la seal. Si la seal se recibe por mdem tambin se debe compensar por la ruta de la seal y la velocidad del mdem. Se dificulta la obtencin del tiempo con una precisin extremadamente alta.2.2.2 relojes logicosLas computadoras poseen un circuito para el registro del tiempo conocido como dispositivo reloj [25, Tanenbaum].Es un cronmetro consistente en un cristal de cuarzo de precisin sometido a una tensin elctrica que: Oscila con una frecuencia bien definida que depende de: o Al forma en que se corte el cristal. o El tipo de cristal. o La magnitud de la tensin. A cada cristal se le asocian dos registros: 24. o Registro contador.o Registro mantenedor. Cada oscilacin del cristal decrementa en 1 al contador. Cuando el contador llega a 0:o Se genera una interrupcin.o El contador se vuelve a cargar mediante el registro mantenedor. Se puede programar un cronmetro para que genere una interrupcin x veces por segundo. Cada interrupcin se denomina marca de reloj.Para una computadora y un reloj: No interesan pequeos desfasajes del reloj porque:o Todos los procesos de la mquina usan el mismo reloj y tendrn consistencia interna.o Importan los tiempos relativos.Para varias computadoras con sus respectivos relojes: Es imposible garantizar que los cristales de computadoras distintas oscilen con la misma frecuencia. Habr una prdida de sincrona en los relojes (de software), es decir que tendrn valores distintos al ser leidos.La diferencia entre los valores del tiempo se llama distorsin del reloj y podra generar fallas en los programas dependientes del tiempo. Lamport demostr que la sincronizacin de relojes es posible y present un algoritmo para lograrlo. Lamport seal que la sincronizacin de relojes no tiene que ser absoluta: Si 2 procesos no interactan no es necesario que sus relojes estn sincronizados. Generalmente lo importante no es que los procesos estn de acuerdo en la hora, pero s importa que coincidan en el orden en que ocurren los eventos.2.2.3 usos de la sincroninizacion manejo de cache comunicacion en grupo exclusion mutua eleccion transacciones atomicas e interbloqueo memoria cache En los sistemas de archivos convencionales, el fundamento para la memoria cach es la reduccin de la E/S de disco (lo que aumenta el rendimiento), en un SAD el objetivo es reducir el trfico en la red. Esquema Bsico, el concepto de memoria cach es sencillo, si los datos necesarios para satisfacer la solicitud de acceso no se encuentran en la memoria cache, se trae una copia de servicio al usuario y los accesos se llevan a cabo con la copia de memoria cach. La idea es conservar all los bloques de disco de acceso mas reciente, para as manejar localmente los accesos repetidos a la misma informacin y no aumentar el trfico de la red. Se utiliza una poltica de reemplazo (por ejemplo, la de utilizacin menos reciente) para limitar el tamao de la memoria cach. Polticas de Actualizacin, la poltica empleada para escribir los bloques de datos modificados en la copia maestra del servidor tiene un efecto decisivo sobre la 25. confiabilidad y el rendimiento del sistema. La poltica mas sencilla consiste en escribir los datos directamente en el disco tan pronto se coloquen en una memoria cach. La ventaja de la escritura directa es su confiabilidad, ya que se pierde poca informacin si un sistema cliente falla. Sin embargo, esta poltica requiere que cada acceso de escritura espere hasta que se enve la informacin al servidor, por lo que representa una escritura de escaso rendimiento. La memoria cach con escritura directa equivale a usar el servicio remoto para accesos de escritura y explotar la memoria cache nicamente para accesos de lectura. NFS proporciona el acceso de escritura directa. Consistencia, una maquina cliente se enfrenta al problema de decidir si una copia de datos en memoria cach local es consistente con la copia maestra ( y por tanto, puede usarse). Si la maquina cliente determina que sus datos en memoria cach estn desfasados, ya no pueden servir para los accesos y hay que colocar en la memoria cach una copia actualizada de los datos. Existen dos enfoques para verificar la validez de los datos en memoria cach ..: Enfoque iniciado por el cliente, el cliente inicia una comprobacin de validez, en la cual se pone en contacto con el servidor y comprueban si los datos locales son consistentes con la copia maestra. Enfoque iniciado por el servidor, el servidor anota, para cada cliente, las partes de los archivos que coloca en memoria cache, y cuando detecta una inconsistencia, debe reaccionar. Una posible fuente inconsistencia ocurre cuando dos clientes, que trabajan en modos conflictivos, colocan en memoria cach un archivo.Comunicacin en grupos (Algoritmos Para la Sincronizacin de Relojes) Si una mquina tiene un receptor de UTC, todas las mquinas deben sincronizarse con ella. Si ninguna mquina tiene un receptor de UTC: Cada mquina lleva el registro de su propio tiempo. Se debe mantener el tiempo de todas las mquinas tan cercano como sea posible. Se supone que cada mquina tiene un cronmetro que provoca una interrupcin h veces por segundo. Cuando el cronmetro se detiene, el manejador de interrupciones aade 1 a un reloj en software. El reloj en software mantiene un registro del nmero de marcas (interrupciones) a partir de cierta fecha acordada antes; al valor de este reloj se lo llama C. Algoritmo de Cristian Es adecuado para sistemas en los que: Una mquina tiene un receptor UTC, por lo que se la llama despachador del tiempo. El objetivo es sincronizar todas las mquinas con ella. Cada mquina enva un mensaje al servidor para solicitar el tiempo actual, peridicamente, en un tiempo no mayor que prontamente con un mensaje que contiene el tiempo actual CUTC. Cuando el emisor obtiene la respuesta puede hacer que su tiempo sea CUTC. Un gran problema es que el tiempo no puede correr hacia atrs: CUTC no puede ser menor que el tiempo actual C del emisor. La atencin del requerimiento en el servidor de tiempos requiere un tiempo del manejador de interrupciones. Tambin se debe considerar el tiempo de transmisin. El cambio del reloj se debe introducir de manera global: Si el cronmetro genera 100 interrupciones por segundo:Cada interrupcin aade 10 mseg al tiempo.Para atrasar solo agregara 9 mseg.Para adelantar agregara 11 mseg.La correccin por el tiempo del servidor y el tiempo de transmisin se hace midiendo en el emisor: El tiempo inicial (envo) T0. El tiempo final (recepcin) T1. Ambos tiempos se miden con el mismo reloj. El tiempo de propagacin del mensaje ser (T1 - T0) / 2. Si el tiempo del servidor para manejar la interrupcin y procesar el mensaje es I: El tiempo de propagacin ser (T1 - T0 - I) / 2. Para mejorar la precisin: Se toman varias mediciones. Se descartan los valores extremos. Se promedia el resto. El tiempo de propagacin se suma al tiempo del servidor para sincronizar al emisor cuando ste recibe la respuesta. Algoritmo de Berkeley 26. En el algoritmo de Cristian el servidor de tiempo es pasivo. En el algoritmo de Berkeley el servidor de tiempo: Es activo. Realiza un muestreo peridico de todas las mquinas para preguntarles el tiempo. Con las respuestas: Calcula un tiempo promedio. Indica a las dems mquinas que avancen su reloj o disminuyan la velocidad del mismo hasta lograr la disminucin requerida.Es adecuado cuando no se dispone de un receptor UTC. Algoritmos con Promedio Los anteriores son algoritmos centralizados. Una clase de algoritmos descentralizados divide el tiempo en intervalos de resin