Llamadas a Procedimientos Remotos (RPC)

Intriago Intriago Byron Javier

Carrera de Ingeniera en Sistemas, Facultad de Ciencias Informaticas, Universidad Tecnica de Manab
Av. Urbina y Che Guevara, Portoviejo, Manab, Ecuador
bintriago2008@utm.edu.ec

Resumen- Este presente trabajo esta basado sobre las llamadas

a procedimientos remotos (RPC) los cual nos da a extender como
funcionan los protocolos los cuales permiten a un al software y
al hardware ejecutar codigo remotamente sin tener en cuenta la
comunicacion de la misma para ello se utilizo el metodo clienteservidor para su conexion, ademas de conocer los tipos de RPC
que existen por ello este trabajo tiene como fin dar una idea mas
concreta sobre las llamadas a procedimientos remotos.
Palabras clave- Procedimientos, protocolos, remotos, software,
hardware, llamadas.

I. I NTRODUCTION

ste documento hace referencia a las llamadas a procedimientos

remotos o como se las conoce por sus ciclas RPC el cual explica
muy detalladamente el funcionamiento y como esta desarrollado
las RPC ya que se han tomado ideas de diferentes autores, estas
ideas son muy importantes ya que contribuyen al entendimiento y el
funcionamiento de las de las RPC, donde se pueden aplicar.
La mayora de las RPC se utilizan el lenguaje de descripcion
de interfaz los cuales estos definen los metodos exportados por el
servidor las RPC son mas utilizadas en la famosa comunicacion
cliente servidor en el cual el cliente inicia el proceso solicitando al
servidor unos procesos y el mismo devuelva un resultado por ello se
inicia la investigacion mediante varios documentas que nos prestan
mas informacion de las llamadas a procedimientos remotos.

II. M ARCO T E ORICO

Llamadas a Procedimientos Remotos (RPC)
Una llamada de procedimiento remoto (RPC) consiste en un
protocolo que permite a un software o programa ejecutar codigo en
otra maquina remota sin preocuparse por la comunicacion, por lo
regular es bastante utilizado en el paradigma cliente y servidor(2).
Un servidor RPC consiste en una coleccion de procedimientos que
un cliente puede solicitar por el envo de una peticion RPC al servidor
junto con los parametros del procedimiento. El servidor invocara el
procedimiento indicado en nombre del cliente, entregando el valor de
retorno, si hay alguno. Para ser independiente de la maquina, 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 representacion 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 a puesto RPC en el
dominio publico; se describe en una serie de RFCs(1).

A veces las mejoras en una aplicacion RPC introducen cambios

incompatibles con la interfaz de llamada a procedimientos. Por
supuesto, simplemente cambiando el servidor hara que no funcionen todas las aplicaciones que todava esperen el comportamiento
original. Por lo tanto, los programas RPC tienen numeros de version
asignados, casi siempre empezando por 1, y con cada nueva version
de la interfaz RPC, este contador se incrementa. A menudo, un
servidor puede ofrecer varias versiones simultaneamente; entonces
los clientes indican a traves del numero de version en la peticion que
implementacion del servicio quieren usar(1).
La comunicacion entre servidores RPC y clientes es un tanto peculiar. Un servidor RPC ofrece una o mas colecciones de procedimientos; cada conjunto se llama un programa y es idenficado de forma
u nica por un numero de programa. Una lista que relaciona nombres
de servicio con numeros de programa se mantiene usualmente en
/etc/rpc(1).
En redes TCP/IP , los autores de RPC se enfrentan al problema
del mapeo de numeros de programa con servicios genericos de red.
Disenaron cada servidor para proveer ambos puertos TCP y UDP
para cada programa y cada version. Generalmente, las aplicaciones
RPC usan UDP cuando envan datos, y vuelven a TCP solo cuando
los datos a transferir no caben en un solo datagrama UDP(1).
Si bien es cierto que resulta posible establecer sesiones entre
clientes y servidores y luego usar una comunicacion semiduplex
sobre esas sesiones, frecuentemente la elevada sobrecarga ocasionada
por multiples capas de conexion se hace poco atractiva para las
aplicaciones donde la performance es crtica, tales como servidores de
archivos. Una forma de comunicacion sin conexion construida directamente encima de una facilidad de datagramas nativa (especialmente
sobre LANs), a menudo, es una eleccion mucho mejor(3).
Aun cuando los problemas de performance puede solucionarse
usando el modo sin conexiones, el modelo aun tiene sus fallas
importantes: la base conceptual de toda comunicacion es la de entrada/salida (input/output). Los programas se comunican con otros usando comandos tales como X-DATA.request y X-DATA.indication, el
primero de los cuales es I/O y el u ltimo de los mismos probablemente
sea una interrupcion. Ellos difcilmente constituyan la herramienta
adecuada para construir aplicaciones bien estructuradas(3).
Por otros motivos, se ha estado investigando en las universidades
y en la industria sobre un modelo radicalmente diferente para el
dialogo y el control de errores basado en un servicio sin conexiones.
Este trabajo, conocido bajo el nombre de llamadas a procedimientos
remotos o RPC (remote procedure calls), ha sido ampliamente
implementado en redes y especialmente en sistemas distribuidos(3).
Las RPCs, a la hora de hablar de servicios de comunicaciones,
aunque desde una perspectiva muy diferente, estan logicamente
relacionadas con las mismas exigencias que la capa de sesion. Sin
embargo, el lector debera notar a lo largo del estudio que parte del

mecanismo esta implementado en las capas de presentacion y de

aplicacion(3).
Comercialmente, el producto NFS mencionado anteriormente proporciona una implementacion de RPCs mediante tres modulos: la
biblioteca de RPC propiamente dicha (ubicable en el nivel de sesion
OSI), una biblioteca de presentacion de datos denominada XDR
(a nivel de presentacion) y la interfaz al usuario junto a otras
utilidades (a nivel de aplicacion). Vale aclarar que algunos autores
tienen una opinion diferente respecto a esta distribucion y, mas aun,
hay ciertos paquetes de software que implementan una idea similar
directamente a la capa de aplicacion (aunque sea mucho menos
eficiente) por lo que algunas veces se lo discute en ese contexto.
Por simplicidad, aqu estudiaremos u nicamente la filosofa de la
propuesta, sin preocuparnos demasiado de su encuadre formal(3).
La escuela RPC propone el modelo cliente-servidor desde una
perspectiva completamente diferente, que ha sido disenada para ser
rapida y transparente. Una RPC es un metodo de comunicacion
entre procesos de una red que permite trabajar con un alto nivel de
abstraccion, ignorando los mecanismos de comunicacion subyacentes
y las caractersticas de su implementacion. La poltica de trabajo
surge a partir de la fusion de las ideas directrices del modelo clienteservidor (muy adecuado en una red) con las del mecanismo de
llamada a un procedimiento (muy conocido por los usuarios). Un
cliente enviando un mensaje al servidor y obteniendo una replica
se comporta de la misma manera que un programa llamando a un
procedimiento y consiguiendo un resultado. En ambos casos, el que
llama inicia una accion, espera que se complete y los resultados esten
disponibles. Si bien en el caso ordinario (local) el procedimiento
corre sobre la misma maquina mientras que con RPCs corre sobre
una maquina diferente, quien llama no necesita preocuparse por esta
distincion(3).
Para ayudar a ocultar aun mas la diferencia entre llamadas remotas
y locales, es posible embeber la RPC en el lenguaje de programacion.
Supongamos, por ejemplo, que proveemos a cada cliente de un
servidor de archivos con un procedimiento de biblioteca read(), que
puede llamarse con tres parametros: un identificador que indica cual
archivo leer, un buffer para almacenar los datos ledos y una cuenta
del numero de bytes a leer. Una llamada ordinaria a un procedimiento
local (es decir, un procedimiento incluido por el linker en el espacio
de direcciones de quien llama) toma la forma read(fileid, buffer,
count). Este procedimiento podra modificarse adecuadamente de
manera que se enve un mensaje al servidor de archivo y se espere
una respuesta. Solamente despues que llega la respuesta, read retorna
el control a quien efectuo la llamada(3).
La bondad de este esquema es que la comunicacion clienteservidor ahora toma la forma de llamadas de procedimientos en
lugar de comandos de I/O (o peor aun, de interrupciones). Todos los
detalles sobre como trabaja la red se le pueden ocultar al programa
de aplicacion poniendolos en los procedimientos locales tales como
el read() modificado. Esos procedimientos son llamados stubs(3).
En este ejemplo, el procedimiento stub realmente transfiere datos,
pero un procedimiento de este tipo tambien puede enviar un mensaje
pidiendole al servidor que ejecute una operacion arbitraria. Por
ejemplo, la llamada delete(filename), puede dar lugar a que el
procedimiento stub delete() enve un mensaje al servidor de archivos
pidiendole que destruya el archivo especificado como parametro.
Suministrando los procedimientos stubs apropiados, podemos tener
clientes invocando acciones arbitrarias sobre el servidor de una manera mucho mas natural para los programadores de aplicaciones que
enfrentarse con I/O o con interrupciones. El objetivo final es hacer
que las llamadas a procedimientos remotos no parezcan diferentes de
las llamadas a procedimientos locales(3).

En una llamada a procedimiento remoto el programador no necesita preocuparse de como se realiza la comunicacion entre procesos.
Simplemente realiza llamadas a procedimientos que seran ejecutados
en computadoras remotas. En este sentido, el programador desarrolla
sus aplicaciones de forma convencional descomponiendo su software
en una serie de procedimientos bien definidos. En una RPC, el
proceso que realiza la llamada empaqueta los argumentos en un
mensaje, se los enva a otro proceso y esperael resultado. Por su
parte, 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 realizo la llamada. Este proceso,
totalmente transparente al usuario que utiliza las RPC, es realizado
por unos modulos denominados resguardos, suplentes o stubs(4).

Fig. 1.

ONC RPC, abreviacion del ingles Open Network Computing

Remote Procedure Call, es un protocolo de llamada a procedimiento
remoto (RPC) desarrollado por el grupo ONC de Sun Microsystems
como parte del proyecto de su sistema de archivos de Red NFS,
algunas veces se lo denomina Sun ONC o Sun RPC. Trabaja sobre los
protocolos TCP y UDP. La codificacion de datos se realiza utilizando
el protocolo XDR (presentacion de datos)(5).
Implementaciones
Las implementaciones de ONC RPC existen para la mayora de
los sistemas como Unix (OpenVMS Alpha ,OpenVMS I64, etc.) y
Linux (en el subdirectorio sunrpc de la biblioteca Glibc)(5).
Las tecnologas que involucran a ONC RPC (incluyendo NFS y
NIS) desarrollada por Sun para su sistema operativo Solaris, en sus
versiones mas recientes se denominan tecnologas ONC+(5).
La Free Software Foundation esta desarrollando una implementacion GNU de este protocolo, denominado GNU Guile-RPC,
como parte del desarrollo del lenguaje de programacion GNU
Guile(5).
DCE Remote Procedure Call o bien DCE RPC
Es un sistema de llamada a procedimiento remoto del conjunto
de software OSF DCE. DCE / RPC, la abreviatura de Distributed
Computing Environment / Remote Procedure Calls , es el sistema
de llamada a procedimiento remoto desarrollado para el entorno de
la informatica distribuida (DCE)(5).
Este sistema permite a los programadores escribir software distribuido como si fuera todos los que trabajan en el mismo equipo,
sin tener que preocuparse por el codigo de red subyacente(5).
DCE RPC no debe confundirse con DCE el cual es un conjunto de
servicios que incluye DCE RPC, ademas de otras cosas como CDS
y DCE DFS(5).

Distributed Component Object Model (DCOM)

En espanol Modelo de Objetos de Componentes Distribuidos, es
una tecnologa propietaria de Microsoft para desarrollar componentes
software distribuidos sobre varios ordenadores y que se comunican
entre s. Extiende el modelo COM de Microsoft y proporciona el
sustrato de comunicacion entre la infraestructura del servidor de
aplicaciones COM+ de Microsoft. Ha sido abandonada en favor del
framework .NET(5).
La adicion de la D a COM fue debido al uso extensivo de
DCE/RPC, o mas especficamente la version mejorada de Microsoft,
conocida como MSRPC(5).
El Open Group tiene una implementacion DCOM llamada COMsource, cuyo codigo fuente esta disponible, as como la documentacion completa, suficiente para su uso y suficiente tambien para
implementar una version interoperable de DCOM. De acuerdo con la
documentacion, COMsource viene directamente del codigo fuente de
Windows NT 4.0, e incluso incluye el codigo fuente de un Servicio
de Registro de Windows NT(5).
El equipo de Wine tambien esta implementando DCOM. Lo hacen
para conseguir la interoperabilidad binaria, y no estan interesados en
la parte de distribucion sobre la red de DCOM, que es proporcionada
por MSRPC. Si bien se centran en implementar representacion de
datos en red a traves de los APIs de Microsoft, dicha implementacion
tratara de ser tan compatible como sea posible con MSRPC(5).
Paso por valor
El paso de parametros por valor consiste en copiar el contenido
de la variable que queremos pasar en otra dentro del a mbito local de
la subrutina, consiste pues en copiar el contenido de la memoria
del argumento que se quiere pasar a otra direccion de memoria,
correspondiente al argumento dentro del a mbito de dicha subrutina.
Se tendran dos valores duplicados e independientes, con lo que la
modificacion de uno no afecta al otro(5).
Paso por valorPaso por referencia
El paso de parametros por referencia consiste en proporcionar a
la subrutina a la que se le quiere pasar el argumento la direccion de
memoria del dato. En este caso se tiene un u nico valor referenciado
(o apuntado) desde dos puntos diferentes, el programa principal y la
subrutina a la que se le pasa el argumento, por lo que cualquier accion
sobre el parametro se realiza sobre la misma posicion de memoria(5).

IV. AGRADECIMIENTOS
Agradezco principalmente al docente encargado de la materia de
Sistemas Distribuidos ya que nos dio la oportunidad para realizar este
trabajo sobre llamada a procedimientos remotos y prestarnos su ayuda
con sus conocimientos sobre el tema para que este trabajo tenga una
gran valides, tambien a mis companeros del curso ya que la ayuda
entre companero fue muy u til para sacar las dudas que quedaban sin
entender.

R EFERENCES
[1] Llamada a Procedimiento Remoto.
http://es.tldp.org/Manuales-LuCAS/GARL2/garl2/x-087-2appl.rpc.html.
[Accessed: 03-Ago-2015].
[2] Que son los RPC (llamadas de procedimiento remoto).
http://culturacion.com/que-son-los-rpc-llamadas-deprocedimiento-remoto/.
[Accessed: 03-Ago-2015].
[3] RPC LLAMADA A PROCEDIMIENTO REMOTO.
http://www.textoscientificos.com/redes/tcp-ip/servicios-capatransporte/rpc.
[Accessed: 03-Ago-2015].
[4] Llamadas a Procedimientos Remotos (RPC).
http://www.tamps.cinvestav.mx/ vjsosa/clases/sd/RPCp pt.pdf.
[Accessed: 04-Ago-2015].
[5] Llamadas a Procedimientos Remotos(ONC RPC).
http://sistemasod.blogspot.com/2012/09/llamadasprocedimientos-remotos.html.
[Accessed: 04-Ago-2015].
[6] LLAMADAS A PROCEDIMIENTOS REMOTOS.
http://sistemas-distribuidos-ist-ucpr.wikispaces.com.
[Accessed: 04-Ago-2015].
[7] Remote Procedure Call.
http://www.arcos.inf.uc3m.es.
[Accessed: 04-Ago-2015].
[8] Generacion de Programas Distribuidos (Concepto de RPCGEN)
http://ldc.usb.ve/ mcuriel/Cursos/redes/claserpc.pdf.
[Accessed: 04-Ago-2015].
[9] Llamada a procedimientos remotos (RPC).
http://ccia.ei.uvigo.es/docencia/SCS/1011/transparencias/Tema22.pdf.
[Accessed: 04-Ago-2015].
[10] ecured-(Llamada a Procedimiento Remoto)
http://www.ecured.cu/index.php/LlamadaaP rocedimientoR emoto.
[Accessed: 04-Ago-2015].

III. C ONCLUSIONES Y TRABAJOS FUTUROS

Podemos concluir que las llamadas a procedimientos remotos son
conocida como un protocolo el cual hace que un software o programa
ejecute el codigo en otro maquina la misma que sera remota si
preocupacion por la comunicacion y a este paradigma lo conocemos
como el diagrama cliente servidor.
Tambien podemos decir que la realizacion de este trabajo de
llamadas a procedimientos remotos tiene como objetivo analizar las
RPC para los estudiantes del curso por ello se analizaron muchos
contenidos que daban informacion de como estaba estructurada las
RPC ademas de los diferentes tipos que existen y algo en comun que
la mayora utilizan el lenguaje de descripcion de interfaz los cuales
definen los metodos exportados del servidor.

Byron Intriago Intriago Intriago Estudiante de la

Carrera de Ingeniera en Sistemas de la Universidad
Tecnica de Manab, conocedor de algunos lenguajes
de programacion y de gestores de base de datos y
su uso. Provincia de Manab, Ciudad Portoviejo ,
Ecuador, 2015.