colouris-resumo-cap1-2-4-5.pdf

Prévia do material em texto

CAPITULO 1 
 
 
Principais Desafios em SD 
 
● Heterogeneidade:​ A internet permite aos usuários acessarem serviços e executarem 
aplicativos por meio de um conjunto heterogêneo de computadores e redes. A 
heterogeneidade (isto é, variedade e diferença) se aplica aos seguintes aspectos: 
○ redes 
○ hardware de computador 
○ SOs 
○ linguagens de programação 
○ implementações de diferentes desenvolvedores 
 
● Abertura (openness):​ Capacidade de o sistema ser extensível, quer em hardware 
quer em software. Novos componentes devem poder ser adicionados sem por em 
causa o funcionamento dos já existentes, e poder comunicar com eles. Para isso é 
importante que sejam conhecidas as interfaces dos novos componentes através da 
publicação da sua documentação e utilizar protocolos. 
● Segurança:​ A segurança de recursos de informação tem três componentes: 
confidencialidade ​( proteção contra exposiçõa para pessoas não autorizadas), 
integridade​ (proteção contra alteração ou dano) e ​disponibilidade​ (proteção contra 
interferência com os meios de acesso aos recursos). 
○ Ataque de negação de serviço:​ ocorre quando um usuário interrompe um 
serviço por algum motivo. Isso pode ser conseguido bombardeando o serviço 
com um número tão grande de pedidos sem sentido, que os usuários não são 
capazes de usá­lo. 
● Escalabilidade:​ Um sistema é descrito como escalável se permanece eficiente 
quando há um aumento significativo no número de recursos e no número de usuários. 
○ É necessário desenhar o software de forma a que o aumento de utilizações 
não exija grandes alterações, evitar algoritmos, serviços e estruturas de dados 
centralizados, controlar o aumento de custos devido à disponibilização de mais 
recursos, controlar a perda de performance e evitar o transbordo de certos 
limites de  recursos. 
● Tratamento de falhas: ​As falhas em um SD são parciais ­ isto é, alguns 
componentes falham, enquanto outros continuam funcionando. Portanto, o tratamento 
de falhas é particularmente difícil. Seguem as técnicas comuns: 
○ Detecção de falhas: ​algumas falhas podem ser detectadas. Por exemplo, 
somas de verificação podem ser usadas para detectar dados danificados em 
uma mensagem ou em um arquivo. 
○ Mascaramento de falhas:​ algumas falhas detectadas podem ser ocultas ou 
se tornar menos sérias. Exemplo de ocultação de falhas: 
■ mensagens podem ser retransmitidas quando não chegam; 
■ dados de arquivos podem ser gravados em dois discos, para que, se 
um estiver danificado, o outro ainda possa estar correto. 
○ Tolerância a falhas:​ a maioria dos serviços na Internet apresenta falhas ­ não 
seria pratico tentar detectar e mascarar tudo que possa ocorrer em uma rede 
tão grande, com tantos componentes. Seus clientes podem ser projetados de 
forma a tolerar falhas. por exemplo: 
■ quando um navegador não consegue contatar um servidor web, ele não 
faz o usuário esperar indefinidamente, enquanto continua tentando ­ ele 
informa o usuário sobre o problema, deixando­o livre para tentar 
novamente. 
○ Recuperação de falhas​: a recuperação envolve projetar software de modo 
que o estado dos dados permanentes possa ser recuperado ou retrocedido, 
após a falha de um servidor. Em geral, as computações realizadas por alguns 
programas ficarão incompletas quando ocorrer uma falha e os dados 
permanentes que eles atualizam podem não estar em um estados consistente. 
○ Redundância: ​ os serviços podem se tornar tolerantes a falhas com o uso de 
componentes redundantes. Considere os exemplos a seguir: 
■ Sempre deve haver pelo menos duas rotas diferentes entre dois 
roteadores quaisquer na Internet. 
■ No Domain Name System, toda tabela de correspondência de nomes é 
replicada em pelo menos dois servidores diferentes. 
■ Um banco de dados pode ser replicado em vários servidores, para 
garantir que os dados permaneçam acessíveis após a falha de 
qualquer servidor. Os servidores podem ser projetados de forma a 
detectar falhas em seus pares: quando uma falha é detectada em um 
servidor, os clientes são redirecionados para os servidores restantes. 
● Concorrência:  ​os vários utilizadores utilizam o sistema em simultâneo (é necessário 
coordenar o acesso aos recursos partilhados) 
● Transparência: ​O sistema deve ser visto como um todo e não como uma coleção de 
componentes distribuídos. 
○ Transparência de Acesso​: permite que o acesso a recursos locais e a 
recursos remotos seja feito através das mesmas operações (i.é, usando a 
mesma interface). 
○ Localização​: permite que os recursos possam ser acedidos sem o 
conhecimento da sua localização. (ex. Programas de correio electrónico) 
○ Concorrência​: permite que os vários clientes de um componente não 
necessitem de ter em conta o acesso concorrente ao componente. 
○ Replicação​: permite que os clientes de um componente não se apercebam se 
existe replicação e estão a usar uma réplica e não o original; a utilização de 
várias instâncias de um componente pode ocorrer por razões de desempenho 
ou de fiabilidade; os utilizadores do componente não necessitem de saber que 
o componente possa ser replicado. 
○ Falhas​: permite que o sistema funcione na presença de falhas de hardware ou 
software sem que utilizadores e programadores saibam como as falhas foram 
ultrapassadas. (por ex. um sistema de e­mail pode retransmitir uma mensagem 
até que a mesma seja entregue com sucesso) 
○ Migração​: permite que um recurso possa mudar de localização sem que isso 
afecte a sua utilização. (ex. Telemóveis em movimento) 
○ Desempenho:​ permite que o sistema seja reconfigurado para melhorar o seu 
desempenho sem que os utilizadores se apercebam.  
○ Escalabilidade:​ permite que o sistema seja expandido sem que os utilizadores 
se apercebam de como isso foi conseguido. 
 
CAPITULO 2 
 
Modelos: 
 
Descrição abastrata e simplificada de aspectos relevantes relacionados ao design de 
um sistema distribuído 
● Modelos Físicos 
● Modelos Arquiteturais: Um modelo arquitetural de um sistema distribuído é a 
estrutura do sistema em termos de ​localização ​das suas diferentes partes, do 
papel ​que cada parte desempenha e como se inter­relacionam. 
● Modelos Fundamentais: Os sistemas distribuídos podem ainda ser analizados 
segundo 3 aspectos transversais a todos os sistemas: 
○ Modelo de Interação( ou de sincronismo):  
○ Modelo de Falhas (ou Avarias) 
○ Medolo de Segurança 
 
 
Modelo de interação: ​Interação é a ação (comunicação e sincronização) entre as 
partes para realizar um qualquer trabalho.  
 
É afetada por dois aspectos: 
➔ Performance dos canais de comunicação:​ A comunicação em uma rede de 
computadores tem as seguintes características de desempeno relacionadas à 
latência​, ​largura de banda​ e ​jitter​: 
 
◆ Latência :​ Intervalo de tempo que medeia entre o início da transmissão 
de uma mensagem por um processo e o início da sua recepção pelo outro 
processo. A latência inclui: 
● O tempo que o primeiro bit de um conjunto de bits transmitido em 
uma rede leva para chegar ao seu destino. Por exemplo, a latência 
da transmissão de uma mensagem por meio de um enlace de 
satélite é o tempo necessário para que um sinal de rádio vá até o 
satélite e retorne a terra para seu destinatário. 
● O atraso no acesso à rede, que aumenta significativamente 
quando a rede está muito carregada. Por exemplo, para 
transmissão Ethernet, a estação remetente espera que a rede 
esteja livre de tráfego para poder enviar sua mensagem. 
● O tempo de processamento gasto pelos serviços de comunicação 
do sistema operacional nos processos de envio e recepção, que 
varia de acordo com a carga momentânea dos computadores. 
◆ Largura de banda​: É o volume total de informações que pode ser 
transmitido em determinado momento. Quando um grande número de 
comunicações usa a mesma rede, elascompartilham a largura de banda 
disponível. 
◆ Jitter:​ É a variação no tempo exigida para distribuir uma série de 
mensagens. O Jitter é crucial para dados multimídia. Por exemplo, se 
amostras consecutivas de dados de áudio são reproduzidas com 
diferentes intervalos de tempo, o som resultante será bastante distorcido. 
   
 
 
➔ Inexistência de um tempo global;​ Cada computador possui seu próprio relógio 
interno, o qual pode ser usado pelos processos locais para obter o valor atual da 
hora. Mesmo que dois processos leiam seus relógios locais simultâneamente 
esses podem fornecer valores diferentes. 
◆ Taxa de desvio do relógio (Drift):​ se refere à quantidade relativa pela 
qual um relógio de computador difere de um relógio de referência perfeito 
● Os drifts de dois relógios distintos são também distintos, o que 
significa que entre eles o tempo será sempre divergente. 
 
◆ Uma solução passa por obter o tempo fornecido por GPS – Global 
Positioning System, e enviar aos participantes do sistema distribuído. 
Problema: Delays no envio dessa mensagem!!! 
 
➔ Duas variantes do modelo de interação:  ​Em um sistema distribuído é muito 
difícil estabelecer limites para o tempo que leva a execução dos processos, para 
a troca de mensagens ou para o desvio do relógio. Dois pontos de vistas 
opostos fornecem modelos simples; o primeiro é fortemente baseado na idéia de 
tempo, o segundo não. 
 
◆ Sistemas distribuídos síncronos:   
● o tempo para executar cada etapa de um processo tem limites 
inferior e superior conhecidos; 
● cada mensagem transmitida em um canal é recebida dentro de um 
tempo limitado, conhecido; 
● cada processo tem um relógio local cuja taxa de desvio do tempo 
real tem um limite conhecido 
 
Dessa forma, é possível estimar prováveis limites superior para o tempo 
de execução de um processo, para o atraso das mensagens e para as 
taxas de desvio do relógio em um SD. 
 
Os SDs síncronos podem ser construídos, desde que se garanta que os 
processos sejam executados de forma a respeitar as restrições temporais 
impostas. 
 
➔ Sistemas distribuídos assíncronos: ​ Um SD assíncrono é aquele em 
que não existem considerações sobre: 
◆ as velocidades de execução de processos ­ por exemplo, uma 
etapa do processo pode levar apenas um picossegundo e outra, 
um século; tudo que pode ser dito é que cada etapa pode demorar 
um tempo arbitrariamente longo; 
◆ os atrasos na transmissão das msnssagens ­ por exemplo, uma 
mensagem do processo A para o processo B pode ser enviada em 
um tempo insignificante e outra pode demorar vários anos. Em 
outras palavras, uma mensagem pode ser recebida após um 
tempo arbitrariamente long; 
◆ as taxas de desvio do relógio ­ novamente, a taxa de desvio de um 
relógio é arbitrária. 
 
O modelo assíncrono não faz nenhuma consideração sobre os intervalos 
de tempo envolvidos em qualquer tipo de execução 
 
➔ Modelo de Falhas: ​Uma falha é qualquer alteração do comportamento do 
sistema em relação ao esperado, isto é, em relação à sua especificação. As 
falhas podem atingir os ​processos​ ou os ​canais de comunicação. 
 
 
 
◆  Tipos de falhas 
● Falhas por Omissão; 
● Falhas arbitrárias; 
● Falhas em temporização; 
 
 
Falha por Omissão: ​As falhas por omissão se referem aos casos em que um 
processo ou canal de comunicação deixa de executar as ações que deveria. 
 
● Falhas por omissão de processo: ​a principal falha por omissão 
de um processo é quando ele entra em colapso, parando e não 
executando outro passo de seu programa. O colapso de um 
processo é chamado de ​parada por falha​ se outros processos 
puderem detectar, com certeza, a ocorrência dessa situação. Em 
um sistema síncrono, uma parada por falha ocorre quando 
timeouts são usados para determinar que certos processos 
deixaram de responder a mensagens sabidamente entregues. 
●  Falhas por omissão na comunicação: ​O canal de comunicação 
produz uma falha por omissão quando não concretiza a 
transferência de uma mensagem ​m​ do buffer de encio de um 
processo ​p​ para o buffer de recepção de um outro processo ​q​. Isso 
é conhecido como “perda de mensagens” e geralmente é causado 
pela falta de espaço no buffer de recepção, ou pela mensagem ser 
descartada ao ser detectado que houve um erro durante sua 
transmissão. 
 
Falhas Arbitrárias: ​ O termo falha arbitrária, ou bizantina, é usado para 
descrever a pior semântica de falha possível na qual qualquer tipode erro pode 
ocorrer. 
 
● Uma falha arbitrária de um processo​ é aquela em que ele omite 
arbitrariamente passos desejados do processamento ou efetua 
processamento indesejado. Portanto, as falhas arbitrárias não podem ser 
detectadas verificando­se se o processo responde às invocações, pois ele 
poderia omitir arbitrariamente a resposta. 
●  Os canais de comunicação ​ podem sofrer falhas arbitrárias: por 
exemplom o conteúdo da mensagem pode ser corrompido, mensagens 
inexistentes podem ser enviadas ou mensgens reais podem ser 
entregues mais de uma vez. As falhas arbitrárias dos canais de 
comunicação são raras, pois o software de comunicação é capaz de 
reconhece­las e rejeitar as mensagens com problemas. 
 
Falhas de temporização: ​As falhas de temporização são aplcãveis aos SDs 
síncronos onde limites de tempo são estabelecidos para o tempo de execução 
do processo, para o tempo de entrega de mensagens e para a taxa de desvio do 
relógio. 
Em um SD assíncrono, um servidor sobrecarregado pode responder muito 
lentamente, mas não podemos dizer que ele apresenta uma falha de 
temporização, pois nenhuma garantia foi oferecida. 
 
 
Mascaramento de falhas: ​É possível construir serviços confiáveis a partir de 
componentes que exibem falhas. Por exemplo vários servidores que contêm 
réplicas dos dados podem continuar a fornecer um serviço quando um deles 
apresenta um defeito. 
Um serviço mascara uma falha ocultando­a completamente ou convertendo­a 
em um tipo de falha mais aceitável. 
 
Confiabilidade da comunicação de um para um: ​O termo comunicação 
confiável é definido em termos de validade e integridade, como segue: 
● validade: ​qualquer mensagem do buffer de envio é entregue ao buffer de 
recepção de seu destino, independentemente do tempo necessário para 
tal; 
● integridade: ​a mensagem recebida é idêntica à enviada e nenhuma 
mensagem é entregue duas vezes. 
○ São ameaças à integridade:​ Qualquer protocolo que retransmita 
mensagens, mas não rejeite uma mensagem que entregue duas 
vezes. Usuários mal­intencionados que podem injetar mensagens 
espúrias, reproduzir mensagens antigas ou falsificar mensagens. 
 
 
 
 
 
 
 
 
 
➔ Modelo de Segurança: ​Proteção das entidades do sistema, processo/utilizador 
(“principal”). 
 
 
 
 
Direitos de acesso​ especificam ​que entidades ​podem aceder, e​ de que forma, a que 
recursos​. 
Ex: Que entidade pode executar que operações num dado objeto. 
 
O servidor ​é responsável por verificar a ​identidade​ de quem (entidade) fez o pedido, e 
verificar se essa entidade tem ​direitos de acesso​ para realizar a ​operação pretendida. 
 
O cliente​ deverá verificar a ​ identidade​ de quem lhe enviou a resposta, para ver se a 
resposta veio da entidade esperada. 
 
Ameaças​: Supondo que existe um processo inimigo capaz de enviar qualquer 
mensagem para qualquer processo, interceptar (ler/copiar) qualquer mensagem 
trocada entre 2 processos. 
As ameaças de um inimigo em potencial são discutidas sob os títulos : 
Ameaças aos processos: ​um processo projetado para tratar de pedidos pode receber 
uma mensagem de qualquer outro processo no sistema distribuído e não ser capaz de 
determinar com certeza a identidade do remetente. IP inclui o endereço do computador 
origem da mensagem mas um processo inimigo pode forjar esse endereço. Um clientetambém não dispõe de métodos para validar as respostas de um servidor. 
Ameaças aos canais de comunicação: ​Um processo inimigo pode copiar, alterar ou 
unjetar mensagens na rede e em seus sistemas intermediários (roteadores por 
exemplo). Tais ataques representam uma ameaça à privacidade e à integridade das 
informações quando elas trafegam pela rede. Essas mensagens podem ser reveladas 
a terceiros. 
Negação de serviço: ​ Esta é uma forma de ataque na qual o atacante interfere nas 
atividades dos usuários autorizados, fazendo inúmeras invocações sem sentido em 
serviços ou transmitindo mensagens incessantemente em uma rede para gerar uma 
sobrecarga dos recursos físicos (capacidade de processamento do servidor, largura de 
banda da rede, etc). Tais ataque normalmente são feitos com a intenção de retardar, 
ou impedir, as invocações válidas de outros usuários. 
 
Definição de canal seguro:​ Canal utilizado para comunicação entre dois processos 
com as seguintes características: 
Cada processo pode identificar com 100% de confiança a entidade responsável 
pela execução do outro processo; 
As mensagens que são transferidas de um processo a outro, são garantidas do 
pondo de vista da integridade e da privacidade; 
As mensagens tem garantia de não repetibilidade ou reenvio por ordem distinta 
(cada mensagem inclui um tempo físico ou lógico); 
 
Criptografia: ​Técnica de codificar o conteúdo de uma mensagem de forma a 
“esconder” o seu conteúdo. É necessário que ambos os processos possuam a chave 
de codificação / decodificação. 
Autencitação: ​Incluir na mensagem uma porção (encriptada) que contenha informação 
suficiente para identificar a entidade e verificar os seus direitos de acesso. 
 
 
 
 
 
CAPITULO 4 
 
As características da comunicação entre processos 
 
Comunicação síncrona e assíncrona: ​Uma fila é associada a cada destino de 
mensagem. Os processos remetentes fazem as mensagens serem adicionadas em 
filas remotas e os processos destino removem mensagens de suas filas locais. A 
comunicação entre os processos remetente e destino pode ser síncrona ou assíncrona. 
 
Comunicação síncrona: ​ Os processos remetente e destino são sincronizados 
a cada mensagem. Nesse caso, send e receive são operações que causam bloqueio. 
Quando um envio (send) é feito, o processo remetente (ou thread) é bloqueado até que 
a recepção (receive) correspondende seja realizada. Quando uma recepção é 
executada, o processo é bloqueado enquanto a mensagem não chegar. 
 
Comunicação assíncrona: ​O uso da operação send é não bloqueante, no 
sentido de que o processo remetente pode prosseguir assim que a msnsagem 
tenha sifo copiada para um buffer local, e a transmissão da mensagem ocorre 
em paralelo com o processo remetente. A operação receive pode ter variantes 
com e sem bloqueio.  
● Variante não bloqueante​: O processo destino prossegue sua execução 
após ter realizado a operação receive, a qual fornece um buffer para ser 
preenchido em background. Nesse caso, o processo deve receber 
separadamente uma notificação de que seu buffer possui dados a serem 
lidos, isso pode ser feito baseado em polling ou em interrupção. 
● Variante Bloqueante: ​a recepção bloqueante pode ser executada por 
uma thread, enquanto outras threads do processo permanecem ativas; e 
a simplicidade de sincronização das threads destinos com a mensagem 
recebida é uma vantagem significativa. 
 
Destinos de mensagem: ​Uma porta local é um destino de mensagem dentro de um 
computador, especificado como um valor inteiro. Uma porta tem exatamente um 
destino, mas pode ter varios remetentes. 
 
Para proporcionar transparência de localização​, podemos fazer uso das seguintes 
estratégias: 
● Os programas clientes se referem aos serviços pelo nome e usam um servidor 
de nomes ou de associação (binder), para transformar seus nome em 
localizações de servidor no momento da execução. Isso permite que os serviços 
sejam movidos enquanto o sistema está em execução. 
● O sistema operacional, fornece identificadores independentes da localização 
para os destinos de mensagem, mapeando­os em um endereço de nível mais 
baixo para elas serem entregues nas portas, o que possibilita a migração e a 
movimentação do serviço. 
 
Confiabilidade: ​ ​Um serviço ponto a ponto pode ser descrito como confiável​ se 
houver garantia que as mensagens forem entregues, independente de um número 
razoável de pacotes que possam ter sido eliminados ou perdidos. 
Em contraste, um serviço de mensagem é não confiavel ​se não houver 
garantia de que as mensagens sejam entregues. Quanto à integridade, as mensagens 
devem chegar não corrompidas e sem duplicação. 
 
Ordenamento: ​Algumas aplicações exigem que as mensagens sejam entregues na 
ordem de emissão ­ isto é, na ordem em que foram transmitidas pelo remetente. A 
entrega de mensagens fora de ordem é considerar uma falha por tais aplicações. 
 
 
Soquetes: ​As duas formas de comunicação (UDP e TCP) usam a abstração de 
soquete, um ponto de destino para a comunicação entre processos. A comunicação 
entre processos consiste em transmitir uma mensagem entre um soquete de um 
processo e um soquete de outro processo. 
 
Para que um processo receba mensagens, seu soquete deve estar vinculado a uma 
porta local e a um endereço IP do computador em que é executado. As mensagens 
enviadas a esse endereço IP e ao numero de porta, so podem ser recebidas por um 
processo cujo soquete esteja associado a esse IP e a esse número de porta. 
 
Um processo não pode compartilhar portas com outro processo no mesmo 
computador. Cada computador tem disponível 2​16​ ​números de portas disponíveis  
Os processos multicast IP são uma exceção, pois eles compartilham portas. Entretanto 
, qualquer número de processos pode enviar mensagens para a mesma porta. Cara 
soquete é associado a um protocolo em particular. 
 
 
Comunicação por datagrama UDP: ​Um datagrama enviado pelo protocolo UDP é 
transmitido de um processo remetente para um processo destino sem a existência de 
confirmações ou novas tentativas de envio. Se ocorrer uma falha, a mensagem poderá 
não chegar. Um datagrama é transmitido entre processos quando um deles efetua um 
send​ e o outro um ​receive​. 
 
Como é feita a troca de mensagem: 
Para enviar ou receber mensagens, um processo precisa primeiro criar uma 
associação entre um soquete com um endereço IP e com um aporta do ​host​ local. Um 
servidor associará seu soquete a uma porta de serviço ­ uma que ele torna conhecida 
dos clientes para que eles possam enviar mensagens a ela. Um cliente vincula seu 
soquere a qualquer porta local livre. O método ​receive​ retorna, além da mensagem, o 
endereço IP e a porta do remetente permitindo que o destinatário envia uma resposta a 
este. 
 
Problemas: 
● Tamanho da mensagem: ​o processo destino precisa especificar um vetor de 
bytes de um tamanho em particular para receber as mensagens. Se a 
mensagem for grande demais para esse vetor, ela será truncada na chegada. 
● Bloqueio: ​ Os soquetes fornecem operações ​send​ não bloqueantes e ​receive 
bloqueantes para cominicação por datagrama. A operação ​send 
retornaráquando tiver repassado a mensagem para as camadas UDP e IP, que 
são responsáveis por transmiti­la para seu destino. Se nenhum processo tiver 
um soquere associado à porta de destino, as mensagens seráo descartadas. 
(pag 130) 
● Timeouts: ​a recdepção bloqueante é conveniente para uso por um servidor que 
esteja esperando para receber requisições de seus clientes. Em algumas 
situações não é adequado que um processo espere undefinidamente para 
receber algo, nesse caso, considera­se um ​timeout​. 
● Recepção anonima: ​o método ​receive​ não especifica uma origem para as 
mensagens. A invocação ao método ​receive​ obtém uma mensagem endereçada 
para seu soquete, independente da origem. O método​receive ​retorna o 
endereço IP e a porta local do remetente, permitindo que o destinatário verifique 
de onde ela veio. 
 
Modelo de Falhas: ​O modelo de falhas pode ser usado em datagramas UDP, que 
sofrem das seguintes falhas: 
● Falhas por omissão: ​Ocasionalmente, mensagens podem ser descartadas 
devido a erros de soma de verificação ou porque não há espaço disponível no 
buffer, na origem ou no destino. 
● Falhas por ordenamento: ​ás vezes, as mensagens podem ser entregues em 
uma ordem diferente da que foram emitidas. 
Utilização do protocolo UDP: ​ Para algumas aplicações, é aceitável usar um serviço 
que esteja exposto a falhas por omissão ocasionais. Por exemplo o Domain Naming 
Service ­ DNS. As vezes, os datagramas UDP são uma escolha atraente, pois eles não  
sofrem sobrecargas necessárias a entrega de mensagens garantida. São elas: 
 
● a necessidade de armazenar informações de estado na origem e no destino; 
● a transmissão de mensagens extras; e  
● a latencia do remetente. 
 
Comunicação por fluxo TCP: ​As seguintes características da rede são ocultadas pela 
abstração de fluxo (stream): 
 
● Tamanho das mensagens:​ o aplicatico pode escolher o volume de dados que vai 
ser enviado ou recebido em um fluxo.A camada TCP decide o volume de dados a 
coletar, antes de transmiti­los efetivamente como um ou mais pacotes IP. 
● Mensagens perdidas: ​Se o remetente não receber uma confirmação dentro de um 
tempo limite, ele retransmite a mensagem. 
● Controle de fluxo:​ o protocolo TCP tenta combinar a velocidade dos processos que 
lêem e escrevem em um fluxo. Se o processo que escreve (envia) for rapido demais 
para o que lê, então ele será bloqueado até que o leitor tenha consumido dados 
suficientes. 
● Duplicação e ordenamento de mensagens: ​idenficadores de mensagem são 
associados a cada datagrama IP, o que permite ao destinatário detectar e rejeitar 
duplicatas ou reordenar as mensagens que chegam fora da ordem de emissão. 
● Destinos de mensagens: ​dois processos que estão em comunicação estabelecem 
uma conexão antes de poderem se comunicar. O estabelecimento de uma conexão 
envolve uma requisição de ​connect​, do cliente para o servidor, seguido de uma 
requisição de ​accept​, do servidor para o cliente, antes que qualquer comunicação 
possa ocorrer. Em um  modelo cliente­servidor, isso causa uma sobrecarga 
considerável para cada requisição­resposta. (pag 135). 
 
Cliente: ​Cria um objecto do tipo Socket que tenta estabelecer uma ligação com uma porta de 
um servidor, numa máquina remota. Para estabelecer esta ligação é necessário indicar o 
endereço IP e a porta da máquina remota. 
Servidor: ​Cria um objecto do tipo “listening” socket associado ao porto servidor. Este socket 
possui um método que fica bloqueado até que receba um pedido de ligação ao porto 
correspondente. Quando chega o pedido de ligação, o servidor aceita­a instanciando um 
novo socket que, tal como o socket do cliente, tem duas streams associadas, uma para saída 
outra para entrada de dados. 
 
 
Problemas importantes relacionados à comunicação por fluxo: 
 
● Correspondência de itens de dados: ​ doi processos que estejam se comunicando 
precisam concordar ao conteúdo dos dados transmitidos por um fluxo. Por exemplo, 
se um processo envia um valot int seguido de um valor double, o outro lado deverá ler 
um valor int seguido de um valor double. Quando dois processos não cooperam 
corretamente no uso de um fluxo, o processo leitor pode causar erros ao interpretar 
os dados, ou ser bloqueado devido a dados insuficientes no fluxo. 
● Bloqueio: ​os dados gravados em um fluxo são mantidos em uma fila no soquete de 
destino. Quando um processo tentar​ ler​ dados de um canal de entrada, obterá dados 
da fila ou será bloqueado até que dados se tornem disponíveis. O processo que 
escreve ​dados em um fluxo pode ser bloqueado pelo mecanismo de controle de fluxo 
TCP, caso o soquete no outro lado já esteja armazenando o volume máximo de dados 
permitido. 
● Threads: ​ quando um servidor aceita uma conexão, geralmente ele cria uma nova 
thread, para se comunicar com o novo cliente. 
○ Vantagem em se usar uma thread separada para cada cliente​ é que o 
servidor pode bloquear quando estiver esperando por dados, sem atrasar os 
outros cliente. 
 
Modelo de falhas: ​ Para satisfazer a ​propriedade da integridade​ da comunicação 
confiável, os fluxos TCP usam somas de verificação para detectar e rejeitar pacotes 
corrompidos, assim como números de sequência para detectar e rejeitar pacotes duplicados. 
Quando à ​propriedade da validade​, os fluxos TCP usam timeout e retransmissões para 
tratar com pacotes perdidos. Portanto há garantia de que as mensagens sejam entregues, 
mesmo quando alguns dos pacotes das camadas inferiores são perdidos. 
 
 
Representação externa de dados e empacotamento: 
 
● Representação externa de dados ​: Padrão aceito para representação de estruturas 
de dados e valores primitivos. 
● Empacotamento (​marshalling): é o procedimento de pegar um conjunto de itens de 
dados e monta­los em uma forma conveniente para transmissão em uma mensagem.  
● Desempacotamento (unmarshilling): ​ é o procedimento inverso de desmontá­los na 
chegada para produzir um conjunto de itens de dados equivalente no destino. 
 
Assim, o ​marshilling​ consiste na transformação de itens de dados estruturados e valores 
primitivos em uma representação externa de dados. Analogamente, o ​unmarshilling 
consiste na geração de valores primitivos a partir de sua representação externa de dados e 
na reconstrução das estruturas de dados. 
 
 
Comunicação cliente­servidor: ​Projetada para suportar as funções e trocas de mensagem 
em interações cliente­servidor típicas. 
 
Interações cliente­servidor (send receive para datagramas UDP) 
 
● as confirmações são redundantes, pois as requisições são seguidas pelas respostas; 
● o estabelecimento de uma conexão envolve mensagens extras, além do par exigido 
para a requisição e sua resposta; 
● o controle de fluxo é redundante para a maioria das invocações, que passam apenas 
pequenos argumentos e resultados. 
 
 
O protocolo requisição­resposta: ​Baseado em 3 primitivas de comunicação:  
 
● doOperation​:Usado pelos clientes para invocar operações remotas. Seus 
argumentos especificam o objeto remoto e o método a ser executado. Seu resultado é 
uma resposta RMI. 
● getRequest: ​Usado por um processo servidor para ler as requisições de 
serviço.Quando o servidor tiver executado o método no objeto especificado, usará 
sendReply​ para enviar a mensagem de resposta para o cliente. O cliente, ao receber 
a mensagem resposta, fará com que o método doOperation original seja 
desbloqueado e a execução do programa cliente continue. 
 
 
Modelo de falhas do protocolo pedido­resposta:  
 
Se as três operações são implementadas sobre UDP, então sofrem do mesmo tipo de falhas 
de comunicação que aquele protocolo: . 
­falhas de omissão​ .  
­Mensagens não são garantidamente entregues por ordem. 
 Além disso, podem ocorrer falhas no processo: ­ assumem­se “crash failures”, se o processo 
parar e permanece parado não produzindo valores arbitrários 
 
Timeouts: ​Para resolver o problema das mensagens perdidas, a doOperation permite definir 
um serviço de tempo, timeout. 
Após esgotar o timeout, a operação pode retornar com uma indicação de erro. 
Geralmente, em vez de retornar, reenvia a mensagem várias vezes para ter a certeza que o 
problema foi “o fim” do servidor e não mensagens perdidas. 
 
Perda da mensagem de resposta: ​Se a resposta se perdeu, o servidor ao receber novo 
pedido pode processar o método novamente (caso seja idempotente) e reenviar os 
resultados. 
 
Operações idempotentes: ​Têm o mesmo efeito se executadas uma ou mais vezes. 
Ex: Operação que adiciona um elemento a um conjunto.Contra­exemplo: adicionar um montante a uma conta bancária 
 
Em vez de reexecutar o método, pode reenviar a mensagem, desde que esta fique 
armazenada num ficheiro que irá conter o registo do histórico do servidor. 
Problema: consumo de memória; 
Solução: o servidor ser capaz de identificar que o registro pode ser apagado do 
histórico, i.é, quando a resposta tiver sido recebida. 
 
 
Semânticas perante falhas: 
 
● Maybe (talvez): ​ perante perdas, não é repetido o pedido de invocação (em geral não 
é aceitável). 
● At­least­once (pelo­menos­uma­vez) : ​perante perdas ou atrasos na resposta, são 
reenviados pedidos de execução que não são reconhecidos como duplicados pelo 
servidor (só deve ser usado em operações idempotentes). 
● At­most­once (no máximo­uma­vez) : ​Os possíveis reenvios de pedidos são 
reconhecidos como duplicados pelo servidor (é a semântica habitual dos sistemas de 
invocação remota) 
 
 
 
CAPITULO 5 
 
Middleware: ​É o sofwater que fornece um modelo de programação acima dos blocos de 
construção básicos de processos e de passagem de mensagens. Um aspecto importante do 
middleware é a transparência da localização e a independência dos detalhes dos protocolos 
de comunicação, sistemas operacionais e hardware de computador. Algumas formas de 
middleware permitem que componentes distintos sejam escritos em diferentes linguagens de 
programação. 
 
Transparência de localização: ​na RPC, o cliente que chama um procedimento não pode 
identificar se ele é executado no mesmo processo ou em um outro processo, possivelmente 
em um computador diferente. O cliente  também não precisa saber a localização do servidor. 
 
Protocolos de comunicação: ​os protocolos que suportam as abstrações de middleware são 
independentes dos protocolos de transporte subjacentes. Por exemplo, o protocolo 
requisição­resposta pode ser implementado sobre UDP ou sobre TCP. 
 
Hardware de computador: ​Usam­se padrões de representação externa de dados no 
marshilling e unmarshilling de mensagens. Eles ocultam as diferenças devido às arquiteturas 
de hardware, como a ordem dos bytes. 
 
Sistemas Operacionais: ​as abstrações de mais alto nível fornecidas pela camada de 
middleware são independentes dos SOs subjacentes. 
 
Uso de varias linguagens de programação: ​Isso é obtido pelo uso de uma ​linguagem de 
definição de interface​ (IDL) para definir interfaces. 
 
 
Interfaces: ​Forma de organizar um programa como um conjunto de módulos que podem se 
comunicar. Uma interface é definida para cada módulo. A interface de um módulo especifica 
os procedimentos e as variáveis que podem ser acessadas a partir de outros módulos. 
 
Interfaces em sistemas distribuídos: ​Apenas os métodos são acessíveis através de 
interfaces. 
 
Interface remota: ​Cada objeto remoto tem uma interface remota que especifica quais dos 
seus métodos podem ser invocados remotamente. 
 
Interface de serviço: ​no modelo cliente­servidor, cada servidor fornece um conjunto de 
procedimentos que estão disponíveis para uso pelos clientes. Por exemplo, um servidor de 
arquivos forneceria procedimentos para ler e gravar arquivos. O termo interface de serviço é 
usado para se referir à especificação dos procedimentos oferecidos por um servidor, 
definindo os tipos dos argumentos de entrada e saída de cada um dos procedimentos. 
 
 
 
O modelo de Objeto: 
 
● Referencias de objeto: ​As referências de objeto são valores de primeira classe, 
significando que eles podem, por exemplo, ser atribuídos a variáveis, passados como 
argumentos e retornados como resultados de métodos. 
● Interfaces: ​Uma interface também define os tipo que podem ser usados para declarar 
o tipo de variáveis, ou dos parâmetros, e valores de retorno dos métodos. Interfaces 
não tem construtores. 
● Ações:​ Em um programa OO, a ação é iniciada por um objeto invocando um método 
em outro objeto. Uma invocação pode incluir informações adicionais (argumentos) 
necessárias para executar o método. Uma ​ação ​é um encadeamento de invocações 
relacionadas de métodos, cada uma com seu respectivo retorno. A ativação de um 
método pode ter 3 efeitos:, 
 
1. o estado do receptor pode ser alterado; 
2. um novo objeto pode ser instanciado; por exemplo, pelo uso de um construtor 
em JAVA ou C++; 
3. outras invocações podem ocorrer nos métodos de outros objetos. 
 
● Exceções: ​As exceções proporcionam uma maneira de tratar com condições de erro, 
sem complicar o código. Além disso, cada cabeçalho de método lista, explicitamente, 
como exceções as condições de erro que pode encontrar, permitindo que os usuários 
desse método as tratem adequadamente. 
● Coleta de lixo: ​É necessário fornecer uma maneira de liberar o espaço em memória 
ocupado pelos objetos, quando eles não são mais necessários. Quando um objeto 
não está mais acessível, recupera o espaço em memória e o torna disponível para 
alocação por outros objetos. 
 
O modelo de Objetos distribuídos:  ​Cada processo contém um conjunto de objetos, alguns 
dos quais podem receber invocações locais e remotas, enquanto outros objetos podem 
receber somente invocações locais. 
 
Referencia de objeto remoto: ​outros objetos podem invocar os métodos de um objeto 
remoto, se tiverem acesso à sua referência de objeto remoto. 
As referências de objeto remoto são análogas às locais, pois: 
1. o objeto remoto que vai receber uma invocação a método remoto é especificado pelo 
incovador como uma referência de objeto remoto; e 
2. as referências de objeto remoto podem ser passadas como argumentos e resultados 
de invocações a  métodos remotos. 
 
Interface remota: ​todo objeto tem uma interface remota especificando qual de seus métodos 
pode ser invocado de forma remota. Objetos em outros processos só podem invocar 
métodos pertencentes à interface remota. 
 
Ações em um sistema de objeto distribuído: ​Assim como no caso não distribuído, uma 
ação é iniciada por uma invocação a método, a qual pode resultar em mais invocações a 
métodos em outros objetos. No caso distribuído, os objetos envolvidos em um encadeamento 
de invocações relacionadas podem estar localizados em diferentes processos ou em 
diferentes computadores. 
 
– requisição para executar alguma operação em um objeto remoto 
– obtenção de referências de objetos remotos 
– instanciação de objetos remotos (através de fábricas) 
 
 
 
Coleta de lixo em um sistema de objeto distribuído: ​A coleta de lixo distribuída 
geralmente é obtida pela cooperação entre o coletor de lixo local existente e um módulo 
adicionado que realiza uma forma de coleta de lixo distribuída, normalmente baseada em 
contagem de referência. 
 
– requer contagem de referências explícita 
– rastreamento de todas as referências trocadas 
– pouco eficiente ou difícil de ser implementada 
 
 
Exceções: ​A invocação a método remoto deve ser capaz de lançar exceções, como 
timeouts, causados pelo envio de mensagens, assim como aquelas ocorridas durante a 
execução do método invocado. 
 
­­ erros de aplicação: gerados pela lógica do servidor 
– erros de sistema: gerados pelo middleware 
– conduzidos de volta ao cliente sob a forma de 
mensagens 
 
Representação de Referências de Objetos: 
● Necessária quando objetos remotos são passados como parâmetro 
● A referência é serializada (não o objeto) 
● Contém toda informação necessária para identificar (e endereçar) um objeto 
unicamente no sistema distribuído. 
 
 
 
 
Semântica de invocação RMI: 
 
● Semântica de ​invocação talvez​: ​O método remoto pode ser executado uma vez ou 
não ser executado. A semântica ​talvez​ surge quando nenhuma das medidas de 
tolerância a falhas é aplicada. Tipos de falhas são: 
○ Falha por omissão, se a mensagem de invocação ou de resultado for perdida 
○ falhas por colapso, quando o servidor que contém o objeto remoto falha.Se a mensagem de resultado não tiver sido recebida após um dado tempo limite (timeout) e 
não houver novas tentativas, não haverá certeza se o método foi executado. Se a mensagem 
de invocação foi perdida, então o método não terá sido executado. Por outro lado, o método 
pode ter sido executado e a mensagem de resultado, perdida. Uma falha por colapso pode 
ocorrer antes ou depois do método ser executado.  
A semântica talvez é útil apenas para aplicações nas quais são aceitáveis invocações 
mal­sucedidas ocasionais. 
 
● Semântica de invocação ​pelo menos uma vez​: ​Com a semântica de invocação 
pelo menos uma vez​, o invocador recebe um resultado quando o método foi 
executado pelo menos uma vez, ou recebe uma exceção, informando que nenhum 
resultado foi obtido. Mascara as falhas por omissão e pode sofrer os seguintes tipos 
de falhas: 
○ falhas por colapso 
○ falhas arbitrarias (bizantinas), nos casos em que a mensagem de invocação é 
retransmitida, o objeto pode recebê­la e executar o método mais de uma vez 
possivelmente causando o armazenamento ou o retorno de valores errados. 
● Semântica de invocação ​no máximo uma vez​: ​com a semântica de invocação ​ no 
máximo uma vez,​ ou o ativador recebe um resultado quando o método foi executado 
exatamente uma vez, ou em caso contrário, uma exceção. 
 
 
Transparência:  ​Todas as etapas necessárias para empacotamento e trocas de mensagens 
são ocultadas do programador que faz uma chamada de procedimento remoto. 
 
 
Módulo de comunicação: ​O módulo de comunicação usa apenas os três primeiros 
elementos, os quais especificam o tipo de mensagem, sua requestId e a referência remota do 
objeto a ser invocado. O identificador de método, e todo o marshilling e unmarshilling, é de 
responsabilidade do software RMI.  
O módulo de comunicação no servidor seleciona o despachante para a classe do objeto a ser 
invocado, passando sua referência local, obtida a partir do módulo de referência remota 
através do identificador do objeto remoto dado pela mensagem de requisição. 
 
● Cuida do protocolo de comunicação de mensagens entre cliente e servidor 
● Implementa o protocolo requisição­e­resposta 
● Define os tipos de mensagens utilizados 
● Provê a identificação das requisições 
● Semântica de chamadas (ex.: at­most­once) 
● Retransmissão e eliminação de duplicatas 
 
Módulo de referências remotas: ​É responsável pela transformação entre referências de 
objeto local e remoto e pela criação de referências de objeto remoto. O módulo de referência 
remota de cada processo contém um tabela de objetos remotos para registrar a 
correspondência entre as referências de objeto local desse processo e as referências de 
objeto remoto. A tabela inclui: 
 
● Uma entrada para todos os objetos remotos mantidos pelo processo. 
● Uma entrada para cada proxy local. 
● Quando um objeto remoto precisa ser passado como argumento ou resultado pela 
primeira vez, o módulo de referência remota cria uma referência de objeto remoto, a 
qual adiciona em sua tabela. 
● Quando uma referência de objeto remoto chega em uma mensagem de requisição ou 
resposta, é solicitada ao módulo de referência remota de objeto local, a qual pode se 
referir a um proxy ou a um objeto remoto. No caso da referência de objeto remoto não 
estar na tabela, o RMI cria um novo proxy e pede ao módulo de referência remota 
para adiciona­lo na tabela. 
 
Serventes: ​Um servente é uma instância de uma classe que fornece o corpo de um objeto 
remoto. É o servente que trata as requisições remotas repassadas pelo esqueleto 
correspondente. Os serventes são partes integrantes do processo servidor. Eles são criados 
quando os objetos remotos são instanciados e permanecem em uso até não serem mais 
necessários, sendo finalmente excluídos. 
 
O software RMI: ​É uma camada de software  ­ middleware ­ entre os objetos do aplicativo e 
os módulos de comunicação e de referência remota. 
 
● Proxy:​ A função de um proxy é tornar a invocação a método remoto transparente 
para os clientes, comportando­se como um objeto local para o invocador; mas, em 
vez de executar uma invocação local, ele encaminha uma mensagem para um objeto 
remoto. Ele oculta os detalhes de referência de objeto remoto, do marshilling de 
requisições e do unmarshilling de respostas, e do envio e recepção de mensagens do 
cliente. 
 
● Despachante: ​ um servidor tem um despachante e um esqueleto para cada classe 
que representa um objeto remoto. O despachante e o proxy usam o mesmo methodId 
para os métodos da interface remota. 
Funcionamento: O servidor tem um despachante e um esqueleto pada a 
classe de um objeto remoto. O despachante recebe a mensagem de requisição do módulo de 
comunicação e utiliza o methodId para selecionar o método apropriado no esqueleto, 
repassando a mensagem de requisição. 
 
 
 
 
 
● Esqueleto: ​a classe de um objeto remoto tem um esqueleto, o qual implementa os 
métodos da interface remota, mas de uma forma diferente dos métodos 
implementados no servente que personifica o objeto remoto. ​Um método de 
esqueleto ​desempacota os argumentos na mensagem de requisição e invoca o 
resultado, junto com as exceções, em uma mensagem de resposta que é enviada 
para o método do proxy que fez a requisição. 
 
O vinculador (binder) : ​Um vinculador é um serviço separado que mantém uma tabela 
contendo mapeamentos dos nomes textuais para referências de objeto remoto. Ele é usado 
pelos servidores para registrar seus objetos remotos pelo nome e pelos clientes, para 
pesquisa­los. 
 
Proxy dinâmico:  
– genérico, independente de interface 
– utiliza uma definição de interface acessível dinamicamente para formatar as 
requisições 
 
● repositório de interfaces 
– útil quando não se conhece a interface em tempo de programação 
 
● Skeleton dinâmico 
– permite receber chamadas destinadas a “qualquer” tipo de objeto/interface 
– útil na construção de servidores “genéricos” 
 
 
Progamas clientes e servidores: ​ O programa ​servidor​ contem as classes para os 
despachantes e esqueletos, junto com as implementações das classes de todos os serventes 
que suporta. Contém uma sessão de inicialização que é responsável por criar e inicializar 
pelo menos um dos serventes que fazem parte do servidor. Mais serventes podem ser 
criados em resposta à requisições dos clientes. 
 
O programa cliente ​ conterá as classes dos proxies de todos os objetos remotos que 
ativará. Ele pode usar um vinculador para pesquisar referências de objeto remoto. 
 
Trheads no servidor: ​ Para evitar que a execução de uma invocação atrase a execução de 
outra, geralmente os servidores criam uma thread para cada invocação remota. 
 
Ativação de objetos: ​ consiste na criação de um objeto ativo a partir do objeto passivo 
correspondente, pela criação de uma nova instância de sua classe e pela inicialização de 
suas variáveis de instância a partir do estado armazenado. Os objetos passivos podem ser 
ativados por demanda; por exemplo, quando eles precisam ser invocados por outros objetos. 
 
 
Repositório de objetos persistentes: ​Um objeto que mantém seu estado entre invocações 
é chamado de objeto persistente. Geralmente os objetos persistentes,  são gerenciados por 
repositórios de objetos persistentes, que guardam seus estados em uma forma empacotada 
no disco. 
 
Coleta de lixo distribuída: ​O objetivo do coletor distribuído é garantir que, se uma referência 
local ou remota para um objeto ainda for mantida em algum lugar, em um conjunto de objetos 
distribuídos, então o próprio objeto continuará a existir; mas assim que não houver mais 
nenhuma referência para ele, esse objeto será coletado e a memória por ele utilizada será 
recuperada.(PAG 181) 
 
 
 
Chamada  de procedimento remoto: ​Uma chamada de procedimento remoto é muito 
parecida com uma invocação a método remoto, poisum processo cliente chama um 
procedimento que está sendo executado em um processo servidor.  
O software RPC não se preocupa com objetos e referências de objeto. O cliente que acessa 
um serviço inclui um procedimento stub para cada procedimento da interface de serviço. 
 
Stub: ​É semelhante ao proxy. Ele se comporta como um procedimento local para o cliente, 
mas em vez de executar a chamada, ele empacota o identificador de procedimento e os 
argumentos em uma mensagem de requisição e a envia para o servidor por meio de seu 
módulo de comunicação. Quando a mensagem chega ele desempacota os resultados. 
 
Interfaces:  
● Provêem acesso às características externamente visíveis de um objeto ou módulo 
– em geral: métodos e variáveis 
● Papel fundamental no encapsulamento 
● Em sistemas distribuídos: apenas os métodos são acessíveis através de interfaces 
● Passagem de parâmetros: copy­restore 
– parâmetros de entrada e saída 
– ponteiros não são permitidos 
– objetos como parâmetros: referência de objeto 
 
 
RMIregistry: ​ é o vinculador da RMI Java. Uma instancia de RMIresgistry deve ser 
executada em cada computador servidor que contenha objetos remotos. Ele mantém uma 
tabela mapeando nomes textuais no estilo URLs, em referência para objetos remotos 
contidos nesse computador.