Filas de mensagens e streams Ficheiro - Moodle

Comunicação por Mensagens
e Streams
Pedro Ferreira
DI - FCUL
Comunicação por Mensagens

Comunicação Transitória por Mensagens

(interlocutores precisam estar ativos ao mesmo tempo)
– Berkley Sockets
» Centra-se no conceito de socket: end point usado para ler e escrever
mensagens transmitidas através da pilha de comunicação subjacente (que
pode concretizar quaisquer protocolos)
» API de comunicação que estudaremos nas teórico-práticas
– Message-Passing Interface (MPI)
» Fornece uma API mais elaborada para comunicação eficiente em
aplicações paralelas (super computadores e clusters de computadores)
» Não se preocupa em recuperar falhas e oferecer mecanismos de
sincronização entre processos
Comunicação Persistente por Mensagens
– Filas de Mensagens
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Comunicação Persistente por Mensagens: Motivação
[140-145]

Integração de aplicações pré-existentes sem divisão cliente-servidor possível

Desacoplamento temporal: possibilidade de desconexão temporária

Necessidade de execução exactamente uma vez

Necessidade de elevada fiabilidade
Banco 1
atm1
atm2
SIBS
Banco 2
atm3
atmN
Banco n
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Comunicação Persistente por Mensagens: Motivação
[140-145]

Integração de aplicações pré-existentes sem divisão cliente-servidor possível

Desacoplamento temporal: possibilidade de desconexão temporária

Necessidade de execução exactamente uma vez

Necessidade de elevada fiabilidade
Banco 1
atm1
atm2
SIBS
Banco 2
atm3
atmN
Banco n
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Comunicação Persistente por Mensagens: Motivação
[140-145]

Integração de aplicações pré-existentes sem divisão cliente-servidor possível

Desacoplamento temporal: possibilidade de desconexão temporária

Necessidade de execução exactamente uma vez

Necessidade de elevada fiabilidade
Banco 1
atm1
atm2
SIBS
Banco 2
atm3
atmN
Banco n
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Introdução às Filas de Mensagens

A chamada de procedimentos remotos (RPC) e a invocação de métodos
remotos (RMI) fornecem transparência na comunicação, mas requerem:
1. que o interlocutor esteja em funcionamento no momento da comunicação
2. o bloqueio do cliente enquanto o seu pedido é processado
(a menos que usemos RPC assíncrono)

A comunicação através de Filas de Mensagens remove estas duas limitações

Faz sentido usar este tipo de comunicação quando
–
os interlocutores estão ligados através de redes de grande escala, para as
quais a probabilidade de existirem desconexões não é desprezível
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Modelo das Filas de Mensagens

Message-Oriented Middleware
(MOM), ou message-queuing

Fornecem suporte para
comunicação persistente e
assíncrona

Oferecem espaço dentro do
sistema para o armazenamento de
mensagens até que o receptor
esteja apto/disposto a lê-las
Não obrigam a que o emissor e
receptor estejam simultaneamente
em funcionamento

© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Interface Básica
Primitiva
Put
Colocar uma mensagem numa fila
Get
Bloquear até que a fila não esteja vazia, e retirar a primeira
mensagem
Poll
Notify

Significado
Verificar se a fila tem uma mensagem e retirá-la nesse caso
(ou retornar sem bloquear)
Definir uma função que será chamada sempre que uma
mensagem for colocada na fila
Existem variantes destas primitivas que permitem, por exemplo, seleccionar
mensagens específicas dentre aquelas que estão na fila à espera de serem retiradas
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Arquitectura para um Sistema de Filas de Mensagens
Network

As mensagens são enviadas para uma fila (que tem um identificador único)

O endereço da fila é mapeado num endereço do nível transporte (IP/porto) para
que a mensagem possa ser enviada para o destino (estilo DNS)

A mensagem depois é entregue ou encaminhada por um conjunto de servidores
(ou relays) até ser copiada para a fila no receptor
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Arquitectura para um Sistema de Filas de Mensagens

Arquitectura genérica de um sistema de fila de mensagens
– cada máquina oferece uma interface para o envio/recepção de mensagens
– as máquinas encontram-se ligadas a um ou mais servidores responsáveis pelo
encaminhamento entre máquinas (relays)
– em várias localizações da rede existem buffers que permitem o armazenamento
temporário das mensagens
– Note que esta arquitectura é muito similar aos sistemas de emails
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Arquitectura para um Sistema de Filas de Mensagens
[145-149]


Para que a mensagem possa ser
entregue ao destino, no caso geral,
tem de se resolver um problema de
encaminhamento semelhante ao do
encaminhamento de pacotes nas
redes, e.g., IP.
– Só que numa rede overlay os
encaminhadores (relays)
oferecem espaço de
armazenamento onde as
mensagens podem ficar
guardadas caso o próximo
servidor não esteja acessível
Para além disso só têm de saber a
localização das filas seguintes
– Isto para obter escalabilidade
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Exemplo de aplicação: Brokers de Mensagens


Uma área importante de aplicação das filas de mensagens é a interligação de
aplicações pré-existentes (legacy applications)
– geralmente permitem e aceitam mensagens com formatos diferentes
O broker de mensagens utiliza uma base de dados de regras para fazer a
conversão de um formato para outro
– Funciona como um gateway ao nível de aplicação que traduz mensagens
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Exemplo de Aplicação: Brokers de Mensagens
[149-151]
Integração de
Aplicações
Corporativas


O núcleo de um broker de mensagens é
a sua base de regras para conversão de
formatos de mensagens
As regras podem ser muito complexas e
a sua concretização é responsável por
uma parte significativa dos custos de um
sistema de informação distribuído
– Problema da Integração
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Regras de Conversão
T1 -> T2: executar X
T2 -> T1: executar Y
T1 -> T3: executar Z
T2 -> T3: executar W
Exemplo de MOM: IBM WebSphere MQ

Sistema utilizado normalmente nos mainframes para o acesso e manipulação de
informação de grandes bases de dados (mas não só)
– Garante entrega exactamente uma vez e alta fiabilidade
MCA = Message Channel Agent
queue managers são ligados por pares de
message channels unidireccionais
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Exemplo de MOM: IBM WebSphere MQ


Cada MCA (Message Channel Agent) tem um conjunto de atributos associados
que definem o comportamento dos canais
– Alguns desses atributos tem de ser negociados pelos dois MCAs nas pontas
de um canal (e.g., tamanho máximo da mensagem, entrega FIFO)
Alguns exemplos de atributos:
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Exemplo de MOM: IBM WebSphere MQ

[152-156]
A transferência de mensagens entre Queue Managers (QM) é feita através de tabelas de
encaminhamento. O modelo suporta a utilização de aliases. Exemplo:
– (1) QMA quer enviar m para LA1; (2) LA1 = QMC; (3) QMC  SQ1;
(4) SQ1  QMB; (5) QMB quer enviar m para QMC; (6) QMC  SQ1;
(7) SQ1  QMC
(2)
(3)
(6)
(1) envia m a LA1
(5) recebe m
(4)
(7)
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Exemplo de MOM: IBM WebSphere MQ

[151-156]
A transferência de mensagens entre Queue Managers (QM) é feita através de tabelas de
encaminhamento. O modelo suporta a utilização de aliases. Exemplo:
– (1) QMA quer enviar m para LA1; (2) LA1 = QMC; (3) QMC  SQ1;
(4) SQ1  QMB; (5) QMB quer enviar m para QMC; (6) QMC  SQ1;
(7) SQ1  QMC
(2)
(3)
(1) envia m a LA1
(6)
As tabelas de
(5) recebe m
encaminhamento nos QMs
são definidas a mão!
(4)
(7)
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Comunicação por Streams
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Motivação

Vídeo/áudio através da Internet
– RPCs?
– Filas?
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Introdução às Streams


As streams suportam formas de comunicação para as quais o instante em que os
dados são recebidos é da maior importância
– Exemplos: áudio e vídeo contínuos (streaming na Internet)
Neste tipo de sistema, mais importante que os dados chegarem depressa é
chegarem numa taxa constante (i.e., com atrasos semelhantes)
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Especificação da Qualidade de Serviço (QoS)

Para que se consiga garantir os requisitos de tempo é conveniente que haja um
acordo com o sistema de suporte da rede de forma a que os canais de
comunicação ofereçam uma dada QoS

Exemplo de parâmetros que definem uma QoS (especificação da QoS):
– Máximo de perdas (bytes por unidade de tempo)
– Taxa de transmissão
– Tempo máximo para iniciar a comunicação (início de sessão)
– Atraso fim-a-fim
– Jitter máximo (variação no atraso)

Calculados com base em:
– tamanho máximo dos pacotes
– taxa de transmissão máxima (é possível na Internet?)
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Processo de Criação de uma Stream

A especificação da QoS tem de ser mapeada num conjunto de recursos a reservar
na rede de forma a que os requisitos indicados possam ser garantidos (e.g.,
buffers reservados nos encaminhadores, percentagem da largura de banda)

Exemplo de arquitectura possível:
– a rede tem de suportar RSVP (Resource reSerVation Protocol)
Isto quase nunca é
Suportado na Internet por
razões de escalabilidade.
Temos de procurar
soluções best-effort!
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Controlo de QoS



Mecanismos que nos permitem manter (com alta probabilidade) uma determinada QoS
mesmo com as imprecisões da rede
Um primeiro mecanismo são os serviços diferenciados (IP’ DiffServ): avisam-se os
encaminhadores da rede que certos pacotes tem de ser transmitidos o mais rápido possível
– Requer suporte dos encaminhadores...
Usando buffers de recepção de tamanho variável (e definido de acordo com a QoS
requerida) na recepção é possível evitar furos e atrasos na apresentação do conteúdo
multimédia, i.e., efetivamente reduz-se o jitter
– Solução fim-a-fim!
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Controlo de QoS
[157-162]


Certos tipos de conteúdo multimédia suportam perda de alguns quadros sem degradar de
maneira significativa a apresentação do conteúdo
– Se houver perda, é difícil pedir e esperar retransmissão!
– Em geral, estes conteúdos usam FEC (Forward Error Correction)
Para tirar proveito disso utiliza-se transmissão intercalada de quadros (outra solução
fim-a-fim) de tal forma que a perda de um pacote não significa a perda de vários frames
consecutivos (que seria percebida pelo receptor)
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Controlo de QoS
[157-162]


Certos tipos de conteúdo multimédia suportam perda de alguns quadros sem degradar de
maneira significativa a apresentação do conteúdo
– Se houver perda, é difícil pedir e esperar retransmissão!
– Em geral, estes conteúdos usam FEC (Forward Error Correction)
Para tirar proveito disso utiliza-se transmissão intercalada de quadros (outra solução
fim-a-fim) de tal forma que a perda de um pacote não significa a perda de vários frames
consecutivos (que seria percebida pelo receptor)
Sem intercalamento
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Controlo de QoS
[157-162]


Certos tipos de conteúdo multimédia suportam perda de alguns quadros sem degradar de
maneira significativa a apresentação do conteúdo
– Se houver perda, é difícil pedir e esperar retransmissão!
– Em geral, estes conteúdos usam FEC (Forward Error Correction)
Para tirar proveito disso utiliza-se transmissão intercalada de quadros (outra solução
fim-a-fim) de tal forma que a perda de um pacote não significa a perda de vários frames
consecutivos (que seria percebida pelo receptor)
Sem intercalamento
Com intercalamento
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Mecanismos de Sincronização entre Streams


[163-166]
Muitas vezes a tarefa que se pretende realizar resulta na transmissão de dados por
dois ou mais streams que devem estar sincronizados entre eles (sub-streams)
– video/legendas
dificuldade
– lip-synch
crescente
– canais stereo
Quem faz a sincronização de streams?
(feito pelo SO)
(feito por um middleware)
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Backup
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Sincronismo e Persistência na Comunicação – classificação geral




Comunicação persistente : cada mensagem que enviada é mantida pelo sistema o tempo
necessário para que o receptor a vá ler; logo
– após o envio da mensagem o emissor pode terminar imediatamente
– o receptor não precisa de estar em execução quando ocorre a emissão
Comunicação transitória : as mensagens são apenas armazenadas pelo sistema enquanto
o emissor e receptor se encontram em execução; logo
– a mensagem é descartada se receptor não estiver em execução no momento do envio
Comunicação assíncrona : o emissor continua a sua execução imediatamente após a
submissão da mensagem
– isto sucede mal a mensagem tenha sido copiada para o tampão local ou do primeiro
servidor
Comunicação síncrona : o emissor fica bloqueado até que
– a mensagem seja copiada para o tampão da máquina do receptor,
– ou que o receptor a leia/receba,
– ou que o receptor a tenha processado
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Exemplos de formas de comunicação
a) Comunicação persistente e assíncrona
Exemplo: email, filas de mensagens (Message-Oriented Middleware)
b) Comunicação persistente e síncrona
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Exemplos de formas de comunicação (cont)
2-22.2
c) Comunicação transitória e assíncrona
Exemplo: sockets UDP; MPI_bsend do Message Passing Interface (MPI)
d) Comunicação transitória e síncrona baseada na recepção
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia
Exemplos de formas de comunicação (cont)
e) Comunicação transitória e síncrona baseada na entrega
Exemplo: RPC assíncrono; MPI_ssend e em alguns casos de MPI_send
f) Comunicação transitória e síncrona baseada na resposta
Exemplo: RPC, chamada a objectos remotos (ex. RMI)
© 1999-2015 Alysson Neves Bessani, Nuno Ferreira Neves, Miguel Correia, Pedro Ferreira. Reprodução proibida sem autorização prévia