Unidad II

Modelo Cliente – Servidor:Tiene como idea fundamental la estructuración del S. O. como:

Direccionamiento en C – S:

Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la dirección de éste. La primitiva tiene al menos dos argumentos:

• La dirección del proceso a quien el mensaje debe ir dirigido.• La dirección de un buffer con los datos a enviar.

De forma genérica el formato es:• Enviar(dirección_destino,&mensaje)

EjemplosEn UNIX

• write(int fd, char*buffer, tamBuffer)

Implantación del Modelo C – S:

Direccionamiento: Número de máquina. Direcciones ralas de procesos. Búsqueda de nombres en ASCII por medio del servidor.

Bloqueo: Primitivas con bloqueo. Sin bloqueo, con copia al núcleo. Sin bloqueo, con interrupciones.

Almacenamiento en buffers: No usar el almacenamiento en buffers, descartar los mensajes inesperados. Sin almacenamiento en buffers, mantenimiento temporal de los mensajes inesperados. Buzones.

Confiabilidad: No confiable. Solicitud - reconocimiento - respuesta - reconocimiento. Solicitud - respuesta - reconocimiento.

Existen 34 = 81 combinaciones, pero no todas son igual de buenas.

Confiabilidad:

Los principales tipos de paquetes son los siguientes:REQ: Solicitud.

De cliente a servidor. El cliente desea servicio.

REP: Respuesta.

De servidor a cliente. Respuesta del servidor al cliente.

ACK: Reconocimiento.

De cualquiera de ellos a algún otro. El paquete anterior que ha llegado.

AVA: ¿ Estás vivo ?

De cliente a servidor. Verifica si el servidor se ha descompuesto.

IAA: Estoy vivo.

De servidor a cliente. El servidor no se ha descompuesto.

TA: Intenta de nuevo.

De servidor a clientes. El servidor no tiene espacio.

AU: Dirección desconocida.

De servidor a cliente. Ningún proceso utiliza esta dirección.

Llamada a un Procedimiento Remoto (RPC)

INTRODUCCIÓN

Inconveniente del Modelo cliente servidor utilizando primitivas de paso de mensaje:

El modelo cliente - servidor es una forma conveniente de estructurar un S. O. distribuido, pero posee una falencia :

• La comunicación se basa en operaciones de entrada / salida.

Los procedimientos send / receive están reservados para la realización de e / s.

Es complejo desarrollar aplicaciones distribuidas basadas en este tipo de operaciones

Es un mecanismo que permite que un proceso pueda invocar procedimientos que se encuentran en otro proceso de otra máquina.

El Objetivo principal que persigue es la transparencia

-FUNCIONAMIENTO ● Cuando un proceso en la máquina “A” llama a un procedimiento en la máquina “B”: ● El proceso que realiza la llamada se suspende. ● La ejecución del procedimiento se realiza en “B”. ● La información se puede transportar de un lado al otro mediante los parámetros y puede regresar en el resultado del procedimiento. ● El programador no se preocupa de una transferencia de mensajes o de la e / s. ● A este método se lo denomina llamada a procedimiento remoto o RPC. ● El procedimiento que hace la llamada y el que la recibe se ejecutan en máquinas diferentes, es decir que utilizan espacios de direcciones distintos.



PROBLEMA A RESOLVER

• El procedimiento que invoca y el invocado se ejecutan en máquinas diferentes

• El paso de parámetros es complejo, sobretodo si las máquinas son diferentes

• Fallos en las máquinas o en la red


EXISTEN VARIAS FORMAS DE PASAR PARAMETROS A PROCEDIMIENTO- Por valor- Por referencia- Por copia/restauración

La ida es que una llamada a un procedimiento remoto (RPC) se parezca lo más posible a una llamada local: PROBLEMA

- Los mecanismos de paso de mensajes dependen del lenguaje de programación Ejemplos

Los lenguajes C/C++ tiene paso por valor y paso por referencia

El lenguaje Java tiene paso por referencia


SOLUCIÓN EMPLEADA PARA CONSEGUIR EL OBJETIVO DE LA TRASPARENCIA

– Utilizar funciones que se encarguen de todos los detalles de bajo nivel:• Empaquetamiento/desempaquetamiento de mensajes• Envío/recepción de mensajes• Control de errores

- Estas funciones se suelen denominar stubs• Existen funciones stub tanto en el cliente como enel servidor• En algunos sistemas, se utiliza el término skeletonpara hacer referencia al stub de un servidor(CORBA)


PASO DE PARAMETRO


PASO DE PARAMETRO• El procedimiento cliente llama al stub del cliente de la manera usual.

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

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

• El núcleo remoto proporciona el mensaje al stub del servidor.

• El stub del servidor desempaca los parámetros y llama al servidor.

• El servidor realiza el trabajo y regresa el resultado al stub.

• El stub del servidor empaca el resultado en un mensaje y hace un señalamiento al núcleo.

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

• El núcleo del cliente da el mensaje al stub del cliente.

• El stub desempaca el resultado y regresa al cliente.


Vinculación entre clientes y servidores

• Se denomina vinculación (binding) al proceso por el cuál un cliente conoce la dirección de un servidor

• Cuestiones a considerar

1. Cómo indica el cliente a qué servidor quiere vincularse

2. Localización del servidor

3. Cuándo se produce la vinculación en el cliente

• Los dos primeros puntos son similares al problema del direccionamiento en el paso de mensajes

– Lo habitual es usar un servidor de nombres

INTRODUCCIÓN A LOS OBJETOS DISTRIBUIDOS

• En la actualidad– La orientación a objetos es el paradigma de programación predominante• La orientación a objetos– Ofrece un conjunto de técnicas para el diseño y desarrollo de software que favorece el diseño modular y la reutilización de código• Estas ventajas son también de interés en el ámbito de los sistemas distribuidos– Como consecuencia, en los sistemas distribuidos se utiliza un paradigma basado en objetos distribuidos


• Un objeto distribuido es– Una entidad compuesta por un estado oculto y por una interfaz pública– Las operaciones (o métodos) pueden ser invocadosde forma local o remota por un proceso o por otroobjeto distribuido• Comparación con RPC– En RPC se invocan procedimientos; con objetos distribuidos se invocan operaciones de objetos– Las operaciones de los objetos pueden tener a su vez objetos como argumentos, y pueden devolver objetos como valor de retorno


• El mecanismo de invocación de objetos es

denominado

– Invocación de métodos remotos (Remote Method

Invocation o RMI)

• Ejemplos de sistemas basados en objetos

distribuidos

– CORBA (Common Object Request Broquer Architecture)

– Java RMI

– Microsoft DCOM


INTERFACES

• En general

La interfaz de un módulo de programa especifica los procedimientos y las variables del módulo que son accesibles desde otros módulos

• En programas distribuidos

• Los módulos pueden ejecutarse en procesos que están en distintas máquinas• Como consecuencia, un módulo no puede acceder a las variables de un módulo remoto• Por este motivo, las interfaces usadas tanto en RPC como RMI no permiten el acceso a directo a las variables del módulo• Tampoco se permiten punteros en los argumentos y valores de retorno de las operaciones


• Cuando un objeto es distribuido– La referencia al objeto debe permitir acceder al objeto distribuido

• Arquitectura básica (CORBA)


• Adaptador de objetos (CORBA)– Constituye el medio de enlazar los sirvientes con el middleware

– Es una entidad que adapta la interfaz de un objeto a una interfaz diferente, que es la que espera el cliente

• Hay que tener en cuenta que el cliente y el objeto pueden estar escritos en lenguajes diferentes

• Mediante herencia o delegación permite que un cliente invoque servicios de un objeto sin conocer cuál es la interfaz real del objeto

– Permite establece políticas de activación

• Un sirviente representa todos los objetos

• Se crea un sirviente por objeto, bajo demanda

• Vinculación estática entre objeto y sirviente

• Ar

Comunicación en Grupo

Una hipótesis subyacente e intrínseca de RPC es que la comunicación solo es entre dos partes: el cliente y el servidor.

A veces existen circunstancias en las que la comunicación es entre varios procesos y no solo dos:

Un grupo de servidores de archivo que cooperan para ofrecer un único servicio de archivos tolerante a fallos: Sería recomendable que un cliente envíe el mensaje a todos los servidores para garantizar la ejecución de la solicitud aunque alguno falle.

RPC no puede controlar la comunicación de un servidor con muchos receptores, a menos que realice RPC con cada uno en forma individual.

“Un grupo es una colección de procesos que actúan juntos en cierto sistema o alguna forma determinada por el usuario”


Cuando un mensaje se envía, todos los miembros del grupo lo reciben.

Se trata de una comunicación uno – muchos ( un emisor – muchos receptores ),

Los grupos son dinámicos

La implantación de la comunicación en grupo depende en gran medida del hardware:

En ciertas redes es posible crear una dirección especial a la que escuchan varias máquinas ( multitransmisión ).

Las redes que no soportan multitransmisión operan con transmisión simple, son menos eficientes, ya que se deben enviar un paquete por cada máquina, y cada máquina debe verificarlo mediante su software si le corresponde o no.

En estos casos, conviene crear grupos pequeños.


Aspectos del Diseño de la Comunicación en Grupo● Grupos Cerrados vs Grupos Abiertos

● Grupos de Compañeros vs Grupos Jerárquicos

● Membresía del Grupo

● Direccionamiento al Grupo

● Primitivas Send y Receive

● Atomicidad

● Ordenamiento de Mensajes

● Grupos Translapados

● Escalabilidad

Documents

Unidad II