COMUNICAÇÃO

ASSUNTOS PROTOCOLOS MODELOS DE COMUNICAÇÃO Rpc Midleware orientado a mensagem(MOM) Fluxo de dados

A E B TEM QUE CONCORDAR COM OS BITS PROTOCOLOS Comunicação em SD é baseada em envio e recepção de mensagem de baixo nível. A E B TEM QUE CONCORDAR COM OS BITS A ENVIA MESAGEM B 1. MONTAR MENSAGEM 2. CHAMADA AO SO PARA ENVIO

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

Cada camada lida com um aspecto específico de comunicação do processo MÁQUINA A 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). CONSTRÓI A MENSAGEM ENVIA PARA A CAMADA DE APLICAÇÃO (ANEXA CABEÇALHO) ENVIA PARA A CAMADA DE APRESENTAÇÃO (ANEXA CABEÇALHO) ... MÁQUINAB ENVIA PARA A CAMADA FÍSICA (ANEXA CABEÇALHO)

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 ENLACE (USA CABEÇALHO) ENVIA PARA A CAMADA DE APRESENTAÇÃO (ANEXA CABEÇALHO) ENVIA PARA A CAMADA FÍSICA (USA CABEÇA 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.

PDU – PROTOCOL DATA UNIT

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

CAMADAS

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.

Tipos de Comunicação 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: Remetente bloqueado até que o middleware avise que se encarregará da transmissão da requisição. Remetente pode sincronizar até que a requisição seja entregue ao receptor. A sincronização ocorre até o receptor retornar uma resposta.

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ção RPC 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

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 - 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.

Chamada de procedimento remoto - Modelo 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.

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ência Em 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

Operação Básica de RPC 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 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

Transporte de mensagens Operação Básica de RPC Máquina Cliente Máquina Servidora Desempacota Parâmetros Chamada Chamada Empacota Parâmetros Cliente Servidor Desempacota Resultado Empacota Resultado Retorno Retorno Stub do Cliente Stub do Servidor SO SO Transporte de mensagens na rede

Passos seguidos por um RPC 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

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 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

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.java HelloStub.java Hello.java Helper.java HelloHolder.java

HelloClient.java   import HelloApp.*;             // o pacote contendo nossas bases import org.omg.CosNaming.*;        // serviço de nomes import 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 bases import HelloApp.*; // serviço de nomes que será usado pelo servidor import org.omg.CosNaming.*; // o pacote contendo as exceções especiais lançadas pelo serviço de nomes import org.omg.CosNaming.NamingContextPackage.*; // todas as aplicações CORBA precisam desta classe import 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 servidor A mensagem de requisição do cliente para o servidor é perdida A mensagem de resposta do servidor para o cliente é perdida O servidor falha depois de receber uma requisição O cliente falha depois de fazer uma requisição

Possíveis falhas em RPCs O 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 RPCs A 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