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)
Ejemplos
En 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.

Los principales tipos de paquetes son los siguientes:
REQ: Solicitud. REP: Respuesta. ACK: Reconocimiento.

De cliente a servidor. De servidor a cliente. De cualquiera de ellos a algún
El cliente desea servicio. Respuesta del servidor al otro.
cliente. El paquete anterior que ha
llegado.

AVA: ¿ Estás vivo ? IAA: Estoy vivo. TA: Intenta de nuevo.

De cliente a servidor. De servidor a cliente. De servidor a clientes.
Verifica si el servidor se ha El servidor no se ha El servidor no tiene espacio.
descompuesto. descompuesto.

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 en
el servidor
• En algunos sistemas, se utiliza el término skeleton
para 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 invocados
de forma local o remota por un proceso o por otro
objeto 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

Unidad II

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Unidad II

Más de Luis Morán

Unidad II