comunicaÇÃo. assuntos protocolos modelos de comunicaÇÃo rpc midleware orientado a mensagem(mom)...
TRANSCRIPT
COMUNICAÇÃO
ASSUNTOS
• PROTOCOLOS• MODELOS DE COMUNICAÇÃO• Rpc• Midleware orientado a
mensagem(MOM)• Fluxo de dados
PROTOCOLOS
• Comunicação em SD é baseada em envio e recepção de mensagem de baixo nível.
A B1. MONTAR MENSAGEM2. CHAMADA
AO SO PARA ENVIO
ENVIA MESAGEM
A E B TEM QUE CONCORDAR COM OS BITS
ACORDOS...
• Quantos volts para sinalizar um bit?• Como o receptor sabe que é o último bit da
mensagem?• Como detectar se uma mensagem foi
danificada ou perdida? E o que fazer se isso aconteceu?
• Qual o comprimento de cadeias, números e itens de dados e como serão representados?
• São necessários acordos em uma variedade de níveis desde a transmissão de bits até a formatação da informação.
• ISO (International Organization for Standardization) desenvolveu o modelo de referência – vários níveis envolvidos – com nomes padronizados e funções de cada nível.
• OSI: Modelo de referência para interconexão de sistemas abertos.
MODELO OSI• Um sistema aberto está preparado para se comunicar com
outro sistema aberto usando regras padronizadas. As formalizações das regras são chamadas de protocolos.
• Dois tipos:– Protocolo orientado à conexão
• A e B estabelecem a conexão e negociam o protocolo que usarão. Liberam a conexão após concluir.
– Protocolo sem conexão • O remetente transmite a mensagem quando estiver
pronto
• Divide-se o problema em porções gerenciáveis e resolvidas de forma independente.
• Cada camada serve de interface para camada acima dela (conjunto de operações).
MÁQUINA A
MÁQUINAB
CONSTRÓI A MENSAGEM
ENVIA PARA A CAMADA DE APLICAÇÃO (ANEXA CABEÇALHO)
ENVIA PARA A CAMADA DE APRESENTAÇÃO (ANEXA CABEÇALHO)
ENVIA PARA A CAMADA FÍSICA (ANEXA CABEÇALHO)
...
Cada camada lida com um aspecto específico de comunicação do processo
Cada camada lida com um aspecto específico de comunicação do processo
MÁQUINA A
MÁQUINA B
CONSTRÓI A MENSAGEM
ENVIA PARA A CAMADA DE APLICAÇÃO (ANEXA CABEÇALHO)
ENVIA PARA A CAMADA DE APRESENTAÇÃO (ANEXA CABEÇALHO) ENVIA PARA A CAMADA FÍSICA (USA
CABEÇA CABEÇALHO)...
ENVIA PARA A CAMADA DE ENLACE (USA CABEÇALHO)
...
• Cada protocolo pode ser alterado de acordo com as condições de tecnologia, independente dos outros.
• Ao conjunto de protocolos chamamos suíte de protocolo ou pilha de protocolos.
CAMADA FÍSICA
• Função - Cuidar da transmissão de bits:• Quantos volts usar para 0 e 1;• Quantos bits por segundo podem ser
enviados;• Se a transmissão pode ocorrer em ambas as
direções simultaneamente.• O tamanho e a forma do conector de rede,
número de pinos e significado de cada um.
CAMADA DE ENLACE
• Permite detectar e corrigir erros de transmissão.• Agrupa os bits em unidades (quadros) e providencia
para que cada quadro seja corretamente recebido.• Método: 1) Colocar um padrão de bits no início e final de cada quadro para marca-lo.2) Executar uma soma de verificação que vai acompanhar o quadro. A soma é conferida na recepção do quadro, e caso erro é solicitada nova recepção.
CAMADA DE REDE• Encarrega-se do roteamento dos dados, isto é enviá-
los para o destino certo a nível da sua organização em pacotes. O que esta camada faz é "routear" e reencaminhar os dados.
• A camada de rede deve tornar transparente para a camada de transporte a forma como os recursos dos níveis inferiores são utilizados para implementar conexões de rede.
• Deve também equacionar e uniformizar as diferenças entre as diversas sub-redes utilizadas de forma a fornecer um serviço único aos seus utilizadores (independentemente da rede utilizada).
CAMADA DE REDE
• Protocolo mais utilizado é o Internet Protocol (IP).
• Pacote IP pode ser enviado sem nenhuma preparação antecipada. Cada pacote é roteado ao seu destinatário independente de todos os outros.
IP estático e IP dinâmico
• IP estático (ou fixo) é um endereço IP dado permanentemente a um dispositivo, ou seja, seu número não muda, exceto se tal ação for executada manualmente.
• IP dinâmico é um endereço que é dado a um computador quando este se conecta à rede, mas que muda toda vez que há conexão.
• O método mais utilizado na distribuição de IPs dinâmicos é o protocolo DHCP (Dynamic Host Configuration Protocol).
CAMADA DE TRANSPORTE
• Garantir que os seguimentos tenham seu recebimento confirmado.
• Retransmitir seguimentos não confirmados• Colocar os segmentos na ordem correta.• Ao receber mensagem da camada de aplicação, a
camada de transporte desmembra em porções pequenas, suficientes para transmissão, designa um numero para cada uma e então envia todas elas.
TCP/IP
• O Protocolo de Transporte da Internet é o Protocolo de controle de Transmissão.
• A sigla TCP/IP fazer referência a dois protocolos - Transmission Control Protocol e Internet Protocol mas é um conjunto que conta ainda com vários outros padrões, cada um sendo responsável por uma determinada tarefa.
Protocolo UDP• Protocolo Universal de Datagramas• Protocolo sem conexão• Programas que não precisam de protocolo orientado
a conexão• Exemplo: O Remote Procedure Call é um protocolo
que permite a um host utilizar uma função localizada em um host remoto. O RPC permite a troca de mensagens, onde a origem envia parâmetros a um servidor e fica esperando um retorno, que fornecerá o resultado da função remota.
CAMADA DA SESSÃO
• Serviços da camada de SESSÃO: • 1-> Admnistração de sessão: Une duas entidades
para um relacionamento e mais tarde as desune. (ex. de união: login/autenticação e desunião: logoff).
• 2-> Diálogo da sessão: Controla troca de dados,delimita e sincroniza operações em dados entre duas entidades. Ex. pode-se abrir uma conexão de sessão para trocar informações em half, full-duplex,etc...
CAMADA DE APRESENTAÇÃO
• Se preocupa com o significado dos bits do remetente ao receptor.
• Mensagens: informações estruturadas.• Exemplo: nomes, endereços, quantidades de
dinheiro.
CAMADA DE APLICAÇÃO
• Função original: conter um conjunto de aplicações padronizadas de rede, como de correio eletrônico, transferência de arquivos e emulação de terminal.
• Hoje: repositório para todas as aplicações e protocolos que não se ajustam as camadas inferiores.
• Protocolos FTP HTTP
PROTOCOLOS DE MIDDLEWARE
• Middleware é uma aplicação que reside logicamente na camada de aplicação, com muito protocolos de uso geral (protocolos de comunicação de alto nivel e protocolos para estabelecer vários serviços de middleware.
• Protocolos de autenticação, protocolos de autorização, protocolos de comprometimento (Todos os processos executam ou de jeito nenhum).
PROTOCOLOS DE MIDDLEWARE
• Protocolo distribuído de bloqueio : recurso protegido contra acesso de processos simultâneos.
• Protocolos de comunicação e sincronização
Tipos de Comunicação
• Comunicação persistente – exemplo correio – o cerne do correio=serviço de comunicação de middleware.
• Remetente continua em execução após apresentar mensagem
• Aplicação receptora precisa estar em execução no momento do envio.
Tipos de Comunicação
• Comunicação transiente: a mensagem é armazenada pelo sistema de comunicação, somente durante o tempo em que a aplicação remetente e a receptora estiverem executando.
• Comunicação assíncrona: o remetente continua sua execução imediatamente após ter apresentado sua mensagem para transmissão.
Tipos de Comunicação
• Comunicação síncrona: O remetente é bloqueado até saber se sua requisição for aceita.
Pontos em que pode ocorre sincronização: 1) Remetente bloqueado até que o middleware avise
que se encarregará da transmissão da requisição. 2) Remetente pode sincronizar até que a requisição
seja entregue ao receptor. 3) A sincronização ocorre até o receptor retornar uma
resposta.
Tipos de Comunicação
TIPOS DE COMUNICAÇÃO
• Comunicação discreta: As partes comunicam por mensagem e cada mensagem forma uma unidade de informação completa.
• Comunicação por fluxos: Mensagens são enviadas, uma atrás da outra, relacionadas umas com as outras em ordem.
CHAMADA DE PROCEDIMENTO REMOTO (RPC)
Definição
Permite que um programa procedural chame uma função que reside em outro computador tão convenientemente como se esta função fosse parte do mesmo programa que executa, no mesmo computador.
Chamada de procedimento Remoto
Chamada de procedimento Remoto
Chamada de procedimento Remoto
DefiniçãoRPC foi desenvolvida para permitir aos programadores se concentrar nas tarefas exigidas de um programa chamando funções e, tornando transparente ao programador o mecanismo que permite que as partes do aplicativo se comuniquem através de uma rede.
Chamada de procedimento Remoto
História:
A ideia de RPC data de 1976. Um dos primeiros usos comerciais da tecnologia foi feita pela Xerox no "Courier", de 1981. A primeira implementação popular para Unix foi o Sun RPC (atualmente chamado ONC RPC), usado como base do Network File System e que ainda é usada em diversas plataformas.
Chamada de procedimento Remoto
História:
Outra implementação pioneira em Unix foi o Network Computing System (NCS) da Apollo Computer, que posteriormente foi usada como fundação do DCE/RPC no Distributed Computing Environment (DCE).
Uma década depois a Microsoft adotou o DCE/RPC como base para a sua própria implementação de RPC, MSRPC, a DCOM foi implementada com base nesse sistema. Ainda no mesmo período da década de 1990, o ILU da Xerox PARC e o CORBA ofereciam outro paradigma de RPC baseado em objetos distribuídos, com mecanismos de herança.
Chamada de procedimento Remoto
História:
De forma análoga, atualmente utiliza-se XML como linguagem de descrição de interface e HTTP como protocolo de rede para formar serviços web, cujas implementações incluem SOAP(Simple Object Access Protocol) e XML-RPC.
Chamada de procedimento Remoto• Características:
· a definição de um procedimento remoto especifica parâmetros de entrada e de saída. Parâmetros de entrada são passados para o servidor enviando os valores dos argumentos na mensagem (request message). Parâmetros de saída são retornados para o cliente na mensagem de resposta (reply message).
· Um procedimento remoto é executado em um ambiente diferente do seu chamador e não pode acessar variáveis do ambiente do chamador, como variáveis globais por exemplo.
Chamada de procedimento remoto
Problemas● Arquiteturas de duas máquinas podem
ser diferentes.● Espaço de endereçamento diversos● Passagem de parâmetros
Chamada de procedimento remoto
Chamada de Procedimento Remoto - RPC
A idéia fundamental é fazer com que uma chamada de procedimento remoto pareça com
uma chamada local
Transparência
Chamada de Procedimento Remoto - Modelo
Similar ao modelo de chamadas locais de procedimentos●Rotina que invoca o procedimento coloca os argumentos em uma área de memória bem conhecida e transfere o controle para o procedimento em execução, que lê os argumentos e os processa.●Em algum momento, a rotina retoma o controle, extraindo o resultado da execução de uma área bem conhecida da memória. Após isso, a rotina prossegue com a execução normal.
● Thread é responsável pelo controle de dois processos: invocador e servidor. O processo invocador primeiro manda uma mensagem para o processo servidor e aguarda (bloqueia) uma mensagem de resposta.● A mensagem de invocação contém os parâmetros do procedimento e a mensagem de resposta contém o resultado da execução do procedimento. Uma vez que a mensagem de resposta é recebida, os resultados da execução do procedimento são coletados e a execução do invocador prossegue.
Chamada de procedimento remoto - Modelo
Do lado do servidor, um processo permanece em espera até a chegada de uma mensagem de invocação. Quando uma mensagem de invocação é recebida, o servidor extrai os parâmetros, processa-os e produz os resultados, que são enviados na mensagem de resposta. O servidor, então, volta a esperar por uma nova mensagem de invocação.
Chamada de procedimento remoto - Modelo
Chamada de procedimento remoto - Modelo
Uma chamada remota de procedimento difere das chamadas locais em alguns pontos:●Tratamento de erros: falhas do servidor ou da rede devem ser tratadas.●Variáveis globais e efeitos colaterais: Uma vez que o servidor não possui acesso ao espaço de endereços do cliente, argumentos protegidos não podem ser passados como variáveis globais ou retornados.
Chamada de procedimento remoto - Modelo
Desempenho: chamadas remotas geralmente operam a velocidades inferiores em uma ou mais ordens de grandeza em relação às chamadas locais.
Autenticação: uma vez que chamadas remotas de procedimento podem ser transportadas em redes sem segurança, autenticação pode ser necessário.
Chamada de procedimento remoto - Modelo
Operação Básica de RPC
Chamada de procedimento convencional
count = read (fd, buf, nbytes)
fd → descritor de um arquivo
buf → vetor para o qual os caracteres serão lidos
nbytes → quantos bytes serão lidos
Operação Básica de RPC
Chamada de procedimento convencional
– Em C, parâmetros podem ser chamados por valor ou chamados por referênciaEm RPCs
– A diferença entre chamadas por valor e por referência é importante.
–Outro mecanismo de passagem de parâmetros é o copiar/restaurar: “chamador” copia a variável para a pilha e ao copiá-la de volta, sobreescreve o valor original → semelhante a chamada por referência
Operação Básica de RPC Consideremos a chamada da função read–Em um sistema tradicional, a função read é um tipo de interface entre o código de usuário e o sistema operacional local Usando RPC, é possível conseguir transparência na execução da função read–Por ser um procedimento remoto, uma versão diferente da função read, denominada apêndice de cliente é colocada na biblioteca–Ela não pede por dados ao SO local. Empacota os parâmetros em uma mensagem e a envia ao servidor
Operação Básica de RPC
Usando RPC, é possível conseguir transparência na execução da função read–Apêndice de cliente chama receive, bloqueando até que a resposta volte.–Quando a mensagem chega ao servidor, o SO do servidor a passa para um apêndice do servidor–O apêndice de servidor desempacota os parâmetros da mensagem e chama o procedimento do servidor da maneira usual
Operação Básica de RPC
Usando RPC, é possível conseguir transparência na execução da função read–Do ponto de vista do servidor, é como se ele fosse chamado diretamente pelo cliente–No caso de read o servidor colocará os dados no buffer, interno ao apêndice de servidor–Ao final, empacota o buffer em uma mensagem e retorna o resultado ao cliente
–Ao chegar no cliente, o SO reconhece que a msg está direcionada ao processo cliente–Msg é copiada para o buffer e o processo cliente é desbloqueado
Operação Básica de RPC
Operação Básica de RPC
Operação Básica de RPC
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
Operação Básica de RPC
Cliente
Chamada EmpacotaParâmetros
DesempacotaResultadoRetorno
DesempacotaParâmetros
Servidor
EmpacotaResultado
Chamada
Retorno
Máquina Cliente Máquina Servidora
Stub do ServidorStub do Cliente
Transporte de mensagens
na rede
SO SO
Passos seguidos por um RPC1.Procedimento do cliente chama stub cliente de modo usual2.Stub do cliente constrói uma msg e chama o SO3.SO envia msg para SO remoto4.SO remoto repassa msg para stub do servidor5.Stub do servidor desempacota parâmetros e chama procedimento servidor6.Procedimento servidor executa e retorna o resultado7.Stub do servidor empacota resultado em uma msg e chama SO8.SO remoto envia msg para SO da máquina cliente9.SO do cliente passa msg para stub cliente10.Stub cliente desempacota resultado, repassando-o para o cliente
Passagem de Parâmetros
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)?
Passagem de Parâmetros por valor
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
Passagem de parâmetros por valor
Passagem de parâmetros por valor
Solução: Cliente diz seu tipo. Conversão feita pelo servidor se tipos forem diferentes.
Passagem de parâmetros por referência
Como são passados ponteiros ou, em geral, referências?Um ponteiro somente é significativo dentro do espaço de endereço do processo no qual está sendo usado!
Passagem de parâmetros por referência
Consideremos a função 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/restaurar:–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
Linguagem de Definição de Interface - IDL
Interface consiste em um conjunto de procedimentos que podem ser chamados por um cliente e que são implementados por um servidorUtilização de interface simplifica consideravelmente aplicações cliente-servidor baseadas em RPCsGerar completamente stubs de cliente e servidor - todos os sistemas de middleware baseados em RPC oferecem uma IDL para suportar desenvolvimento de aplicação
• Java IDL é uma tecnologia para objetos distribuídos, ou seja, objetos em diferentes plataformas interagindo através de uma rede.
• O Java IDL é similar ao RMI (Remote Method Invocation), que suporta objetos distribuídos que sejam escritos totalmente em Java.
• Vantagem do Java IDL é que ele permite que objetos se interajam independentemente de terem sido escritos em Java ou em alguma outra linguagem como C, C++, Cobol, etc. (baseado no CORBA - Common Object Request Brokerage Architecture)
Suporte a interação entre objetos em programas separados: ORB (Object Request Broker)Biblioteca de classes Java que permite a comunicação de baixo-nível entre aplicações Java IDL e outras aplicações que suportam CORBA.Entre os ORBs, a comunicação ocorre através de um protocolo compartilhado, o IIOP - Internet Inter-Orb Protocol, o qual é baseado no protocolo TCP/IP, e define como os ORBs do CORBA transferem informações.
• O cliente (aplicativo ou applet) chama a operação Hello do HelloServer• O ORB transfere a chamada para o objeto registrado com a interface IDL • O método sayHello do servidor é executado, retornando uma string Java • O ORB transmite essa string para o cliente • O cliente imprime os valores da string
A Interface IDL Hello.idl module HelloApp // declaração do módulo{ interface Hello // declaração da interface { string sayHello(); // declaração das operações };}; Utilizando o compilador idltojava neste código, serão gerados os seguintes arquivos: HelloImplBase.javaHelloStub.java Hello.javaHelper.javaHelloHolder.java
HelloClient.java import HelloApp.*; // o pacote contendo nossas basesimport org.omg.CosNaming.*; // serviço de nomesimport org.omg.CORBA.*; // toda aplicação CORBA precisa desta classe public class HelloClient { public static void main(String args[]) { try{ // Criando e inicializando o ORB ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; Hello helloRef = HelloHelper.narrow(ncRef.resolve(path)); // chama o objeto servidor e mostra os resultados String Hello = helloRef.sayHello(); System.out.println(Hello); } catch (Exception e) { System.out.println("ERROR : " + e) ; e.printStackTrace(System.out); }}}
HelloServer.java // o pacote que contém nossas basesimport HelloApp.*; // serviço de nomes que será usado pelo servidorimport org.omg.CosNaming.*;// o pacote contendo as exceções especiais lançadas pelo serviço de nomesimport org.omg.CosNaming.NamingContextPackage.*;// todas as aplicações CORBA precisam desta classeimport org.omg.CORBA.*; class HelloServant extends _HelloImplBase { public String sayHello() {// retornando a string "Hello World" quando o método for chamado return "\nHello world !!\n"; }} public class HelloServer { public static void main(String args[]) { try{ // criando e inicializando o ORB ORB orb = ORB.init(args, null); // criando o servidor e o registrando com o ORB HelloServant helloRef = new HelloServant(); orb.connect(helloRef); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); // ligando a referência ao objeto no serviço de nomes NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; ncRef.rebind(path, helloRef); // aguardar requisições feitas pelo cliente java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait(); } } catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out); } }}
Possíveis falhas em RPCs
O cliente não consegue localizar o servidorA mensagem de requisição do cliente para o servidor é perdidaA mensagem de resposta do servidor para o cliente é perdidaO servidor falha depois de receber uma requisiçãoO cliente falha depois de fazer uma requisição
Possíveis falhas em RPCsO cliente não consegue localizar o servidor
Causas:•Servidor Desligado•Versão desatualizada da interface
Soluções:•Retornar o código indicando erro•Ativar exceção: destruir a transparência
Possíveis falhas em RPCs
A mensagem de requisição do cliente para o servidor é perdida
–Soluções• Kernel do cliente inicializa um timer assim que a mensagem é enviada• Se o timer expirar antes da resposta, o cliente re-envia a mensagem
Possíveis falhas em RPCsA mensagem de resposta do servidor para o cliente é perdida
RPC Assíncrona
Chamadas de procedimentos convencionais → cliente bloqueia até que uma resposta seja retornada
RPCs podem implementar facilidades pelas quais um cliente continua imediatamente após emitir a requisição RPC → RPCs assíncronas
RPC Assíncrona