chamada remota de procedimento (rpc) cont…noemi/sd-09/aula5.pdf · rpc e multithreading (cliente)...
TRANSCRIPT
Chamada Remota de Procedimento (RPC) cont…
semântica de chamadas
• pelo menos uma vez • no máximo uma vez • exatamente uma vez
• relação com protocolo subjacente • falhas e reinicializações de servidores
– funções idempotentes
binding
• amarração entre cliente e servidor reedita problema de localização de destinatário – solução portmapper no Sun RPC
• em geral: chamada a servidor que detém: – nome – localização (IP, porta) – estado
• e se… – nenhum servidor for localizado – vários servidores forem localizados
críticas
• sincronismo • modelo um a um • dificuldades de tratamento de falhas
• dinamismo
sincronismo
• processo que faz a chamada permanece bloqueado – falta de interatividade local – desperdício de uso da CPU
• processamento • outras operações de comunicação
RPC e multithreading (cliente)
• combinação de RPC com multithreading – sobreposição de computação
e comunicação – disparo de várias chamadas
• trocas de contexto preemptivas – custo – necessidade de sincronização
A1 B A2 C
alternativas
• cliente pode disparar threads apenas no momento de fazer chamadas remotas
• uso de mecanismos como co-rotinas • chamadas assíncronas
tratamento de chamadas
• concorrência no servidor B S A
como tratar???
concorrência no servidor
• opções análogas às vistas para servidores em geral
RPC assíncrona
• controle retorna imediatamente foo(a,b);
• mas como tratar retorno? – não tratar (funções oneway) – handler para sincronização posterior (futuros) – chamadas com callbacks
futuros
• promessas, chamadas adiadas, ... • chamada retorna valor que pode ser usado
para sincronização ou consulta: fut = foo (a, b) ...
if rpc.isReady(fut) ... ou ... rpc.waitFor(fut)
futuros
• implementações em muitas linguagens/bibs • ex:
% declaration - this is a comment statement objtype = promise returns (type) signals (...) % stream call operation objtype$operation_name(x, ...) % claim operation y: type = objtype$claim(x)
B. Liskov and Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems", in Proc. of the SIGPLAN'88 Conference on Programming Language Design and Implementation, Atlanta, Georgia, June 22-24, 1988, pp. 260-267.
RPC assíncrona - callbacks
• função de callback pode ser chamada qdo chamada se completa – aderência ao modelo de programação
function funcb(v) globalVal = v end obtemNovoVal(args, funcb);
programa como máquina de estado
function collect(val) acc = acc + val repl = repl + 1 if (repl==expected) then print ("Current Value: ", acc/repl) end end function askvals (peers) repl = 0; expected = 0; acc = 0 for p in pairs (peers) do expected = expected + 1 p:currValue{callback=collect} end end
problema de perda de locais
exemplo luarpc
function request(peers) local acc, repl = 0, 0 local expected = table.getn(peers) function avrg (val) repl = repl+1 acc = acc + val if (repl==expected) then print ("Current Value: ", acc/repl) end end for _,p in ipairs (peers) do rpc.async(p, "currValue", avrg)() end end
CLOSURE
comunicação um a um
• como pensar em canais ou mailboxes onde processos espalhados por várias máquinas podem recolher chamadas?
• no caso de tolerância a falhas: às vezes desejável que os diversos processos recebam a mesma chamada – replicação – comunicação em grupo
tratamento de falhas
• como retornar informações sobre falhas no modelo de chamada remota? – callbacks – exceções
dinamismo…
• modelo apresentado exige conhecimento sobre interfaces antes da geração do programa cliente – geração estática de stubs – suficiente para maior parte das situações
• adaptação dinâmica – servidores com diferentes otimizações
• cache – otimização dependendo do estilo de uso do cliente
• chamada dentro de loop – descoberta dinâmica de servidores
• relação com serviços de binding mais complexos
objetos distribuídos
• invocação remota de métodos – objetos como unidades localizadas, argumentos, etc – algumas facilidades para lidar com críticas anteriores
or1.mx
processo servidor
or2.my
o.main()
ol1.ma ()
ol1.mb () ol2.mn ()
ol2.mm ()
processo cliente
or1.mx(ol2) or1.mz
servant
callbacks ou upcalls
sistemas de objetos distribuídos
• sistemas acadêmicos – Emerald, ORCA, …
• sistemas largamente difundidos
– CORBA - interoperabilidade – Java RMI - integração com linguagem
• JINI • J2EE
RMI
• utilização de características da linguagem • carga dinâmica (download) de stubs e de
implementações de argumentos – interfaces x classes
• interface Remote define propriedades comuns a todos os objetos remotos – usada nas declarações do cliente – exceção RemoteException
• classe UnicastRemoteObject implementa funcionalidade básica de objeto remoto – estendida pela implementação do objeto servidor
Java RMI
• stub implementa “falsa” chamada a método remoto – empacota argumentos, realiza chamada, e retorna
resultados
Stub
RMI Client RMI Server
skeleton
return
call
arquitetura RMI
RMI Server
skeleton
stub
RMI Client
Registry
bind
lookupreturn call
Local Machine
Remote Machine
• servidor se registra em registry
• cliente contacta registry com lookup
• cliente pode baixar código de stub dinamicamente!
Localização: Product p = (Product) Naming.lookup(“rmi://fulano.com//sicrano”);
servidor RMI
/* SampleServer.java */ import java.rmi.*; public interface SampleServer extends Remote { public int sum(int a,int b) throws RemoteException; }
/* SampleServerImpl.java */ ... public class SampleServerImpl extends
UnicastRemoteObject implements SampleServer { SampleServerImpl() throws RemoteException { super(); }
cliente RMI
package client; import java.rmi.registry.LocateRegistry; import java.rmi.registry.Registry; ... public class ComputePi { public static void main(String args[]) { if (System.getSecurityManager() == null) { System.setSecurityManager(new SecurityManager()); } try { String name = "Compute"; Registry registry = LocateRegistry.getRegistry(args[0]); Compute comp = (Compute) registry.lookup(name); Pi task = new Pi(Integer.parseInt(args[1])); BigDecimal pi = comp.executeTask(task); System.out.println(pi); } catch (Exception e) { System.err.println("ComputePi exception:"); e.printStackTrace(); } } }
propostas de extensão
• ProActive: extensões para paralelismo – sincronismo inerente a chamadas remotas
bloqueio
– ausência de operações coletivas – outras críticas:
• obrigações com extensão de classe Remota e com sinalização de exceções
• !!!!
ProActive
• exploração de modelo de programação assíncrono – transparência de localização de objetos – futuros e wait on necesssity
• comunicação coletiva – extensão de chamada de método
• alocação de objetos em nós remotos • integração com bibliotecas para grades
Baude F., Baduel L., Caromel D., Contes A., Huet F., Morel M. and Quilici R.,in "GRID COMPUTING: Software Environments and Tools”, Springer Verlag, January 2006.
Java//
• biblioteca para programação multithread e distribuída • uso de reflexão computacional para interceptar
chamadas
sincronização inter objetos
• objetos ativos modelam concorrência e distribuição
• chamadas a objetos ativos são sempre assíncronas
• chamada retorna imediatamente um valor futuro – instância de subclasse do retorno declarado – tem todos os métodos do retorno esperado
• quando algum método é chamado sobre esse valor retornado é que ocorre a sincronização – wait-by-necessity
futuros
futuros como obj de 1a classe
• objetos retornados por operações assíncronas podem ser passados como argumentos em novas operações
• otimização da transferência de dados v1 = a.foo (...); // chamada assíncrona v2 = a.bar(...); // chamada assíncrona ... v1.f(v2)
CORBA
• mais do que o modelo de chamadas remotas – middleware
⇒ material introdutório do curso de componentes