Troca de Mensagens - TerraLAB

Troca de Mensagens
_ Notas de Aula _
Prof. Tiago Garcia de Senna Carneiro
DECOM / UFOP
Num sistema distribuído não há memória compartilhada. Portanto, toda a comunicação
entre processos deve ser realizada através de troca de mensagens.
•
Pilha de Protocolos
Os processos de um sistema distribuído comunicam-se através da pilha de protocolos da
rede que interliga as máquinas sobre as quais estão executando. Entretanto, este fato pode
impor sérias restrições ao desempenho do sistema.
Quando uma mensagem é recebida ou enviada através de uma pilha de protocolos, cada
camada da pilha tende a anexar às mensagens enviada pelos processos um cabeçalho
contendo informações de controle.A existência de todos esses cabeçalhos cria uma
sobrecarga considerável no sistema. Nas redes de longa distância, onde a banda passante é
limitada a algums kbps (tipicamente, 64kbps), esta sobrecarga não chega a ser um problema
sério. O fator limitante neste caso é a capacidade das linhas de transmissão. Mesmo com
toda a manipulação de cabeçalhos, os processadores são suficientemente rápidos para
manter as linhas trabalhando à máxima velocidade. Então, um sistema distribuído de longa
distância pode usar pilhas de protocolos, tais como o TCP/IP, sem comprometer de forma
considerável o desempenho da comunicação entre processos. Entretanto, num sistema
distribuído baseado em rede local a sobrecarga introduzida pela pilha de protocolos é
desastrosa. Os processadores consomem um tempo muito grande processando protocolos
que acabam transformando a vazão (throughput) da rede em apenas uma pequena fração da
sua capacidade de transmissão nominal.
Portanto, a maioria dos sistema distribuídos baseados em rede local não utilizam protocolos
em camadas ou, no caso de usarem, implementam somente um subconjunto da pilha de
protocolos.
Além disso, para alcaçarem melhor desempenho os sistemas distribuídos tendem a evitar
protocolos baseados em conexão com o TCP/IP. O modelo-cliente servidor é basedo em um
protocolo muito simples, sem conexão, do tipo solicitação/resposta. O cliente envia uma
mensagem ao servidor solicitando algum serviço, o servidor faz o trabalho e envia para o
cliente o resultado ou um código de erro. Este esquema apresenta como vantagens a
simplicidade e a eficiência. Assumindo um sistema homogêneo, este esquema de
comunicação poderia ser implementado diretamente sobre a camada de enlace da pilha de
protocolos TCP/IP evitando-se as demais camadas.
•
Endereçamento
Para que um processo possa enviar mensagens a um processo remoto, ele precisa conhecer
o endereço desse processo. O endereço, end, de um processo deve indentificar numa
primeira instância a máquina na qual ele está executando e depois, quem é ele entre os
vários processos executando naquela máquina. De posse desse endereço, qualquer processo
pode invocar a primitiva send( end, &msg ) do sistema para eviar mensagens ao outro
processo ou então a primitiva receive( end, &msg) quando desejar receber mensagens desse
processo.
Vários esquemas de endereçamento podem ser utilizados, cada um apresenta vantagens e
desvantagens:
a) Endereçamento máquina.processo:neste esquema o endereço de um processo é
formado por duas partes, a primeira parte é o endereço da máquina onde o processo está
executando e a segunda parte é o endereço do processo dentro da máquina. Supondo a
existência de uma máquina cujo endereço IP seja 200.131.209.193 e a existência de um
número que identifica um processo dentro daquela máquina como o processo 5291, o
endereço do processo poderia ser expresso como 200.131.209.193.5291.
Este esquema apresenta dois problemas. O primeiro diz respeito à transparêcia à
migração que todo sistemas distribuído deve prover. O fato de usarmos o endereço da
máquina como parte do endereço quebra tal transparência uma vez que o processo 5291 não
poderia migrar para outra máquina sem causar problema, pois os processos que precisam
comunicar-se com ele não o encontrariam mais. Além disso, para garantir a transparência á
migração deveríamos garantir que nehum outro processo em todo o sistema fosse
identificado pelo número 5291, ou seja, que o identificador 5291 tivesse um escopo global,
pois só dessa forma o processo 5291 podera ser encontrado caso migrasse para uma outra
máquina do sistema. Neste momento é que surge o segundo problema. Que método seria
utilizado para gerar identificadores universais para todos os processos do sistema? Este
método iria interferir na confiabilidade ou desempenho do sistema distribuído? Por
exemplo, centralizar a reponsabilidade de gerar esses identificadores em um único processo
do sistema, com certeza, iria criar um novo gargalo no sistema além de fazer com que todo
o sistema dependa do bom funcionamento de um único processo.
Grande parte do esquema de comunicação do UNIX de Berkley utiliza um esquema um
pouquinho diferente desse: endereçamento máquina.local-ident. O campo máquina é o
endereço IP de 32 bits da máquina e o campo local-ident é um número de 16 bits escolhido
radômicamente pelo próprio processo. Um processo começa sua execução com uma
chamada ao núcleo do sistema para informá-lo que seu identificador é local-ident. A
probabilidade de um processo escolhar um ident-local que esteja sendo utilizado é remota,
mas caso isso aconteça o processo deverá escolher outro identificador.
b) Endereçamento de processo em broadcast: neste método um processo possui um
endereço que não depende do endereço da máquina onde está rodando. Quando um
processo A precisa comunicar-se com um processo B, o processo precisa antes de qualquer
coisa enviar uma mensagem broadcast na rede perguntado "Que máquina está executando
o processo B?". Todas as máquinas receberão esta mensagem, mas somente a máquina que
estiver o processo B responderá enviando o seu endereço para o processo A.
O problema com este esquema é que ele pode causar muita sobrecarga na rede, pois todo
processo para comunicar-se com outro precisará executar um broadcast. Além disso, um
processo terá sempre que esperar pelo endereço da máquina que executa o processo com
quem deseja se comunicar, esta fato torna-se ainda mais grave a penalização que a
comunicação entre processos impõe ao desempenho dos sistemas distribuídos.
c) Endereçamento de através de servidores de nome: no esquema de endereçamento
através de servidores de nome um processo extra é utilizado para mapear o nome de
serviços escritos em alto nível (ASCII), para endereços de máquina. Este processo é
chamado servidor de nome.
Serviços são facilidades que processos servidores oferecem a outros processos do sistema.
Um serviço é está sempre associado a um porto padronizado por convenção, por exemplo, o
serviço de ftp é associado ao porto 21 e o serviço de e-mail é associado ao porto 25. Desta
forma, quando o processo deseja solicitar um serviço, ele primeiro deve consultar o
servidor de nome para saber o endereço da máquina que executa o processo que fornece o
serviço e depois ele deve conectar-se a esta máquina informando o porto que corresponde
ao serviço que ele deseja. O porto é um número que permite ao sistema operacional
multiplexar a rede entre vários processos. Todo processo que deseja fornecer algum serviço
através da rede deve associar-se a um porto, assim quando uma mensagem chegar através
da rede o sistema operacional terá como saber para qual processo a mensagem deverá ser
entregue.
O problema deste esquema de endereçamento é que ele insere um componente centralizado
no sistema: o servidor de nome.
•
Comunicação Síncrona versus Comunicação Assíncrona
A comunicação entre processos pode ocorrer de duas maneiras diferentes. Na comunicação
síncrona quando um processo invoca a primitiva send(addr, &buffer) para enviar uma
mensagem a outro processo, a sua execução fica suspensa até que a mensagem realmente
chegue ao processo destinatário. Quando um processo invoca a primitiva receive( addr,
&buffer), a execução desse processo fica suspensa até que uma mensagem vinda do
processo addr chegue. A comunicação síncrona também é conhecida como comunicação
com bloqueio ou bloqueante. Na comunicação assíncrona a execução de um processo não
é bloqueda quando o processo invoca a primitiva send ou receive.
A comunicação assíncrona é a que apresenta um menor custo em termos de desempenho,
pois permite ao sistema distribuído explorar ao máximo o paralelismo de processamento e
comunicação. Entretanto, é a forma de comunição que apresenta maiores dificuldades de
implementação, além de criar novos problemas para o programador. Por exemplo, suponha
que um processo tenha invocado de forma assíncrona a primitiva send(addr, &buffer) e que
portanto, sua execução tenha continuado a ser realizada. Quando este processo terá certeza
que pode alterar o conteúdo da variável buffer sem alterar a informação a ser trocada
durante a comunicação? A resposta é simples, não há como.
Duas soluções podem ser dadas para o problema acima:
1) antes de ser enviada toda mensagem deve ser copiada para uma área de armazenamento
temporário interna ao núcleo do sistema. Assim, qualquer alteração no conteúdo da variável
buffer não influenciará a comunicação em andamento. Fatores críticos para esta estratégia é
a determinação do tamanho dessa área de armazenamento temporário e o número máximo
permitido de mensagens assíncronas sendo enviadas.
2) sempre que uma mensagem terminar de ser entregue ao seu destino, o processo que a
gerou deverá ser interrompido e informado do fato, ou seja, uma interrupção será gerada na
máquina do processo que originou a mensagem. Porém, o uso de interrupções torna o
programação dos processos comunicantes mais difícil, além de quase impossibilitar a
depuração dos mesmos.
Um aspecto importante da comunicação síncrona é a necessidade do uso de
temporizadores. Este temporizadores deverão ser utilizados para evitar que processos
fiquem eternamente esperando pela confirmação do envio de uma mensagem ou pela
chegada de uma mensagem gerada por outro processo.
•
Comunicação com Bufferização versus Comunicação SemBufferização
Suponha que um processo A envie uma mensagem M para um processo B, mas que o
processo B ainda não tenha executado a primitiva receive(addrA, &buffer), ou seja, que o
processo B ainda não esteja esperando por uma mensagem. Quando a mensagem chegar à
máquina onde o processo B está executando o sistema operacional deverá descartar a
mensagem ou esperar que o processo B a solicite? O que acontecerá se o processo B nunca
requisitar a mensagem M?
Duas soluções podem ser adotadas para resolver este problema. A primeira e a menos
desejada é simplesmente proibir que um processo invoque a primitiva send se não houver
um lugar para armazená-la na máquina destino. Isto é, o processo transmissor ficará
bloqueado até o processo destino invoque a primitiva receive. A segunda solução faz uso de
um buffer interno ao núcleo do sistema operacional chamado mailbox e de temporizadores.
A medida que as mensagens são recebidas elas vão sendo inseridas no mailbox que
funciona como uma fila de mensagens e para cada mensagem um novo temporizador é
iniciado com o objetivo de medir o tempo de permanência da mensagem no mailbox.
Conforme os processos forem requisitando as mensagens, estas vão sendo retiradas do
mailbox. Se nehum processo requisitar uma determinada mensagem e seu temporizador
atingir um valor máximo permitido, a mensagem é descartada.O problema com a segunda
solução é a sobrecarga gerada pela manutenção dos mailboxes.
•
Comunicação Confiável versus Comunicação Não-Confiável
Muitas vezes o envio de uma mensagem deve ser confiável, isto é, o processo que enviou a
mensagem deve receber uma confimação do processo destino informando o perfeito
recebimento da mensagem. Este mecanismo evitaria que uma mensagem perdida ou corrompida
atrapalhe o funcionamento do sistema.
Num arquitetura cliente-servidor a confirmação pode ser necessária tanto para garantir que um
servidor recebeu a solicitação de um cliente como para garantir que um cliente recebeu a
resposta de um servidor. Como tanto a solicitação do cliente como a resposta do servidor são
recebidas pelo núcleo do sistema operacional na forma mensagens a serem entregues aos
processos servidor e cliente, respectivamente, o próprio núcleo do sistema poderia confirmar o
recebimento dessas mensagens evitando-se que esses processos tivessem que fazê-lo, resultando
num melhor desempenho do sistema.
Para melhorar ainda mais o desempenho do sistema, quando o processamento solicitado por um
cliente for muito pequeno, em termos computacionais, a própria resposta a esta solicitação
poderia ser utilizada como confirmação. Desta forma, não sera necessário o envio de duas
mensagens para o mesmo processo onde um intervalo de tempo muito pequeno separaria uma
mensagem da outra, evitando-se sobrecargas na rede de comunicação do sistema distribuído.