Amade Baptista Maiquita

Magido Mascate
Snia Massuanganhe

















ARQUITECTURA DE SISTEMAS PARALELOS
E DISTRIBUDOS


CHAMADA REMOTA DE PROCEDIMENTO (RPC)

Sun Microsystems




















Universidade Pedaggica

Nampula, Maio de 2014

Amade Baptista Maiquita
Magido Mascate
Snia Massuanganhe







ARQUITECTURA DE SISTEMAS PARALELOS E DISTRIBUDOS



Docente: Eng Diamantino Amisse









Universidade Pedaggica
Delegao de Nampula
Maio de 2014
Trabalho prtico de Arquitectura de
sistemas paralelos e distribudos,
para efeitos de avaliao, curso de
Engenharia Informtica, 5 Ano,
Turma nica.

ndice
1. Introduo ............................................................................................................................... 2
2. Objectivos de implementao de RPC ................................................................................... 3
3. Enquadramento do sistema no mbito de comunicao de processos .................................... 3
4. Arquitectura do sistema RPC SUN ........................................................................................ 4
5. Processo de binding ............................................................................................................ 5
6. eXternal Data Representation (XDR) ..................................................................................... 6
7. Passagem de parmetros ......................................................................................................... 7
8. Ficheiro Cliente ...................................................................................................................... 8
9. Ficheiro Servidor .................................................................................................................... 9
10. Ficheiro de cabealho do sistema ....................................................................................... 10
11. Concluso ........................................................................................................................... 11
12. Bibliografia ......................................................................................................................... 12



















P g i n a | 2

Chamada Remota de Procedimento (RPC)

1. Introduo
A Sun Microsystems desenvolveu o RPC na dcada de 80 com o objetivo de permitir o
desenvolvimento de aplicaes cliente/servidor sem necessidade de programar com interfaces
sob a camada de transporte como, por exemplo, sockets.

Este mecanismo de interao cliente/servidor serve de base para o desenvolvimento de
servios estendidos em sistemas operacionais de rede e encontra-se disponvel em
praticamente todos os sistemas operacionais derivados do UNIX.

Exemplo de servidores acessados via RPC:
Servidores NFS (Network File System): permitem acesso transparente
sistemas de arquivos remotos;
Portmapper: directrio de servidores RPC;
Servidor de NIS (Network Information System):
Servio de nomes e passwords;
Servidores de estatsticas.

RPC permite ao projectista de uma aplicao distribuda focalizar na aplicao e no na
comunicao entre os vrios componentes que compem a aplicao.

RPC utiliza os conceitos sedimentados de programao modular e os conceitos mais recentes
de orientao a objetos. Assim a aplicao dividida em mdulos:
mdulo = { proc. relacionados + dados associados }
procedimentos de um mdulo podem chamar procedimentos de outro mdulo de forma
arbitrariamente aninhada
mdulos podem ser localizados em mquinas distintas para aumentar o desempenho da
aplicao







P g i n a | 3

Chamada Remota de Procedimento (RPC)

2. Objectivos de implementao de RPC
A chamada de um procedimento deve ser transparente no que diz respeito localizao
(local ou remota) do procedimento chamado;
A semntica de uma chamada remota deve ser idntica de uma chamada local: passa
parmetros e retorna resultados;
No caso de erro de implementao, uma chamada local pode no retornar, caso o
procedimento chamado entre num lao infinito, porm falhas de comunicao local entre
o procedimento chamador e o chamado equivalem a uma falha total do sistema.

Esses objectivos foram parcialmente conseguidos nas implementaes correntes:
A sintaxe de uma chamada local idntica de uma chamada remota, porm o
programador deve codificar uma rotina de inter-face com o sistema run-time do RPC
chamada de rotina stub;
Mdulos remotos devem ter seus procedimentos registrados junto ao ambiente de
execuo do RPC;
A semntica de execuo no transparente a falhas de comunicao, ou seja, uma
chamada remota pode retornar um erro do tipo timeout.

3. Enquadramento do sistema no mbito de comunicao de processos

Como j mencionado, a Sun desenvolveu o RPC na dcada de 80 com o objetivo de permitir o
desenvolvimento de aplicaes cliente/servidor sem a necessidade de programar directamente
sobre a camada de transporte.
Um sistema RPC completo foi especificado e implementado pela Sun (inspirado em
implementaes pioneiras na Xerox) e posteriormente enquadrado pela ONC - Open Network
Computing

Este enquadramento da ONC inclui:
Um protocolo de comunicao incluindo formatos de mensagens para chamada remota e
retorno de resultados;
Um protocolo para especificao de representao de dados independente de arquitetura
(big endian versus little endian);
Regras para identificao de mdulos remotos e de seus procedimentos;
Escolha pela aplicao de dois protocolos: TCP ou UDP;
P g i n a | 4

Chamada Remota de Procedimento (RPC)

Especificao de semntica de execuo compatvel com a do protocolo de transporte
escolhido pela aplicao.

4. Arquitectura do sistema RPC SUN











Na rotina de adaptao temos:


















P g i n a | 5

Chamada Remota de Procedimento (RPC)

5. Processo de binding
O processo pelo qual um Cliente associa-se com um Servidor chamado de Binding.

1. Servidor registra servio
2. Cliente requisita localiza
3. Agente retorna localizao
4. Cliente chama Servidor

O binding tem de ser efectuado pelo cliente
Estabelecimento da sesso - ligao ao servidor (binding)
Localizao do servidor Autenticao do cliente e/ou do servidor Estabelecimento de
um canal de transporte {Chamada de procedimentos remotos}* - efectua os RPC necessrios
Terminao da sesso
Eliminao do canal de transporte

O registo tem de ser efectuado pelo servidor
Registo (Escolha da identificao do utilizador)
Nome do porto de transporte
Outros nomes alternativos
Registo dessa identificao {Esperar por pedidos de criao de sesses} *
Estabelecimento de um canal de transporte
Autenticao do cliente e/ou do servidor {Esperar por invocaes de procedimentos}
Enviados pelos clientes ligados
Terminao da sesso (Eliminao do canal de transporte)

Antes de executar um RPC, o cliente deve saber a localizao do servidor. A abordagem mais
flexvel para se obter o endereo acessar o servio de encapsulamento.
O encapsulador (binder) um servidor de endereo conhecido e fixo o qual possui
informaes sobre a localizao dos demais servidores (servidor de nomes). Quando um
servidor inicia sua execuo ele registra sua localizao e os procedimentos que ele suporta
no binder (exportao). O cliente acessa o binder para encontrar o endereo na rede do
procedimento que ele precisa.


P g i n a | 6

Chamada Remota de Procedimento (RPC)

Binding : Cliente RPC Sun

void main (int argc, char *argv[]){
CLIENT *cl;
int a, *result;
char* server;
if (argc < 2) {
fprintf(stderr, "Modo de Utilizao: %s mquina do
servidor\n", argv[0]);
exit(1); }
server = argv[1];
cl = clnt_create(server, BANCOPROG, BANCOVERS, "tcp");
if(cl == NULL) {
clnt_pcreateerror(server);
exit(1); }
sresult = saldo(nconta, cl); }

6. eXternal Data Representation (XDR)
O XDR uma especificao para a representao de vrios tipos de dados. Pelo uso de uma
representao padronizada de tipos de dados, o programa pode ter certeza de que est
interpretando corretamente o dado, mesmo que a fonte do dado seja uma mquina com uma
arquitetura completamente diferente [IBM].
So dois os propsitos do XDR. O primeiro prover um mtodo independente de arquitetura
para a representao de dados a serem passados na rede. O segundo prover um mtodo para
converter uma representao interna de dado prpria da arquitetura para o formato XDR e
vice-versa. O XDR necessrio por causa da proliferao de mquinas no mercado que tem
diferentes representaes de um mesmo tipo de dado [SIV93].

Na prtica, muitos programas no usam o XDR internamente. Eles usam a representao de
tipo de dado especfica da arquitetura do computador em que o programa est rodando.
Quando o programa precisa se comunicar com outro programa, ele converte seus dados para
um formato XDR antes de mandar o dado. Reciprocamente, quando o programa recebe o
dado, ele converte o dado do formato XDR para a sua representao especfica de tipo de
dado [IBM].

O XDR (External Data Representation) um padro para codificao e decodificao de
dados para o transporte entre diferentes arquiteturas (SUN, VAX, PC, CRAY). Cria uma
representao independente de mquina, sendo a converso automtica e transparente, sendo
realizada em tempo de compilao.
P g i n a | 7

Chamada Remota de Procedimento (RPC)


7. Passagem de parmetros

A chamada do procedimento remoto add(i,j), que pega dois parmetros inteiros, i e j, e retorna
sua soma aritmtica como resultado.
O add mostrada na parte esquerda (cliente), um apndice de cliente toma seus dois
parmetros e os coloca em uma mensagem como indicado. Coloca tambm o nome ou o
nmero do procedimento a ser chamado na mensagem porque o servidor poderia suportar
vrias chamadas diferentes e preciso lhe dizer qual delas requerida.













Quando a mensagem chega ao servidor, o apndice a examina para ver qual procedimento
necessrio e ento faz a chamada apropriada. Se o servidor tambm suportar outros
procedimentos remotos, o apndice de servidor poderia conter um comando de chaveamento
para selecionar o procedimento a ser chamado, dependendo do primeiro campo da mensagem.

A chamada propriamente dita do apndice para o servidor parecida com a chamada original
do cliente, exceto que os parmetros so variveis inicializadas com base na mensagem que
entra.
Exemplo de chamadas de para metros
/* addsub.x : definio da interface */

#define PROGRAM_NUMBER 12345678
#define VERSION_NUMBER 1
P g i n a | 8

Chamada Remota de Procedimento (RPC)


/* tipo de dado que ser passado aos procedimentos remotos */

struct operands
{
int x;
int y;
};

/* Definio da interface que ser oferecida aos clientes */

program ADDSUB_PROG
{
version ADDSUB_VERSION
{
int ADD (operands) = 1;
int SUB (operands) = 2;
}
= VERSION_NUMBER;
}
= PROGRAM_NUMBER;

8. Ficheiro Cliente
Chamamos clnt_create para criar um identificador (handle) RPC para o programa e verso
especfico em um host. Especificamos tambm o protocolo UDP como o protocolo.
Poderamos ter especificado o argumento final como tcp para usar o TCP como protocolo
de transporte.
Uma vez que temos o identificador, estamos aptos a chamar qualquer dos procedimentos
definidos para aquele programa e verso particular.
Quando chamamos bin_date_1, o primeiro argumento da chamada o mesmo definido no
arquivo de especificao (date.x).
O segundo argumento o identificador do cliente. O valor de retorno um ponteiro para um
inteiro longo, como visto no arquivo de cabealho date.h, gerado pelo compilador rpcgen.
Se um ponteiro para NULL retornado da chamada de procedimento remoto, porque
ocorreu um erro. Quando chamamos a funo str_date_1, o primeiro argumento um
ponteiro para um inteiro longo.
/* rdate.c - client program for remote date service. */
#include <stdio.h>
#include <rpc/rpc.h> /* standard RPC include file */
#include "date.h /* file generated by rpcgen */
main(int argc, char *argv[]) {
CLIENT *cl; /* RPC handle */
char *server;
P g i n a | 9

Chamada Remota de Procedimento (RPC)

long *lresult; /* return value from bin_date_1() */
char **sresult; /* return value from str_date_1() */

if (argc != 2) {
fprintf(stderr, "usage: %s hostname\n", argv[0]);
exit(1);
}
server = argv[1];
/* Create the client "handle." */
if ( (cl = clnt_create(server, DATE_PROG, DATE_VERS,
"udp")) == NULL) {
/* Couldn't establish connection with server. */
clnt_pcreateerror(server);
exit(2);
}

/* First call the remote procedure "bin_date". */
if ( (lresult = bin_date_1(NULL, cl)) == NULL) {
clnt_perror(cl, server); exit(3);
}
printf("time on host %s = %ld\n", server, *lresult);
/* Now call the remote procedure "str_date". */
if ( (sresult = str_date_1(lresult, cl)) == NULL) {
clnt_perror(cl, server); exit(4);
}
printf("time on host %s = %s", server, *sresult);
clnt_destroy(cl); /* done with the handle */
exit(0);
}


9. Ficheiro Servidor
A razo de se comentar que os valores de retorno devem ser variveis estticas (static)
porque ambas as funes retornam os endereos destas variveis.
Se as variveis no fossem estticas (static) ou externas (extern), isto , fossem variveis
automticas, seus valores estariam indefinidos logo aps a instruo return passasse o
controle de volta ao stub do servidor, que quem chama os procedimentos remotos.

/* dateproc.c: remote procedure called by server stub*/
#include <rpc/rpc.h> /* standard RPC include file */
#include "date.h" /* file generated by rpcgen */
/* Return the binary date and time. */
long *bin_date_1() {
static long timeval; /* must be static */
long time(); /* Unix function */
timeval = time((long *) 0);
P g i n a | 10

Chamada Remota de Procedimento (RPC)

return(&timeval);
}
/* Convert a binary time and return a human readable
string. */
char **str_date_1(long *bintime) {
static char *ptr; /* must be static */
char *ctime(); /* Unix function */
ptr = ctime(bintime); /* convert to local time */
return(&ptr); /* return the address of pointer */
}

10. Ficheiro de cabealho do sistema
O arquivo de cabealho define o valor de retorno da funo bin_date_1 como um ponteiro
para um inteiro longo e o valor de retorno da funo str_date_1 como um ponteiro para um
ponteiro de carcter.
O RPC da Sun especifica que o procedimento remoto retorne o endereo do valor
retornado. Alm disso, passado ao procedimento remoto o endereo de seu argumento,
quando este chamado pelo stub do servidor.

#define DATE_PROG ((u_long) 0x31234567)
#define DATE_VERS ((u_long) 1)
#define BIN_DATE ((u_long) 1)
extern long *bin_date_1();
#define STR_DATE ((u_long) 2)
extern char **str_date_1(long
*bintime);











P g i n a | 11

Chamada Remota de Procedimento (RPC)

11. Concluso
Construir um sistema distribudo segundo o modelo cliente/servidor utilizando as primitivas
send e receive pode se tornar complicado: estas primitivas no fazem parte dos conceitos-
chave dos sistemas centralizados.

Deseja-se que sob a ptica do usurio o sistema distribudo se parea com o centralizado, e
assim usamos o mtodo: Chamada Remota a Procedimento (RPC - Remote Procedure Call),
que permite ao projectista de uma aplicao distribuda focalizar na aplicao e no na
comunicao entre os vrios componentes que compem a aplicao.

O objectivo da biblioteca RPC permitir ao programador uma forma de escrever o seu cdigo
de forma similar ao mtodo adoptado para a programao convencional. Para isso, a estrutura
RPC define um esquema de encapsulamento de todas as funes associadas conexo remota
num pedao de cdigo chamado de STUB.




















P g i n a | 12

Chamada Remota de Procedimento (RPC)

12. Bibliografia
Tanenbaum, Andrew S. e Steen, Marteen Van. Sistemas Distribudos, So Paulo: Prentice
Hall, 2008.

Andrew S. TANENBAUM Sistemas operacionais modernos Prentice-Hall, 1995 Seo
10.3 pg. 285-304