Sistemas Distribuídos Professor Luiz José Hoffmann filho

Slides:



Advertisements
Apresentações semelhantes
Sistemas Distribuídos
Advertisements

Sistemas Distribuídos Baseados em Objetos
Sistemas distribuídos Metas de Projeto Prof. Diovani Milhorim
Redes de computadores I
Redes de computadores I
Redes de computadores I
Bruno Rafael de Oliveira Rodrigues
Modelos de Comunicação em Sistemas Distribuídos
Comunicação Distribuída
MODELO DE REFERÊNCIA OSI
Interação Cliente Servidor
1 Comunicação Inter-Processos -> RMI -> RPC -> TCP -> UDP (Abstração de passagem de mensagem)
Modelo TCP/IP Versus Modelo OSI
ESTRUTURA DE COMUNICAÇÃO DE DADOS
Sistemas Distribuídos
Sistemas Distribuídos
Modelos de Referência.
Sistemas Distribuídos
REDES DE COMPUTADORES II
Middleware e Sistemas Distribuídos
Software de Rede Willamys Araújo.
Universidade do Vale do Rio dos Sinos - São Leopoldo -
Modelo de referência OSI
Sistemas Distribuídos
Tópicos em redes e sistemas distribuídos Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação.
Uma descrição detalhada da rede
Aula 2 Arquitetura & Protocolos
O Modelo OSI Guilherme Guimarães.
Sistemas Distribuídos
Concorrência e Java RMI
Gerenciamento de Redes Utilizando Agentes Móveis
Sistemas Distribuídos Carlos A. G. Ferraz DI/UFPE Aula 05.
Sistemas Distribuídos Introdução. Conceito Coleção de múltiplos processos que executam sobre uma coleção de processadores autônomos interligados em uma.
Comunicação entre Processos - Sockets. Conceitos Básicos Sockets são uma forma de IPC ( InterProcess Communication ) fornecida pela 4.3 BSD que fornecem.
Redes e Sistemas Distribuídos II – Cód
UNEMAT-FACIEX MODELOS DE REFERÊNCIA Dr. José Raúl Vento 2005.
Prof. Carlos Roberto da Silva Filho, M. Eng.
Java RMI João Gabriel (jggxm).
1 Comunicação Inter-Processos -> RMI -> RPC -> TCP -> UDP (Abstração de passagem de mensagem)
Redes de Computadores Prof Rafael Silva.
Comunicação.
MODELO DE REFERÊNCIA TCP/IP
Modelo OSI Apresentação Sessão Transporte Rede Enlace Física Aplicação
Disciplina de: Comunicação de Dados Professor: Carlos Pereira Trabalho Realizado por: João Santos.
Modelo OSI Disciplina: Comunicação de Dados Ricardo Bento 12ºL nº11.
Capítulo 4: Processos.
Sistemas Distribuídos Prof. Marcus Rodrigues
Administração e Projeto de Redes
Modelos de Comunicação em Sistemas Distribuídos
Modelos de Comunicação em Sistemas Distribuídos
Pontes Transparentes Luiz Peralta Prof. Ronaldo Alves Ferreira
TCP/IP.
Arquitetura TCP/IP Aplicação Transporte Rede Enlace Física.
Camada de Aplicação Prof. Horácio. Objetivo Apresentar os detalhes específicos dos tipos de aplicação; Apresentar o modelo cliente-servidor; Apresentar.
Sistemas Distribuídos Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação.
Trabalho elaborado por: -Daniel Nº26 -André Nº3. * A camada de rede do modelo OSI é responsável por controlar a operação da rede de um modo geral. As.
Sistemas Distribuídos
Passagens de Mensagens Prof. Dr. Norian Marranghello
Redes e Sistemas Distribuídos II – Cód Prof. MSc. Ronnison Reges Vidal.
Sistemas Distribuídos
Protocolos de Comunicação e Passagem de Mensagens
Arquitetura em Camadas
Redes de Computadores Prof. Msc. Moisés Pereira Bastos.
Redes de Computadores Protocolos de Transporte
Prof. Ivair Teixeira Redes de Computadores.
Redes de Computadores e Aplicações – Camada de Rede Protocolos de Roteamento IGOR ALVES.
SOCKET - É um canal de comunicação entre processos que estabelece uma conexão entre eles na forma de cliente-servidor. Por meio de sockets, os computadores.
Bruna Cavallero Martins Universidade Católica de Pelotas.
Curso Superior em Redes de Computadores Camada de Aplicação Prof. Sales Filho.
Redes de Computadores Técnico em Informática Prof. Alberto Felipe / Ester.
Transcrição da apresentação:

Sistemas Distribuídos Professor Luiz José Hoffmann filho

Comunicação-Protocolos, tipos, RPC Capitulo 4

Agenda Protocolos em camadas Pilhas de protocolos e Sistemas Distribuídos Tipos de comunicação (camada de Middleware) Persistência e sincronização Camanda de Procedimento Remoto (RPC) Operação Básica Passagem de Parâmetros Comunicação orientada a mensagem Comunicação transiente: MPI Comunicação persistente: Sistema de enfileiramento de Mensagens Comunicação Orientada a fluxo Tipos de fluxo Qualidade de Serviço

Comunicação entre Processos “Coração” de qualquer Sistema Distribuído Como processos em diferentess máquinas trocam informações? Não é uma tarefa trivial!! Desejável obter modelos onde a complexidade da comunicação seja transparente para o desenvolvedor.

Participantes são divididos em: – Servidores: implementam um serviço específico – Clientes: solicitam ao servidor um determinado serviço e espera pela resposta Comportamento requisição-resposta Modelo Cliente-Servidor

Protocolos em Camadas

Responsável pelo envio de bits Trata da padronização das interfaces elétrica, mecânica e de sinalização Protocolos são dependentes do meio de transmissão do link Camada Física

Responsável pelo envio de frames entre os links Característica importante: um datagrama pode ser manipulado por diferentes tipos de protocolos da camada de enlace: Ethernet (CSMA/CD), PPP Cada protocolo diferente pode ou não implementar um conjunto de serviços. Ex.: entrega confiável da informação Camada de Enlace

Redes de longa distância são constituídas de muitos nós com diferente caminhos entre eles. Como definir um caminho entre um par origem-destino? Roteamento é a principal tarefa da camada de rede Internet Protocol: protocolo sem conexão, onde pacotes são roteados de forma independente – best-effort service Camada de Redes

Responsável pela comunicação lógica entre diferentes processos sendo executados em diferentes hosts (fim-a-fim) Protocolos da camada de transporte não estão implementados nos roteadores Pode fornecer os seguintes serviços: – multiplexing/demultiplexing – transmissão confiável – garantias de banda, retardo Camada de Transporte

Transmission Control Protocol (TCP) – Orientado a Conexão – Confiável, porém “lento” Universal Datagram Protocol (UDP) – Sem conexão – “Rápido”, porém não confiável Escolha está ligada as caracteristicas da aplicação! Protocolos de Transporte na Internet

Distinção entre aplicação para redes e protocolos da camada de aplicação – Protocolo: pequena (talvez grande) peça de uma aplicação Ex.1: Aplicação WEB → HTTP Ex.2: Aplicação → SMTP Protocolos definem: tipos de mensagens trocadas, sintaxe Camada de Aplicação

Camada de software que é situada logicamente entre uma camada de nível mais alto, composta de usuários e aplicações e uma camada subjacente, que consiste de facilidades básicas de comunicação Inúmeros protocos para suportar serviços de middleware: – Autenticação: não estão vinculados a uma aplicação – Comprometimento – Comunicação: Serviços de comunicação de alto nível Camada de Middleware

Como os processos executando em diferentes máquinas trocam informação? – Em uma visão pilha de protocolos TCP/IP → Enviando mensagens através da utilização de sockets Socket: ponto final de uma comunicação full- duplex entre dois processos – Processo → casa / Socket → Porta – Socket: Porta entre o processo da aplicação e o protocolo de transporte (Sockets)

Informações são string de bytes, sem significado aparente Não existe a transparência de distribuição: toda a comunicacão está está explícita, através de procedimentos send e receive – Funções mais sofisticadas devem ser feitas na camada de aplicação Por que não oferecer comunicação de alto nível, indepedente da aplicação? (Sockets)

Solução!!!! Middleware de comunicação Tipos Chamadas de Procedimento Remoto Comunicação orientada a Mensagens Comunicação Orientada a Fluxo

Persistência – Persistente: Mensagem é armazenada pelo middleware de comunicação durante o tempo que for necessário para entregá-la ao receptor. – Transiente: Mensagem é armazenada somente durante o tempo em que a aplicação remetente e a aplicação receptora estiverem executando Tipos de Comunicação (Middleware)

Sincronização – Assíncrona: Remetente continua sua execução imediatamente após ter apresentado sua mensagem para transmissão – Síncrona: Remetente é bloqueado até saber que sua requisição foi aceita –Middleware avise que se encarregará da transmissão –Requisiçao ser entregue ao receptor –Ate o instante que o receptor retornar uma resposta Tipos de Comunicação (Middleware)

Granularidade – Discreta: Partes se comunicam por mensagens e cada mensagem forma uma unidade de informação completa – Fluxo: Várias mensagens,sendo que as mensagens estão relacionadas uma com as outras pela ordem ou pela relação temporal Tipos de Comunicação (Middleware)

Birrell and Nelson (1984) “Permite a processos chamar procedimentos localizados em outras máquinas” Desenvolvedor não precisa se preocupar mais com detalhes de implementação de rede (sockets nunca mais!) Conceitualmente simples, mas... Chamada de Procedimento Remoto

Arquiteturas de duas máquinas podem ser diferentes Espaço de endereçamento diversos Passagem de parâmetros RPC - Complicações

A idéia fundamental é fazer com que uma chamada de procedimento remoto pareça com uma chamada local Transparência RPC – Como funciona??

Transparência conseguida com o uso de stubs (apêndices) Stub do cliente responsável por empacotar os parâmetros em uma msg e enviar a msg para a máquina do servidor. Quando resposta chega, resultado é copiado para cliente, e controle volta a ele Stub do servidor responsável por desempacotar parâmetros, chamar o procedimento do servidor e retornar resposta para máquina do cliente RPC – Como Funciona??

Cliente Empacota Parâmetros Desempacota Resultado Chamada Retorno Servidor Desempacota Chamada Parâmetros Empacota Retorno Resultado Máquina Cliente Máquina Servidora Transporte de mensagens na rede Stub do Cliente SO Stub do Servidor SO RPC – Como Funciona?

RPC – Como Funciona??

Procedimento do cliente chama stub cliente de modo usual Stub do cliente constrói uma msg e chama o SO SO envia msg para SO remoto SO remoto repassa msg para stub do servidor Stub do servidor desempacota parâmetros e chama procedimento servidor Procedimento servidor executa e retorna o resultado Stub do servidor empacota resultado em uma msg e chama SO SO remoto envia msg para SO da máquina cliente SO do cliente passa msg para stub cliente Stub cliente desempacota resultado, repassando-o para o cliente Passos seguidos por um RPC

Função do stub do cliente é pegar seus parâmetros, empacotá-los em uma mensagem e enviá-los ao stub do servidor (montagem de parâmetros - parameter marshaling). Operação parece simples, mas: Arquiteturas diferentes? Passagem de ponteiros (diferente espaço de endereçamento)? RPC – Passagem de Parâmetros

RPC – Passagem de Parâmetros por valor

A chamada do procedimento remoto add somente funcionará se as máquinas do cliente e do servidor forem idênticas Problemas: – Representação diferentes para caracteres – Ordenação de bytes Solução: Cliente diz seu tipo. Conversão feita pelo servidor se tipos forem diferentes. RPC – Passagem de Parâmetros por valor

Problema: um ponteiro é significativo somente dentro do espaço de endereço do processo no qual está sendo usado read(fd,buf,nbytes) (executado no servidor de arquivos) fd → inteiro que indica um arquivo buf → endereço do vetor de caracteres nbytes → total de bytes a serem lidos RPC – Passagem de Parâmetros por referência

Mecanismo de passagem de parâmetro → copiar/restaurar – Variável é copiada na pilha do cliente (passagem de parâmetro por valor) – Variável é manipulada no servidor – Valor de retorno sobreescreve o valor original na pilha do cliente RPC – Passagem de parâmetro por referência

No caso do read, stub do cliente “sabe” que o segundo parâmetro aponta para um conjunto de caracteres Suponha que o cliente saiba o tamanho do vetor Solução: – Copiar o vetor para a mensagem e enviar ao servidor – Stub do servidor, chama o servidor com um ponteiro para este vetor – Modificação feita pelo servidor é armazenada diretamente no vetor que está no stub – Ao enviar o vetor de volta ao stub do cliente, o vetor é copiado de volta ao cliente RPC – Passagem de Parâmetros por referência

Interface consiste em um conjunto de procedimentos que podem ser chamados por um cliente e que são implementados por um servidor Utilização de interface simplifica consideravelmente aplicações cliente-servidor baseadas em RPCs Gerar completamente stubs de cliente e servidor - todos os sistemas de middleware baseados em RPC oferecem uma IDL para suportar desenvolvimento de aplicação RPC – Linguagem de programação de interface - IDL

Permite a um cliente o acesso a um serviço remoto por meio de uma simples chamada a um procedimento local Possibilita que programas clientes sejam escritos de modo simples Pode localizar automaticamente o servidor correto Estabelece a comunicação entre software cliente e software servidor RPC – Resumindo …

Comomecanismos de comunicação, RPC e RMI podem ser inadequados O que acontece caso não seja possível considerar que o receptor esteja sempre 'acordado'? Comportamento padrão <sincronismo,bloqueia> é muito restritivo Como contornar estas limitações: Mensagens Comunicação orientada a mensagem

Com multicomputadores de alto desempenho, desenvolvedores começaram a procurar primitivas orientadas a mensagem Objetivo: Escrever com facilidade aplicações de alta eficiência Necessidade de independência de hardware e de plataforma Interface de troca de mensagens (MPI)

Considerado como um padrão de troca de mensagens para escrever programas paralelos a serem executados em clusters Comunicação transiente → mensagem é armazenada no sistema enquanto remetente e receptor estiverem ativos Interface de troca de mensagens (MPI)

A comunicação ocorre dentro de um grupo conhecido de processos Cada grupo recebe um identificador Cada processo dentro de um grupo recebe um indentificador Par (groupID,processID) identifica fonte ou destinatário de uma mensagem Vários grupos de processos poderão estar envolvidos em um serviço de computação, podendo estar em execução ao mesmo tempo MPI – Como Funciona??

Mais de 100 funções diferentes para troca de mensagens: – MPI_recv → recebimento de mensagem; bloqueia o chamador até chegar uma mensagem – MPI_irecv → receptor pode verificar se a mensagem realmente chegou ou não – MPI_ALLtoall → distribui igualmente os dados entre todos os nós participantes da computação IBM, Intel, TMC, Meiko, Cray, Convex, Ncube MPI

Conhecidos como sistemas de enfileiramento de mensagens Suporte para comunicação assíncrona persistente Capacidade de armazenamento de médio prazo para as mensagens trocadas Idéia básica: Aplicações se comunicam retirando e colocando mensagens em filas específicas Mensagem será eventualmente entregue ao receptor Middleware orientado a mensagem (MOM)

Consulta que abranja vários bancos de dados pode ser repartida em subconsultas que são repassadas para bancos de dados individuais. Sistemas de enfileiramento de mensagens ajudam fornecendo meios básicos para empacotar cada subconsulta em uma mensagem e roteá-la até o banco de dados adequado. MOM - Exemplo

, fluxo de trabalho, groupware,processamento em lotes, integração de banco de dados e aplicações MOM – Outras Aplicações

1 – Aplicações se comunicam inserindo mensagens em filas específicas 2 – Mensagens são repassadas por uma série de servidores de comunicação 3 – Mensagens são entregues ao destinatário, mesmo que ele não esteja em funcionamento quando a mensagem foi enviada Remetente e Receptor podem executar em completa independência MOM – Como funciona?

MOM – Estados do Remetente e Receptor

Mensagens podem conter qualquer tipo de dado Mensagens devem ser adequadamente endereçadas O endereçamento é feito com o fornecimento de um nome exclusivo da fila destinatária no âmbito do sistema MOM – Características das Mensagens

Fila de Fonte Fila de Destino Gerenciadores de Fila Repassadores MOM – Arquitetura Geral

Fila de Fonte: Fila na qual o remetente envia a mensagem. Estas filas são filas locais do remetente Fila de Destino: Uma mensagem colocada em uma fila contém a especificação de uma fila de destino para a qual ela deve ser transferida MOM – Arquitetura Geral

MOM – Como encontrar uma fila dentro do sistema?

Gerenciadores de Fila: Um gerenciador de fila interage diretamente com a aplicação que está enviando ou recebendo uma mensagem Repassadores: Repassam mensagens que chegam para outros gerenciadores de fila. Sistema de enfileiramento de mensagens pode crescer até uma rede de sobreposição (overlay) completa de nível de aplicação MOM – Arquitetura Geral

Repassadores podem ajudar a construir sistemas escaláveis de gerenciamento de fila Atualizações de remoção e adição de filas devem ser feitas somente nos repassadores Gerenciadores de fila somente devem saber onde está o repassador mais próximo MOM - Repassadores

Sistemas de – Requisitos de filtragem automática de mensagens – Não precisam garantir entrega de mensagens, prioridades de mensagens, facilidades de registro, balanceamento de carga, tolerância a falha Sistemas de Enfileiramento de Mensagens versus

Sistemas de Enfileiramento de Mensagens – Fornece recursos mais amplos para tratamento de diversas aplicações diferentes – Possibilitam comunicação persistente entre processos – Manipular acesso a banco de dados – Realizar cálculos – Prioridades de mensagens Sistemas de Enfileiramento de Mensagens versus

Troca de unidades de informação mais ou menos completas e independentes Ex: Requisição para invocar um procedimento Quais são as facilidades que um sistema distribuído deve oferecer para trocar informaçõees dependentes de tempo (fluxos de áudio e vídeo)? TEMPO É CRUCIAL!!! Até o momento…

Fluxos Simples – Sequência simples de dados. – Ex: Voz Fluxos “Complexos” – Consiste em vários fluxos simples relacionados denominados subfluxos – Relação temporal entre os subfluxos – Ex: Transmissão de um filme: vídeo,som, legenda Comunicação Orientada a Fluxo – Tipos de Fluxos

Requisitos que descrevem o que é necessário para garantir que as relações temporais em um fluxo possam ser preservadas Está relacionada com: – Pontualidade – Volume – Confiabilidade Sistemas operacionais e redes não suportam QoS!!! → Serviço IP é best-effort Qualidade de Serviço (QoS)

Serviço Diferenciados Bufferização para reduzir variância de atraso no receptor Como Garantir QoS?(1)

Idéia Básica: Nós se organizam em uma rede de sobreposição que é usada para disseminar informações para seus membros Nós na rede de sobreposição podem cruzar vários enlaces físicos: roteamente pode não ser ótimo Construção do overlay – Árvore: único caminho entre cada par de nós – Malha: Cada nó terá vários vizinhos, em geral, existem vários caminhos entre cada par de nós Multicasting de Nível de Aplicação

No caso da estrutura em árvore, o problema é construir uma árvore eficiente! Multicasting de Nível de Aplicação (MNA)

Correção de Erro de Envio (Forward Error Correction - FEC) Como garantir QoS? (2)

Estresse de enlace: Quantas vezes uma mensagem atravessa o mesmo enlace? Exemplo: mensagem de A a D atravessa Ra,Rb duas vezes Penalidade de atraso relativo: Razão entre o atraso entre dois nós na sobreposição e o atraso que esses dois nós sofreriam na rede subjacente. Exemplo: mensagens de B a C possuem um atraso de 71 no overlay, mas de 47 no nível de rede, que gera uma penalidade de 1.51 Custo da árvore: parâmetro de medição global, relacionado com a minimização dos custos agregados de enlaces. Exemplo: atraso entre dois nós finais → spanning tree MNA – Qualidade da estrutura

Idéia Básica: propagar informações rapidamente entre um grande conjunto de nós usando somente informações locais. Não há nenhum componente central que coordena a disseminaçã o de informações. Atualizações para um item de dado específico são iniciadas em um único nó, evitando conflito de escrita. Disseminação de Dados – Algoritmos Epidêmicos

Três tipos de nós: – Infectado: se contiver dados que está disposto a espalhar para outros nós – Suscetível: nó que ainda não tenha visto esses dados – Removido: nó atualizado que não está disposto ou capacitado para propagar os dados. Modelos de Disseminação de Dados

Idéia Básica: Um nó P escolhe aleatoriamente um outro nó Q : Push: P envia suas próprias atualizações a Q Pull: P recebe novas atualizações de Q Push-Pull: P e Q enviam atualizações um ao outro, (abordagem enviar-receber) Antientropia

Idéia Básica: Se um nó P acabou de ser atualizado com o item de dado x, ele contata um nó arbitrário Q e tenta enviar a atualização a Q. Contudo, é possível que Q já tenha sido atualizado por um outro nó. Nesse caso, P pode perder o interesse em levar adiante a propagação da atualização, com probabilidade 1/k Problema: Nós poderão não receber atualizações! Gossiping