Sistemas de informa¸c˜ao – Univ´as
Roberto Ribeiro Rocha
Mar¸co de 2014
Sum´
ario
1 Objetivos 1
2 Introdu¸c˜ao 1
3 Aspectos do RPC 1
3.1 Funcionamento de Chamadas Locais a Procedimentos . . . 2
4 Funcionamento de Chamadas Remotas a Procedimentos 3
4.1 Binding . . . 4 4.2 Semˆantica do RPC na presen¸ca de falhas . . . 5
5 Considera¸c˜oes Finais 8
1
Objetivos
• Mostrar como s˜ao feitas as chamadas remotas a um um procedimento, provendo um meio transparente para a execu¸c˜ao dessas chamadas;
• Apresentar as caracter´ısticas e funcionamento do mecanismo RPC;
• Entender como s˜ao empacotados os pedidos e respostas da chamada de um proce-dimento;
• Entender os problemas que podem ocorrer em uma chamada remota;
2
Introdu¸c˜
ao
No ambiente cliente/servidor, os usu´arios interagem com aplica¸c˜oes clientes que solicitam tarefas dos servidores.
A comunica¸c˜ao entre clientes e servidores se d´a atrav´es de um mecanismo do tipo
send/receive (request/reply).
Figura 1: Ambiente cliente/servidor
RPC introduz uma abstra¸c˜ao maior nesse esquema, permitindo que os clientes se comuniquem com os servidores atrav´es de chamadas a procedimentos.
Assim, um servi¸co pode ser visto como um m´odulo que possui uma interface bem definida de acesso `as suas fun¸c˜oes, permitindo uniformidade de acesso (mais simples), seguran¸ca e transparˆencia
Um exemplo do uso de RPC em Java pode ser visto no projeto XML-RPC da Apache (http://ws.apache.org/xmlrpc/xmlrpc2), no qual usa XML e HTTP para fazer a transferˆencia de informa¸c˜oes pela rede e fazer a chamada do procedimento remoto.
3
Aspectos do RPC
• N˜ao faz sentido utilizar vari´aveis globais ou ponteiros→ referˆencias “opacas”.
• Introdu¸c˜ao do uso de Interface Definition Language:
– Especifica os nomes dos procedimentos de acesso aos servi¸cos, lista de parˆametros, tipos e se s˜ao de entrada ou sa´ıda (assinatura das fun¸c˜oes).
– Benef´ıcios:
∗ esconde a implementa¸c˜ao dos procedimentos; ∗ independˆencia em rela¸c˜ao `a linguagem; ∗ maior abstra¸c˜ao.
• Classes de RPC:
– O sistema de RPC est´a integrado com uma linguagem de programa¸c˜ao.
– E utilizada uma linguagem espec´ıfica para defini¸c˜ao da interface entre clientes´ e servidores. Ex: Sun RPC(NFS), CORBA, ANSA, MIG (Mach).
• Tratamento de Exce¸c˜oes
• Transparˆencia
3.1
Funcionamento de Chamadas Locais a
Procedimentos
Como funciona uma “Local” Procedure Call ? Suponha a seguinte fun¸c˜ao: int mult(int x, int y)
Em uma chamada local, acontecem as seguintes a¸c˜oes:
• os parˆametros e o endere¸co de retorno s˜ao colocados na pilha;
• ´e alocado espa¸co para as vari´aveis locais;
• o controle ´e passado para a rotina chamada.
Quando o procedimento chega ao fim, ocorre o seguinte:
• o valor retornado ´e copiado para um registrador;
• recupera-se o endere¸co de retorno;
• a ´area na pilha ´e liberada;
Os parˆametros podem ser passados por: valor, referˆencia oucopy/restore
4
Funcionamento de Chamadas Remotas a
Procedimentos
Em uma chamada remota, com existˆencia da rede e dos sistemas operacionais entre o chamador e a fun¸c˜ao chamada, ´e necess´ario ter uma estrutura (middleware) para permitir essa opera¸c˜ao, conforme ilustra a Figura 2.
Figura 2: Processo de chamada de um procedimento remoto
Assim temos novos componentes de software para que isso se torne poss´ıvel:
• Stub do cliente: Respons´avel por prover uma interface amig´avel com o cliente, executando as seguintes a¸c˜oes:
– Criar uma mensagem com os parˆametros e o identificador da procedimento a ser chamada;
– Enviar essa mensagem ao servidor, atrav´es do m´odulo de comunica¸c˜ao;
– Esperar pela resposta (bloqueante);
– Recuperar o valor de retorno da resposta e devolver ao caller.
• Stub do servidor: Respons´avel por tratar um request vindo de um cliente, cha-mando a fun¸c˜ao e retornando a resposta:
– receber a mensagem;
– retirar os argumentos da mensagem;
– selecionar corretamente o procedimento a ser chamado;
– faz uma chamada local ao procedimento;
– quando este retornar, comp˜oe a mensagem de retorno e a envia ao cliente.
Devido ao fato do cliente ficar esperando a resposta do servidor, esta forma de chamada remota ´e s´ıncrona.
Em uma chamada RPC, o cliente chama um tipo especial de rotina, denominada
stub client que coloca os parˆametros em uma mensagem e a envia ao servidor, ficando bloqueado at´e que venha uma resposta.
No lado do servidor, o stub server recebe a mensagem, retira os parˆametros e faz uma chamada “local”ao procedimento servidor.
Durante todo o processo, cliente e servidor acreditam que tudo est´a acontecendo localmente.
4.1
Binding
Como o cliente localiza o servidor? Uma solu¸c˜ao ´e colocar o endere¸co de rede do servidor no programa cliente, por´em isso torna a solu¸c˜ao inflex´ıvel.
Uma alternativa ´e mapear dinamicamente cada servi¸co em uma porta espec´ıfica de um dado servidor, chamado de binding dinˆamico, utilizando um socket, que ´e um identificador do servi¸co do servidor ´e composto por: IP + port number.
Binder
Mant´em uma tabela mapeando os servi¸cos e suas respectivas portas/servidores. Ele possui trˆes fun¸c˜oes b´asicas para registrar, remover registro e buscar servi¸cos:
• Register (Servico:String; Porta:Port; Versao:Int): Solicita ao binder que registre o nome de um servi¸co, seu endere¸co de acesso e n´umero de vers˜ao.
• WithDraw (Servico:String; Porta:Port; Versao:Int): Solicita ao binder que retire um determinado servi¸co de sua tabela.
• LookUp (Servico:String; Versao:Integer):Port: O binder procura por um servi¸co (na vers˜ao desejada) em sua tabela e retorna o endere¸co de acesso.
O binder est´a localizado em um endere¸co well-known (host address), mantido nor-malmente em uma vari´avel de ambiente. Para localiz´a-lo, o cliente ou servidor faz um
broadcast, ao qual o binder responde com seu host address. O binding dinˆamico possui algumas vantagens:
• bastante flex´ıvel.
• permite v´arios servidores para o mesmo servi¸co balancear os clientes entre os servi-dores o servidor pode escolher os clientes que deseja atender controle de vers˜ao
Desvantagens:
• overhead
• O binder pode se tornar um gargalo. Alternativa: m´ultiplos binders, por´em h´a o
overhead de mantˆe-los consistentes.
4.2
Semˆ
antica do RPC na presen¸ca de falhas
O objetivo do RPC ´e esconder a comunica¸c˜ao atrav´es da cria¸c˜ao de uma chamada remota semelhante a uma chamada local. Por´em os problemas surgem quando erros ocorrem. Existem, basicamente, 5 classes diferentes de falhas que podem ocorrer em um sistema RPC:
1. O cliente n˜ao est´a apto a localizar o servidor: Ocorre devido `a algumas situa¸c˜oes: quando o servidor ´e desligado ou quando o cliente est´a usando uma vers˜ao desatualizada (o server foi atualizado sem o cliente ficar sabendo).
Formas de tratamento: retornar um valor de erro, por´em esse valor de erro pode ser confundido com algum valor retornado realmente pela fun¸c˜ao. Outra forma ´e gerar exce¸c˜ao, mas depende de implementa¸c˜oes e linguagens.
2. A mensagem de requisi¸c˜ao do cliente para o servidor ´e perdida: Essa situa¸c˜ao ´e a mais simples de resolver. Basta fazer com que o stub client inicie um temporizador ap´os o envio da mensagem de requisi¸c˜ao (request). Se o tempo expirar antes da chegada da mensagem de resposta (reply) ou de uma mensagem de confirma¸c˜ao, ent˜ao o stub client reenviar´a a mensagem de requisi¸c˜ao.
Figura 3: Perda da requisi¸c˜ao
3. A mensagem de resposta do servidor para o cliente ´e perdida: este ´e um problema mais s´erio. O temporizador n˜ao resolve totalmente o problema, pois o
Certas opera¸c˜oes podem ser repetidas com seguran¸ca (ou seja, s˜ao idempotentes) sem afetar o resultado final. Outras opera¸c˜oes n˜ao podem ser repetidas sem afetar o resultado final ou afetar chamadas subsequentes.
Uma forma de resolver ´e fazer com que o stub client associe um n´umero de identi-fica¸c˜ao a cada mensagem de requisi¸c˜ao. Assim, quando o stub server receber uma mensagem com um n´umero de identificador j´a executado, ele poder´a responder ao cliente sem a necessidade de reprocessar o pedido.
(a) Reprocessamento da requisi¸c˜ao (b) Reenvio da resposta
Figura 4: Perda da resposta.
4. O servidor falha e ´e reiniciado: Neste caso ´e dif´ıcil definir o que foi ou n˜ao executado, pois o erro no servidor pode antes de receber, antes de executar ou antes de enviar a resposta. Assim, ´e necess´ario definir uma das 4 semˆanticas de tratamento de erro no caso de falha do servidor:
• Semˆantica Maybe: N˜ao se garante nada. O cliente n˜ao fica sabendo e tamb´em n˜ao existe nenhuma garantia. Vantagem: F´acil de implementar. • Semˆantica At-least-once: Garante que a solicita¸c˜ao foi executada uma ou
mais vezes. Se as opera¸c˜oes do servidor s˜ao todas idempotentes, ent˜ao n˜ao h´a problema. O objetivo ´e repetir a opera¸c˜ao at´e que uma mensagem reply seja recebida com sucesso.
• SemˆanticaAt-most-once: Garante que a solicita¸c˜ao foi executada no m´aximo uma vez, mas pode tamb´em n˜ao ter sido executada (mais comum). A falha ´e reportada imediatamente quando ela ocorre.
• Semˆantica Exactly-once: Semˆantica ideal, onde a chamada ´e executada uma ´unica vez, por´em isso n˜ao ´e f´acil de conseguir em um sistema distribu´ıdo.
processo cliente aguardando a resposta. Estas solicita¸c˜oes perdidas s˜ao chamadas de
´orf˜as. Em v´arios casos, reiniciar o cliente resolveria o problema, pois a solicita¸c˜ao seria reenviada ao servidor, por´em existem casos mais complexos onde essa falha pode afetar outros sistemas travando arquivos e recursos.
(a) Falha no servidor (b) Falha no cliente
Figura 5: Falhas no cliente ou servidor.
Exerc´ıcio 1 –
Considerando a realiza¸c˜ao de uma chamada de
procedi-mento remoto, escreva, justificando, qual ´e o comportaprocedi-mento geral da
chamada quando o parˆametro passado ´e um ponteiro para uma vari´avel
local do cliente. O que acontecer´a se o procedimento modificar o conte´
udo
apontado por este ponteiro? Fa¸ca as considera¸c˜oes que achar necess´ario.
Exerc´ıcio 2 –
O que pode ser feito quando ocorre uma exce¸c˜ao na execu¸c˜ao
do c´odigo do servidor? A exce¸c˜ao deve ser tratada no servidor ou deve ser
devolvida para o cliente. Pense em uma forma que o cliente fique sabendo
que ocorreu e qual foi o erro ocorrido no servidor.
Exerc´ıcio 3 –
Qual a vantagem do uso de RPC em sistemas distribu´ıdos?
Quais s˜ao as preocupa¸c˜oes que o desenvolvedor deve ter para usar o RPC?
Exerc´ıcio 4 –
Cite dois exemplos de opera¸c˜oes idempotentes e dois
exem-plos de opera¸c˜oes n˜ao idempotentes. Justifique a escolha dos 4 exemexem-plos.
n˜ao idempotente e o servidor utiliza a semˆantica
At-least-once? Sugira pelo
menos uma forma de solu¸c˜ao.
5
Considera¸c˜
oes Finais
O uso de RPC facilitou muito o desenvolvimento de aplica¸c˜oes nas quais necessita-vam executar parte de seu c´odigo em uma outra m´aquina na rede. Essas chamadas s˜ao feitas de forma relativamente simples, pois o desenvolvedor n˜ao precisa mais preocupar com os detalhes de rede, referentes a envio e recebimento de informa¸c˜oes via sockets.
6
Bibliografia
• Chamada de Procedimentos Remotos - Edmilson Marmo Moreira - UNIFEI
• Remote Procedure Calls - M´ario Antonio Meireles Teixeira
• Remote Procedure Call - Andrey Shadrin - Saarland University Informatik, Sa-arbr¨ucken
• COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed Systems - Con-cepts and Design. 2. ed., 1994
