Sistemas distribuídos:comunicação



Documentos relacionados
3. Comunicação em Sistemas Distribuídos


Sistemas Distribuídos Grupos

SISTEMAS DISTRIBUÍDOS

Comunicação. Parte II

Comunicação entre Processos

Sistemas Distribuídos

Tópicos em Sistemas Distribuídos. Modelos de Comunicação

Arquitetura de Computadores II

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

UNIVERSIDADE. Sistemas Distribuídos

Grupos de Processos (Comunicação Grupal)

Comunicação em Sistemas Distribuídos. Conceitos: Paradigma C/S. Conceitos: Paradigma C/S. Paradigma Cliente/Servidor

SISTEMAS DISTRIBUÍDOS

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo

Arquitetura de Sistemas Operativos

3 SCS: Sistema de Componentes de Software

Introdução ao Modelos de Duas Camadas Cliente Servidor

Sistemas Distribuídos RPC x RMI. Edeyson Andrade Gomes

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO

SUMÁRIO 1. AULA 6 ENDEREÇAMENTO IP:... 2

Padrões Arquiteturais. Sistemas Distribuídos: Broker

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2)

Comunicação Inter-Processos. Prof. Adriano Fiorese. Conceitos Iniciais

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos

Programação de Sistemas

Programação de Sistemas

Nomes e Endereçamento. Nomes e Endereçamento. Paradigmas em Sistemas Distribuídos. Paradigmas em Sistemas Distribuídos

MODELO CLIENTE SERVIDOR

Adriano Reine Bueno Rafael Barros Silva

Sistemas Distribuídos. Aleardo Manacero Jr.

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet:

Sistemas Distribuídos

TOPOLOGIAS. Em redes de computadores modernos a transmissão de dados não ocorre através de bits contínuos.

Arquitetura de Rede de Computadores

Um Driver NDIS Para Interceptação de Datagramas IP

SISTEMAS DISTRIBUÍDOS

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Processos e Threads (partes I e II)

Sistemas Operacionais

SISTEMAS OPERACIONAIS

Engenharia de Software III

Sistemas Distribuídos RPC

ESTUDO DE CASO WINDOWS VISTA

Organização de Computadores 1

Sistemas Distribuídos

Sistemas Operacionais

Profs. Deja e Andrei

Paradigma Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor

Sistemas Distribuídos: Conceitos e Projeto Introdução a Criptografia e Criptografia Simétrica

Sistemas Distribuídos Modelo Cliente-Servidor

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido

Características Carlos Ferraz

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V

Chamadas Remotas de Procedimentos (RPC) O Conceito de Procedimentos. RPC: Programa Distribuído. RPC: Modelo de Execução

REDES DE COMPUTADORES

Sistemas Distribuídos

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4

Sistemas Distribuídos

Interconexão de redes locais. Repetidores. Pontes (Bridges) Hubs. Pontes (Bridges) Pontes (Bridges) Existência de diferentes padrões de rede

Protocolo TCP/IP. Neste caso cada computador da rede precisa de, pelo menos, dois parâmetros configurados:

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Arquitetura TCP/IP. Parte IV Mapeamento de endereços IP em endereços físicos (ARP) Fabrízzio Alphonsus A. M. N. Soares

TCEnet e TCELogin Manual Técnico

Introdução Ligação direta Ligação direta Default

Curso: Redes II (Heterogênea e Convergente) Tema da Aula: Características Roteamento

MC714 - Sistemas Distribuídos. Leandro Villas

SMTP, POP, IMAP, DHCP e SNMP. Professor Leonardo Larback

Projetos. Universidade Federal do Espírito Santo - UFES. Mestrado em Informática 2004/1. O Projeto. 1. Introdução. 2.

4 Estrutura do Sistema Operacional Kernel

On Scalability of Software-Defined Networking

SISTEMAS DISTRIBUIDOS

Sistemas Operacionais

Comunicação em Sistemas Distribuídos

Distributed Systems Principles and Paradigms

Redes Locais. Prof. Luiz Carlos B. Caixeta Ferreira

Sistemas Operacionais Distribuídos e de Redes

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Funções específicas de cada camada do modelo OSI da ISO.

Camadas de Serviço de Hardware e Software em Sistemas Distribuídos. Introdução. Um Serviço Provido por Múltiplos Servidores

Entendendo como funciona o NAT

ADDRESS RESOLUTION PROTOCOL. Thiago de Almeida Correia

Sistemas Cliente-Servidor

Comunicação entre processos (grupos) COMUNICAÇÃO ENTRE PROCESSOS Comunicação de grupo. Comunicação entre processos (grupos)

Redes. Pablo Rodriguez de Almeida Gross

Sistemas Operacionais. Prof. André Y. Kusumoto


SISTEMAS DISTRIBUÍDOS

Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo

Orientação a Objetos

Na Figura a seguir apresento um exemplo de uma "mini-tabela" de roteamento:

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013

A máscara de sub-rede pode ser usada para dividir uma rede existente em "sub-redes". Isso pode ser feito para:

TRANSMISSÃO DE DADOS Prof. Ricardo Rodrigues Barcelar

Transcrição:

M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010

Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor. Cliente-: cliente controla totalmente o. Comunicação em grupo.

Formas de qualidade de serviço Garantia de entrega. Banda de transmissão. Latência. Segurança.

Questões relacioanadas aos serviços de comunicação Primitivas disponíveis. Garantia de QoS. Protocolo: alguns sistemas incorporam seus próprios protocolos de. O problema é que esses sistemas não são usuais Abertura de implementação. Procedimentos para aumentar a eficiência.

Comunicação entre processos Sistemas Operacionais fornecem mecanismos para comunicação entre processos (IPC), tal como filas de, semáfaros e memória compartilhada. Sistemas de computação distribuída utilizam estes mecanismos para fornecer uma interface de programação da aplicação (API) que permita a comunicação entre processos ser programada em alto nível de abstração. Computação distribuída requer troca de informação entre processos independentes. A comunicação entre processos pode ser por meio de troca de, utilizando a arquitetura cliente- ou através de Remote Procedure Call ou por comunicação em grupo.

Comunicação entre processos A comunicação é o coração de qualquer Sistema Distribuido Deve-se saber como processos em diferentes máquinas trocam informações? A tarefa de troca de é uma tarefa nada trivial. É desejável obter modelos onde a complexidade da comunicação seja transparente para o desenvolvedor.

Comunicação entre processos Em computação distribuída, dois ou mais processos envolvidos em IPC através de um protocolo que ambos concordam. Um processo pode ser o enviante em alguns pontos durante o protocolo um recebedor durante outros. Quando a comunicacao é de um processo para outro o IPC é chamado de unicast. Quando a comunicação é de um processo para um grupo de processos, o IPC é chamado de multicast.

As são objetos de dados cuja estrutura e aplicação são definidas pelas próprias aplicações que a usarão. Sendo a troca de feita através de primitivas explicitas de comunicação. As primitivas de comunicação podem ser classificadas do seguinte modo: forma de comunicação (direta ou indireta) ou forma de sincronização(síncrono ou bloqueante e assíncrona ou não bloqueante) Receive Connect Send Disconnect

Formas de comunicação Direta: há indicação do processo, receptor ou emissor Indireta: o envio é feito para uma porta ou mailbox sem o conhecimento de qual será o receptor, ou no caso de receive a mensagem é obtida guardada no mailbox, possivelmente desconhecendo a identidade do processo emissor.

Sincronização de Evento Comunicação entre processos requer que 2 processos sincronizem suas operações: um lado envia e o outro recebe até que todos os dados tenha sido enviados e recebidos. Ideal, a operação send inicia antes da operação receive começar. Na prática, a sincronização requer suporte do sistema.

Comunicação Síncrona X Assíncrona As operações IPC podem fornecer a sincronização necessária usando bloqueamento. Uma operação bloqueante emitida por um processo irá bloquear o processamento do processo até a operação ser completada. Alternativamente, operações IPC podem ser assíncronas ou não bloqueantes. Uma operação assíncrona emitida por um processo não irá bloquear o processamento do processo. Ao contrário, o processo está livre para proceder seu processamento e pode opcionalmente ser notificado pelo sistema quando a operação é completada.

Comunicação entre processos A construção básica em comunicação entre processos é a passagem de. Esta abstração permite um processo transmitir uma mensagem para outro. A principal desvantagem dessa abordagem é o baixo nível de abstração que permite apenasa modelagem de troca indireta de informações entre processos.

Definição Implica um processamento cooperativo de requisições submetidas por um cliente para o que as processa e retorna os resultados para o cliente. Neste modelo o processamento da aplicação é dividido entre o cliente e o. O processamento é iniciado e parcialmente controlado pelo cliente e tanto cliente quanto cooperam para executar com sucesso uma aplicação.

No modelo cliente é possível a existência de vários es, onde os mesmos podem ser replicados, isto é, quando há várias instâncias do mesmo. A replicação muitas vezes ocorre por questões de desempenho, distribuição natural dos recursos ou por tolerância a falhas. Também é possível termos es hierárquicos, isto é, es que usam o(s) serviço(s) de outros es. Nestes casos, as localizações e conversões entre es deverá ser transparentes aos clientes.

- Endereçamento Para que um cliente envie para o, o clietne deve necessariamente conhecer o endereço do e isso é realizado estabelecendo-se um esquema de identificação. O esquema de identificação pode ser de quatro tipos: um identificador único de processo quando na mesma máquina endereçamento indicando o processo e a máquina processos escolhem endereços que são detectados por broadcast uso de de nomes.

- Endereçamento um processo por máquina Um identificador único de processo quando na mesma máquina: nesse tipo de endereçamento temos um processo por máquina, para que se enderece esse processo basta indicar o endereço da máquinha pois o kernel consegue determinar qual é o processo único Esse tipo de abordagem não é viável, pos dificilmente teremos um único processo em uma máquina.

- Endereçamento indicando o processo e a máquina Quando se permite mais de um processo por máquina, deve-se endereçar a mensagem a esse específico. Um esquema comum é o uso de um nome composto por duas partes. Ex: 12,4 ou, sendo que 12 é a máquina e quatro é o processo. O kernel da máquina cliente usa o número 12 para enviar ao máquina correspondente e com o número 4 e o Kernel remoto determina para qual a mensagem é endereçada.

- Endereçamento indicando o processo e a máquina Nessa abordagem a identificação é incluída no código do cliente. Com isso evita-se o custo de coordenação global e evita-se ambiguidades entre processos com identificador idênticos mas em máquinas distintas. Porém, perde-se em transparência pois é preciso que o cliente conheça a localização física do. Isso pode causar problemas, como por exemplo: se um de banco de dados normalmente executa na maquina 12, no momento em que a mesma for desligada para manutenção, pode-se disponibilizar o mesmo serviço em outra máquina. Ao usar este esquema com maquinas fixas, o serviço poderá estar disponível em outra máquina, mas não poderá ser usado.

- Processos escolhem endereços que são detectados por broadcast Cada processo deve receber um endereço único que não envolva o número da sua máquina. Este endereço pode ser atribuído de duas formas: através de um escalonador de endereços de processo centralizado, que mantém um contador e ao receber uma requisição incrementa esse contador e envia o valor. cada processo escolhe um valor aleatoriamente a partir de um espaço de endereçamento grande (ex. 64 bits) e portanto com pouca probabilidade de colisão.

- Processos escolhem endereços que são detectados por broadcast O kernel emissor de uma requisição pode localizar para qual máquina enviar através do seguinte procedimento: 1 o emissor envia a mensagem para todas as maquinas (broadcast) com um pacote especial de localização contendo o endereço do processo destino; 2 em cada maquina da rede o kernel verifica se o processo está na máquina. Quem localizar envia mensagem indicando seu endereço na rede; 3 o kernel emissor guarda essas informações para requisições futuras. Vantagem e desvantagem Essa abordagem tem como vantagem ser transparente mas tem um custo da mensagem broadcast.

- Processos escolhem endereços que são detectados por broadcast O uso de de nomes: neste esquema os es são indicados por um identificador de alto nível (nome ASCII) que não inclui nem identificação da maquina nem do processo. Quando um cliente executa uma requisição a um pela primeira vez, uma mensagem especial é enviada para um de mapeamento ou de nomes solicitando o número da máquina onde está o.

Remote Procedure Call é uma tecnologia popular para a implementação do modelo cliente- de computação distribuída. Uma chamada de procedimento remoto é iniciada pelo cliente enviando uma mensagem para um remoto para executar um procedimento específico. Uma resposta é retornada ao cliente. Uma diferença importante entre chamadas de procedimento remotas e chamadas de procedimento locais é que, no primeiro caso, a chamada pode falhar por problemas da rede. Nesse caso, não há nem mesmo garantia de que o procedimento foi invocado.

Apesar de simples este paradigma tem alguns problemas nos seguintes pontos: o processo chamador e o chamado executam em espaço de endereçamento diferentes; como fazer a passagem de parâmetros e resultados quando a arquitetura das máquinas envolvidas são distintas? existe uma grande possibilidade de falhas.

- Algumas definições Stub são partes (fragmentos) de algoritmos que provêm a abstração de uma chamada (local) de procedimento (método) fazendo a ligação deste com o mecanismo de comunicação. O stub é parte do código que faz a chamada remota, é utilizado no cliente e no. Na Virtual Machine remota, cada objeto deve ter um skeleton correspondente ao stub. O skeleton é responsável por enviar a chamada ao objeto remoto.

- Operação básica A chamada de procedimento remoto deve parecer o máximo com o máximo possível com chamada local de procedimentos. Por isso, utiliza-se a estrutura de cliente/ stubs. A segue os seguintes passos: 1 O procedimento chama o stub cliente de forma normal, isto é, como se fosse um procedimento local qualquer; 2 O stub cliente constrói e passa ao kernel; 3 O kernel remoto envia a mensagem ao stub ; 4 O kernel remoto entrega a mensagem ao stub ; 5 O stub desempacota os parâmetros e chama o ; 6 O realiza o trabalho solicitante e envia o resultado ao stub ; 7 O stub empacota o resultado em uma mensagem e passa para o kernel; 8 O kernel remoto envia mensagem ao kernel cliente; 9 O kernel cliente entrega a mensagem ao stub cliente; 10 O stub desempacota o resultado e retorna ao stub cliente.

- Funcionamento O efeito da execução de todos esses passos é a conversão da chamada local de um cliente a um stub cliente em uma chamada ao procedimento sem que o cliente ou percebam os passos intermediários. Via de regra os stubs são gerados automaticamente por um compilador.

Comunicação em grupo Um transmissor para múltiplos receptores Grupos de processo: um conjunto de processos que interagem entre si A comunicação é um-pra-muitos (quando uma mensagem é enviada todos os membros recebem estta mensagem) Os grupos são entidades dinâmicas e pode-se ter processos que fazem parte de vários grupos

Implementação de comunicação em grupo A maneira como a comunicação é implementada depende de forma direta do hardware e da rede de comunicação A comunicação em grupo pode ser: Multicast: criação de um endereço especial de rede onde múltiplas máquinas podem escutar este endereço Broadcast: pacotes com um determinado endereço são escutados pelo grupo Unicast: o transmissor envia um pacote separado para cada um dos receptores

Organização do grupo Pode-se ter uma classificação com relação as : grupo aberto e grupo fechado E uma com relação a natureza dos processos que constituem o grupo: grupo semelhante e grupo hierárquico Grupo fechado: somente membros do grupo podem enviar para o grupo Grupo aberto: qualquer processo pode enviar para o grupo A decisão de se utilizar um grupo fechado ou um grupo aberto depende da aplicação. Por exemplo uma aplicação típica de processamento paralelo, não interessa a intervenção de não membros. Porém se tivermos um grupo formado por es replicados, um não membro pode fazer uma requisição (cliente).

Organização do grupo E uma com relação a natureza dos processos que constituem o grupo: grupo semelhante e grupo hierárquico Grupo semelhante: processos semelhantes, não existe a hierarquia, ou seja, nenhum processo é gerente, as decisões são tomadas de forma colaborativa Grupo hierárquico: um processo coordena e o restante obedece ao coordenador. O coordenador decede quem é o melhor para executar determinada aplicação.

Organização do grupo - Vantagens e desvantgens dos Grupos semelhantes A principal VANTAGEM é não se ter um ponto único de falha. Se tivermos um processo que falhou, o grupo somente diminui de tamanho mas não para. Já como DESVANTAGEM tem-se a demora da tomada das decisões, já que essas são tomadas colaborativamente, o que gera uma demora no kernel e um overhead.

Organização do grupo - Vantagens e desvantgens dos Grupos hierárquicos A principal VANTAGEM é não ter demora na toma de decisão. Já como DESVANTAGEM a falha do coordenador significa a parada do grupo.

Gerenciamento na comunicação em grupo É preciso ter um controle dos processos que entram, dos processo que saem, da criação e da destruição dos mesmos. Uma maneira é ter o de grupo para o qual todas as requisições são feitas. Esse detem o controle total de todos os membros do seu grupo e quais participante a qual grupo. O grande problema é a centralização do serviço.

Gerenciamento na comunicação em grupo Por outro lado pode-se fazer um gerenciamento distribuído.

Gerenciamento na comunicação em grupo Outro ponto importante com relação ao controle é como os processos membro de um grupo devem se comportar quando um determinado processo falha. Pode não haver um aviso e os processos pertencentes ao grupo só irão verificar que aquele participante não é mais membro do grupo quando solicitarem algo e ele não responder. Outra questão do controle é a SINCRONIZAÇÃO, deve haver um sincronismo entre as e a entrada ou saída do processo do grupo. E como ultima preocupação com relação ao controle tem-se a maneira como os processos irão se comportar quando muitas máquinas pararem de forma anormal, deve haver um protocolo para reconstruir o grupo com as máquinas que restaram.

Endereçamento na comunicação em grupo Endereçamento único. Multicast Broadcast Unicast Lista de possíveis destinos. Endereço com predicado.

Propriedades na comunicação em grupo Atomicidade: uma mensagem enviada deve ser recebida por todos do grupo. Ordenação das : diferentes, enviadas por processos diferentes devem ser recebidas por todos processos de um grupo. Sobreposição de grupo: um processo pode ser membro de diversos grupos ao mesmo tempo. Escalabilidade: muitos protocolos só funcionam bem quando os grupos são pequenos ou em uma única LAN.