RCP (REMOTE PROCEDURE CALL

)
El mecanismo general para las aplicaciones cliente-servidor se proporciona por el paquete Remote Procedure Call (RPC). RPC fue desarrollado por Sun Microsystems y es una colección de herramientas y funciones de biblioteca. Un servidor RPC consiste en una colección de procedimientos que un cliente puede solicitar por el envío de una petición RPC al servidor junto con los parámetros del procedimiento. El servidor invocará el procedimiento indicado en nombre del cliente, entregando el valor de retorno, si hay alguno. Para ser independiente de la máquina, todos los datos intercambiados entre el cliente y el servidor se convierten al formato External Data Representation (XDR) por el emisor, y son reconvertidos a la representación local por el receptor. RPC confía en sockets estándar UDP y TCP para transportar los datos en formato XDR hacia el host remoto. Sun amablemente a puesto RPC en el dominio público; se describe en una serie de RFCs. Un servidor RPC ofrece una o más colecciones de procedimientos; cada conjunto se llama un programa y es identificado de forma única por un número de programa. La llamada remota toma 10 pasos, en el primero de los cuales el programa cliente (o procedimiento) llama al procedimiento stub enlazado en su propio espacio de direcciones. Los parámetros pueden pasarse de la manera usual y hasta aquí el cliente no nota nada inusual en esta llamada ya que es una llamada local normal. El stub cliente reúne luego los parámetros y los empaqueta en un mensaje. Esta operación se conoce como reunión de argumentos (parameter marshalling). Después que se ha construido el mensaje, se lo pasa a la capa de transporte para su transmisión (paso 2). En un sistema LAN con un servicio sin conexiones, la entidad de transporte probablemente sólo le agrega al mensaje un encabezamiento y lo coloca en la subred sin mayor trabajo (paso 3). En una WAN, la transmisión real puede ser más complicada. Cuando el mensaje llega al servidor, la entidad de transporte lo pasa al stub del servidor (paso 4), que desempaqueta los parámetros. El stub servidor llama luego al procedimiento servidor (paso 5), pasándole los parámetros de manera estándar. El procedimiento servidor no tiene forma de saber que está siendo activado remotamente, debido a que se lo llama desde un procedimiento local que cumple con

todas las reglas estándares. Únicamente el stub sabe que está ocurriendo algo particular. Después que ha completado su trabajo, el procedimiento servidor retorna (paso 6) de la misma forma en que retornan otros procedimientos cuando terminan y, desde luego, puede retornar un resultado a un llamador. El stub servidor empaqueta luego el resultado en un mensaje y lo entrega a la interfaz con transporte (paso 7), posiblemente mediante una llamada al sistema, al igual que en el paso 2. Después que la respuesta retorna a la máquina cliente (paso 8), la misma se entrega al stub cliente (paso 9) que desempaqueta las respuestas. Finalmente, el stub cliente retorna a su llamador, el procedimiento cliente y cualquier valor devuelto por el servidor en el paso 6, se entrega al cliente en el paso 10. El propósito de todo el mecanismo de la Fig.1 es darle al cliente (procedimiento cliente) la ilusión de que está haciendo una llamada a un procedimiento local. Dado el éxito de la ilusión, ya que el cliente no puede saber que el servidor es remoto, se dice que el mecanismo es transparente. Sin embargo, una inspección más de cerca revela algunas dificultades en alcanzar la total transparencia. TOLERANCIA A FALLOS Que el sistema de archivos sea tolerante a fallos implica qué el sistema debe guardar copias del mismo archivo en distintos ordenadores para garantizar la disponibilidad en caso de fallo del servidor original. Se debe aplicar un algoritmo que nos permita mantener todas las copias actualizadas de forma constante, o un método alternativo que solo nos permita al archivo actualizado como invalidar el resto de copias cuando en cualquiera de ellas se vaya a realizar una operación de escritura. • • FACTORES QUE AFECTAN LA FIABILIDAD EN LOS SISTEMAS TECNICAS QUE PERMITEN TOLERAR FALLOS EN EL SISTEMA

ALGUNOS FALLOS EN EL FUNCIONAMIENTO DE UN SISTEMA PUEDEN ORIGINARSE POR: • • • Especificaciones impropias o con errores. Diseño deficiente e la creación del software y/o el hardware. Deterioros o averías en al hardware.

Interferencias en las comunicaciones (temporales o permanentes). 1. Fallos temporales o transitorios: Desaparecen por si solos al cabo de un tiempo. 2. Fallos permanentes: Duran hasta que se raparan. 3. Fallos intermitentes: Ocurren solo de vez en cuando.

PREVENCION Y TOLERANCIA A FALLOS Existen dos formas de aumentar la fiabilidad de un sistema. 1. Prevención de fallos: Se trata de evitar que se implementen sistemas que pueden introducir fallos. 2. Tolerancia a fallos: Se trata de conseguir que el sistema continué funcionando correctamente aunque se presenten algunos fallos. En ambos casos el objetivo es desarrollar sistemas con modos de fallos bien definidos. HARDWARE: • • Utilización de componentes fiables.

Técnicas rigurosas de ensamblaje de subsistemas. • • •

SOFTWARE: Especificación rigurosa de requisitos. Métodos de diseños comprobados. Lenguajes con abstracción de datos y modularidad.

LA REALIZACION SE BASA EN DOS ETAPAS 1. Evitación de fallos: impedir que se introduzcan fallos durante la construcción del sistema. 2. Eliminación de fallos: consiste en encontrar y corregir los fallos que se producen en el sistema una vez construido. TECNICAS DE ELIMINACION DE FALLOS Comprobaciones: • • • Revisiones del diseño. Verificación de los programas. Inspección del código.

Pruebas: • Son necesarias pero insuficientes.

• • • • • • •

Nunca llegan a ser exhaustivas Solo sirven para mostrar que hay errores pero no que no los hay. Los errores de especificaciones no se detectan.

LIMITACIONES DE LA PREVENCION DE FALLOS Los componentes del hardware fallan a pesar de las técnicas de prevención. La prevención es insuficiente si la frecuencia o la duración de las reparaciones es corta. No se puede detener el sistema para efectuar reparaciones. La alternativa es utilizar técnicas de tolerancia a fallos.

TOLERANCIA A FALLOS

• •
• •

Tolerancia completa: el sistema continúa funcionando durante un tiempo sin perder funcionabilidad Degradación elegante: El sistema sigue funcionando con una pérdida parcial de funcionabilidad hasta que se repare el fallo. Parada segura: el sistema se detiene en un estado que asegura la integridad del entorno hasta que se repare el fallo.

Comunicación Cliente-Servidor (Socket) Sockets Son el mecanismo de sincronización distribuida más importante. Se les denomina conectores porque pueden unir un proceso cliente y un proceso servidor de manera semejante a como se puede unir un enchufe de un dispositivo eléctrico a su respectivo zócalo. De los mecanismos de sockets el mas conocido es referente a al API de Berkeley y esta implementado en prácticamente todos los sistemas Unix por lo que se maneja C, pero también esta portado a otras arquitecturas como Windows (WinSock) y otros lenguajes como Java. Para la comunicación de procesos remotos se necesita conocer la dirección de la maquina destino y el puerto. Para hacer uso de los sockets necesitamos dos cosas una familia de protocolos para comunicación y un tipo de conexión. Para establecer una comunicación a través de sockets se necesitan 5 requerimientos: • Dirección del servidor • Puerto del servidor

• Dirección del cliente • Puerto del cliente • Canal de comunicación abierto Para leer datos de un socket se pueden utilizar las siguientes primitivas: read, readv, recv, recvfrom y recvmsg; siendo las más utilizadas read y recv(sfd, buf, len, flags). Para escribir datos en un socket se utilizan las siguientes primitivas: write, writev, send, sendto y sendmsg, siendo las más utilizadas write y send(sfd, buf, len, flags). Las primitivas del socket en el servidor para comunicación orientada a conexión (Stream). Socket(); Bind(); Listen(); Acept(); Read(); Write();. Primitivas de sockets en el cliente • Las primitivas de sockets pueden ser bloqueantes y no bloqueantes: socket(); connect(); write(); read(); close();. Primitivas de sockets en el servidor
Las primitivas son para comunicación entre procesos no orientada a conexión (Datagramas).

socket(); bind(); recvfrom(); sendto();. Primitivas de sockets en el cliente socket(); bind(); sendto(); recvfrom (); shutdown();

La programación de sockets proporciona un mecanismo de muy bajo nivel para la comunicación e intercambio de datos entre dos ordenadores uno que se considera como cliente que es el que inicia la conexión con el servidor que esta esperando la requisición de conexiones de clientes. El protocolo de comunicación entre ambos es el que determinara lo que suceda después de que se establezca la conexión. Para que las dos maquinas puedan entenderse ambas deben implementar un protocolo común y conocido por ambas. En la programación de sockets el flujo de comunicación es Full Duplex en ambos sentidos siendo responsabilidad del sistema llevar los datos de una maquina a otra, parte de la información que fluye entre las dos maquinas es para implementar el protocolo y el resto son los propios datos que se quieren transferir.

Sockets Java Java proporciona formas diferentes de abordar la programación de comunicaciones por un lado están las clases Socket, DatagramSocket y ServerSocket y por otro lado están las clases URL, URLEncoder y URLConnectio.

Sockets Stream (TCP) Son un servicio orientado a conexión, donde los datos se transfieren sin encuadrarlos en registros o bloques. Si se rompe la conexión entre los procesos, éstos serán informados de tal suceso para que tomen las medidas oportunas.

El protocolo de comunicaciones con streams es un protocolo orientado a conexión, ya que para establecer una comunicación utilizando el protocolo TCP, hay que establecer en primer lugar una conexión entre un par de sockets. Mientras uno de los sockets atiende peticiones de conexión (servidor), el otro solicita una conexión (cliente). Una vez que los dos sockets estén conectados, se pueden utilizar para transmitir datos en ambas direcciones.

Sockets Datagrama (UDP) Son un servicio de transporte sin conexión. Son más eficientes que TCP, pero en su utilización no está garantizada la fiabilidad. Los datos se envían y reciben en paquetes, cuya entrega no está garantizada. Los paquetes pueden ser duplicados, perdidos o llegar en un orden diferente al que se envió. El protocolo de comunicaciones con datagramas es un protocolo sin conexión, es decir, cada vez que se envíen datagramas es necesario enviar el descriptor del socket local y la dirección del socket que debe recibir el datagrama. Como se puede ver, hay que enviar datos adicionales cada vez que se realice una comunicación, aunque tiene la ventaja de que se pueden indicar direcciones globales y el mismo mensaje llegará a muchas máquinas a la vez.

Sockets Raw Son sockets que dan acceso directo a la capa de software de red subyacente o a protocolos de más bajo nivel. Se utilizan sobre todo para la depuración del código de los protocolos.

Diferencias entre Sockets Stream y Datagrama Ahora se presenta un problema, al haber varias opciones, ¿qué protocolo, o tipo de sockets, se debe emplear - UDP o TCP? La decisión depende de la aplicación cliente/servidor que se esté escribiendo; aunque hay algunas diferencias entre los protocolos que sirven para ayudar en la decisión y decantar la utilización de sockets de un tipo.

En UDP, cada vez que se envía un datagrama, hay que enviar también el descriptor del socket local y la dirección del socket que va a recibir el datagrama, luego los mensajes son más grandes que los TCP. Como el protocolo TCP está orientado a conexión, hay que establecer esta conexión entre los dos sockets antes de nada, lo que implica un cierto tiempo empleado en el establecimiento de la conexión, que no es necesario emplear en UDP.

En UDP hay un límite de tamaño de los datagramas, establecido en 64 kilobytes, que se pueden enviar a una localización determinada, mientras que TCP no tiene límite; una vez que se ha establecido la conexión, el par de sockets funciona como los Streams: todos los datos se leen inmediatamente, en el mismo orden en que se van recibiendo.

UDP es un protocolo desordenado, no garantiza que los datagramas que se hayan enviado sean recibidos en el mismo orden por el socket de recepción. Al contrario, TCP es un protocolo ordenado, garantiza que todos los paquetes que se envíen serán recibidos en el socket destino en el mismo orden en que se han enviado.

Los datagramas son bloques de información del tipo lanzar y olvidar. Para la mayoría de los programas que utilicen la red, el usar un flujo TCP en vez de un datagrama UDP es más sencillo y hay menos posibilidades de tener problemas. Sin embargo, cuando se requiere un rendimiento óptimo, y está justificado el tiempo adicional que supone realizar la verificación de los datos, la comunicación a través de sockets TCP es un mecanismo realmente útil.

En resumen, TCP parece más indicado para la implementación de servicios de red como un control remoto (rlogin, telnet) y transmisión de ficheros (ftp); que necesitan

transmitir datos de longitud indefinida. UDP es menos complejo y tiene una menor sobrecarga sobre la conexión; esto hace que sea el indicado en la implementación de aplicaciones cliente/servidor en sistemas distribuidos montados sobre redes de área local. 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

Ej.: un grupo de servidores de archivo que cooperan para ofrecer un único servicio de archivos tolerante a fallos:
o

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. La propiedad fundamental de todos los grupos es que cuando un mensaje se envía al propio grupo, todos los miembros del grupo lo reciben. Se trata de una comunicación uno - muchos (un emisor, muchos receptores), que se distingue de la comunicación puntual o punto a punto (un emisor, un receptor). Los grupos son dinámicos:
• • •

Se pueden crear y destruir. Un proceso se puede unir a un grupo o dejar a otro. Un proceso puede ser miembro de varios grupos a la vez.

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 de red a la que pueden escuchar varias máquinas:
o

Cuando se envía un mensaje a una de esas direcciones se lo entrega automáticamente a todas las máquinas que escuchan a esa dirección. Esta técnica se denomina multitransmisión. Cada grupo debe tener una dirección de multitransmisión distinta.

o o

Las redes que no soportan multitransmisión operan con transmisión simple:

Significa que los paquetes que tienen cierta dirección se entregan a todas las máquinas. Se puede utilizar para implantar los grupos, pero es menos eficiente que la multitransmisión. Cada máquina debe verificar, mediante su software, si el paquete va dirigido a ella:
o

En caso negativo se descarta, pero para analizarlo se generó una interrupción y se dedicó ciclos de cpu.

Otra solución es implantar la comunicación en grupo mediante la transmisión por parte del emisor de paquetes individuales a cada uno de los miembros del grupo:
• • • •

En vez de un paquete se precisan “n” paquetes. Es menos eficiente que las soluciones anteriores. Es una solución valida particularmente con grupos pequeños. El envío de un mensaje de un emisor a un único receptor se llama unitransmisión.

Bibliografía: http://es.wikipedia.org/wiki/RPC

http://www.mcc.unam.mx/~cursos/Algoritmos/javaDC99-1/resumen2.html#Streams http://www.fismat.umich.mx/mn1/manual/node24.html

http://espejos.unesco.org.uy/simplac2002/Ponencias/Segurm%E1tica/VIR011.doc http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/SO8.htm

Trabajo Realizado por: Paola A. Ruiz Rojas Luís A. Fraga de los Santos Maria Luisa Sánchez Fernández Andrés Tejada Pérez Materia: Sistemas operativos II Sexto Semestre.