Universidad de Ixtlahuaca CUI. Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan. RPC.

Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan.

edu-s-p@hotmail.com, emmanuel.chavez90@gmail.com
Facultad de Ingeniera, Ingeniera en Computacin, Universidad de Ixtlahuaca CUI

Modelo Cliente-Servidor y funcionamiento de RPC

Resumen Un sistema distribuido es un conjunto de

computadoras conectadas en red que le dan la sensacin al
usuario de ser una sola computadora. Este tipo de sistema
brinda una serie de bondades tales como: comparticin de
recursos, la concurrencia, alta escalabilidad, y tolerancia a
fallos. A pesar que agregar complejidad al software y
disminuir los niveles de seguridad, los sistemas de
procesamiento distribuidos brindan una buena relacin y
pueden aumentar su tamao de manera gradual al aumentar la
carga de trabajo. RPC es una tecnologa, tradicionalmente
empleada en ambiente UNIX, que permite el desarrollo de
sistemas de procesamiento distribuido basados en el
paradigma procedimental. Con el advenimiento de
implementaciones para plataforma Windows, as como para
Java, es posible pensar en RPC como un mecanismo de
integracin de software heterogneo.

Summary - A distributed system is a set of networked

computers that give users the feeling of being a single
computer. This type of system provides a number of benefits
such as resource sharing, concurrency, high scalability, and
fault tolerance. Although software and add complexity to
decrease levels of security, distributed processing systems
provide good value and can increase its size gradually
increasing workload. RPC is a technology traditionally used in
UNIX environment that allows the development of distributed
processing systems based on the procedural paradigm. With
the advent of Windows platform implementations as well as
for Java, you may think of RPC as a mechanism for
integrating heterogeneous software.
Palabras claveProcedimientos, remotos, distribuido,
RPC, llamadas, protocolo, API, Cliente, Servidor, Red.

I. INTRODUCCIN
RCP es un estndar desarrollado por Sun
Microsystems y usado por muchos distribuidores de
sistemas UNIX.
El RPC (del ingls Remote Procedure Call,
Llamada a Procedimiento Remoto) es un protocolo
que permite a un programa de ordenador ejecutar
cdigo en otra mquina remota sin tener que
preocuparse por las comunicaciones entre ambos. El
protocolo es un gran avance sobre los sockets

usados hasta el momento. De esta manera el

programador no tena que estar pendiente de las
comunicaciones, estando stas encapsuladas dentro
de las RPC.
El RPC es una interfaz de programacin de
aplicacin (API) disponible para el desarrollo de
aplicaciones distribuidas. Permite que los
programas llamen a subrutinas que se ejecutan en
un sistema remoto. El programa llamador (llamado
cliente) enva un mensaje de llamada al proceso
servidor y espera un mensaje de respuesta. La
llamada incluye los parmetros del procedimiento y
la respuesta los resultados.
RPC, definido como una tecnologa de
comunicacin entre procesos que permite a un
programa
de
computadora
llamar
un
procedimiento en otro espacio de direcciones
(generalmente en otra computadora, conectado por
una red). El desarrollador no se preocupa con
detalles de implementacin de esa interaccin
remota: del punto de vista del cdigo, la llamada se
asemeja a llamadas de procedimientos locales.
Una llamada a un procedimiento (funcin o
subrutina) es un mtodo bien conocido para
transferir el control de una parte del programa a
otra, con un retorno del control a la primera.
Asociado con la llamada a un procedimiento estn
el pase de argumentos y el retorno de uno o varios
resultados. Cuando el cdigo que invoca a un
procedimiento y dicho procedimiento est en un
mismo proceso en un computador dado, se dice que
ha ocurrido una llamada a un procedimiento local.
II. EL MODELO CLIENTE-SERVIDOR
Una aplicacin Cliente/Servidor o aplicacin de dos
capas es aquella donde los datos y la lgica de
negocio se encuentran separados de la interfaz, este
tipo de aplicacin tambin es denominada, cliente
liviano. [1]

Universidad de Ixtlahuaca CUI. Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan. RPC.

decisiones:
a. Separacin datos-programas.
b. Programas flexibles.
4. Nuevas tecnologas de alta productividad.

Figura 1: cliente liviano

Otro escenario vlido para una aplicacin
Cliente/Servidor, se da separando los datos de la
interfaz y la lgica de negocio, este tipo de
aplicacin tambin es denominado, cliente pesado.
[1]

FUNCIONAMIENTO DEL SISTEMA CLIENTE /

SERVIDOR
Un sistema cliente/servidor funciona tal como se
detalla en el siguiente diagrama:

Figura 4: Solicitud de cliente al servidor

Figura 2: cliente pesado

En el mundo las comunicaciones entre
computadoras se rigen bsicamente por lo que se
llama modelo Cliente-Servidor, ste es un modelo
que intenta proveer usabilidad, flexibilidad,
interoperabilidad
y
escalabilidad
en
las
comunicaciones. Su funcionamiento es sencillo: se
tiene una mquina cliente, que requiere un servicio
de una mquina servidor, y ste realiza la funcin
para la que est programado (ntese que no tienen
que tratarse de mquinas diferentes; es decir, una
computadora por s sola puede ser ambos cliente y
servidor
dependiendo
del
software
de
configuracin). [2]
CUNDO IMPLANTAR CLIENTE/ SERVIDOR?
1. Cambios estructurales y organizativos.
2. Cambios en organigramas.
3. Respuesta dinmica de mercado.
4. Cambio en procesos de negocio.
QU AYUDA A LA IMPLEMENTACIN?
1. La demanda de sistemas fciles.
2. Precio/rendimiento de estaciones y servidores.
3. Creciente acceso a la informacin para

Front/end: Es la parte de la aplicacin que

interacta con el usuario. Basados en una interfaz
grfica con el usuario (GUI). El Cliente corre la
aplicacin que ofrece la interfaz con el usuario.
Back/end: Es la parte no-interactiva de la
aplicacin. La mayor parte reside en las Bases de
Datos (relacionales o no). [2]
APLICACIONES SIMPLES
No requieren una gran Base de Datos compartida,
pueden ser elaboradas solamente en el Cliente.
APLICACIONES COMPLEJAS
Exigen dos capas, una para la aplicacin del usuario
(Cliente) y otra para la base de datos (Servidor).
Nivel

Responsabil
idad

Funciones

Herramient
as

Aplicati
vo del
Usuario

Interfaz
Incomprensibl
e y Eficiente

Presentacin,
Navegacin,
Manejo y
Anlisis

Herramienta
s Graficas y
Lenguaje de
Programaci
n

Reglas
de
Negoci
o

Polticas,
Reglas y
Heurstica

Toma de
Decisiones,
Polticas y
Administracin
de Recursos

Lenguaje de
Programaci
n

Base
de
Datos

Datos
Consistentes
y Seguros

Mantenimiento
, Actualizacin,
Integridad y
Seguridad

Base de
Datos,
Lenguaje de
Base de
Datos

Tabla 1: Funciones de los niveles en la arquitectura c/s

Universidad de Ixtlahuaca CUI. Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan. RPC.

El cliente enva una solicitud al servidor mediante

su direccin IP y el puerto, que est reservado para
un servicio en particular que se ejecuta en el
servidor. El servidor recibe la solicitud y responde
con la direccin IP del equipo cliente y su puerto.
Proceso de una llamada a un procedimiento remoto:

Figura 3: Modelo RPC

1. El cliente llama a un procedimiento local
llamado stub del cliente, el cual aparenta ser
el procedimiento servidor que el cliente desea
llamar. El propsito del stub del cliente es
empaquetar los argumentos del procedimiento
remoto, adecuarlos a algn formato estndar y
construir uno o varios mensajes de red. El
empaquetamiento de los argumentos del
procedimiento remoto en mensajes de red se
conoce como marshaling.
2. Estos mensajes son enviados por el stub del
cliente al sistema remoto, lo cual requiere una
llamada del sistema.
3. Los mensajes son transferidos al sistema remoto
empleando protocolos con o sin conexin.
4. Un procedimiento stub del servidor espera en
el sistema remoto la solicitud del cliente.
Desempaqueta los argumentos de los mensajes
de red y si es necesario realiza alguna
conversin.
5. El stub del servidor realiza la llamada al
procedimiento local que realmente invoca la
funcin del servidor y le pasa los argumentos
transferidos a travs de la red desde el stub
del cliente.
6. Cuando el procedimiento del servidor termina,
ste le regresa el control al stub del servidor
devolviendo los resultados obtenidos.

7. El stub del servidor adecua el formato de tales

resultados, si es necesario, y los empaqueta en
mensajes de red para ser devueltos al stub del
cliente.
8. Los mensajes son transmitidos al stub del
cliente.
9. El stub del cliente lee los mensajes recibidos.
10. Luego de posiblemente convertir los valores de
retorno, el stub del cliente retorna finalmente
dichos resultados a la funcin del cliente
haciendo parecer un retorno normal de funcin.
Segn el modelo OSI, RPC cae en algn lado entre
la capa de transporte y aplicacin. Tpicamente se
considera parte de la capa de presentacin. Debido a
que RPC le oculta a la capa de aplicacin los
detalles de la red, usualmente incluye una
especificacin de algn formato estndar para el
intercambio de argumentos y resultados entre el
cliente y el servidor. [1]
II. FUNCIONAMIENTO DE RPC
Objetivos del RPC
Proporcionar un middelware que simplifique el
desarrollo de aplicaciones distribuidas.
Evitar que programador tenga que interactuar
directamente con los Sockets.
Abstraer (ocultar) los detalles relativos a la red.
El Servidor ofrece procedimientos que el cliente
llama como si fueran procedimientos locales.
Se busca ofrecer un entorno de programacin lo
ms similar posible a un entorno no distribuido.
El sistema RPC oculta los detalles de
implementacin de esas llamadas remotas.
Implementa la llamada remota mediante un
dialogo peticin respuesta.

Figura 4: cliente servidor

1. Mensaje de peticin: identifica al procedimiento

Universidad de Ixtlahuaca CUI. Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan. RPC.

2.
3.

4.

5.

6.

7.

llamado, contiene parmetros de la llamada.

Mensaje de respuesta: contiene valores
devueltos.
Transporte: Se encarga de enviar/recibir
mensajes para comunicar ambas partes. Se
encarga de gestionar los contenidos de esos
mensajes (empaquetado y formateado de datos).
El stub del cliente: se encarga de empaquetar los
parmetros y la solicitud, enviarlos al
intermediario en el servidor, y luego esperar la
respuesta, desempaquetarla y entregarla a la
aplicacin.
El programa principal del servidor (que incluye
el stub y el dispatcher): se encarga de recibir
peticiones, desempaquetar los parmetros,
invocar la funcin solicitada, pasarle los
parmetros, luego obtener el resultado,
empaquetarlo y enviarlo al cliente.
Las rutinas de serializacin de datos: Se debe
tomar en cuenta que las mquinas cliente y
servidor puedan ser de arquitectura diferente (y
no compatible).
Servicio de binding: Responsable de la
transparencia de localizacin, gestiona la
asociacin entre el nombre del procedimiento
remoto (y su versin) con su localizacin en la
maquina servidor (direccin, puertos, skeleton,
etc). Realiza la bsqueda del skeleton de la
implementacin concreta del procedimiento
remoto llamado por un cliente. [3]

Segn el modelo OSI, RPC cae en algn lado entre

la capa de transporte y aplicacin. Tpicamente se
considera parte de la capa de presentacin. Debido a
que RPC le oculta a la capa de aplicacin los
detalles de la red, usualmente incluye una
especificacin de algn formato estndar para el
intercambio de argumentos y resultados entre el
cliente y el servidor. [1]

Figura 5: El modelo para sistemas distribuidos

Herramientas del RPC hacen aparecer a los usuarios
como si un cliente llama directamente a un
procedimiento en un programa de servidor remoto.
El cliente y servidor tienen sus propios espacios de
direccin; es decir, cada uno tiene su propio recurso
de memoria asignada a los datos utilizados por el
procedimiento. La siguiente figura muestra la
arquitectura RPC.

Figura 6: llamada a un procedimiento remoto

Como se muestra en la ilustracin, la aplicacin
cliente llama a un procedimiento local trozo en vez
del cdigo real de aplicar el procedimiento. Est
compilado y vinculado con la aplicacin cliente. En
vez de contener el cdigo que implementa el
procedimiento remoto, el cdigo del stub del
cliente:
Recupera los parmetros requeridos del espacio
de direcciones del cliente.
Traduce los parmetros necesarios en un
formato estndar de NDR para transmisin
sobre la red.
Llama a funciones en la biblioteca de tiempo de
ejecucin de cliente RPC para enviar la peticin

Universidad de Ixtlahuaca CUI. Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan. RPC.

y sus parmetros al servidor.

Servidor realiza los siguientes pasos para llamar
al procedimiento remoto.

Componentes RPC
RPC incluye los siguientes componentes
principales:
Compilador de MIDL
Tiempo de ejecucin bibliotecas y archivos de
encabezado
Proveedor de servicio de nombres (a veces
denominado el localizador)
Asignador de extremos (a veces referido como
el asignador de puerto)
En el modelo RPC, puede especificar formalmente
una interfaz para los procedimientos remotos
utilizando un lenguaje diseado para este propsito.
Este lenguaje se denomina lenguaje de definicin de
interfaz, o IDL. La implementacin de Microsoft de
este lenguaje se denomina lenguaje de definicin de
interfaz de Microsoft, o MIDL.
Despus de crear una interfaz, usted debe pasar por
el compilador MIDL. Este compilador genera los
talonarios que se traducen en llamadas a
procedimientos
locales
en
llamadas
a
procedimientos remotos. Recibos son funciones de
marcador de posicin que hacen las llamadas a las
funciones de biblioteca de tiempo de ejecucin, que
la llamada a procedimiento remoto. La ventaja de
este enfoque es que la red se convierte casi
totalmente transparente para su aplicacin
distribuida. Su programa de cliente llama a lo que
parecen ser los procedimientos locales; el trabajo de
convertirlos en llamadas remotas se realiza
automticamente para usted. Todo el cdigo que
traduce los datos, tiene acceso a la red y obtiene
resultados se genera por el compilador MIDL y es
invisible para su aplicacin.
III. TRANSPORTE SEMNTICA
El protocolo RPC se puede implementar en
diferentes protocolos de transporte, ya que no hay
diferencia la forma en cmo se transmite un
mensaje entre procesos. Es importante destacar que

el protocolo RPC no implementa ningn tipo de

fiabilidad y que la aplicacin tiene que cuidar el
tipo de protocolo en el que opera RPC. Si se trata de
un protocolo fiable, como TCP, las preocupaciones
sobre la fiabilidad ya estn resueltos. Por otro lado,
si la capa de transporte no es fiable, tales como
mecanismos de tiempo de espera UDP, la
retransmisin y la deteccin de duplicados se debe
implementar, ya que estos servicios no son
proporcionados por RPC.[5]
Debido a la independencia de la capa de transporte,
el protocolo RPC no cambia la semntica de las
llamadas remotas, o los requisitos de rendimiento.
La semntica se puede deducir de la capa de
transporte en uso. Por ejemplo, consideremos el
caso en el PRC opera sobre una capa de transporte
no fiable, como UDP. Si una aplicacin retransmite
mensajes de invocacin RPC despus de los
tiempos de espera, y no recibe respuestas, no se
puede inferir el nmero de veces que se ejecuta el
procedimiento. Si se recibe un mensaje, se puede
inferir que el procedimiento se lleva a cabo al
menos una vez. El servidor puede realizar el control
del nmero de ejecuciones, simplemente registrando
el nmero del ltimo procedimiento realizado con
xito.[5]
Por otro lado, cuando PRC opera sobre una capa
de transporte fiable tal como TCP, la aplicacin
puede inferir a partir de un mensaje de respuesta, el
procedimiento se realiz exactamente una vez. Sin
embargo, si no se recibe una respuesta del mensaje,
la aplicacin no puede suponer que no se realiz el
procedimiento. Tenga en cuenta que, incluso
utilizando una conexin orientada protocolo, las
aplicaciones tambin requieren tiempos de espera
para identificar fallas en el servidor.[6]
Tambin hay muchos otros medios de transporte,
adems de datagrama y protocolos basados en
conexiones. Por ejemplo, los protocolos de
consulta-respuesta como VMTP pueden ser
utilizados por TCP. [6]
IV. IMPLEMENTANDO RPC
Para permitir que los servidores sean accesados por
diferentes clientes, diversos sistemas padronizados
de RPC fueron creados. La mayora de ellos usa un

Universidad de Ixtlahuaca CUI. Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan. RPC.

lenguaje de descripcin de interfaz (IDL) para que

diferentes
plataformas
puedan
llamar
procedimientos. Haciendo uso de una herramienta
como el RPCGEN, se puede generar interfaces entre
cliente y servidor a partir de un archivo IDL, los
llamados stubs. Como los stubs son embarcados en
las aplicaciones cliente y servidora, la RPC no es
una capa de middleware.[5]
En la codificacin, el procedimiento remoto del
cliente llama el stub cliente cmo cualquier otro
procedimiento local, y la implementacin interna
del stub cliente es responsable por iniciar el proceso
de transmisin para stub servidor, empaquetando la
llamada en un mensaje. Al llegar, el stub servidor
desempaqueta el mensaje e invoca localmente el
procedimiento, aguardando el retorno. Cuando la
llamada local retorna, el stub servidor es
responsable por iniciar el proceso de transmisin
para el stub cliente, empaquetando la respuesta en
un mensaje. Llegando, la respuesta es
desempaquetando por el stub cliente, siendo
retornada localmente para el procedimiento que
realiz la llamada remota.[8]
Al invocar el procedimiento remoto, se debe atentar
que cliente y servidor pueden ser plataformas
diferentes, que representan datos de forma diferente.
En ese caso es preciso un protocolo comn de
representacin de los datos, como el XDR, o la
garanta de que ambas partes saber convertir los
datos para tipos de dato soportados.[8]
V. LIMITACIONES
Diferentes implementaciones de llamada de
procedimiento
remoto
acostumbran
ser
incompatibles entre s, aunque existan excepciones.
Por eso, el uso de una determinada implementacin,
probablemente, resultar en la dependencia con el
proveedor de la
implementacin. Esa
incompatibilidad entre implementaciones se
muestra tambin en la
disponibilidad de
funcionalidades, en el soporte de los diferentes
protocolos de red y diferentes sistemas de archivo.
La mayora de las implementaciones no soporta P2P
y o interaccin asncrona entre cliente y servidor
(por definicin, la llamada remota corresponde a
una llamada local del punto de vista de la
aplicacin, bloqueando de la misma forma). La

comunicacin sncrona implica en la disponibilidad

de constante tanto del cliente cunto del servidor.[5]
Las implementaciones de RPC ms populares son:
La desarrollada por Sun Microsystem
denominada ONC-RCP (Open Network
Computing, ONC-RCP), distribuida con casi
todos los sistemas UNIX.
La desarrollada por Microsoft en lnea con el
Ambiente de Computacin Distribuida (DCE,
Distributed Computing Enviroment) definido
por la Fundacin de Software Abierto (OSF,
Open Software Foundation). Incluida en los
sistemas operativos Windows.
CORBA (Common Object Requesting Broker
Architecture): soporta la invocacin de mtodos
remotos bajo un paradigma orientado a objetos
en diversos lenguajes.
SOAP (Simple Object Access Protocol):
protocolo RPC basado en el intercambio de
datos (parmetos+resultados) en formato XML
VI. EN LINUX
El mecanismo general para las aplicaciones clienteservidor se proporciona por el paquete Remote
Procedure Call (RPC). RPC fue desarrollado por
Sun Microsystems y es una coleccin de
herramientas
y
funciones
de
biblioteca.
Aplicaciones importantes construidas sobre RPC
son NIS, Sistema de Informacin de Red y NFS,
Sistema de Ficheros de Red.[9]
Un servidor RPC consiste en una coleccin de
procedimientos que un cliente puede solicitar por el
envo de una peticin RPC al servidor junto con los
parmetros 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 mquina, 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
representacin local por el receptor. RPC confa en
sockets estandard UDP y TCP para transportar los
datos en formato XDR hacia el host remoto. Sun
amablemente ha puesto RPC en el dominio pblico.
[10]

Universidad de Ixtlahuaca CUI. Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan. RPC.

A veces las mejoras en una aplicacin RPC

introducen cambios incompatibles con la interfaz de
llamada a procedimientos. Por supuesto,
simplemente cambiando el servidor har que no
funcionen todas las aplicaciones que todava
esperen el comportamiento original. Por lo tanto,
los programas RPC tienen nmeros de versin
asignados, casi siempre empezando por 1, y con
cada nueva versin de la interfaz RPC, este
contador se incrementa. A menudo, un servidor
puede ofrecer varias versiones simultneamente;
entonces los clientes indican a travs del nmero de
versin en la peticin que implementacin del
servicio quieren usar.[8]
La comunicacin entre servidores RPC y clientes es
un tanto peculiar. Un servidor RPC ofrece una o
ms colecciones de procedimientos; cada conjunto
se llama un programa y es identificado de forma
nica por un nmero de programa. Una lista que
relaciona nombres de servicio con nmeros de
programa se mantiene usualmente en /etc/rpc.[10]
#
# /etc/rpc - servicio miscelneos
basados en RPC
#
portmapper
100000 portmap sunrpc
rstatd
100001 rstat
rstat_svc rup perfmeter
rusersd
100002 rusers
nfs
100003 nfsprog
ypserv
100004 ypprog
mountd
100005 mount
showmount
ypbind
100007
walld
100008 rwall shutdown
yppasswdd
100009 yppasswd
bootparam
100026
ypupdated
100028 ypupdate

En redes TCP/IP , los autores de RPC se

enfrentan al problema del mapeo de nmeros de
programa con servicios genricos de red. Disearon
cada servidor para proveer ambos puertos TCP y
UDP para cada programa y cada versin.
Generalmente, las aplicaciones RPC usan UDP
cuando envan datos, y vuelven a TCP slo cuando
los datos a transferir no caben en un solo datagrama
UDP.[10]
Por supuesto, los programas cliente necesitan
averiguar a qu puerto se refiere un nmero de

programa. Usar un fichero de configuracin para

esto podra ser demasiado inflexible; debido a que
las aplicaciones RPC no usan puertos reservados, no
hay garanta de que un puerto originalmente usado
por nuestra aplicacin de base de datos, no haya
sido tomado por cualquier otro proceso. Por lo
tanto, las aplicaciones RPC toman cualquier puerto
que puedan obtener y lo registran con un programa
especial llamado el demonio portmapper.[5] El
mapeador de puertos acta como un intermediario
para todos los servidores RPC ejecutndose en su
mquina. Un cliente que desea contactar con un
servicio con un nmero de programa dado primero
pregunta al mapeador de puertos en el host del
servidor, el cul devuelve el nmero de puerto TCP
y UDP en donde el servicio puede ser alcanzado.[6]
En Linux, el mapeador de puertos se llama
/sbin/portmap, o a veces /usr/sbin/rpc.portmap. Una
vez que se cerciora de que se inicia desde sus
guiones de inicio de red, el mapeador de puertos no
requiere ninguna configuracin.[10]
VII.

FUNCIONAMIENTO DE LAS RPC

El proceso que realiza la llamada empaqueta los

argumentos en un mensaje, se los enva a otro
proceso y espera el resultado.
El proceso que ejecuta el procedimiento extrae
los argumentos del mensaje, realiza la llamada
de forma local, obtiene el resultado y se lo enva
de vuelta al proceso que realiz la llamada.
Objetivo: acercar la semntica de las llamadas a
procedimiento convencional a un entorno
distribuido (transparencia)[1]
Fallos que pueden aparecer con las RPC
El cliente no es capaz de localizar al servidor
Prdidas de mensajes
o Se pierde el mensaje de peticin del cliente
al servidor
o Se pierde el mensaje de respuesta del
servidor al cliente
El servidor falla despus de recibir una peticin
El cliente falla despus de enviar una peticin
Cliente no puede localizar al servidor
Posibles causas:

Universidad de Ixtlahuaca CUI. Snchez Pia, Eduardo, Chvez Varela, Emmanuel Jonathan. RPC.

El servidor puede estar cado

El cliente puede estar usando una versin
antigua del servidor
o La versin ayuda a detectar accesos a copias
obsoletas

VIII.
CONCLUSIONES
Podemos concluir que una llamada a
procedimiento remoto lo utilizamos como
mecanismo por el que dos procesos se pueden
comunicar entre s, en distintas conexiones que
realizamos, en la actualizada cuando utilizamos
servicios de distintos servidores. En cual nos
permite solicitar funcionalidades residentes en otros
procesos. Dichos procesos pueden residir en el
mismo equipo, en una red local o en internet.
Por ejemplo si disponemos de dos ordenadores, el
primero de ellos con un procesador muy pobre
donde se disean grficos de alta calidad y un
segundo ordenador desocupado y de mucha
potencia de clculo. Podemos en este caso
programar una aplicacin manejada desde el primer
ordenador que mostrar grficos muy complejos pero
que estos se calculan previamente en el segundo
ordenador bajo las rdenes del primero utilizando
RPCs.
.
REFERENCIAS

[1] S. B. Garca Zapata, Aplicaciones Distribuidas, Mxico:

Chief Mobile Architect at Avanet.co at Microsoft, 2009,
pp. 47-48.

[2] H. E. Ramrez Zelaya, . J. J. Hodgson Amador, . J. A.

Reyes Bolaos y K. A. Coleman Bermdez,
ARQUITECTURA
CLIENTE/SERVIDOR,
INGENIERA DE SOFTWARE I ed., NICARAGUA:
UNIVERSIDAD POLITCNICA DE NICARAGUA,
2010.
[3] J. Baier y A. Soto, Modelo Cliente Servidor, Sockets y
RPC, P. U. C. d. Chile, Ed., Departamento de Ciencias de
la Computacin, 2002.
[4] documents. (1 de julio de 2015). documents. Obtenido de
http://documents.mx/documents/el-rpc-trabajo-deinvestigacion.html
[5] dtic. (5 de junio de 2015). dtiv. Obtenido de
http://www.dtic.ua.es/asignaturas/SOR/practicas/SOR_P1
_rpc_teoria.pdf
[6] gwolf. (noviembre de 2001). gwolf. Obtenido de
http://sistop.gwolf.org/biblio/Sistemas_Operativos__Luis_La_Red_Martinez.pdf
[7] remostos, R. l. (26 de septiembre de 2015). tmps.
Obtenido de
http://www.tamps.cinvestav.mx/~vjsosa/clases/sd/RPC_n
otas.pdf
[8] uvigo. (26 de septiembre de 2015). uvigo. Obtenido de
http://ccia.ei.uvigo.es/docencia/SCS/1011/transparencias/
Tema2-2.pdf
[9] ARCOS, G. (s.f.). arcos. Recuperado el 27 de septiembre
de 2015, de
http://www.arcos.inf.uc3m.es/~infosd/lib/exe/fetch.php?
media=es:t6_llamadas_a_procedimientos_remotos.pdf
[10] tldp. (s.f.). tldp. Recuperado el 27 de septiembre de
20015, de http://es.tldp.org/ManualesLuCAS/GARL2/garl2/x-087-2-appl.rpc.html

Autores
Snchez Pia Eduardo, Chvez Varela Emanuel Jonathan,
estudiantes de la Licenciatura en Ingeniera en Computacin
de la Universidad de Ixtlahuaca CUI.