SISTEMAS OPERATIVOS 2

Unidad 2 Comunicacin en los Sistemas Operativos Distribuidos

Cd. Victoria, Tamps.

Mayo 2012

2.1.1 EL MODELO CLIENTE SERVIDOR

Los protocolos con capas a lo largo de las lneas OSI se ven como una buena forma de organizar un sistema distribuido. Un emisor establece una conexin con el receptor y bombea los bits, que llegan sin error y en orden al receptor.

Sin embargo se crean unos encabezados genera un costo excesivo. Cada que se enva un mensaje se procesa cerca de media docena de capas que generan y aaden encabezados en el camino hacia abajo o elimina y examina el encabezado en el camino hacia arriba.

Clientes y Servidores
Con la idea de estructurar el sistema operativo como un grupo de procesos en cooperacin, llamados servidores, que ofrezcan servicios a los usuarios llamados clientes. Una maquina puede ejecutar un proceso o varios clientes, varios servidores o combinaciones de ambos.

Para evitar un gasto excesivo en los protocolos como OSI o TCP/IP lo usual es que se base en un protocolo solicitud/respuesta sencillo y sin conexin.

El cliente enva un mensaje de solicitud al servidor para pedir cierto servicio, el servidor hace el trabajo hace el trabajo y regresa los datos solicitados o un cdigo de error para indicar que el trabajo no se pudo llevar a cabo.

UN EJEMPLO CLIENTE/SERVIDOR
Tanto el cliente como el servidor comparten algunas definiciones. Las dos constantes MAX_PATH y BUF_SIZE, determinan el tamao de los dos arreglos necesarios en el mensaje. La primera indica el numero de caracteres que puede tener un nombre de archivo.

La segunda fija la cantidad de datos que se pueden leer o escribir en una operacin, al establecer el tamao del buffer.
La siguiente constante FILE_SERVER proporciona la direccin en la red del servidor de archivos para que los clientes puedan ver los mensajes.

 El segundo grupo de constantes define los nmeros de operacin, necesarios para garantizar que el cliente y el servidor queden de acuerdo en el cdigo que un RED representara. Cada respuesta tiene un cdigo de resultado, si la operacin tiene xito es frecuente que este cdigo contenga informacin til, si no existe un valor por regresar se utiliza el valor OK.

 Si la operacin fracasa el cdigo de resultado lo indica mediante cdigos tales como E_BAD_OPCODE, E_BAD_PARAM, etc. Llegamos a la definicin del propio mensaje, en un sistema real tal vez no se tenga un formato fijo de mensaje.

 Los campos source y dest identifican el emisor y el receptor. El campo opcode es: CREATE, READ, WRITE o DELETE. Los campos count y offset se utilizan como parmetros en caso de que el servidor tenga un desarrollador posterior.

 El campo result no se utiliza para las solicitudes del cliente al servidor, sino que conserva el valor resultado en las respuestas del servidor al cliente. Tenemos dos arreglos: name, contiene el nombre del archivo al que se tiene acceso; y data, que contiene los datos que se envan de regreso como respuesta a un READ.

Direccionamiento
Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la direccin de este. El servidor de archivos tiene asignada una direccin numrica, si este se refiere a una maquina determinada, el ncleo emisor puede extraerla de la estructura de mensajes y utilizarla como direccin fsica para enviar el mensaje al servidor.

El ncleo emisor construye un marco con esta direccin como enlace de datos y colocar el marco en la LAN para que la tarjeta de interfaz vea el marco y la reconozca como propia direccin y la acepte. Otro tipo de direccionamiento es el que enva mensajes a los procesos en vez de las maquinas.

En este se utilizan nombres con dos partes, para especificar tanto la maquina como el proceso. As, 243,4 o 243@4 para especificar tanto la maquina (243) como el proceso (4).

Otro mtodo consiste en asignarle a cada proceso una direccin que no contenga un numero de maquinas, lo cual se realiza mediante un asignador centralizado de direcciones a los procesos que mantenga solo un contador. La desventaja es que no se pueden extender a los grandes sistemas. Otro proceso consiste en dejar que cada proceso elija el propio identificador, en una LAN que soporte transmisiones el emisor puede transmitir un paquete especial de localizacin. Este ser recibido por todas las maquinas de la red, los ncleos verifican y en caso de que sea su direccin regresa un mensaje aqu estoy con su direccin en la red.

Primitivas con Bloqueo vs. sin Bloqueo

Las primitivas con bloqueo: cuando un proceso llama a send, especifica un destino y un buffer donde enviarlo, el proceso emisor se bloquea y la instruccin que sigue a la llamada de send no se ejecuta hasta que el mensaje se enva en su totalidad. Una llamada a receive no regresa el control hasta que en realidad se reciba un mensaje y este se coloque en el buffer de mensajes, el proceso se suspende hasta que llega un mensaje, incluso aunque tarde varias horas.

Las primitivas sin bloqueo: si send no tiene bloqueo regresa de inmediato el control a quien hizo la llamada antes de enviar el mensaje. La ventaja es que el proceso emisor puede continuar su computo en forma paralela con la transmisin del mensaje en vez de estar inactivo. Una desventaja de esta ventaja es que el emisor no puede modificar el buffer de mensajes sino hasta que el mensaje haya sido enviado. El proceso emisor no tiene idea de cuando termine la transmisin por lo que no sabe cuando es seguro volver a usar el buffer.

Existen dos formas de salir del problema: El ncleo copia el mensaje a un buffer interno as permite que el proceso contine, la desventaja es que cada mensaje se copia dos veces (en el buffer del ncleo y posteriormente en un buffer en el hardware). Esto hace que el desempeo del sistema se reduzca considerablemente.

La segunda opcin es interrumpir al emisor cuando se envi el mensaje para informarle que el buffer ya esta disponible, este ahorra mas tiempo ya que no necesita copias. Pero las interrupciones a nivel usuario hacen que la programacin sea truculenta, difcil y sujeta a condiciones de competencia.

Primitivas almacenadas en buffer vs. no almacenadas

Primitivas no almacenadas: esto significa que una direccin se refiere a un proceso especifico. Una llamada receive indica al ncleo de la maquina donde se ejecuta esta que el proceso llamo escucha a la direccin addr y esta preparado para recibir un mensaje enviado a esta direccin.

Se dispone de un buffer de mensajes, cuando el mensaje llega, el ncleo receptor lo copia al buffer y elimina el bloqueo del proceso receptor. Esto funciona mientas el servidor llame a receive antes de que el cliente llame a send. Esta llamada indica al ncleo del servidor la direccin que utiliza el servidor y la posicin donde colocar el mensaje que esta por llegar.

Esto tiene sus desventajas ya que si el cliente fracasa un numero suficiente de intentos, el ncleo del cliente se podra dar por vencido y concluir que el servidor esta descompuesto o que la direccin no es valida. Para enfrentar este problema puede crearse un cronometro pero si el tiempo expira antes de que ocurra un receive apropiado el mensaje se descarta.

Aunque este mtodo reduce la probabilidad de que el mensaje se pierda, se necesitan los buffers, una manera de enfrentar el manejo de estos es definir una nueva estructura de datos llamada:
Buzn: proceso interesado en recibir mensajes, el ncleo especifica una direccin en la cual busca los paquetes de la red.

La llamada a receive elimina un mensaje del buzn o se bloque si no hay mensajes presentes. El ncleo sabe que hacer con los mensajes que lleguen y tiene un lugar para colocarlos , esta tcnica se conoce como primitiva con almacenamiento en buffers.

Sin embargo los buzones son finitos, cuando llega un mensaje a buzn totalmente ocupado, el ncleo se enfrenta de nuevo a la eleccin de mantener el mensaje pendiente por un momento o bien descartar dicho mensaje

Primitivas confiables vs. no confiables.

Como es usual los mensajes se pueden perder y esto afecta la semntica del modelo de transferencia de mensajes. Cuando un cliente enva un mensaje, se suspende hasta que el mensaje ha sido enviado pero no existe ninguna garanta de que el mensaje haya sido entregado.

Existen tres distintos enfoques de este problema: 1er. Consiste en volver a definir la semntica de send para hacerla no confiable. El sistema no da garanta alguna acerca de la entrega de los mensajes, la implantacin de una comunicacin confiable se deja por completo en manos de los usuarios.

2o. Exige que el ncleo de la maquina receptora envi un reconocimiento al ncleo de la maquina emisora. Solo cuando reciba este reconocimiento, el ncleo emisor liberara al cliente, el reconocimiento va de ncleo a ncleo, ni el cliente ni el servidor ven alguna vez un reconocimiento. 3er. Aprovecha el hecho de que la comunicacin cliente-servidor se estructura como solicitud del cliente al servidor. Aqu el cliente se bloquea despus de enviar el mensaje, el ncleo del servidor no enva de regreso un reconocimiento si no que la misma respuesta funciona como tal.

Implantacin del modelo cliente-servidor.

Virtualmente todas las redes tienen un tamao mximo de paquete, los mensajes que exceden esta cantidad deben dividirse en varios paquetes y enviarse de manera independiente. Algunos de estos se pierden o mezclan o en incluso pueden llegar en orden equivocado.

Pero basta con asignar un numero de mensaje a cada uno de ellos y colocarlo dentro de cada paquete perteneciente al mismo junto con un numero secuencial que d el orden de los paquetes. Una estrategia hablando de los reconocimientos es que debe existir uno de cada paquete individual, otra es solo agradecer los mensajes completos.

La primera tiene la ventaja de que si se pierde un paquete solo hay que retransmitirlo, per tiene la desventaja de que se necesitan mas paquetes en la red.
La segunda tiene la ventaja de menos paquetes, pero la desventaja de una recuperacin mas compleja cuando se pierde uno de ellos.

Otro aspecto es el protocolo subyacente utilizado en la comunicacin cliente-servidor.

El paquete REQ se utiliza para enviar un mensaje de solicitud de un cliente a un servidor. El paquete REP regresa los resultados del servidor al cliente

El paquete ACK se utiliza en protocolos confiables para confirmar la recepcin correcta de un paquete anterior.
El paquete AYA se utiliza en ciertas ocasiones de modo que el cliente pueda preguntar al servidor que es lo que ocurre. Si la respuesta es IAA el ncleo del cliente sabe que todo esta bien, si no genera respuesta espera un poco e intenta de nuevo.

Existen dos razones por las que el paquete REQ no es aceptado:

1. El buzn al que se envi la solicitud este lleno, al enviar de regreso el paquete al ncleo del cliente, el ncleo del servidor puede indicar que la direccin es valida y que debe repetirse la solicitud mas tarde. 2. La direccin no pertenezca a ningn proceso o buzn y su repeticin posterior no ayudara en nada. Esta situacin tambin aparece cuando no se utiliza el almacenamiento en buffers y el servidor no esta bloqueado por el momento en una llamada receive.

El hecho de que el ncleo del servidor olvide incluso la existencia de la direccin entre llamadas a receive puede conducir a ciertos problemas.

Un servidor puede hacer una llamada cuya nica funcin ser registrar cierta direccin del ncleo, de esa forma al menos el ncleo puede decir la diferencia entre una direccin que nadie escucha y una que esta equivocada.

2.1.2 Llamada a un Procedimiento Remoto

La comunicacin se construye en base a Entrada/Salida, su objetivo es lograr que el computo Distribuido se vea como Centralizado, aunque esta no es la forma de lograrlo.

En 1984 Birrell y Nelson presentaron una forma de abordar la comunicacin en los SOD, permitiendo a los programas que llamen a procedimientos localizados en otras mquinas
As el programador no se preocupa de una transferencia de mensajes o de la E/S.

Posibles Problemas RPC

Utilizan espacios de direcciones distintos. Se deben transferir los parmetros y resultados, problema si las maquinas no son idnticas. Se pueden descomponer ambas maquinas y cada una con diversas fallas y diversos problemas.

Operacin bsica del RPC

Primero hay que entender el funcionamiento de una llamada convencional a un procedimiento. count = read(fd, buf, nbytes); fd: es un entero buf: es un arreglo de caracteres nbytes: es un entero

a) La pila antes de la llamada a read b) Coloca los parmetros en orden inverso, el ultimo en primer lugar c) Cuando read termina, coloca el valor de regreso en un registro, elimina las direcciones y da el control a quien hizo la llamada

Existen diferentes mecanismos para el paso de parmetros, la decisin de cual usar la toman los diseadores del sistema y es una propiedad fija del lenguaje.
Llamada por valor C, enteros y escalares Pascal, predefinido Llamada por referencia C, los arreglos Pascal, anteponiendo la palabra var en los parmetros especficos Ada, algunos lo utilizan Llamada con copia de restauracin

Ada, utilizada para los parmetros in out

Llamada por valor.- como fd o

nbytes solo se copia a la pila, para quien recibe la llamada, es tan solo una variable local ya iniciada, el procedimiento llamado puede modificarlo, sin que esto afecte el valor original de quien hizo la llamada.

es un apuntador a una variable(direccin), en lugar del valor de la variable, la cual se introduce en la pila. Si el procedimiento llamado utiliza este parmetro para guardar algo en el arreglo, esto s modifica el arreglo en el procedimiento que hizo la llamada.

Llamada por referencia.-

quien recibe la llamada copia la variable en la pila, como en la llamada por valor, y entonces la copia de regreso despus a la llamada, escribiendo sobre el valor original.

Llamada con copia/restauracin.-

Una llamada a un Procedimiento Remoto se realiza mediante los siguientes pasos:

resguardo del cliente de la manera usual. construye un mensaje y hace un sealamiento al ncleo.

1. El procedimiento cliente llama al

2. El resguardo del cliente

3. El ncleo enva el mensaje al

ncleo remoto.

4. El ncleo remoto proporciona

el mensaje al resguardo del servidor.

desempaca los parmetros y llama al servidor.

5. El resguardo del servidor

trabajo y regresa el resultado al resguardo.

6. El servidor realiza el

empaca el resultado en un mensaje y hace un sealamiento al ncleo.

7. El resguardo del servidor

mensaje al ncleo del cliente.

8. El ncleo remoto enva el

9. El ncleo del cliente da el

mensaje al resguardo del cliente.

10. El resguardo desempaca el

resultado y regresa al cliente.

Transferencia de Parmetros
La funcin del resguardo del cliente es tomar sus parmetros, empacarlos en un mensaje y enviarlos al resguardo del servidor. El empacamiento de parmetros en un mensaje se llama ordenamiento de parmetros.

Ejemplo

5 1 2

Calculo remoto de sum(4,7), toma 2 enteros y regresa su suma aritmtica

1. El resguardo del cliente toma sus dos parmetros y los coloca en un mensaje, tambin coloca el nombre o nmero del procedimiento por llamar. 2. Cuando el mensaje llega al servidor, el resguardo lo examina para ver cual procedimiento necesita y lleva a cabo la llamada apropiada.

3. Cuando el servidor termina su labor, su resguardo recupera el control.

4. Toma el resultado proporcionado por el servidor y lo empaca en un mensaje. 5. El mensaje se enva de regreso al resguardo del cliente, que lo desempaca y regresa el valor al procedimiento del cliente.

Si las mquinas son idnticas y todos los parmetros son escalares, este modelo funciona bien.

El problema surge en los sistemas de gran tamao, donde las maquinas pueden ser diferentes.

Mas Problemas RPC

* El tipo de cdigo de caracteres que

usan puede ser diferente en cada mquina. Si la representacin de enteros puede no ser similar, al igual que en los nmeros de punto flotante. Como se realiza la numeracin, little

endian(extremo menor) o big endian(extremo mayor).

Una forma de que se logre el procedimiento es dar un formato en especifico a cada tipo de dato, y luego disear un estndar de red o forma cannica, para enteros, caracteres, booleanos, punto flotante, etc. y pedir a todos los emisores que conviertan sus representaciones internas a esta forma durante el ordenamiento.

Problema en algunos casos ineficiente, ya que, solo aplica cuando los sistemas son diferentes, pero en caso de que sean iguales, tendrn que hacerse 2 conversiones no necesarias.
Little endian Big endian Necesita conversin Big endian Little endian Necesita conversin Little endian Little endian Conversin Innecesaria Big endian Big endian Conversin innecesaria

Para esto se busca otra solucin, cada cliente usa su formato original e indica en el primer byte del mensaje su formato, una vez que llega, el resguardo del servidor, analiza el primer byte y con esto considera o no hacer la conversin.
Cliente LITTLE ENDIAN
lit end A S O

Servidor BIG ENDIAN

big end

Cmo se transfieren los apuntadores..?

El resguardo del cliente sabe cuando un parmetro apunta a un arreglo de caracteres, supongamos que tambin conoce el tamao, entonces se copia el arreglo en el mensaje y se enva al servidor..

El resguardo del servidor puede llamar a este con un apuntador a este arreglo. Los cambios que realice el servidor afectaran al buffer de mensajes dentro del resguardo del servidor.
Cuando concluye, el mensaje original se enva de regreso al resguardo del cliente, quien lo copia de nuevo al cliente.

Una optimizacin de esto es, si el resguardo sabe si es parmetro de entrada o de salida hacia el servidor, puede eliminar una de las copias.
Si es de entrada (write) el arreglo no necesita volverse a copiar. Si es de salida, no necesita enviarse de regreso.

As, a cada procedimiento remoto se le asocia una especificacin, escrita en cierto lenguaje.

Conexin

Dinmica

Utilizada para que concuerden los clientes y los servidores. Su punto de partida es la especificacin formal del servidor: 1) indica el nombre del servidor, 2) el numero de versin y 3) una lista de procedimientos que proporciona.
1 2

bytes
Indican al servidor el nmero de bytes por transferir.

position
Indica el sitio del archivo donde se comenzara la lectura o escritura.

buf
Lugar donde el servidor coloca los datos solicitados por el cliente.

Se tienen los tipos de parmetros para cada procedimiento in, out o in-out.
In Se enva del cliente al servidor, indica al servidor el archivo que debe leer, escribir, crear o eliminar Out In-Out Se enva del cliente al Se enva del servidor, donde se le servidor al modifica y que cliente. despus se enva de regreso al cliente.

Cuando el servidor inicia su ejecucin, la llamada initialize exporta la interfaz del servidor, ste enva un mensaje a un programa llamado conector para darle a conocer su existencia. Esto se conoce como registro del servidor. Para registrarse, el servidor proporciona al conector: su nombre, nmero de versin, un identificador de 32bits y un asa para localizarlo(puede ser una direccin Ethernet, IP, X.500, un identificador ralo de procesos o alguna otra cosa.

Llamada Registro De Registro Bsqueda

Entrada Nombre, versin, asa, identificacin nica Nombre, versin, identificacin nica Nombre, versin

Salida

Asa, identificador nico

El cliente enva un mensaje al conector, donde solicita la importacin de la versin de la interfaz X, el conector verifica si uno o mas servidores ya han exportado esa interfaz con nombre y numero de versin.

El mtodo de exportacin e importacin de interfaces es altamente flexible.

Ventajas Puede manejar varios servidores con interface semejante. Desventajas Costo adicional en el tiempo generado por exportacin e importacin de interfaces.

El conector puede difundir los clientes de manera aleatoria en los servidores.

Puede ayudar en la autenticacin, especificando una lista predeterminada de usuarios. Puede hacer un muestreo peridico de los servidores. Verificas que cliente y servidor usen la misma versin de interfaz.

En SD grandes, el conector se puede convertir en cuello de botella.

Se necesitan muchos mensajes para mantener la sincronizacin y actualizacin de los conectores.

RPC SUS FALLAS

El cliente no puede localizar al servidor
El cliente no puede localizar un servidor adecuado. El servidor podra estar inactivo. El servidor actualiza su interfaz y empieza a utilizar nuevos resguardos, los cuales no podran concordar con los del cliente.

El cliente no puede localizar al servidor

Una posible solucin, es que el error provoque una excepcin, aunque esto tambin tiene sus desventajas:
No todos los lenguajes tienen excepciones o seales. Al escribir una excepcin se destruira la transparencia que queremos lograr de nuestro sistema distribuido.

Perdida de mensajes de solicitud

Hay que hacer que el ncleo inicie un cronmetro al enviar la solicitud. Si el tiempo se termina, el ncleo vuelve a cargar el mensaje; si ste se perdi, el servidor no notara la diferencia entre la retransmisin y el original.

Perdida de mensajes de respuesta

Si no llega la respuesta, hay que enviarla de nuevo, aunque el cliente puede llegar a pensar Se perdi la solicitud? Se perdi la respuesta? Ocurre que el servidor es lento?

Perdida de mensajes de respuesta

solicitud de 1024 bytes se puede ejecutar una y otra vez sin causar dao alguno. Aunque esto no funcionaria en cuestin de una cuenta bancaria, no podemos estar depositando seguidamente si ocurre un error y el cliente no se da cuenta de ello.

Solicitud idempotente.- una

Perdida de mensajes de respuesta Otro mtodo es mediante el registro del nmero secuencial de recepcin, el ncleo del servidor podr notar la diferencia entre una solicitud original y una retransmisin. Una proteccin adicional es un bit en el encabezado del mensaje para distinguir solicitudes adicionales de las retransmisiones.

Fallas del Servidor

Se relaciona con la idempotencia, aunque no se resuelve mediante nmeros secuenciales.

b) El sistema tiene que informar de la falla de regreso al cliente c) Solo se tiene que transmitir de nuevo la solicitud.

Fallas del Servidor

Existen 3 cosas que se pueden hacer en torno a este caso:

(garantiza que la RPC se ha relizado al menos una vez o ms) esperar hasta que el servidor vuelva a arrancar e intente realizar de nuevo la operacin, asi hasta recibir una respuesta.

Semntica al menos una a la vez:

Fallas del Servidor

(garantiza que la RPC se realiza a lo ms una vez , no ms) se da por vencida inmediatamente e informa la falla.
obtiene ayuda o alguna promesa) la RPC se realiza en cualquier lugar, va desde 0 hasta un nmero muy grande de veces.

Semntica a lo ms una a la vez:

No Garantizar Nada: (el cliente no

Fallas del Servidor

(garantiza que la RPC se realice una vez, sin falla alguna) no existe forma de garantizar esto en general.

Semntica de exactamente uno:

Las posibles fallas del servidor cambian de manera radical la naturaleza de la RPC y distingue de manera clara los sistemas con un procesador y los sistemas distribuidos.

Fallas del Cliente

enva una solicitud al servidor y esta falla antes de que el servidor responda. Desperdician los ciclos del CPU. Bloquean archivos o recursos valiosos(causa por la cual seria peligroso eliminarlo, ya que podra dejar archivos bloqueados permanentemente). Pueden crear confusin.

Hurfano: cuando se

Fallas del Cliente

Qu se puede hacer?
Exterminacin: Antes que el resguardo del
cliente envi un mensaje RPC, crea un registro donde indica que har, en un medio o disco. Despus al volver a arrancar, se verifica el contenido del registro y se elimina el hurfano.

numeradas en manera secuencial, cuando se reporten los hurfanos, sus respuestas contendrn un nmero de poca obsoleto, lo cual facilitara su deteccin.

Reencarnacin: Dividir el tiempo en pocas

Fallas del Cliente

mensaje de cierta poca, cada mquina revisa si tiene cmputos remotos, si es as, intenta localizar a su poseedor, en caso de que no lo encuentre se elimina.

Reencarnacin sutil: Cuando llega un

Expiracin: A cada RPC se le asigna una

cantidad estndar de tiempo T para que realice su trabajo. Si no lo puede terminar, solicita otro quantum. El problema es elegir un valor de T razonable.

Aspectos de la Implantacin

Protocolos RPC
Veremos los posibles protocolos a utilizar, aunque seria mejor contar con un protocolo exclusivo para RPC, lo cual podra ser poco aceptado y muy costoso, por lo que tenemos algunas opciones de protocolos: Protocolo sin Conexin (usado en SD instalados en edificios) Protocolo orientado a la conexin Protocolo IP y UDP

Protocolos RPC

Ventajas La comunicacin es ms fcil. Al enviar mensajes no hay que preocuparse por si ste se pierde. No hay que preocuparse por reconocimientos, eso lo maneja el Sw que soporta la conexin Desventajas Prdida en el desempeo El Sw adicional estorba El no perder los paquetes no es necesario, ya que las LAN son confiables.

Protocolo Orientado a la Conexin

Protocolos RPC

Protocolo IP UDP
Ventajas El protocolo ya ha sido diseado Se dispone de muchas implantaciones Paquetes que se envian y reciben en casi todos los sistemas UNIX Son soportados por muchas redes existentes Desventajas Su desempeo, ya que no se dise como un protocolo para usuario final El clculo en sus encabezados produce perdida de tiempo

Reconocimientos
Cuando las RPC grandes se dividen en pequeos paquetes, Deben reconocerse de manera individual?

establece que el cliente envi el paquete 0 con el primer 1K, espera un reconocimiento del servidor, y as enva el segundo 1K, espera el reconocimiento, etctera. Si un paquete se daa, no se recibe a tiempo un reconocimiento.

Protocolo detenerse y esperar,

Reconocimientos

Protocolo de chorro, establece que el cliente envi todos los paquetes tan pronto como pueda, el servidor reconoce todos los mensajes al recibir todos los paquetes, no uno por uno.
El servidor se enfrenta a una decisin cuando, se pierde el pq1, pero el pq2 llega de manera correcta, puede guardar el pq2 en buffer, esperando que el pq3 llegue de forma correcta, a lo que se le denomina repeticin selectiva, la cual necesita ms administracin, pero utiliza menos ancho de banda en la red.

Reconocimientos

Control de flujo
Muchos circuitos de una red pueden enviar paquetes consecutivos con un espacio muy pequeo entre ellos, pero no siempre pueden recibir un numero ilimitado de paquetes adyacentes, debido a la capacidad finita del circuito. Cuando un paquete llega a un receptor que no lo puede aceptar, ocurre un error de sobre-ejecucin y el paquete se pierde, error que puede ocurrir en el protocolo del chorro.

Reconocimientos

La minimizacin de reconocimientos de los paquetes y la obtencin de un buen desempeo dependen de las propiedades de sincronizacin del circuito de la red, el protocolo deber ajustarse al Hw utilizado.

Ruta Crtica
Serie de instrucciones que se ejecutan con cada RPC.

Ruta Crtica

14 Pasos de la RPC desde el cliente hasta el servidor 1. 2. 3. 4. 5. Llama al resguardo Obtiene el buffer de mensajes Ordena los parmetros Llena los encabezados Calcula la suma de verificacin UDP 6. Seala al Ncleo 7. Forma una fila de paquetes para la transmisin

Ruta Crtica

8. Desplaza el paquete al controlador sobre el Qbus 9. Tiempo de transmisin de Ethernet 10. Obtiene el paquete del controlador 11. Interrumpe la rutina de servicio 12. Calcula la suma de verificacin UDP 13. Cambio de contexto al espacio de usuario 14. Cdigo de resguardo del servidor

Ruta Crtica

a) Para una RPC nula.

b) Para una RPC con un parmetro dado por un arreglo de 1440 bytes.

Copiado
Domina los tiempos de ejecucin de RPC. El nmero de veces que se debe copiar un mensaje vara de uno a ocho, segn el Hw, Sw y tipo de llamada.
El Hw es gran ayuda para eliminar el copiado innecesario, con la dispersin-asociacin. Organizando un paquete mediante la concatenacin de 2 o mas buffers en memoria, as el ncleo puede construir el encabezado del paquete en su espacio, as los datos quedan en el resguardo del cliente y el Hw los empuja al salir el paquete, as se elimina el copiado.

Copiado

El circuito de la red puede utilizar el acceso directo a la memoria para transferir el mensaje del espacio de direcciones al resguardo del cliente a la red(copia 1), depositarlo en a memoria del ncleo del servidor, el cual inspecciona el paquete y asocia la pgina que la contiene en el espacio de direcciones del servidor. Si esta asociacin no se da, el ncleo copia el paquete al resguardo del servidor(copia 2)

El mejor de los casos(2 copias)..

Copiado

El ncleo copia el mensaje del reguardo del cliente en un buffer para su posterior transmisin(c1), el ncleo copia le mensaje, en Sw, a un buffer de Hw en la tarjeta interfaz de la red(c2), se inicia el Hw, el paquete se desplaza hasta la tarjeta de interfaz de destino(c3), se hace la interrupcin en el servidor, s ncleo hace una copia en buffer, lo extrae del buffer del Hw(c4), el mensaje es copiado al resguardo del servidor(c5). Adems si la llamada transfiere como parmetro un arreglo de gran tamao, esto generara 3 copias ms.

El peor de los casos(8 copias)..

Manejo de Cronmetro
El establecimiento de un cronometro requiere la construccin de una estructura de datos que especifique el momento en que el cronmetro debe detenerse, y la accin a realizar si esto sucede.
No es necesario que sean muy precisos. Una eleccin inadecuada del tiempo de expiracin afecta solo el desempeo del protocolo. Un valor muy pequeo har que los cronmetros expiren con frecuencia. Un valor muy grande provocar un largo retraso innecesario.

Manejo del Cronmetro

Mientras se lleva a cabo una RPC, el ncleo tiene un apuntador a la entrada de la tabla correspondiente al proceso activo en una variable local. Cada entrada tiene un campo para su tiempo de expiracin, si es que este existe.

Manejo del Cronmetro

La activacin de un cronmetro para RPC consta de la suma de la longitud de su tiempo de expiracin al tiempo actual. Para que este mtodo funcione, el ncleo debe revisar de forma peridica toda la tabla, para comparar los valores, cualquier valor distinto de 0 que sea menor o igual que el tiempo actual, corresponde a un tiempo expirado, el cual se procesa y se vuelve a activar. Los algoritmos que operan en una transferencia secuencial peridica se llaman algoritmos de barrido.

rea de Problemas

rea de Problemas

Lo ideal.. RPC transparente

La introduccin de RPC en un sistema que se ejecutaba antes en un CPU no debe ir acompaada de una serie de reglas que prohban construcciones ya vlidas o que exijan construcciones que antes eran opcionales, pocos, si no es que ningn Sistema Distribuido actual, puede considerarse transparente.

rea de Problemas

Lenguajes dbilmente tipificados

En pascal , el compilador y su procedimiento de resguardo conocen todo lo relativo a los parmetros, esto permite ordenar los parmetros con facilidad. El problema de C, ya que aunque se haga un calculo de arreglos, es imposible que el resguardo del cliente ordene los parmetros, no hay forma de determinar su tamao. La solucin seria obligar al programador a definir un tamao mximo cuando escriba la definicin formal del servidor. Aunque esto fallara ya que seria un numero fijo.

rea de Problemas

Transferir como parmetro un apuntador a una grfica

El resguardo del cliente no tiene forma de encontrar toda la grfica. Esto acarrea otro problema, no siempre es posible deducir los tipos de parmetros. Un ejemplo printf, que puede tener un nmero arbitrario de parmetros, que puede ser una mezcla de enteros, cortos, largos, flotantes, cadenas, etc. El intento por llamar a printf como un procedimiento remoto seria prcticamente imposible.

2.1.3 COMUNICACIN EN GRUPO

La comunicacin solo es entre dos partes, el cliente y el servidor.
Existen ciertas circunstancias en las que la comunicacin es entre varios procesos; un mensaje se puede enviar a varios receptores en una operacin. La implantacin de la comunicacin en un grupo depende en gran parte del HW.

Introduccin a la Comunicacin en Grupo.

Un grupo es una coleccin de procesos que actan juntos en cierto sistema o alguna forma determinada por el usuario. La propiedad, es que cuando un mensaje se envi al propio grupo, todos los miembros de este grupo lo reciben. Es una forma de comunicacin uno-muchos y contraste con la comunicacin puntual.

 Los grupos son dinmicos; se pueden crear nuevos grupos y destruir grupos anteriores. Un proceso se puede unir a un grupo o dejar otro; puede ser miembro de varios grupos a la vez y se necesita mecanismos para el manejo de grupos y la membreca de los mismos.

Su finalidad es permitir a los procesos que trabajen con coleccin de procesos como una abstraccin; adems puede enviar un mensaje a un grupo de servidores sin tener que conocer su numero o su localizacin, que puede cambiar de una llamada a la siguiente.

 En ciertas redes, es posible crear una direccin especial de red; cuando se enva un mensaje a una de estas direcciones, se entrega de manera automtica a todas las maquinas que escuchan a esa direccin; a esto se le llama multitransmicin. Las redes que no tiene multitransmicin seguido tiene transmisin simple (los paquetes que contiene cierta direccin se entregan a todas las maquinas y se pueden utilizar para implantar los grupos). Para un grupo con n miembros , se necesitan n paquetes, lo contrario a la multitransmicin. El envi en un mensaje de un emisor a un receptor se llama unitransmicin.

Aspectos del diseo.

Tiene posibilidades de diseo similares a la transferencia regular de mensajes, como el almacenamiento en buffers vs, el no almacenamiento, bloqueo vs, no bloqueo, etc. El envi a un grupo es distinto de manera inherente de el envi a un proceso: los grupos se pueden organizar internamente de varias formas.

Grupos Cerrados vs. Grupos Abiertos

Algunos sistemas soportan los grupos cerrados, donde solo los miembros del grupo pueden enviar hacia el grupo; aunque pueden enviar mensajes a miembros del grupo en lo individual. Otros sistemas soportan a los grupos abiertos, cualquier proceso del sistema puede enviar a cualquier grupo.

Los grupos cerrados se utilizan en general para el procesamiento paralelo. Ejemplo: coleccin de procesos (partida de ajedrez) , tiene su propio objetivo y no interacta con el mundo exterior.

Grupos De Compaeros vs. Grupos Jerrquicos.

El grupo de compaeros es simtricos y no tiene punto de falla, si uno de los procesos fallas, el grupo solo se vuelve mas pequeo pero puede continuar. Una desventaja es que la toma de decisiones es mas difcil, hay que pedir voto , lo que produce cierto retraso y costo. El grupo jerrquico tiene propiedades opuestas; la perdida de coordinacin lleva a el grupo a un agobiante alto, pero mientras se mantenga en ejecucin, puede tomar decisiones sin molestar a los dems.

En algunos grupos, todos los procesos son iguales; nadie es el jefe y todas las decisiones se toma en forma colectiva. Existe cierto tipo de jerarqua. Ejemplo: un proceso es el coordinador y todo los dems son trabajadores, y hay jerarquas mas complejas.

Membreca del grupo.

Se requiere cierto mtodo para la creacin y eliminacin de grupos, as como para permitir a los procesos que se unan o dejen grupos. Un posible mtodo es tener un servidor de grupos al cual se puede enviar todas las solicitudes; puede mantener entonces una base de datos de todos los grupos y sus membrecas exactas. Una desventaja, es si el servidor de grupos falla, deja de existir el manejo de los mismos y se reconstruye desde cero.

 Hay dos aspectos asociados con la membreca :

o Si un miembro falla , se elimina del grupo; ya sea voluntariamente o esta inactivo.

o La salida y entra del grupo debe sincronizarse con el envi de mensaje.

o Un aspecto relacionado con la membreca es, la acciona realizar sin fallas tantas maquinas que el grupo ya no puede funcionar. Se necesita cierto protocolo para reconstruir el grupo.

Direccionamiento al Grupo
Los grupos deben poder direccionarse, al igual que los procesos. Una forma, es darle a cada grupo una direccin, parecida a una direccin de proceso. Si la red soporta la multitransmicin la direccin del grupo se puede asociar con una direccin de multitransmicin, de forma que cada mensaje enviado a la direccin del grupo se puede multitransmitir, el mensaje ser enviado todas las maquinas que lo necesiten y a ninguna mas.

Cada ncleo recibir y extraiga de el la direccin del grupo; si no se soportan la multitransmicin o multitransmicin simple el ncleo de la maquina emisora debe contar como una lista de las maquinas que tiene procesos pertenecientes al grupo para entonces enviar a cada una un mensaje puntual.

Tercer mtodo, direccionamiento de predicados, donde se enva cada mensaje a todos los miembros del grupo mdiate uno de los mtodos ya descritos pero con un nuevo giro , cada mensaje contiene un predicado para ser evaluado. Si el valor del predicado es verdadero se acepta el mensaje, si es faso se descarta.

Un segundo mtodo de direccionamiento de grupos consiste en pedir al emisor una lista explicita de todos los destinos. Este mtodo tiene la desventaja de que obliga a los procesos del usuario a ser consientes de quien es miembro de cada grupo. Cuando cambia la membreca del grupo, los procesos del usuario deben actualizar su lista de miembros.

Primitivas send y receive

La comunicacin puntual y la comunicacin en grupo debera combinarse en conjunto de primitivas.

Send es un mensaje por enviar e indica el destino.

Anlogamente, receive indica una disposicin para aceptar un mensaje y es posible que se bloquee hasta disponer de uno, si se combinan las 2 formas de comunicacin, entonces receive termina su labor cuando llega un mensaje puntual o un mensaje de grupo.

Atomicidad.
Caracterstica de la comunicacin en grupo, propiedad del todo o nada, llamada : atomicidad o transmisin atmica, facilita la programacin de los sistemas distribuidos. El emisor comienza con el envi de un mensaje a todos miembros del grupo, los cronmetros se activan y se envan las retransmisiones en los casos necesarios y cuando un proceso recibe el mensaje antes no visto, lo enva a todos los miembros y si ya lo vio, lo descarta.

La nica forma de garantizar que cada destino recibe todos sus mensajes es pedirle que envi de regreso un reconocimiento despus de recibir el mensaje. En sistemas distribuidos , es escencial que se cumplan la atomicidad incluso con fallas en maquinas.

Ordenamiento de mensajes.
Un sistema debe tener una semntica bien definida con respecto al orden de entrega de mensajes, Se necesitan 2 propiedades: o transmisin anatmica. Garantiza que un mensaje enviado llegue a todos o a ninguno de los miembros. o ordenamiento de mensajes. El ordenamiento con respecto al tiempo global, obtiene todos los mensajes en el mismo orden preciso en que fueron enviados.

Grupos traslapados.
Un proceso puede ser miembro de varios grupos a la vez; aunque existen un ordenamiento con respecto al tiempo global dentro de cada grupo, no es necesario que exista coordinacin entre varios grupos. Algunos sistemas soportan un ordenamiento bien definido entre los grupos traslapados y otros no, es difcil implantar el orden con respecto al tiempo entre los distintos grupos.

Escalabilidad.

La multitransmicin es mas compleja, consta de 4 LAN y 4 compuertas con el fin de protegerse contra la falla de cualquier compuerta. Una maquina LAN2 ejecuta una multitransmicin. Cuando el paquete de multitransmicin llega a las compuertas G1 y G3, el paquete se copiara a la LAN1 y LAN4 y poco despus ala LAN3 dos veces. La compuerta G2 vera la multitransmicin de G4, la copiara a LAN 2 y viceversa Con las compuertas y redes mltiples, es posible que dos paquetes estn en lnea en forma simultanea lo que destruye esta til propiedad.

Comunicacin en grupos Isis

Desarrollado en Cornell, Isis es conjunto de herramientas para la construccin de aplicaciones distribuidas; Isis es un conjunto de programas que se ejecutan sobre UNIX o algn otro sistema operativo. La idea fundamental de Isis es la sincrona y las primitivas fundamentales de comunicacin son diversas formas de la transmisin atmica.

Un sistema sncrono es donde los eventos ocurren estrictamente en forma secuencial donde cada evento tarda en esencia un tiempo nulo en llevarse acabo.

Los sistemas sncronos son imposibles de construir; un sistema vagamente sncrono, donde los eventos tardan un tiempo finito, pero todos los eventos aparecen en el mismo orden para todas las partes, todos los procesos reciben todos los mensajes en el mismo orden.

Un sistema virtualmente sncrono, es que si dos mensajes estn relacionados casualmente , todos los procesos deben recibirlos en el mismo orden

Dos eventos no relacionados son concurrentes , si son concurrentes no hay garanta y el sistema es libre de entregarlo con orden distinto a los procesos diferentes.

En un sistema distribuido se dice que dos eventos estn relacionados de manera casual si el primero puede influir de alguna forma en la naturaleza del comportamiento del segundo.

Primitivas de comunicacin en Isis

Se definen 3 de ellas:
ABCAST, proporciona la comunicacin vagamente sncrona y se utiliza para la transmisin de datos a los miembros de un grupo. Es complejo y caro.

GBCAST, se parece a ABCAST, excepto que se usa para el manejo de la membreca en vez del envi de datos ordinario.

CBCAST, proporciona comunicacin virtualmente sncrona y se utiliza para el envi de datos. Garantiza la entrega ordenada de los mensajes relacionados de manera casual.

 Isis proporciona la tolerancia de fallas y soporta el ordenamiento de mensajes para grupos traslapados mediante CBCAST.