Comunicação orientada a mensagens

críticas a RPC

•  sincronismo •  modelo um a um •  dificuldades de tratamento de falhas •  dificuldades com arquiteturas não cliente-

servidor

  volta ao modelo de troca de mensagens ⇒  com diferentes níveis de abstração

Sistemas de mensagens

•  suporte para ponto a ponto e grupos

•  desacoplamento –  temporal

•  persistência das mensagens

–  espacial •  canais e congêneres

Comunicação em grupo

•  primitiva única transmite msgs a grupo de procs

•  grupos abertos e fechados •  grupos estáticos e dinâmicos

–  serviços de controle de participantes

Comunicação em Grupo

•  motivações –  replicação e tolerância a falhas –  ferramentas para colaboração

•  jogos •  conferências •  edição colaborativa

•  um primeiro exemplo: no MPI, ligado a modelo SPMD –  operações coletivas

MPI - message passing interface

MPI_Init(&argc, &argv); MPI_Comm_size(MPI_COMM_WORLD, &size); MPI_Comm_rank(MPI_COMM_WORLD, &rank); if (rank == 0) { strcpy(message, "Hello, world"); for (i = 1; i < size; i++) MPI_Send(message, 13, MPI_CHAR, i, type,

MPI_COMM_WORLD); } else MPI_Recv(message, 20, MPI_CHAR, 0, type,

MPI_COMM_WORLD, &status); printf( "Message from process = %d : %s\n",

rank, message); MPI_Finalize(); }

grupos no MPI

•  todos os processos de uma aplicação pertencem a um comunicador (grupo) –  MPI_COMM_WORLD

•  grupos fechados com comunicação sincronizada •  operações coletivas têm como um de seus

parâmetros um comunicador –  MPI_Bcast(&n, 1, MPI_INT, 0, MPI_COMM_WORLD);

•  novos comunicadores podem ser criados dentro do programa

Operações Coletivas no MPI

•  Barrier: sincronização pura •  Broadcast •  Gather •  Scatter •  Reduction

todas criam barreira implícita

exemplo: MPI_Scatterv

Header for MPI_Scatterv

int MPI_Scatterv ( void *send_buffer, int *send_cnt, int *send_disp, MPI_Datatype send_type, void *receive_buffer, int receive_cnt, MPI_Datatype receive_type, int root, MPI_Comm communicator)

ex. simétrico: Function MPI_Gatherv

outros modelos de comunicação em grupo

•  integração com modelos de chamadas de objetos •  divulgação de um para muitos

–  distribuição em escala geográfica –  sistemas pub/sub

•  replicação e tolerância a falhas –  réplicas ativas X passivas

–  necessidade de multicast ordenado e confiável discutido nos tópicos de sincronização e tolerância a falhas

RMI e grupos

•  alguns trabalhos estendem o conceito de chamada remota para chamada em um grupo de objetos –  relação com programação SPMD

•  ProActive •  Charm++ •  ...

programação SPMD no ProActive

•  suporte a operações coletivas –  grupos tipados: coleções de objetos de

determinada classe (ou subclasses) A ag = (A) ProActiveGroup.newGroup (“A”, params, {node1, node2, node3}); ag.foo() // operação coletiva ... V vg = ag.bar() // vg é um grupo de classe “V” vg.f(); // outra operação coletiva // chamadas sobre f’s disparadas a medida // em que resultados se tornam disponíveis

interface Group

OO-SPMD Jacobi

•  barreiras forçam sincronização antes da execução de nova chamada assíncrona

chamadas assíncronas

publish/subscribe

•  sistema onde se registra interesse em receber mensagens –  filtragem de assuntos

•  diferentes níveis –  aplicação final: newsgroups –  primitivas de comunicação

•  modelos –  push e pull –  relação com orientação a eventos e arquitetura da

aplicação

pub/sub

serviço de pub/sub

P

P

P

P

A

A P

A

A

A

A

…

…

•  P. Eugster, P. Ferrer, R. Guerraoui e A. Kermarrec. The many faces of publish/subscribe. ACM Computing Surveys, 35(2), jun 2003.

padrão básico de interação

•  assinantes registram interesse em eventos ou padrões de eventos

•  publicação de evento gera notificação assíncrona

•  desacoplamento –  tempo –  espaço –  sincronização

desacoplamento espacial

Notify()

Notify()

Notify()

Notify()

serviço de eventos

publicador

publica

desacoplamento temporal

Notify() Notify()

Notify()

serviço de eventos

publicador

publica

Notify()

serviço de eventos

publicador

desacoplamento de sincronização

Notify()

Notify()

serviço de eventos publicador

publica

•  estilo assíncrono permite que partes se comuniquem sem se sincronizar

usos

–  exemplo clássico de bolsa de valores… –  notícias em geral –  bancos de dados –  jogos e simuladores – monitoramento de recursos

•  interesse de combinar paradigmas em uma mesma aplicação

variações nos sistemas p/s

1.  baseados em tópicos –  listas de interesse

–  similaridade com grupos –  alguns sistemas p/s baseados no ISIS

–  canais de comunicação –  em geral, strings usados como identificação de

canal –  uso de strings hierárquicos

public class StockQuote implements Serializable { public String id, company, trader; public float price; public int amount; } public class StockQuoteSubscriber implements Subscriber { public void notify (Object o) { if (((StockQuote)o).company == 'TELCO'&& ((StockQuote)o).price < 100) buy(): } } … Topic quotes = EventService.connect ("/LondonMarket/Stock/StockQuotes"); Subscriber sub = new StockQuoteSubscriber(); quotes.subscribe(sub);

inscrição com tópicos

variações nos sistemas p/s

2.  baseados em conteúdo –  em geral atributos internos –  eventos são conjuntos de pares (atributo, valor)

–  uso de filtros para estabelecer registro

4.  baseados em tipo…

public class StockQuote implements Serializable { public String id, company, trader; public float price; public int amount; } public class StockQuoteSubscriber implements Subscriber { public void notify (Object o) { buy(): } } … String criteria = ("company == 'TELCO'and price < 100") Subscriber sub = new StockQuoteSubscriber(); EventService.subscribe(sub);

inscrição por conteúdo

linguagens com filtros

•  filtros podem ser dados por: –  strings

•  SQL •  expressões lógicas

–  templates –  código executável

•  relação com strings •  segurança e otimização

p/s e espaços de tuplas

•  distinção feita qto ao sincronismo no acesso à informação – modelo pull

•  interface de acesso adequada para p/s por tópicos e por conteúdo

•  limitação na linguagem de filtros

arquiteturas

•  centralizadas e distribuídas

serviço de pub/sub

serviço de pub/sub

arquiteturas centralizadas

•  facilidade de ordenação •  consistência e transações •  problemas de escalabilidade

arquiteturas distribuídas

•  redes de servidores

•  rede de overlay –  mais complicado de manter

redes de servidores

•  como distribuir trabalho?

•  sistemas de tópicos: tópicos podem ser distribuídos entre servidores –  cada servidor fica responsável por disseminação de alguns

tópicos –  ex: Scribe

•  sistemas sem estruturas de tópicos –  roteamento a partir de diferentes pontos –  ex: Siena, Rebecca

roteamento

•  inscrições usadas para estabelecer rotas comuns

•  uso de anúncios para facilitar roteamento –  Siena, Rebecca

val<10 val<5 val<10

relação com p2p

•  contexto de p/s têm estimulado discussão sobre arquiteturas simétricas

•  o que é um sistema p2p?

•  disc. no contexto de distribuição de conteúdo –  Androutsellis-Theotokis e Spinellis. A Survey of

P2P Content Distribution Technologies. ACM Computing Surveys, 36(4), dez 2004.

o que é p2p?

•  sistemas onde todos os nós são equivalentes em funcionalidade e no papel desempenhado

•  sistemas que utilizam recursos nas bordas da Internet

.

.

.

características

•  compartilhamento de recursos sem necessidade de um elemento centralizador –  ciclos de CPU, armazenamento, banda ...

•  instabilidade e conectividade variável como normal –  população flutuante

exemplos de uso

•  comunicação entre usuários –  chat, trabalho colaborativo

•  serviços –  específicos: multicast –  genéricos: infras de computação distribuída

•  sistemas replicados –  bancos de dados –  servidores web

•  distribuição de conteúdo

p2p - questões

•  localização de recursos •  adaptação a entradas e saídas •  escalabilidade •  privacidade e confidencialidade •  disponibilidade e persistência •  …

  diferentes objetivos criam diferentes necessidades…   anonimato X reputação

} arquitetura

p2p - arquitetura

•  redes de overlay –  noções de vizinhança e conectividade

independentes daquelas da rede subjacente

p2p - arquiteturas

•  qto a centralização –  híbridas

•  servidores usados para algumas tarefas –  parcialmente centralizadas

•  supernós escolhidos dinamicamente –  totalmente distribuídas

•  servents

•  qto a estrutura –  não estruturadas –  estruturadas: localização de recurso baseada em chave

arquiteturas não estruturadas híbridas

•  uso de um servidor central para informação de disponibilidade de recursos –  em distribuição de conteúdo:

•  índices de arquivos •  listas de conexões correntes

•  simplicidade •  falta de escalabilidade

–  ? para que escala?

ñ estruturadas descentralizadas

•  todos os participantes têm papel simétrico –  uso de bases de dados ou até servidores para

encontrar algum participante corrente •  roteamento por inundação

exemplo ñ estruturada descentralizada

arquiteturas ñ estrut. parcialmente centralizadas

•  supernós atuam como servidores de cache ou de indexamento

•  disponibilidade de banda e de memória usados como critério de escolha de supernós

•  adaptação à heterogeneidade

•  relação com free riding

arquiteturas estruturadas

•  roteamento baseado em endereço/identificador de nó

•  conteúdo: arquivos armazenados em nós com identificador próximo ao seu –  útil para busca por nome exato

exemplo busca estruturada

relação com forma de comunicação

•  como se encaixaria um sistema de RPC aqui?

•  uso de mensagens tradicionais ou pub/sub é mais conveniente