Está en la página 1de 120

SISTEMAS

OPERATIVOS 2

Unidad 2 Comunicación 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 líneas OSI se ven como una buena forma de organizar un sistema distribuido.

Un emisor establece una conexión 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 envía un mensaje se procesa cerca de media

docena de capas que generan y

añaden encabezados en el camino hacia abajo o elimina y examina el

encabezado en el camino hacia

arriba.

Clientes y Servidores
Clientes y Servidores

Con la idea de estructurar el sistema operativo como un grupo de

procesos en cooperación, 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 conexión.

El cliente envía 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 código de error para indicar que el trabajo no se pudo llevar a cabo.

UN EJEMPLO CLIENTE/SERVIDOR
UN EJEMPLO
CLIENTE/SERVIDOR

Tanto el cliente como el servidor comparten algunas definiciones.

Las dos constantes MAX_PATH y BUF_SIZE, determinan el tamaño 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 operación, al establecer el

tamaño del buffer.

La siguiente constante FILE_SERVER

proporciona la dirección en la red

del servidor de archivos para que

los clientes puedan ver los mensajes.

El segundo grupo de constantes define los números de operación, necesarios para garantizar que el cliente y el servidor queden de acuerdo en el código que un RED representara.

Cada respuesta tiene un código de resultado, si la operación tiene

éxito es frecuente que este código

contenga información útil, si no existe un valor por regresar se utiliza el valor OK.

Si

la

operación fracasa

el código

de

resultado

lo

indica

mediante

códigos

tales

como

E_BAD_OPCODE,

E_BAD_PARAM,

etc.

 

Llegamos a la definición del propio mensaje, en un sistema real tal vez

no

se

tenga

mensaje.

un

formato

fijo

de

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 parámetros 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 envían de regreso como respuesta a un

READ.

Direccionamiento

Para que un cliente pueda enviar un

mensaje a un servidor, debe conocer

la dirección de este. El servidor de archivos tiene asignada

una dirección numérica, si este se

refiere a una maquina determinada, el núcleo emisor puede extraerla de la estructura de mensajes y utilizarla como dirección física para enviar el mensaje al servidor.

El núcleo emisor construye un marco

con esta dirección 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 dirección y la acepte.

Otro tipo de direccionamiento es el que envía 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 método consiste en asignarle a cada

proceso una dirección 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 localización.

Este será recibido por todas las maquinas de

la red, los núcleos verifican y en caso de que

sea su dirección regresa un mensaje “aquí estoy” con su dirección 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 instrucción que sigue a la llamada de send no se

ejecuta hasta que el mensaje se envía 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 transmisión 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 transmisión por lo que no sabe cuando es seguro volver a usar el buffer.

Existen dos formas de salir del

problema:

El núcleo copia el mensaje a un buffer interno así permite que el proceso continúe, la desventaja es que cada

mensaje se copia dos veces (en el

buffer del núcleo y posteriormente en un buffer en el hardware).

Esto hace que el desempeño del sistema se reduzca

considerablemente.

La segunda opción 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

programación sea truculenta, difícil y sujeta a condiciones de

competencia.

Primitivas almacenadas en buffer vs. no almacenadas
Primitivas almacenadas en
buffer vs. no almacenadas

Primitivas no almacenadas: esto significa que una dirección se refiere

a un proceso especifico.

Una llamada receive indica al núcleo de la maquina donde se ejecuta esta

que el proceso llamo escucha a la

dirección addr y esta preparado para recibir un mensaje enviado a esta dirección.

Se dispone de un buffer de mensajes,

cuando el mensaje llega, el núcleo

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

núcleo del servidor la dirección que utiliza el servidor y la posición donde

colocar el mensaje que esta por

llegar.

Esto tiene sus desventajas ya que si el

cliente fracasa un numero suficiente

de intentos, el núcleo del cliente se podría dar por vencido y concluir que el servidor esta descompuesto o

que la dirección 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 método 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:

Buzón: proceso interesado en recibir mensajes, el núcleo especifica una

dirección en la cual busca los

paquetes de la red.

La llamada a receive elimina un mensaje del buzón o se bloque si no hay mensajes presentes.

El núcleo sabe que hacer con los mensajes que lleguen y tiene un lugar para

colocarlos , esta técnica se conoce como primitiva con almacenamiento en buffers.

Sin embargo los buzones son finitos, cuando

llega un mensaje a buzón totalmente ocupado, el núcleo se enfrenta de nuevo a la elección de mantener el

mensaje pendiente por un momento o

bien descartar dicho mensaje

Primitivas confiables vs. no confiables.
Primitivas confiables vs. no
confiables.

Como es usual los mensajes se

pueden perder y esto afecta la

semántica del modelo de transferencia de mensajes.

Cuando un cliente envía un mensaje, se suspende hasta que el mensaje

ha sido enviado pero no existe

ninguna garantía de que el mensaje haya sido entregado.

Existen tres distintos enfoques de este problema:

1er. Consiste en volver a definir la semántica de send para hacerla no

confiable.

El sistema no da garantía alguna acerca de la entrega de los

mensajes, la implantación de una

comunicación confiable se deja por completo en manos de los usuarios.

2o. Exige que el núcleo de la maquina receptora envié un reconocimiento al núcleo de la maquina emisora. Solo cuando reciba este reconocimiento, el núcleo emisor liberara al cliente, el

reconocimiento va de núcleo a núcleo, ni

el cliente ni el servidor ven alguna vez un reconocimiento.

3er. Aprovecha el hecho de que la comunicación cliente-servidor se estructura como solicitud del cliente al servidor. Aquí

el cliente se bloquea después de enviar el

mensaje, el núcleo del servidor no envía de regreso un reconocimiento si no que la misma respuesta funciona como tal.

Implantación del modelo cliente-servidor.
Implantación del modelo
cliente-servidor.

Virtualmente todas las redes tienen

un tamaño máximo 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 recuperación mas compleja cuando se pierde

uno de ellos.

Otro aspecto es el protocolo

subyacente utilizado en la comunicación 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 recepción 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 núcleo 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 buzón al que se envió la solicitud este lleno, al

enviar de regreso el paquete al núcleo del

cliente, el núcleo del servidor puede indicar que la dirección es valida y que debe repetirse la solicitud mas tarde.

  • 2. La dirección no pertenezca a ningún proceso o buzón y su repetición posterior no ayudaría en nada.

Esta situación también 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 núcleo del servidor olvide incluso la existencia de la

dirección entre llamadas a receive

puede conducir a ciertos problemas.

Un servidor puede hacer una llamada

cuya única función será registrar cierta dirección del núcleo, de esa

forma al menos el núcleo puede

decir la diferencia entre una dirección que nadie escucha y una que esta equivocada.

2.1.2 Llamada a un

Procedimiento Remoto

La comunicación 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 comunicación en los SOD, permitiendo a los programas

que llamen a procedimientos

localizados en otras máquinas

En 1984 Birrell y Nelson presentaron una forma de abordar la comunicación en los SOD, permitiendo

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 parámetros y resultados, problema si las maquinas no son idénticas. Se pueden descomponer ambas maquinas y cada una con diversas fallas y diversos problemas.

Operación básica del RPC
Operación básica
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 parámetros 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 parámetros, la decisión de cual usar la toman los diseñadores del sistema y es una propiedad fija del lenguaje.

Llamada por

Llamada por

Llamada con copia de

valor

referencia

restauración

C, enteros y escalares

C, los arreglos

 

Pascal,

Pascal, anteponiendo la palabra var en los

Ada, utilizada para los parámetros

predefinido

parámetros específicos

in out

 

Ada, algunos lo utilizan

 

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.

Llamada por referencia.-

es un apuntador a una variable(dirección), en lugar del valor de la variable, la cual se introduce en la pila.

Si el procedimiento llamado

utiliza este parámetro para guardar algo en el arreglo,

esto sí modifica el arreglo en

el procedimiento que hizo la llamada.

Llamada con copia/restauración.-

quien recibe la llamada copia la

variable en la pila, como en la llamada

por valor, y entonces la copia de regreso después a la llamada,

escribiendo sobre el valor original.

Una llamada a un

Procedimiento Remoto se realiza mediante los siguientes pasos:

1. El procedimiento cliente llama al

resguardo del cliente de la manera usual.

Una llamada a un Procedimiento Remoto se realiza mediante los siguientes pasos: 1 . El procedimiento

2. El resguardo del cliente construye un mensaje y hace un señalamiento al núcleo.

3. El núcleo envía el mensaje al núcleo remoto.

4. El núcleo remoto proporciona

el mensaje al resguardo del

3 . El núcleo envía el mensaje al núcleo remoto. 4 . El núcleo remoto proporciona

servidor.

5. El resguardo del servidor desempaca los parámetros y

llama al servidor.

6. El servidor realiza el trabajo y regresa el

resultado al resguardo.

6 . El servidor realiza el trabajo y regresa el resultado al resguardo. 7 . El
6 . El servidor realiza el trabajo y regresa el resultado al resguardo. 7 . El

7. El resguardo del servidor

empaca el resultado en un

mensaje y hace un

señalamiento al núcleo.

8. El núcleo remoto envía el mensaje al núcleo del cliente.

9. El núcleo del cliente da el

mensaje al resguardo del cliente.

10. El resguardo desempaca el resultado y regresa al cliente.

Transferencia de

Parámetros

La función del resguardo del

cliente es tomar sus parámetros,

empacarlos en un mensaje y enviarlos al resguardo del servidor.

El empacamiento de parámetros

en un mensaje se llama

ordenamiento de parámetros.

Ejemplo 5 3 1 2 4
Ejemplo
5
3
1
2
4

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

1. El resguardo del cliente

toma sus dos parámetros y los

coloca en un mensaje, también coloca el nombre o

número 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 envía de regreso

al resguardo del cliente, que lo

desempaca y regresa el valor al

procedimiento del cliente.

Si las máquinas son idénticas y todos los parámetros son escalares, este

modelo funciona bien.

El problema surge en los sistemas

de gran tamaño, donde las maquinas pueden ser diferentes.

Si las máquinas son idénticas y todos los parámetros son escalares, este modelo funciona bien. El
Si las máquinas son idénticas y todos los parámetros son escalares, este modelo funciona bien. El

Mas Problemas RPC

* El tipo de código de caracteres que

usan puede ser diferente en cada

máquina. * Si la representación de enteros

puede no ser similar, al igual que en los

números de punto flotante. * Como se realiza la numeración, 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 diseñar un estándar de red o forma

canónica, para enteros, caracteres,

booleanos, punto flotante, etc.

y pedir a todos los emisores que conviertan sus representaciones

internas a esta

forma durante el ordenamiento.

Una forma de que se logre el procedimiento es dar un formato en especifico a cada

Problema en algunos casos ineficiente, ya

que, solo aplica cuando los sistemas son diferentes, pero en caso de que sean

iguales, tendrán que hacerse 2

conversiones no necesarias.

Little endian

Big endian

Necesita conversión

Big endian

Little endian

Necesita conversión

Little endian

Little endian

Conversión Innecesaria

Big endian

Big endian

Conversión innecesaria

Para esto se busca otra solución, 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 conversión.

Cliente LITTLE ENDIAN

Servidor BIG ENDIAN

 
lit end A S O big end O S A
 

lit end

A

S

O

 
 
lit end A S O big end O S A
 

big end

O

S

A

Cómo se transfieren los

apuntadores ?

..

El resguardo del cliente sabe cuando

un parámetro apunta a un arreglo

de caracteres, supongamos que también conoce el tamaño, entonces se copia el arreglo en el mensaje y se envía 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 envía de regreso al

resguardo del cliente, quien lo copia

de nuevo al cliente.

Una optimización de esto es, si el

resguardo sabe si es parámetro 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 especificación, escrita en cierto lenguaje.

Conexión

Dinámica

Utilizada para que concuerden los clientes y los servidores.

Su punto de partida es la especificación formal del servidor: 1) indica el nombre del servidor, 2) el numero de versión y 3) una lista de procedimientos que proporciona.

3

1 2
1
2

bytes

position

buf

Indican al servidor el número de bytes

Indica el sitio del archivo donde se comenzara la

Lugar donde el servidor coloca los datos solicitados

por transferir.

lectura o escritura.

por el cliente.

Se tienen los tipos de parámetros para cada procedimiento in, out o in-out.

In

Out

In-Out

Se envía del cliente al servidor, indica al

Se envía del

Se envía del cliente al servidor, donde se le

servidor el archivo

servidor al

modifica y que

que debe leer, escribir, crear o

cliente.

después se envía de regreso al cliente.

eliminar

Cuando el servidor inicia su ejecución, la llamada initialize exporta la interfaz del servidor, éste envía 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, número de versión, un identificador de 32bits y un asa para localizarlo(puede ser una dirección Ethernet, IP, X.500, un identificador ralo de procesos o alguna otra cosa.

Llamada

Entrada

Salida

Registro

Nombre, versión, asa, identificación única

 

De

Nombre, versión,

 

Registro

identificación única

Búsqueda

Nombre, versión

Asa,

identificador

único

El cliente envía un mensaje al conector, donde solicita la importación de la versión

de la interfaz X, el conector verifica si uno o

mas servidores ya han exportado esa interfaz con nombre y numero de versión.

El método de exportación e importación de

interfaces es altamente flexible.

Ventajas

Desventajas

Puede manejar varios servidores con interface semejante.

Costo adicional en el tiempo generado por exportación e importación de interfaces.

El conector puede difundir los

En SD grandes, el conector se

clientes de manera aleatoria en los servidores.

puede convertir en cuello de botella.

Puede ayudar en la

Se necesitan muchos mensajes

autenticación, especificando

para mantener la sincronización

una lista predeterminada de usuarios.

y actualización de los conectores.

Puede hacer un muestreo periódico de los servidores.

 

Verificas que cliente y servidor usen la misma versión de interfaz.

RPC SUS FALLAS

El cliente no puede

localizar al servidor

El cliente no puede localizar un servidor adecuado. El servidor podría estar inactivo. El servidor actualiza su interfaz y empieza a utilizar nuevos

resguardos, los cuales no podrían concordar con los del cliente.

El cliente no puede localizar al servidor

Una posible solución, es que el error provoque una excepción, aunque esto también tiene sus desventajas:

No todos los lenguajes tienen excepciones o señales. Al escribir una excepción se destruiría la transparencia que queremos lograr de nuestro sistema distribuido.

El cliente no puede localizar al servidor Una posible solución, es que el error provoque una

Perdida de mensajes de

solicitud

Hay que hacer que el núcleo inicie un cronómetro al enviar la

solicitud.

Si el tiempo se termina, el núcleo vuelve a cargar el

mensaje; si éste se perdió, el

servidor no notara la diferencia entre la retransmisión 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 idempotente.- una

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

Perdida de mensajes de respuesta

Otro método es mediante el registro del número secuencial de recepción, el núcleo del servidor podrá notar la diferencia

entre una solicitud original y una

retransmisión.

Una protección 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 números 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:

Semántica al menos una a la vez:

(garantiza que la RPC se ha relizado al menos una vez o más) esperar hasta que el servidor vuelva a arrancar e intente realizar de nuevo la operación, asi hasta recibir una respuesta.

Fallas del Servidor

Semántica a lo más una a la vez:

(garantiza que la RPC se realiza a lo más una vez , no más) se da por vencida inmediatamente e informa la falla.

No Garantizar Nada: (el cliente no

obtiene ayuda o alguna promesa) la RPC se realiza en cualquier lugar, va desde 0 hasta un número muy grande de veces.

Fallas del Servidor

Semántica de exactamente uno:

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

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

Huérfano: cuando se

envía una solicitud al

servidor y esta falla antes de que el servidor

responda.

Fallas del Cliente Huérfano: cuando se envía una solicitud al servidor y esta falla antes de

Desperdician los ciclos del CPU. Bloquean archivos o recursos valiosos(causa por la cual seria peligroso

eliminarlo, ya que podría dejar archivos

bloqueados permanentemente). Pueden crear confusión.

Fallas del Cliente

¿Qué se puede hacer?

Exterminación: Antes que el resguardo del

cliente envié un mensaje RPC, crea un registro donde indica que hará, en un medio o disco.

Después al volver a arrancar, se verifica el

contenido del registro y se elimina el huérfano.

Reencarnación: Dividir el tiempo en épocas numeradas en manera secuencial, cuando se reporten los huérfanos, sus respuestas contendrán un número de época obsoleto, lo cual facilitara su detección.

Fallas del Cliente

Reencarnación sutil: Cuando llega un

mensaje de cierta época, cada máquina revisa si tiene cómputos remotos, si es así, intenta localizar a su poseedor, en caso de que no lo encuentre se elimina.

Expiración: A cada RPC se le asigna una cantidad estándar 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 Implantación

Protocolos RPC

Veremos los posibles protocolos a utilizar, aunque seria mejor contar con un protocolo exclusivo para RPC, lo

cual podría ser poco aceptado y muy

costoso, por lo que tenemos algunas opciones de protocolos:

Protocolo sin Conexión (usado en SD instalados en edificios) Protocolo orientado a la conexión Protocolo IP y UDP

Protocolos RPC

Protocolo Orientado a la Conexión

Ventajas

La comunicación es más fácil. 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 conexión

Desventajas

Pérdida en el desempeño El Sw adicional estorba El no perder los paquetes no es necesario, ya que las LAN son confiables.

Protocolos RPC

Protocolo IP UDP

Ventajas El protocolo ya ha sido diseñado 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 desempeño, ya que no se diseñó como un protocolo para usuario final El cálculo en sus encabezados produce perdida de tiempo

Reconocimientos

Cuando las RPC grandes se dividen en pequeños paquetes, ¿Deben reconocerse de manera individual?

Protocolo detenerse y esperar,

establece que el cliente envié el

paquete 0 con el primer 1K, espera un reconocimiento del servidor, y

así envía el segundo 1K, espera el

reconocimiento, etcétera. Si un paquete se daña, no se recibe a tiempo un

reconocimiento.

Reconocimientos

Reconocimientos Protocolo de chorro, establece que el cliente envié todos los paquetes tan pronto como pueda,

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 decisión 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 repetición selectiva, la cual necesita más administración, 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

pequeño 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-ejecución y el paquete se pierde, error que puede ocurrir en el protocolo del chorro.

Reconocimientos

La minimización de reconocimientos de los paquetes y la obtención de un buen desempeño

dependen de las propiedades de sincronización

del circuito de la red, el protocolo deberá ajustarse al Hw utilizado.

Ruta Crítica

Serie de instrucciones que se ejecutan con cada RPC.

Ruta Crítica

14 Pasos de la RPC desde el cliente hasta el servidor

  • 1. Llama al resguardo

  • 2. Obtiene el buffer de mensajes

  • 3. Ordena los parámetros

  • 4. Llena los encabezados

  • 5. Calcula la suma de verificación UDP

  • 6. Señala al Núcleo

  • 7. Forma una fila de paquetes para la transmisión

Ruta Crítica

  • 8. Desplaza el paquete al

controlador sobre el Qbus

  • 9. Tiempo de transmisión de Ethernet

    • 10. Obtiene el paquete del

controlador

  • 11. Interrumpe la rutina de servicio

  • 12. Calcula la suma de verificación

UDP

  • 13. Cambio de contexto al espacio de usuario

  • 14. Código de resguardo del

servidor

Ruta Crítica

b) Para una RPC con un parámetro

dado por un arreglo

de 1440 bytes.

a) Para una RPC

nula.

Copiado

Domina los tiempos de ejecución de RPC. El número de veces que se debe copiar un mensaje varía de uno a ocho, según el Hw, Sw

y tipo de llamada.

El Hw es gran ayuda para eliminar el copiado innecesario, con la dispersión-asociación. Organizando un paquete mediante la concatenación de 2 o mas buffers en memoria, así el núcleo 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 mejor de los casos(2 copias) ..

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 núcleo del servidor, el cual inspecciona el paquete y asocia la página que la contiene en el espacio de direcciones del servidor. Si esta asociación no se da, el núcleo copia el paquete al resguardo del servidor(copia 2)

Copiado

El peor de los casos(8 copias) ..

El núcleo copia el mensaje del reguardo del cliente en un buffer para su posterior transmisión(c1), el núcleo 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

interrupción en el servidor, sú núcleo hace

una copia en buffer, lo extrae del buffer

del Hw(c4), el mensaje es copiado al resguardo del servidor(c5). Además si la llamada transfiere como parámetro un arreglo de gran tamaño, esto generara 3 copias más.

Manejo de Cronómetro

El establecimiento de un cronometro requiere la construcción de una estructura de datos que especifique el momento en que el cronómetro

debe detenerse, y la acción a realizar si esto

sucede.

No es necesario que sean muy precisos. Una elección inadecuada del tiempo de expiración afecta solo el desempeño del protocolo. Un valor muy pequeño hará que los cronómetros expiren con frecuencia. Un valor muy grande provocará un largo retraso innecesario.

Manejo del Cronómetro

Manejo del Cronómetro Mientras se lleva a cabo una RPC, el núcleo tiene un apuntador a

Mientras se lleva a cabo una RPC, el núcleo 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 expiración, si es que este existe.

Manejo del Cronómetro

La activación de un cronómetro para RPC consta de

la suma de la longitud de su tiempo de expiración

al tiempo actual. Para que este método funcione, el núcleo

debe revisar de forma periódica 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 periódica se llaman algoritmos de barrido.

Área de Problemas

Área de Problemas

Lo ideal

..

RPC transparente

La introducción de RPC en un sistema que se ejecutaba

antes en un CPU no debe ir

acompañada de una serie de reglas que prohíban construcciones ya válidas o

que exijan construcciones que antes eran opcionales, pocos, si no es que ningún

Sistema Distribuido actual,

puede considerarse transparente.

Área de Problemas Lo ideal .. RPC transparente La introducción de RPC en un sistema que

Área de Problemas

Lenguajes débilmente tipificados

Área de Problemas Lenguajes débilmente tipificados En pascal , el compilador y su procedimiento de resguardo

En pascal , el compilador y su procedimiento de resguardo conocen todo lo relativo a los parámetros, esto

permite ordenar los parámetros con

facilidad.

El problema de C, ya que aunque se haga un calculo de arreglos, es imposible que el resguardo del cliente ordene los parámetros, no hay forma de determinar su tamaño. La solución seria obligar al programador a definir un tamaño máximo cuando escriba la definición formal del servidor. Aunque esto fallaría ya que seria un numero fijo.

Área de Problemas

Transferir como parámetro un apuntador a una gráfica

El resguardo del cliente no tiene forma de encontrar toda la gráfica.

Esto acarrea otro problema, no siempre es posible deducir los tipos de parámetros. Un ejemplo printf, que puede tener un número arbitrario de parámetros, que puede ser una mezcla de enteros, cortos, largos, flotantes, cadenas, etc. El intento por llamar a printf como un procedimiento remoto seria prácticamente imposible.

2.1.3 COMUNICACIÓN

EN GRUPO

2.1.3 COMUNICACIÓN EN GRUPO • La comunicación solo es entre dos partes, el cliente y el

La comunicación solo es entre dos

partes, el cliente y el servidor.

Existen ciertas circunstancias en las que la comunicación es entre varios procesos; un mensaje se puede enviar a varios receptores en una

operación.

La implantación de la comunicación en un grupo depende en gran parte del HW.

Introducción a la

Comunicación en Grupo.

Un grupo es una colección de procesos que actúan 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 comunicación uno-muchos y contraste con la comunicación puntual.

Introducción a la Comunicación en Grupo. • Un grupo es una colección de procesos que actúan

Los grupos son dinámicos; 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 membrecía de los mismos.

Su finalidad es permitir a los procesos que

trabajen con colección de procesos como una abstracción; además puede enviar un mensaje a un grupo de servidores sin tener

que conocer su numero o su localización,

que puede cambiar de una llamada a la siguiente.

En ciertas redes, es posible crear una dirección especial de red; cuando se envía un mensaje a una de estas direcciones, se entrega de manera automática a todas las maquinas que escuchan a esa dirección; a esto se le llama multitransmición.

Las redes que no tiene multitransmición seguido tiene transmisión simple (los paquetes que contiene cierta dirección 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 multitransmición. El envió en un mensaje de un emisor a un receptor se llama

unitransmición.

Aspectos del diseño.

Tiene posibilidades de diseño

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: colección de procesos (partida de ajedrez) , tiene su propio objetivo y no interactúa con el mundo exterior.

Grupos De Compañeros vs.

Grupos Jerárquicos.

•

  • 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 jerarquía.

  • Ejemplo: un proceso es el coordinador y todo los demás son trabajadores, y hay jerarquías mas complejas.

El grupo de compañeros es simétricos y no tiene punto de falla, si uno de los procesos fallas, el grupo solo se vuelve mas pequeño pero puede continuar.

Una desventaja es que la toma de decisiones es mas difícil, hay que pedir voto , lo que produce cierto retraso y costo.

El grupo jerárquico tiene propiedades opuestas; la perdida de coordinación lleva a el grupo a un agobiante alto, pero

mientras se mantenga en

ejecución, puede tomar decisiones sin molestar a los demás.

Membrecía del grupo.

Membrecía del grupo. • Se requiere cierto método para la creación y eliminación de grupos, así
Membrecía del grupo. • Se requiere cierto método para la creación y eliminación de grupos, así

Se requiere cierto método para la creación y eliminación de grupos, así como para permitir a los procesos que se unan o dejen grupos.

Un posible método 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 membrecías 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 membrecía :

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 membrecía 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

dirección, parecida a una dirección de proceso.

Si la red soporta la multitransmición la dirección del

grupo se puede asociar con una dirección de

multitransmición, de forma que cada mensaje enviado a la dirección del grupo se puede multitransmitir, el mensaje será enviado todas las maquinas que lo necesiten y a ninguna mas.

Cada núcleo recibirá y

extraiga de el la dirección del

grupo; si no se soportan la multitransmición o multitransmición simple el núcleo 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 método,

direccionamiento de

predicados, donde se envía cada mensaje a todos los miembros del grupo médiate

uno de los métodos 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 método de direccionamiento de grupos consiste en pedir al emisor una lista explicita de todos los destinos. Este método tiene la desventaja de que obliga a los procesos del usuario a ser consientes de quien es miembro de cada grupo. Cuando cambia la membrecía del grupo, los procesos del usuario deben actualizar su lista de miembros.

Primitivas send y receive

La comunicación puntual

y la comunicación en grupo debería

combinarse en conjunto

de primitivas.

Primitivas send y receive • La comunicación puntual y la comunicación en grupo debería combinarse en
  • Send es un

mensaje por

enviar e indica el destino.

Análogamente, receive indica una

disposición para aceptar un mensaje y es posible que se bloquee hasta disponer de uno, si se combinan las 2

formas de comunicación, entonces receive termina su labor cuando llega un mensaje puntual o un mensaje de grupo.

Atomicidad.

Característica de la

comunicación en grupo, propiedad del todo o nada, llamada : atomicidad o transmisión atómica, facilita la programación de los sistemas distribuidos.

El emisor comienza con el

envió de un mensaje a

todos miembros del grupo, los cronómetros se activan y se envían las retransmisiones en los casos necesarios y

cuando un proceso recibe

el mensaje antes no visto, lo envía 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 después de recibir el mensaje. En sistemas distribuidos , es escencial que se

cumplan la atomicidad incluso con fallas en maquinas.

Ordenamiento de mensajes.

o

o

Un sistema debe tener una semántica bien definida con respecto al orden de entrega de mensajes, Se necesitan 2 propiedades:

transmisión anatómica. Garantiza que un mensaje

enviado llegue a todos o a

El ordenamiento con respecto al tiempo global,

obtiene todos los mensajes

en el mismo orden preciso

en que fueron enviados.

ninguno de los miembros. ordenamiento de mensajes.

Ordenamiento de mensajes. • o o Un sistema debe tener una semántica bien definida con respecto

Grupos traslapados.

Grupos traslapados. • Un proceso puede ser miembro de varios grupos a la vez; aunque existen

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 coordinación entre varios grupos. Algunos sistemas

soportan un

ordenamiento bien definido entre los grupos traslapados y otros no, es

difícil implantar el orden

con respecto al tiempo entre los distintos grupos.

Escalabilidad. La multitransmición es mas compleja, consta de 4 LAN y 4 compuertas con el fin

Escalabilidad.

La multitransmición 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 multitransmición. Cuando el paquete de multitransmición llega a las compuertas G1 y G3, el paquete se copiara a la LAN1 y LAN4 y poco después ala LAN3 dos veces.

La compuerta G2 vera la multitransmición de G4, la copiara a LAN 2 y viceversa

Con las compuertas y redes múltiples, es posible que dos paquetes estén en línea en forma simultanea lo que

destruye esta útil propiedad.

Comunicación en grupos Isis

Desarrollado en Cornell, Isis es conjunto de herramientas para

la construcción de aplicaciones distribuidas; Isis es un conjunto de programas que se ejecutan sobre UNIX o algún otro sistema

operativo.

La idea fundamental de Isis es la sincronía y las primitivas

fundamentales de comunicación son diversas formas de la transmisión atómica.

Comunicación en grupos Isis Desarrollado en Cornell, Isis es conjunto de herramientas para la construcción de
  • Un sistema síncrono es donde los eventos ocurren estrictamente en forma secuencial donde cada evento tarda en esencia un tiempo nulo en llevarse acabo.

  • Los sistemas síncronos son

imposibles de construir; un

sistema vagamente síncrono,

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 síncrono, es que si dos mensajes están relacionados casualmente , todos los procesos deben recibirlos en el mismo orden

Dos eventos no

relacionados son concurrentes , si son concurrentes no hay garantía y el sistema es libre de entregarlo

con orden distinto a los procesos diferentes.

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

Primitivas de comunicación

en Isis

Se definen 3 de ellas:

ABCAST, proporciona la comunicación vagamente síncrona y se utiliza para la transmisión 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 membrecía en

vez del envió de datos ordinario.

CBCAST, proporciona

comunicación virtualmente síncrona 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

Isis proporciona la tolerancia de fallas y soporta el ordenamiento de mensajes para

grupos traslapados mediante CBCAST.