informe sist. distribuidos

5/11/2018 informe sist. distribuidos - slidepdf.com

http://slidepdf.com/reader/full/informe-sist-distribuidos 1/14

Sistemas

distribuidos

RPC

Nombre: Jean Paul Hurtado PincheiraProfesor: Alejandro Mellado

Fecha: miércoles, 26 de octubre de 2011



1

INTRODUCCION

Otro paso en el diseño de un sistema operativo distribuido plantea las

llamadas a procedimientos remotos o RPCs. Los RPC amplían la llamada

local a procedimientos, y los generalizan a una llamada a unprocedimiento localizado en cualquier lugar de todo el sistema

distribuido. En un sistema distribuido no se debería distinguir entre

llamadas locales y RPCs, lo que favorece en gran medida la transparencia

del sistema.

Una de las dificultades más evidentes a las que se enfrenta el RPC es el

formato de los parámetros de los procedimientos. Un ejemplo para ilustrar

este problema es la posibilidad de que en un sistema distribuido formado

por diferentes tipos de ordenadores, un ordenador con formato little

endian llamara a un procedimiento de otro ordenador con formato bigendian, etc. Este problema se podría solucionar si tenemos en cuenta que

ambos programas conocen el tipo de datos de los parámetros, o

estableciendo un estándar en el formato de los parámetros, de forma que

sea usado de forma única.

Otro problema de peor solución es el paso de apuntadores como parámetros.

Debido a que los apuntadores guardan una dirección del espacio de

direcciones local, el procedimiento que recibe el apuntador como

parámetro no puede usar inmediatamente el apuntador, ya que no tiene

acceso a los datos, que para él son remotos. En el tema 7 se describirá

la memoria compartida, que propone una solución a este problema.

Por último queda por solucionar la tolerancia a fallos. Una llamada a un

procedimiento remoto puede fallar por motivos que antes no existían, como

la pérdida de mensajes o el fallo del cliente o del servidor durante la

ejecución del procedimiento.

La limitación del RPC más clara en los sistemas distribuidos es que no

permite enviar una solicitud y recibir respuesta de varias fuentes a la

vez, sino que la comunicación se realiza únicamente entre dos procesos.

Por motivos de tolerancia a fallos, bloqueos, u otros, sería interesantepoder tratar la comunicación en grupo.



2

Parte I

1. ¿Cuáles son las operaciones básicas de RPC (Llamadas a procedimientosremotos)?

Proceso llamador (cliente):

Proceso realiza la llamada a una función.

Llamada empaqueta id. de función y argumentos en mensaje

Envía mensaje a otro proceso.

Queda a la espera del resultado.

Al recibirlo, lo desempaqueta y retorna el valor

Proceso llamado (servidor):

Recibe mensaje con id. de función y argumentos.

Se invoca función en el servidor.

Resultado de la función se empaqueta en mensaje

Se transmite mensaje de respuesta al cliente.

Operación básica del RPC

Una llamada convencional a un procedimiento, es decir en una sola

máquina, funciona de la siguiente manera:

Sea count = read (fd, buf, nbytes); donde:

fd es un entero; buf es un arreglo de caracteres; nbytes es otro

entero.

El programa llamador coloca los parámetros en la pila.

El procedimiento llamado desde el programa llamador se carga en la

memoria.

Después de que read termina su ejecución:

o Coloca el valor de regreso en un registro.

o Elimina la dirección de regreso.

o Transfiere de nuevo el control a quien hizo la llamada.

o Quien hizo la llamada elimina los parámetros de la pila y

regresa a su estado original.



3

2. En que capa de la pila de protocolos OSI se encuentran las RPCLas RPC se encuentran en la capa de sesión de la pila de protocolos

OSI ya que esta establece, mantiene y termina las comunicaciones que

se forman entre dispositivos.

3. ¿Qué pasos se realizan en una RPC (Llamada a procedimientos remotos)?

Pasos que realiza una RPC (Llamada a procedimientos remotos):

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.

4. ¿Cómo son las transferencias de parámetros en RPC?



4

El empacamiento de parámetros en un mensaje se llama ordenamiento de

parámetros. El mensaje también contiene el nombre o número del

procedimiento por llamar; el servidor podría soportar varias llamadas y

se él tiene que indicar cuál de ellas se necesita.

Cuando el mensaje llega al servidor:

• El resguardo (stub) lo examina para ver cuál procedimientonecesita.

• Lleva a cabo la llamada apropiada.

La llamada real del resguardo al servidor es similar a la llamada

original del cliente, excepto en que los parámetros son variables

inicializadas a partir del mensaje recibido, en vez de ser constantes.7

Los elementos del mensaje corresponden a:

• Identificador del procedimiento.

• Parámetros.

Un mensaje que corresponda a un procedimiento remoto con “n” parámetros

tendrá “n + 1” campos:



5

• Uno para identificar al procedimiento.

• Uno para cada uno de los “n” parámetros.

Un aspecto importante es determinar cómo se debe representar la

información en los mensajes:

• Una forma es:

— Diseñar un estándar de red o forma canónica para los enteros,

caracteres, booleanos, número de punto flotante, etc.

— Pedir a todos los emisores que conviertan sus representaciones internas

a esta forma durante el ordenamiento.

Es importante saber la organización del mensaje y la identidad del

cliente.

También es importante determinar de dónde provienen los procedimientos

resguardo:

• En muchos sistemas se generan automáticamente. • Dada una especificación del procedimiento servidor y las reglas

de codificación, el formato del mensaje queda determinado de manera

única.

Es posible tener un compilador que:

• Lea las especificaciones del servidor.

• Genere un resguardo del cliente que empaque sus parámetros en el

formato estándar de los mensajes.

• Genere un resguardo del servidor que los desempaque.

• Llame al servidor.

Un aspecto también muy importante es cómo se transfieren los apuntadores,

pues un apuntador solo tiene sentido dentro del espacio de direcciones

del proceso en el que se utiliza.

Una solución es copiar en el mensaje la estructura para la cual se

utiliza el apuntador y enviarlo al servidor, en tal caso los cambios que

realice el servidor mediante el apuntador afectarán irectamente al

buffer de mensajes en el resguardo del servidor.

5. ¿Qué sistemas operativos usan RPC?Sistemas Unix y Windows.

6. ¿Qué protocolos implementan las RPC?Protocolos que implementan las RPC:

Protocolos orientados a la conexión

Se establece una conexión entre cliente y servidor.

Todo el tráfico en ambas direcciones utiliza esa conexión.



6

Se maneja a un nivel inferior mediante el software que soporta la

conexión.

Es muy útil para redes de área amplia o extendida (WAN).

Es desventajoso en redes de área local (LAN) debido a la pérdida de

performance que significaría procesar software adicional para

aprovechar la ventaja de no perder los paquetes; esto difícilmentese precisa en las LAN.

Muchos sistemas distribuidos en áreas geográficas reducidas

utilizan protocolos sin conexión.

Protocolo estándar de propósito general

La utilización del protocolo estándar IP (o UDP , integrado a IP) posee

las siguientes ventajas:

El protocolo ya fue diseñado, lo que ahorra trabajo.

Se dispone de muchas implantaciones, lo que también ahorra trabajo.

Los paquetes IP se pueden enviar y recibir por casi todos lossistemas UNIX.

Los paquetes IP y UDP se pueden transmitir en muchas de las redes

existentes.

7. ¿Qué servicios hacen uso de los RPC? DCE/RCP (Distributed Computing Environmen RPC): RPC definido por la

Open Software Foundation.

Java-RMI: invocación de los métodos en Java

CORBA (Common Object Requesting Broker Architecture): soporta la

invocación de métodos remotos bajo un paradigma orientado a objetos

en diversos lenguajes.

SOAP (Simple Object Access Protocol): protocolo RPC basado en el

intercambio de datos (parámetros + resultados) en formato XML.

DCOM (Distributed Component Object Model): Modelo de objetos de

componentes distribuidos por Microsoft, con elementos de DCE/RCP.

NET Remoting: infraestructura de invocación remota de .NET.

8. ¿Cuáles son las áreas de problemas en RPC. ?La RPC mediante el modelo C - S se utiliza ampliamente como base de los

S. O. distribuidos. Lo ideal es que la RPC sea transparente:



7

• El programador no debe poder decir si los procedimientos de biblioteca

son locales o remotos.

• El programador debe poder escribir procedimientos sin importar si serán

ejecutados en forma local o remota.

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

única cpu no debe ir acompañada de una serie de reglas que:

— Prohíban construcciones antes válidas.

— Exijan construcciones que antes eran opcionales.

La mayoría de los S. O. distribuidos no cumplen totalmente con estos

criterios de transparencia. Uno de los problemas es el de las variables

globales:

• Ej.: en UNIX existe una variable global errno:

— Luego de una llamada incorrecta al sistema, contiene un código

que indica lo que estuvo mal.

— Su existencia es información pública, ya que el estándar oficial

de UNIX, Posix, exige que sea visible en uno de los archivos de

encabezado imperativos, errno.h.

— No se permite que una implantación lo oculte de los

programadores.

— Supongamos que un programador escribe dos procedimientos quetienen acceso directo a errno:

∗ Uno se ejecuta en forma local, el otro en forma remota.

∗ Uno de los procedimientos tendrá un acceso incorrecto.

— El problema es que no se puede implantar el permiso para el

acceso irrestricto de los procedimientos locales a las variables globales

remotas y viceversa.

— La prohibición del acceso irrestricto mencionado viola el

principio de transparencia:

∗ Los programas no deben actuar de manera distinta según RPC.

Otro problema son los lenguajes débilmente tipificados, como por ejemplo,

“C”:

• En un lenguaje fuertemente tipificado, como “Pascal”:



8

— El compilador y el procedimiento resguardo conocen todo lo relativo a

todos los parámetros.

— El resguardo puede ordenar los parámetros sin dificultad.

• Con “C” se puede trabajar con arreglos sin especificar su tamaño:

— El resguardo del cliente no puede ordenar los parámetros:

∗ No puede determinar su tamaño.

— Una solución consiste en que el programador defina el tamaño máximo

cuando escriba la definición formal del servidor:

∗ Resta flexibilidad y puede generar problemas de memoria.

Un problema adicional consiste en que no siempre es posible deducir los

tipos de los parámetros:

• Ni siquiera a partir de una especificación formal del propio código, en

especial considerando “C”.

• La exclusión de “C” cuando se utilice RPC violaría la transparencia.



9

Parte II

2.1 intercambio de claves con ssh.

Lo que primero debemos hacer en nuestras máquinas virtuales es instalarel servicios ssh que se va a ocupar:

sudo apt-get install ssh

ip server: 10.0.0.4

ip cliente: 10.0.0.3

luego creamos la clave pública en nuestra maquina cliente con el comando: ssh-keygen –t rsa

Luego autorizamos a la maquina cliente que pueda acceder al programa que

ocuparemos para comprobar el funcionamiento del RPC. El programa que se

hizo es el siguiente:



10

El comando ssh 10.0.0.4 ./contador.pl ejecutara el programa contador.pl

desde el cliente que está guardado o creado en la maquina server, en

ningún caso está en el cliente.

Y vemos que hemos accedido desde una maquina a otra a través de un RPC.

2.2 Aplicaciones que ocupan RPC.

2.2.1 NFS.

Instalamos nfs en el server:

sudo apt-get install nfs-kernel-service.Luego editamos el archive de configuracion de nfs:

nano /etc/exports

Acá le hemos dicho que compartiremos el directorio /home/ejemplo con

todos los que deseen conectarse con el server.Debemos reiniciar el servicio nfs cada vez que editamos el archivo

/etc/exports. /etc/init.d/nfs-kernel-server restart



11

Luego desde la maquina cliente vemos que archivo se esta compartiendo

desde el cliente. Showmount –e 10.0.0.3 (ip del server nfs).

Y ahora vemos el punto de montado del archivo.

2.2.2 samba

Lo primero es instalar samba, luego establecemos la contraseña del root

escribiendo passwd. Luego agregamos el root a samba además de crear unnuevo usuario a samba, los comandos son los siquientes

Smbpasswd –a rootSmbpasswd –a alumno

Luego abrimos y editamos el archive de configuracion de samba.

Hacemos los siguientes cambios en el archivo:- Dentro de la etiqueta [global] en workgroup = DOMINIO / que es el

nombre del dominio.- Dentro de la etiqueta [global] en win support quitamos el # y colocamos

yes, quedando “win support = yes”

- Dentro de la etiqueta [Networking] quitamos el; y queda, interfaces =192.168.1.0/24 eth0 que es el rango de ip de la red y la interfaz que se

usa.

- Dentro de la etiqueta [Authentication] en security = pondremos user

- Dentro de la etiqueta [Domains] quitamos el; en la línea domain logons

= yes y añadimos debajo de esta línea:

domain master = yeslocal master = yes- Dentro de la etiqueta [Domains] quitamos el # en la línea logon path =

\\%N\%U\profile

- Dentro de la etiqueta [Domains] quitamos él; en la línea logon drive =H:

- Dentro de la etiqueta [Domains] quitamos el # en la línea logon home =\\%N\%U



12

- Dentro de la etiqueta [Domains] quitamos él; en la línea add machine

script = /usr/sbin/useradd -g machines -c "%u machine account" -d

/var/lib/samba -s /bin/false %u- Dentro de la etiqueta [homes] quitamos él; a la misma etiqueta [homes]

y en la línea browseable = no y añadimos debajo writeable = yes- Dentro de la etiqueta [netlogon] quitamos él; a la misma etiqueta

[netlogon] y en todas sus líneas- Dentro de la etiqueta [profiles] quitamos él; a la misma etiqueta[profiles] y en todas sus líneas

Y guardamos los cambios.

Hacemos un testparm para validar sintácticamente el fichero smb.conf.



13

Conclusión.

En el presente trabajo se han presentado las características técnicas más

importantes e implementaciones hechas por medio de comandos, delmecanismo de Llamadas a Procedimientos Remotos (RPC, Remote Procedure

Calls).

RPC es una tecnología, tradicionalmente empleada en ambiente UNIX, que

permite el desarrollo de aplicaciones cliente/servidor basadas en elparadigma procedimental.

Con el advenimiento de implementaciones para plataforma Windows, así comopara Java, se concibe a RPC como una tecnología de integración entre

plataformas disimiles de hardware y software.

bibliografía

http://www.reubuntu.com/linux/servidor-ssh-public-key/

http://www.slideshare.net/dianapaolalozano/rpc-llamadas-remotas

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/sistope

2.PDF



http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/sistope2.PDF






Documents

informe sist. distribuidos