LABORATORIO #07

RPC

NOMBRE: ROBERT ARCE APAZA

CUI: 20090626
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

LABORATORIO 7: Llamadas a Procedimientos Remotos (RPC)

1. Objetivo:
Desarrollar las siguientes preguntas y proponer la solución mas apropiada.

2. INVESTIGAR Y RESPONDER:

PREMISA 1

En un sistema con RPC:

1. ¿cuál es la función del binder (servidor de nombres, enlazador dinámico)?

¿Cuáles son los servicios que deber ofrecer? ¿Cómo utilizan dichos servicios
el suplente del cliente y del servidor?
Enlazador dinámico (binder), es el servicio que mantiene una tabla de traducciones entre
nombres de servicio y direcciones. Incluye funciones para:
 Registrar un nombre de servicio
 Eliminar un nombre de servicio
 Buscar la dirección correspondiente a un nombre de servicio
Cómo localizar al enlazador dinámico:
 Ejecuta en una dirección fija de un computador fijo.
 El sistema operativo se encarga de indicar su dirección
 Difundiendo un mensaje (broadcast) cuando los procesos comienzan su ejecución.
 Binder utiliza servicios de:

2. ¿Qué diferencias existen entre un servidor de ficheros con estado y uno sin
estado?

Servidor de fiche sin estado: almacena información del cliente que se

conecta, presenta la ventaja que simplifica el diseño del servidor porque
no hay necesidad de asignar dinámicamente almacenamiento para tratar
las conversaciones en curso. Si un cliente desaparece en medio de la
transacción, ninguna parte del sistema
Desventaja: puede ser necesario incluir información adicional en cada
petición, y esta información adicional necesitará ser interpretada por el
servidor.

Servidor de fiche con estado: Mantienen la información de los

clientes que realizan solicitudes dicho servidor Si se cae un servidor con
estado se pierde toda información de los clientes y la recuperación de
dicha información queda a cargo de estos últimos, los mensajes son más
cortos
Página 2 de 10
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

3. ¿Qué es una operación autocontenida? ¿En que tipo de servidores de

ficheros se utiliza (con estado o sin estado)? ¿Por qué?
Cuando el cliente envía una solicitud a un servidor, este la lleva a cabo, envía la respuesta y
elimina de sus tablas internas toda la información relativa a dicha solicitud. Por lo tanto,
cada operación debe de ser autocontenida, es decir, debe incluir todos los datos necesarios
para que el servidor pueda satisfacer dicha petición sin necesidad de información adicional.
Por otro lado, en un servidor sin estado cada solicitud debe ser autocontenida, es decir,
debe incluir el nombre del archivo y toda la información para que el servidor realice el
trabajo.

4. ¿Qué es una operación idempotente?

En computación, una operación idempotente es aquella que no tiene ningún efecto

adicional si se llama más de una vez con los mismos parámetros de entrada. Por ejemplo, la
eliminación de un elemento de un conjunto puede considerarse una operación
idempotente en el conjunto.

5. ¿En qué consiste la semántica de coutilización UNIX? ¿Como intenta NFS

asegurar dicha semántica?
La semántica de coutilización especifica el efecto de varios procesos accediendo de forma
simultánea al mismo archivo. Sigue las siguientes reglas: Una lectura ve los efectos de
todas las escrituras previas, el efecto de dos escrituras sucesivas es el de la última de ellas;
los procesos pueden compartir el puntero de la posición; difícil de implementar en
sistemas distribuidos; mantener una copia única. Con respecto a sus sesiones se tiene.
Cambios a un archivo abierto son visibles únicamente en el proceso (nodo) que modificó el
archivo; una vez cerrado el archivo, los cambios son visibles sólo en sesiones posteriores;
múltiples imágenes del archivo; dos sesiones sobre el mismo archivo que terminan
concurrentemente: la última deja el resultado final; si dos procesos quieren compartir
datos deben abrir y cerrar el archivo para propagar los datos; no adecuado para procesos
que acceden de forma concurrente a un archivo; no existen punteros compartidos. NFS no
utiliza caché en los clientes para datos compartidos en escritura (Sprite). Los accesos
remotos se realizan sobre una única copia para asegurar la semántica UNIX.

PREMISA 2

Defina las operaciones típicas de un servidor de nombres utilizando como

lenguaje de definición de interfaces (IDL), el utilizado en las RPC de SUN.

El estándar CORBA , además de la arquitectura básica de objetos remotos y la

sintaxis de IDL, incluye especificaciones para varios servicios distribuidos de
objetos. El servicio de nombrado de objetos proporciona dos servicios: el Naming

Página 3 de 10
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

service, que encuentra objetos mediante el nombre, y el Trading service, que

encuentra objetos por tipo y propiedades. El Naming service funciona como una
guía de teléfonos y permite encontrar una única referencia usando un
identificador que funciona como una clave. El Trading service, por otro lado,
permite recuperar un conjunto de referencias que cumplen un criterio de
búsqueda, con un funcionamiento muy parecido al de las páginas amarillas.

El servicio Naming proporciona una correspondencia entre un nombre y una

referencia a un objeto. El almacenamiento de dicha correspondencia se denomina
como enlace (binding) de una objeto a un nombre, y la eliminación de la misma se
denomina desenlazar (unbinding) el nombre. Por otro lado, obtener una
referencia a objeto que se ha enlazado con un nombre se conoce como resolver
(resolve) el nombre.

Los traders son repositorios de referencias a objetos que son descritas por un tipo
de interfaz y por un conjunto de valores de propiedades. Tal descripción de la
interfaz se conoce como oferta de servicio (service offer). Cada oferta de servicio
tiene un tipo de servicio (service type), consistente en una combinación del tipo de
interfaz del objeto correspondiente y una lista de propiedades para las que la
oferta de servicio debería proporcionar valores.

PREMISA 3

Se desea implementar un servicio de correo electrónico mediante una

arquitectura cliente-servidor. El servicio ofrece la siguiente funcionalidad:
• Registrar un usuario: esta función permite a un usuario registrar una cuenta
de correo electrónico en un servidor. Un usuario solo puede acceder a las
funcionalidades del servidor de correo en caso de estar registrado
previamente.
• Enviar un correo electrónico: el cliente puede enviar un correo electrónico
a otro usuario. En caso de que el destinatario se encuentre registrado en el
mismo servidor, almacenará el mensaje en el buzón del destinatario. De lo
contrario, el servidor se encargará del reenvío del mensaje al servidor
destino correspondiente.
• Solicitar un correo electrónico: esta función devuelve el correo electrónico
más antiguo almacenado en el servidor, eliminándolo del mismo. En caso
de no existir ningún mensaje, el servidor indicará este hecho al cliente.

Los mensajes de correo electrónico contienen los siguientes elementos:

_ Nombre del cliente
_ Servidor del cliente
_ Nombre del destino
Página 4 de 10
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

_ Servidor del destino

_ Asunto
_ Mensaje
_ Adjunto

Todos los campos, excepto el adjunto, son campos de texto. El mensaje puede ser
de tamaño variable. Se puede adjuntar el contenido de un único fichero al
mensaje, si bien puede aparecer de forma opcional en el mensaje. El tamaño de
los datos también es variable.

Se pide:

a) Utilizando el lenguaje C++ o JAVA, implemente un programa cliente que

permita enviar un correo electrónico (sin adjunto) a un servidor,
considerando que se pasan en la línea de mandatos del programa los
siguientes campos:
· Nombre del cliente
· Servidor del cliente
· Nombre del destino
· Servidor del destino
· Asunto
· Mensaje

Código del Servidor

Para el lado del servidor se agrega un puerto en este caso agregamos el puerto
5000, este servidor estará atento hasta que un cliente se conecte.

Se establece la comunicación a partir de los InputStream

Página 5 de 10
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

InputStream se utiliza para recibir los mensajes por parte del cliente

CODIGO DEL CLIENTE:

INDICAMOS EL HOST A DONDE NOS VAMOS A CONECTAR

pasamos el host y el puerto

le establecemos los inputstream para la comunicación entre el cliente el servidor.

RESULTADOS
Iniciamos el Servidor

Iniciamos el Cliente : Estableciéndose la conexión de manera satisfactoria

Página 6 de 10
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

PREMISA 4

Dada la siguiente especificación de procedimiento remoto

procedure REMOTO (in int A, inout int B, out int C)

Suponiendo que se dispone de las primitivas de comunicación cliente/servidor con

las siguientes especificaciones y semánticas: void sendrecv(port p, char *buffer,
int *bufsize);

Permite a un proceso enviar al puerto p un mensaje con lo que hay en el buffer de

tamaño bufsize. A continuación el proceso se queda bloqueado en espera del
resultado del servicio.
Cuando el proceso se desbloquea se encuentra el resultado en buffer y bufsize
indica el tamaño del buffer resultado.
void receive(por p, char *buffer, int *bufsize);

Permite a un proceso recibir un mensaje por el puerto p. El proceso se bloquea

hasta que el mensaje llegue. El mensaje se almacena en buffer y bufsize indica el
tamaño del buffer resultado. void reply(char *buffer, int *bufsize);

Permite devolver un resultado en buffer con tamaño bufsize al proceso del que se
recibió el último mensaje. port createport();

Permite obtener un puerto único identificable en todo el sistema distribuido.

Suponiendo que el binder (servidor de nombres, enlazador) ofrece tres RPC cuyas
especificaciones son: registrar(in char nombre[longmax], int port p);
buscar(in char nombre[longmax], out port p); borrar(in
char nombre[longmax);

Sabiendo que nos encontramos en un sistema homogéneo, se pide:

Página 7 de 10
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

a) Diseñar y programar el suplente del cliente del procedimiento REMOTO,

especificando la secuencia de funciones que debe realizar y las estructuras
de datos que utiliza.

b) Diseñar y programar el suplente del servidor, especificando la secuencia

de funciones que debe realizar y las estructuras de datos que utiliza. El
diseño del servidor sólo debe considerar que se atiende una petición en
cada momento.
Página 8 de 10
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

c) Indicar si ha sido necesario un cambio de representación de los

parámetros y porqué.

d) ¿Se puede utilizar un servidor concurrente?

Si se desease realizar un servidor concurrente lo que debería pasar es que se cree
Página 9 de 10
UNSA FIPS EPIS Sistemas Distribuidos: Laboratorio

un hilo en cada solicitud de cliente.

REFERENCIAS

[1]. https://www.monografias.com/trabajos106/llamadas-procedimientos-
remotos/llamadas-procedimientos-remotos2.shtml
[2]. https://www.it-swarm.dev/es/language-agnostic/que-es-una-operacion-
idempotente/967304264/
[3]. https://books.google.com.pe/books?
id=fRK3lbTrNy4C&pg=PA363&lpg=PA363&dq=Qu%C3%A9+es+una+operaci
%C3%B3n+autocontenida+sistemas+distribuidos&source=bl&ots=0wzdVqI57H&sig=A
CfU3U16XP7kJUdGfRGzW23zvj_2-
ZyK0A&hl=es&sa=X&ved=2ahUKEwjshfHPxMvqAhU5GbkGHWZ7CKcQ6AEwA3oECAg
QAQ#v=onepage&q=Qu%C3%A9%20es%20una%20operaci%C3%B3n
%20autocontenida%20sistemas%20distribuidos&f=false
[4]. http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/soa/soa_ficheros.pdf
[5]. https://www.monografias.com/trabajos105/introduccion-sistemas-
distribuidos/introduccion-sistemas-distribuidos.shtml

Página 10 de 10