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