CAPITULO 1
Principais Desafios em SD
● Heterogeneidade: A in ternet 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 ○ hardwar hardware e de comput computador ador ○ SOs ○ linguagens linguagens de programação programação ○ implementaçõe implementaçõess de diferen diferentes tes desenvolvedo desenvolvedores res ● 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 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 necessário desenhar desenhar o softwar software e de forma a que que o aumento de de utilizações 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. algu ns ● Tratam Tratament ento o de falhas 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çã Detecção o de falhas 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 mensagens podem podem ser ser retransm retransmitidas itidas quando não chegam; chegam; ■ dados de de arquivos arquivos podem podem ser gravados gravados em dois dois discos, discos, para para que, se 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 um navegador navegador não não consegue consegue contatar contatar um servidor servidor web, web, ele não 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 haver pelo pelo menos duas rotas rotas diferente diferentess entre entre dois roteadores quaisquer na Internet. ■ No Domain Domain Name System System,, toda tabela tabela de corres correspondênc pondência ia de nomes nomes é replicada em pelo menos dois servidores diferentes. ■ Um banco banco de dados dados pode ser replicado replicado em vários vários servidor servidores, es, para 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. ● Concor Concorrên rência cia:: os vários utilizadores utilizam o sistema em simultâneo (é necessário coordenar o acesso aos recursos partilhados) ● Transp Transparê arênci ncia: a: 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, elas compartilham 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.
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.
➔ Inexistência de um tempo global;
◆ 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 cliente també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, pois um 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.
