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.
o Esta técnica se denomina multitransmisión.
o Cada grupo debe tener una dirección de multitransmisión distinta.

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.