Práctica Remote Procedure Call (Sistemas Operativos)

Ejercicio 01:

Pascal tiene una construcción llamada variante de registro, en la que un campo de un registro puede contener una de varias alternativas. Durante la ejecución, no existe una forma segura de decir cuál de ellas se encuentra en dicho campo. Tiene esta característica de Pascal algunas implicaciones para las llamadas a procedimientos remotos?
Explique su respuesta.
Si se necesita enviar este campo a traves de una llamada RPC, se debe saber como serializar el mismo (convertirlo a una cadena de bytes). Si no se conoce el contenido, puede resultar en que no se pueda serializar correctamente, produciendo problemas asi si se lo intentase enviar al servidor por RPC.

Ejercicio 02:

La secuencia usual de los pasos de RPC incluye una interrupción al núcleo para que el mensaje se envíe del cliente al servidor. Supongamos que existe un circuito coprocesador especial para realizar la E/S de la red y que este circuito es directamente direccionable desde el espacio del usuario. Tendría importancia esto ? Cuáles serían los pasos de RPC en este caso ?

Si, tiene importancia, ya que no haria falta interrumpir al nucleo para hacer el envio, sino directamente hacer una llamada al coprocesador con los datos a enviar y q se encargue de enviar y recibir sin problema. Al ser direccionable desde el espacio de memoria del usuario, se pueden enviar sin problemas los parametros.

Ejercicio 03:

El circuito SPARC utiliza una palabra de 32 bits en formato big endian. Si una SPARC envía el entero 2 a una 486, que es little endian, cuál es el valor numérico que vería?

Rta: 02 00 00 00, o sea "al reves" de a byte.

Es decir, el valor numérico que vería sería 2^25 = 33554432 ?.

Ejercicio 04:

4) Una forma de manejar la conversión de parámetros en los sistemas RPC es que cada máquina envíe los parámetros en su propia representación, mientras que la otra realice la traducción, en caso necesario. En el texto se sugiere que el sistema original se podría indicar mediante un código en el primer byte. Sin embargo, puesto que precisamente el problema es localizar el primer byte de la palabra podría funcionar este método ? es incorrecto el apunte?
Si, es correcto. El problema de big endian vs little endian es cuando se tiene un "entero" de tamaño de 2 o mas bytes, como estan ordenados internamente los bytes que lo componen. Un Byte es "representado igual" en las dos arquitecturas.

Ejercicio 05:

En la llamada al binder se tiene como uno de sus parámetros al identificador único. Es esto en realidad necesario ? Después de todo, también se proporcionan el nombre y la versión, que identifican de manera única al servicio.

Si, ya que el identificador unico es usado por el kernel del server para direccionar automaticamente el mensaje al server correcto.

Ejercicio 06:

La lectura del primer bloque de un archivo desde un servidor remoto de archivos es una operación idempotente. Qué ocurre con la escritura del primer bloque ?

La escritura no es una operacion idempotente. Si se pierde el mensaje de requerimiento del cliente al server o el mensaje de respuesta del server se pierde, el cliente, mediante un timer, envia de nuevo el requerimiento. Si pasa eso, puede llegar a pasar q el server haya procesado la primera vez y lo vuelva a procesar.

Ejercicio 07:

7) Para cada una de las siguientes aplicaciones cuál de las semánticas "al menos una vez" o "a lo sumo una vez" sería la mejor ? Analice.
a) lectura y escritura de archivos desde un servidor de archivos: "al menos una vez" (Siempre y cuando la escritura no sea un append)
b) compilación de un programa: "al menos una vez"
c) sistema electrónico de transferencia de fondos: "a lo sumo una vez"

Ejercicio 08:

Suponga que el tiempo de realizar una RPC nula (es decir 0 bytes de datos) es de 1.0 milisegundos, con 1.5 milisegundos adicionales por cada 1 K de datos. Cuánto tarda la lectura de 32 K del servidor de archivos en una RPC de 32 K ? Qué ocurre en el caso de 32 RPC de 1 K ?

49ms para una RPC de 32K. (1.5ms/K x 32K + 1.0ms = 49ms)

80 ms para 32 RPC de 1K. ((1.5ms/K x 1K + 1.0ms) x 32 = 80ms)

Ejercicio 09:

9) RPC es:
a) un mecanismo que permite que un proceso se comunique explícitamente con otro proceso remoto
b) un mecanismo que permite tratar llamadas a procesos remotos como si fueran locales
c) un mecanismo que permite que dos procesos estén ejecutando simultáneamente
d) todas
e) ninguna

RPC es b) un mecanismo que permite tratar llamadas a procesos remotos como si fueran locales

Ejercicio 10:

Un stub cliente es:
a) una librería que provee RPC que se linkedita con el programa cliente y maneja el empaquetamiento de los parámetros y el armado del mensaje
b) un proceso del S.O. que es llamado por el programa cliente y que maneja el empaquetamiento de los parámetros y el armado del mensaje
c) una porción de código que se compila junto con el programa cliente y maneja el empaquetamiento de los parámetros y el armado del mensaje
d) todas
e) ninguna

Un stub cliente es: c) una porción de código que se compila junto con el programa cliente y maneja el empaquetamiento de los parámetros y el armado del mensaje

Ejercicio 11:

11) RPC:
a) no maneja el pasaje de parámetros por referencia
b) utiliza el mecanismo de copy/restore para manejar los parámetros por referencia
c) maneja las referencias empaquetando directamente los punteros
d) todas
e) ninguna

RPC: b) utiliza el mecanismo de copy/restore para manejar los parámetros por referencia

Ejercicio 12:

Cómo tienen que ser la operaciones para que se pueda aplicar la semántica "at least once" (al menos una vez) sin problemas ?

At Least Once : (1 o más) Consiste en esperar a que el Server levante de nuevo, y mandar la operación otra vez. Esto es conveniente cuando se trata de operaciones idempotentes.

Ejercicio 13:

Indicar si las siguientes afirmaciones son falsas o verdaderas : a) antes de bloquearse en espera de requerimientos, el server realiza un export de su interfaz.

b) cada vez que el cliente llama a una misma función remota se accede al binder

c) si se cae el server hay que implementar algún mecanismo que elimine las computaciones huérfanas

d) es necesario que exista un stub servidor por cada función remota que se quiera implementar

CREO:

a) V

b) F

c) V

d) V

Ejercicio 14:

Describa qué son y qué función cumplen los stubs cliente y servidor ? Los stub son una porción de código que se compila junto con el programa cliente y servidor y maneja el empaquetamiento de los parámetros y el armado del mensaje.

Ejercicio 15:

15) Ordenar la siguiente secuencia de acciones
a) el kernel remoto pasa el mensaje al stub server
b) el stub cliente empaqueta los parámetros y arma el mensaje que pasa al kernel local
c) el kernel local pasa el mensaje al stub cliente
d) el server ejecuta el requerimiento y genera un reply
e) el kernel remoto realiza el send del mensaje al kernel local
f) el stub cliente desempaqueta y pasa los datos al programa cliente
g) el kernel local realiza el send del mensaje al kernel remoto
h) el stub server desempaqueta los parámetros y los pasa al server
i) el programa cliente llama a un procedimiento (que no sabe que es remoto)
j) el stub server empaqueta el resultado y lo pasa al kernel

Ordenadas son:
i) el programa cliente llama a un procedimiento (que no sabe que es remoto)
b) el stub cliente empaqueta los parámetros y arma el mensaje que pasa al kernel local
g) el kernel local realiza el send del mensaje al kernel remoto
a) el kernel remoto pasa el mensaje al stub server
h) el stub server desempaqueta los parámetros y los pasa al server
d) el server ejecuta el requerimiento y genera un reply
j) el stub server empaqueta el resultado y lo pasa al kernel
e) el kernel remoto realiza el send del mensaje al kernel local
c) el kernel local pasa el mensaje al stub cliente
f) el stub cliente desempaqueta y pasa los datos al programa cliente

Ejercicio 16:

RPC utiliza el mecanismo de Binding Dinámico, explique qué significa esto.

RTA: Cap. 22 - Pag. 3

Ejercicio 17:

Indique cuáles de las siguientes afirmaciones son falsas :
a)- en un esquema distribuido con RPC los parámetros se traducen a un formato independiente del hardware en el que se ejecuta.
b)- la transformación a formatos independientes en sistemas distribuidos con RPC es altamente eficiente
c)- existe un compilador que genera tanto el código del stub cliente como el del stub servidor.

a) Depende de la implementacion. A veces si, a veces solo se avisa que arquitectura es la del cliente para ver los pasos siguientes.

b) F. Es ineficiente, ya que se agrega el overhead de transformar el mensaje standard al especifico de la maquina receptora.

Depende de como se piense la pregunta:

c) F. El compilador genera, en la maquina cliente el stub cliente, y en el server, otro compilador genera el stub servidor. Como son dos programas diferentes, se compilan por separado, uno en el cliente y otro en el server.

c) V. (Cap 22 Pag 3) : La generación de un código RPC se hace automáticamente. Se define un archivo donde se especifica el nombre y los tipos de parámetros de las funciones remotas al cliente, como el número de programa (o server). Esto se logra teniendo un compilador que lee las especificaciones y genera tanto el stub cliente como el stub del servidor. El código fue generado para ambos stubs a partir de la misma especificación con lo cual reduce las pro- babilidades de error haciendo transparente las dificultades del pasaje de términos.

(Es decir, el compilador es el mismo, está repetido en dos maquinas).

Ejercicio 18:

La siguiente afirmación es falsa, justifique porqué : - En un esquema que opera con RPC la dirección del servidor se encuentra hardwired en cada uno de los clientes.

Por que existe "Dynamic Binding".

Ejercicio 19:

Explique cómo interactúan los stubs del cliente y del servidor para completar una RPC. Los stubs cliente y servidor no interactuan entre si, sino que lo hacen con los procesos y los kernels. Ver Ej. 15.

Ejercicio 20:

Cómo sabe el cliente en dónde se encuentra el servidor en un esquema que utiliza RPC ? Por que el server, al levantar, exportó todos los servicios que provee y la manera de indentificarlos. Ver "Dynamic Binding".

Ejercicio 21:

Si se realiza una llamada RPC a un procedimiento que incrementa en uno el valor de cada parámetro, por ejemplo incr(i,j). Si i vale inicialmente 0, qué valor tendrá si se utiliza: a)- llamada por referencia b)- llamada por copia-restauración Si se utiliza incr(i,i) c)- llamada por referencia d)- llamada por copia-restauración

Ver Cap. 22 - Pag. 3 (justo antes de 22.4).

Ejercicio 22:

En un sistema Cliente/Servidor que ejecuta sobre una red local en etapa de instalación, qué tipo de direccionamiento utilizaría y porqué ? (Opciones: machine_process, machine_local_id, name_server)

Ejercicio 23:

Es posible realizar un RPC en una misma máquina (que el servidor y el cliente estén en la misma máquina) ? No, justifique porqué ? Si, cómo se realiza ?

Si, ya que el stub servidor esta escuchando en la maquina. Cuando se manda el paquete al proceso remoto, la propia maquina responde q esta ahi, y se ejecuta. Aunque no tenga mucho sentido hacerlo por RPC, no es imposible.

Ejercicio 24:

Indique qué método de pasaje de parámetros es el más conveniente en la implementación de RPC's y justifique el porqué.

Copia/Restauración.
Es el unico método viable ya que la memoria es distinta en el cliente y en el servidor, por lo tanto no se puede pasar por referencia, y en necesario serializar (empaquetar) los datos, por lo que no se puede simplemente copiar.

Ejercicio 25:

Comente cuál es el problema que se plantea en RPC's en cuanto a la localización del servidor. Indique alguna solución.

Pueden ser varios:

Si esta implementado con machine.number, el problema es q se pierde la transparencia que se quiere lograr con RPC.

Si esta implementado mediante transmisiones, genera carga adicional al sistema el hecho de encontrar el servidor enviando el mensaje de localizacion a todos lados.

Si esta implementado con un servidor de nombres, el problema reside en que es un componente centralizado y si bien se puede duplicar, presenta problemas en el mantenimiento de la consistencia.

Ejercicio 26:

Indique un problema en los Protocolos de Chorro (blast protocol) que no ocurra en los de Detenerse y Esperar.

En DyE uno espera a recibir la notificacion de la recepcion del mensaje, y recien ahi envia el siguiente. Esto garantiza una coherencia en el envio.

En Blast, se envian todos juntos. Si se pierde un paquete, el servidor puede optar por abandonar todo, no hacer nada y esperar que el cliente haga un receso y vuelva a enviar todo el mensaje, o bien guardar lo que llego bien y pedir que se retransmita el paquete perdido (Repeticion selectiva).

OTRO: (Cap 22 Pag 5): Existe otra consideración más importante que es el control de flujo. Hay veces que el chip de interfase de red no permite recibir un número ilimitado de paquetes adyacentes debido a la capacidad del mismo. Cuando un paquete llega a un receptor que no lo puede recibir se produce un error de sobreejecución (overrun error) y el paquete se pierde (esto puede ocurrir en protocolos a chorro pero nunca en detenerse y esperar).

Ejercicio 27:

Indique la semantica RPC en presencia de fallas

Cap 22 pag 5

La transparencia que proporciona RPC en cuanto a que las llamadas remotas parecen llamadas locales se ve afectada con el surgimiento de fallas, pues son difíciles de enmascarar. Existen 5 tipos de problemas que pueden ocurrir, a saber :

1) El cliente no puede localizar al server.
Esto provoca que el programador deba que codificar qué hacer en caso de tener un error en el bind al server. (procedimiento de EXCEPCIÓN)

2) Se pierde el mensaje de requerimiento del cliente al server.
Para estos casos el kernel pone un timer cuando se envía un mensaje y si no recibe un ACK dentro de un lapso, se retransmite el mensaje. Si realmente se perdió el mensaje, el server toma la retransmisión del requerimiento como la original.

3) El mensaje de respuesta del server se pierde.
Se depende nuevamente del timer, aunque es más difícil de implementar ya que el kernel del cliente no sabe si sucede 2) o 3) o el server está lento. Existen operaciones que son idempotentes (tales que no causan daño alguno el repetirlas o sea que no cambian su valor) como por ejemplo leer una cadena de bytes de un archivo. El problema es con las otras operaciones (por ejemplo la transferencia electrónica de fondos), y una solución para esto, es que el kernel ponga un número de secuencia en el mensaje así se podrán identificar cuál es original y cual la copia y cotejar si se ha procesado el pedido. Otra solución es ponerle a cada mensaje un header que identifique si es el original o una copia. La idea es que una solicitud original siempre puede ejecutarse inmediatamente pero las solicitudes que son copias requieren de mayor cuidado.

4) El server se cae luego de recibir el requerimiento.
Esto tiene un problema un poco mayor. Como ser:
a) si el server ejecutó el pedido y se cayó antes de enviar la respuesta en cuyo caso el cliente debería aplicar alguna rutina de manejo de excepciones, y
b) si el server se cayó justo antes de ejecutar el pedido, situación que el cliente debe abordar reiterando el pedido al servidor.
El núcleo del cliente no puede saber cuál de las dos situaciones ha ocurrido. Hay cuatro formas de solución:
1) At Least Once : (1 o más) Consiste en esperar a que el Server levante de nuevo, y mandar la operación otra vez. Esto es conveniente cuando se trata de operaciones idempotentes.
2) At Most Once : (0 o 1) Se da por vencido al instante y reporta un error. Asegura que el RPC se hace a lo sumo una vez o puede no completarse nunca.
3) Exactly Once : Es la deseable pero no hay forma de garantizarlo. Siempre va a existir un punto en donde se pierde todo rastro de lo hecho hasta el momento.
4) Don't Know?? : Si se cae un server, el cliente no promete nada, la operación se pudo ejecutar de 0-n veces. Fácil de implementar.

5) El cliente se cae.
Esto implica que nadie va e estar esperando la respuesta del server quedando computaciones huérfanas (ORPHANS) que utilizan CPU, pueden lockear archivos, y utilizar recursos cuando realmente no se necesita. Además si el cliente se recupera rápidamente y se retransmitió el mensaje, puede recibir dos mensajes respuesta.
a) Una solución puede ser que el stub cliente lleve un log de los mensajes que va enviando, así cuando bootea se chequea el log y se mata explícitamente aquellos ORPHANS que hubieran quedado(EXTERMINACION). Una desventaja de esto es que hay que escribir a disco cada vez. Y puede no funcionar, ya que un RPC puede a su vez hacer otro RPC y crear GRANDORPHANS (huérfanos de huérfanos), y demás descendientes que son imposibles de localizar.
b) Otra solución se la conoce como REENCARNACIÓN que divide el tiempo en generaciones numeradas secuencialmente. O sea cuando un cliente rebootea, hace broadcast de un mensaje indicando a todas las máquinas que se inicia una nueva generación. Al recibir este mensaje, cada máquina se encarga de hacer un kill a todos aquellos procesos pertenecientes a una generación anterior. Si queda vivo algún ORPHAN, cuando llegue su reply inmediatamente se va a reconocer que es inválido ya que es de otra generación.
c) Se basa en la anterior y se llama REENCARNACIÓN SUAVE. Cuando llega un broadcast indicando una nueva generación, la máquina ubica a todas las computaciones remotas y chequea si todavía sigue existiendo su dueño. Si no lo encuentra recién ahí toma la decisión de eliminarlo.
d) Se la conoce como EXPIRACIÓN, se le da un lapso de tiempo a cada cómputo RPC para que realice su trabajo. Si este no puede terminar, tiene que pedir explícitamente que se le agrande el quantum.
El problema aquí es la elección de un valor adecuado del valor del lapso de tiempo.
Todas estas soluciones no son recomendables en la práctica. La eliminación de un huérfano puede tener consecuencias imprevisibles. Por ejemplo, supongamos que un huérfano haya bloqueado uno o más registros de una base de datos, si se lo elimina súbitamente estos bloqueos pueden permanecer para siempre. Además un huérfano podría crear entradas en alguna ubicación remota de procesos que se ejecutarán en un futuro con lo cual la eliminación del padre no aseguraría la eliminación de todos sus rastros.

Ejercicio 28:

Explique todas las formas de pasaje de parámetros que conoce en llamadas RPC.

Recordemos que en forma estándar existen dos formas de pasar parámetros en una llamada a una subrutina. Uno de ellos es pasar parámetros por valor en cuyo caso el dato que se desea informar al procedimiento se copia directamente (usualmente se coloca en el stack) y la otra forma es por referencia en cuyo caso lo que se copia hacia el procedimiento es un puntero que indica la dirección en dónde se encuentra almacenada el dato en sí. Existe una tercera forma que se denomina copia/restauración en la cual el dato se copia como en el pasaje por valor pero el procedimiento invocado luego lo copia de regreso después de la llamada escribiendo sobre el valor original.

Sin embargo en un sistema distribuido de gran tamaño es común que se encuentren diferentes tipos de máquinas (Pcs, mainframes con diferente tipo de representación interna -ASCII, EBCDIC-); también se plantea un problema con los números de punto flotante y con la forma de numerar los bits en algunas máquinas (de derecha a izquierda little endian o de izquierda a derecha big endian).
Para solucionar este problema, se estableció una forma canónica para el pasaje de parámetros. Este método obliga a que el stub cliente o el servidor realicen conversiones de los mensajes recibidos o enviados siempre lo cual resulta ineficiente si ambos extremos de la comunicación proveen en forma nativa el mismo tipo de representación de datos. Otra solución es indicar en el mensaje el tipo de máquina que lo está enviando, y no realizar ningún tipo de transformación previa. Si el receptor es el mismo tipo de máquina, toma los parámetros sin ningún inconveniente, de otra forma hace la conversión que sea necesaria.
Otro problema en el pasaje de parámetros es si se pasan punteros, ya que un puntero solo tiene sentido en el espacio de direccionamiento (address space) en donde se encuentra el proceso.
Una solución es prohibir el pasaje de punteros y parámetros por referencia. Otra solución puede ser pasar los elementos del vector en su totalidad dentro del mensaje, así el stub del servidor podría llamar a la rutina apuntando a un buffer propio, donde guardó el vector que le pasaron como parámetro. Si el server escribe sobre esta parte de la memoria, el stub del servidor tiene que encargarse de devolverlo al cliente, así puede copiarlo modificado. Luego los parámetros por referencia son reemplazados por un mecanismo de copy/restore. Para optimizar más esta solución, bastaría con que el stub sepa si el buffer es un parámetro de Entrada (no necesita ser devuelto al cliente), Salida (no necesita ser enviado al servidor) o E/S.
Existe una forma de manejar el caso de apuntadores para estructuras de datos complejas. Aquí lo que se realiza es enviar el apuntador mediante la colocación en un registro y realizando un direccionamiento indirecto. La referencia inversa lo que realiza es enviar un mensaje del servidor al cliente para pedirle que le busque el dato deseado. Si bien este esquema es muy ineficiente hay ciertos sistemas que lo utilizan. Pero aún existe un problema como ser en la función INC(i,i) [i=i+1], al stub del server le llegarían dos parámetros diferentes pero en realidad es el mismo, con lo cual si i' = 1 (como parámetro de Entrada) ... en el server ... i = 2 (como parámetro de Salida) [i = i' + 1], pero ambos hacen referencia al mismo lugar de memoria en el cliente, por lo tanto al restaurar los valores en la variable i del cliente puede quedar 1 o 2.

Ejercicio 29:

El esquema de RPC necesita realizar un binding del port del servidor. Indique cuáles de los siguientes esquemas es factible. Justificar brevemente:
a) predicción de la información correspondiente al port (dirección fijada al compilar)
b) binding realizado en forma dinámica por medio de Rendez-Vous a un port fijo de RPC
c) binding realizado en forma dinámica por medio de Rendez-Vous a un port fijo en tiempo de compilación

B factible, Cap 22 Pag 3