Sistemas Distribuídos

Ciência da Computação

Robson Costa
([Link]@[Link])
 Sumário

1)Fundamentos de Sistemas Distribuídos

2)Comunicação entre Processos
3)Sincronização em Sistemas Distribuídos
4)Transações e Concorrências
5)Objetos Distribuídos e Chamadas Remotas
6)Arquitetura Orientada a Serviços
7)Desenvolvimento de Aplicações Distribuídas
 Fundamentos de
Sistemas Distribuídos

Histórico
●
1945 ~ 1985:
●
Máquinas grandes e caras que operavam de forma isolada (stand-alone)
por falta de uma forma confiável de interligá-las;
●
1985 ~ :
●
Desenvolvimento dos microprocessadores + invenção das redes locais
(LAN – Local Area Networks) → Sistemas Distribuídos;

●
Problemática:
●
SOFTWARE;
 Fundamentos de
Sistemas Distribuídos
 Fundamentos de
Sistemas Distribuídos

Conceitos Básicos
●
Um Sistema Distribuído é o resultado da integração de sistemas
computacionais autônomos combinados de forma a atingir um objetivo
comum;
●
Interligados através de redes de comunicação, os computadores se
comunicam e coordenam suas ações por meio de mensagens;
●
Uma coleção de computadores independentes que parecem para os
usuários como um único computador [Coulouris2001];
●
Sistemas formados por nós independentes que não compartilham memória
nem relógio;
●
Hardware: 2 ou + computadores;
●
Controle: mecanismos de controle para administrar os recursos e
coordenar as atividades;
 Fundamentos de
Sistemas Distribuídos

Vantagens dos SD x SC

Característica Descrição

Os microprocessadores oferecem uma melhor relação

Economia
preço/desempenho do que os mainframes.
Pode ter um poder de processamento maior do que qualquer
Velocidade
mainframe.
SD se adaptam melhor a aplicações que enfatizam a
Distribuição
separação física dos componente.
Se uma máquina falhar, o sistema como um todo pode
Confiabilidade
sobreviver.
O poder computacional pode ser expandido gradualmente,
Escalabilidade
conforme a necessidade.
SD enfatiza o compartilhamento de recursos.
Compartilhamento

A comunicação entre usuários é simplificada (ex.: correio

Comunicação
eletrônico).
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Várias questões também encontradas em qualquer sistema são
exacerbadas em SDs;
●
Heterogeneidade;
●
Openness;
●
Escalabilidade;
●
Tolerância a Falhas;
●
Controle de Concorrência;
●
Segurança;
●
Transparência de Distribuição;
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Heterogeneidade:
●
de hardware;
●
de software (sistemas operacionais e linguagens);
●
de tipos de redes;
●
Estas questões podem ser ocultadas do programador através do uso de
middlewares (ex.: CORBA – Common Object Request Broker Architecture);
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Openness (conformidade a sistemas abertos):
●
Suas interfaces são públicas e padronizadas;
●
Permite que o sistema seja compreendido e reimplementado de várias
formas;
●
Conformidade a interfaces nesses sistemas precisa ser
cuidadosamente testada;
●
Podem ser construídos a partir de hardware heterogêneo;
●
Exemplo:
●
RFCs Internet ([Link])
●
Especificações CORBA ([Link])
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Escalabilidade:
●
Um sistema é escalável se ele permanece efetivo mesmo quando há um
aumento no número de recursos e usuários;
●
Um sistema e seu software não deveriam mudar quando a sua escala
(seu “tamanho”) cresce;
●
Entretanto, esta é uma característica difícil de ser alcançada;
Conceito Exemplo
Componentes
Um único servidor de e-mail para todos os usuários.
Centralizados
Tabelas Centralizadas Uma única lista telefônica online.
Algoritmos Fazer o controle de acesso ao meio com base em um ponto
Centralizados único de decisão.
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Escalabilidade:
●
Um sistema é escalável se atende satisfatoriamente uma das duas
dimensões identificadas por [Neuman94]:
●
Um sistema é escalável com respeito ao seu tamanho significando que
se pode adicionar mais recursos ou usuários ao sistema.
●
Um sistema é dito geograficamente escalável se usuários e recursos
podem estar dispostos geograficamente distantes um dos outros.
●
Infelizmente um sistema que é escalável em pelo menos uma destas
dimensões pode perder desempenho;
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Escalabilidade:
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Tolerância a Falhas:
●
Prevenir para que falhas não afetem outros componentes do sistema;
●
Confiabilidade:
●
Replicar funções;
●
Retransmissão de mensagens;
●
Problemática 1:
●
+ cópias, + disponibilidade;
●
+ inconsistência dos dados, = torna-se difícil manter o estado global;
●
Problemática 2:
●
Queda do desempenho
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Segurança:
●
Essa questão é problemática em sistemas distribuídos devido à facilidade
de compartilhamento de recursos;
●
Exemplo: dados médios e bancários na Internet,
●
Segurança costuma ser subdividida em 3 partes:
●
Confidencialidade
●
Proteção contra acesso não autorizado;
●
Integridade
●
Proteção contra alteração não autorizada;
●
Disponibilidade
●
Proteção contra interferência no acesso ao recurso;
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Segurança:
●
É usual, encontrar entre as propriedades de segurança mais 2
características:
●
Autenticidade
●
Garante que os usuários e suas informações são autênticas segundo
as políticas do sistema;
●
Não-Repúdio
●
Impede que usuários neguem a sua participação em operações;
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Controle de Concorrência:
●
Característica intrínseca: compartilhamento de recursos
●
Recurso pode ser hardware, software, abstração de um sistema
operacional, etc…;
●
Acesso simultâneo pode provocar inconsistências no sistema;
●
Soluções de sincronização baseadas em memória compartilhada muitas
vezes não podem ser utilizadas (ex.: semáforos);
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Transparência de Distribuição:
●
Ocultar do usuário e programador da aplicação a separação de
componentes em um sistema distribuído, de forma que o sistema seja
percebido como um todo, em vez de uma coleção de componentes;
●
ANSA (Advanced Networked Systems Architecture) e RM-ODP
(Reference Model of Open Distributed Processing) reconhecem 8 tipos de
transparências:
●
de acesso;
●
de localização;
●
de concorrência;
●
de replicação;
●
de falhas;
●
de migração (mobilidade);
●
de desempenho;
●
de escalabilidade;
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Transparência de Acesso:
●
Oculta diferenças de representação de dados e de como um recurso é
acessado;
●
Transparência de Localização:
●
Permitir que os recursos sejam acessados sem o conhecimento de suas
localizações;
●
Transparência de Concorrência:
●
Oculta que um recurso pode ser compartilhado por várias entidades
concorrentes. O compartilhamento de recursos deve ocorrer sem
interferência entre eles;
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Transparência de Replicação:
●
Permite que múltiplas réplicas de recursos sejam utilizadas para
aumentar o desempenho e a confiabilidade sem o conhecimento de suas
demais réplicas;
●
Transparência de Falhas:
●
Oculta a falha e a recuperação de um recurso; usuários e programas de
aplicações devem completar suas ações apesar de falhas de hardware ou
de componentes de software;
●
Transparência de Migração (Mobilidade):
●
Oculta a movimentação de recursos para diferentes localizações, sem
afetar a operação de usuários ou programas;
 Fundamentos de
Sistemas Distribuídos

Características Principais
●
Transparência de Desempenho:
●
Oculta a inclusão de novos recursos computacionais inseridos no sistema
com o objetivo de suprir uma nova demanda;
●
Transparência de Escalabilidade:
●
Permite que o sistema e aplicações expandam em escala sem alterar a
estrutura do sistema ou dos algoritmos da aplicação;
●
Alguns autores consideram as transparências de acesso e localização
como as mais importantes, resultando na transparência de rede;
●
Em algumas áreas de aplicação, transparências são difíceis de se
conseguir ou até mesmo indesejáveis;
●
ex.: sistemas de hard real-time;
 Fundamentos de
Sistemas Distribuídos

Aplicações típicas de Sistemas Distribuídos

●
Sistemas distribuídos estão por toda a parte:
●
Redes corporativas;
●
Redes de automação fabril;
●
Redes de sistemas embarcados em veículos;

●
Sistemas na Internet:
●
MMOG (Massively Multiplayer Online Games);
●
Home banking;
●
Trabalho cooperativo (CSCW – Computer Supported Cooperative Work);
●
Sistemas de controle e monitoramento:
●
Sistemas embarcados utilizados para o monitoramento de residências,
empresas, plantações, florestas, etc;
 Fundamentos de
Sistemas Distribuídos

Aplicações típicas de Sistemas Distribuídos

●
A convergência de tecnologias de Computação, Comunicação e Entretenimento
tem trazido uma série de oportunidades para o desenvolvimento de sistemas
distribuídos;
●
Ex.: Smart-TV Computação

Entretenimento Comunicação
 Fundamentos de
Sistemas Distribuídos

Aspectos de projeto e arquitetura

●
Objetivos chave
●
Desempenho, confiabilidade, escalabilidade, consistência, segurança;
●
Questões básicas de projeto:
●
Nomeação:
●
Projetar esquemas de nomes de significado global para identificar recursos
e objetos que devem ser suportados por um sistema de interpretação de
nomes;
●
Comunicação:
●
Otimizar a implementação da comunicação (desempenho e confiabilidade)
conservando um modelo de programação de alto nível para seus usuários;
●
Estrutura de Software:
●
Estruturar o sistema para que novos serviços possam ser introduzidos
(sistemas abertos);
 Fundamentos de
Sistemas Distribuídos

Aspectos de projeto e arquitetura

●
Alocação de carga de trabalho:
●
Como aprimorar o processamento, a comunicação e a alocação de
recursos para obter um melhor desempenho (balanceamento de carga);
●
Manutenção da consistência:
●
Manter a consistência a um custo razoável e sem causar um grande
impacto ao desempenho do sistema é talvez o problema mais difícil
encontrado no projeto de sistemas distribuídos (atualizações, réplicas,
relógios e falhas);
 Fundamentos de
Sistemas Distribuídos

Aspectos de projeto e arquitetura

Sistemas Centralizados Sistemas Distribuídos

Aplicações Aplicações

Sup. da Ling. de Prog. Suporte para

Serviços
Programação
Sistema Operacional Abertos
Distribuída
Hardware
Serviços do kernel do S.O.

Módulo Processador e
S.O. é a principal camada de software. Interface de Rede
Ele gerencia todos os recursos básicos
no sistema e fornece os serviços Kernel restrito ao gerenciamento de
essenciais. recursos básicos.
Suporte para programação distribuída
(linguagens, RPC e suporte para
comunicação em grupo)
 Fundamentos de
Sistemas Distribuídos

Aspectos de projeto e arquitetura

Distributed OS
Middleware-
Item Network OS
Multiproc. Multicomp. based DS

Transparência Muito alta Alta Baixa Alta

Mesmo SO em todos os
Sim Sim Não Não
nodos

Número de cópias do SO 1 N N N

Memória Modelo
Bases para comunicação Mensagens Mensagens
compartilhada específico
Global,
Gestão de recursos Centralizado Por nodo Por nodo
distribuído
Escalabilidade Não Moderado Sim Variável
Opennes Fechado Fechado Aberto Aberto
 Fundamentos de
Sistemas Distribuídos

Aspectos de SD: Middleware

Rede
Processo Processo

Middleware

Sistema Sistema
Operacional Operacional
(ex. Linux) (ex. Windows)
 Fundamentos de
Sistemas Distribuídos

Arquitetura de SD: Middleware

●
Uma camada de software, residente acima do sistema operacional e do
substrato de comunicação, que oferece abstrações de alto nível, fornecendo
uma visão uniforme na utilização de recursos heterogêneos existentes,
objetivando facilitar a programação distribuída;
●
Um ambiente distribuído deveria oferecer a aparência de um único sistema,
apesar da diversidade de hardware, software, sistemas operacionais,
representações de dados, política, etc…;
 Fundamentos de
Sistemas Distribuídos

Comunicação em Sistemas Distribuídos

Sistema Centralizados Memória compartilhada;

Sistema Distribuídos Memória não compartilhada;

Regras que os processos PROTOCOLOS

comunicantes devem seguir

Em sistemas distribuídos a comunicação é baseada na troca de mensagens;

mensagens
 Fundamentos de
Sistemas Distribuídos

Comunicação em Sistemas Distribuídos

●
RM-OSI (Reference Model for Open Systems Interconnection)

Aplicação Aplicação
interface Apresentação Apresentação
Sessão Sessão
Transporte Transporte
Rede Rede
Enlace Enlace
Físico Físico

●
Quando o processo A deseja se comunicar com o processo B, ele primeiro
constrói uma mensagem em seu próprio espaço de endereçamento, depois
este processo executa uma chamada de sistema, que faz com que o
sistema operacional busque a mensagem e a envie para o processo B
através da rede de comunicação;
 Fundamentos de
Sistemas Distribuídos

Comunicação Cliente/Servidor
●
Ideia:
●
Estruturar o sistema operacional como um grupo de processos cooperados
denominados servidores, que oferecem serviços à processos usuários,
denominados clientes;
●
Modelo Cliente/Servidor:
●
Baseado em um protocolo simples, sem conexão, do tipo
requisição/resposta;

Requisição
Cliente Servidor
Resposta
Kernel Kernel
Rede
 Fundamentos de
Sistemas Distribuídos

Comunicação Cliente/Servidor
●
Vantagens:
●
Simplicidade: sem conexão;
●
Eficiência: pilha de protocolo é bem menor (rede local);

Serviços de comunicação são fornecidos pelo kernel:

7
6 - Envio: send(dest, &mptr)
Requisição/ 5 - Recebimento: receive(addr, &mptr)
resposta
4
3
Enlace de 2
Chamadas de Sistema
dados
Físico 1
 Fundamentos de
Sistemas Distribuídos

Endereçamento
●
Endereçamento direto:
●
Endereçamento que utiliza os endereços da rede para identificar processos;
●
Ex.: má[Link];

Cliente Servidor Má[Link]-local

1
- UNIX de Berkeley
C S - Máquina: 32 bits (IPv4)
2
Kernel Kernel - Processo: 16 bits

1: Requisição para 243, 0

2: Resposta para 199, 0 O usuário é obrigado a saber onde o
servidor está localizado!
 Fundamentos de
Sistemas Distribuídos

Endereçamento
●
Endereçamento de processo por Broadcast:
Cliente Servidor
3 1: Broadcast
C S 2: Aqui estou
4 3: Requisição
4: Resposta
1 2
●
Endereçamento via Servidor de Nomes: Servidor de
1 Nomes
3
S C NS
1: Lookup 2
2: Resposta do NS 4
3: Requisição
4: Resposta
 Fundamentos de
Sistemas Distribuídos

Endereçamento
●
Resumo:
●
Colocar máquina.número no código do cliente não é um processo
transparente;
●
Deixar que o processo escolha endereços de maneira aleatória; localizá-los
por broadcast gera uma carga extra;
●
Colocar nomes de servidores em ASCII; procurá-los em tempo de
processamento resulta em um componente centralizado (servidor de
nomes);
 Fundamentos de
Sistemas Distribuídos

Bloqueante X Não-bloqueante
●
Bloqueantes:
●
Processo chama SEND (destino, buffer);
●
Processo que está enviando fica bloqueado!

Cliente bloqueado
Cliente rodando Cliente rodando

Interrupção para Retorno do kernel,

o kernel, processo Mensagem sendo processo liberado
bloqueado
enviada
 Fundamentos de
Sistemas Distribuídos

Bloqueante X Não-bloqueante
●
Não-bloqueantes:
●
SEND devolve o controle imediatamente;
●
Vantagem
●
Processo que envia a mensagem pode continuar processando em
paralelo com a transmissão da mensagem, resultando assim em ganho
de desempenho;
●
Desvantagem
●
Transmissor não pode modificar o buffer até que a mensagem tenha sido
enviada;
●
Transmissor não tem ideia de quando a transmissão será completada;
 Fundamentos de
Sistemas Distribuídos

Bloqueante X Não-bloqueante
●
Solução:
●
Cópia da mensagem para um buffer interno do kernel;

Cliente
bloqueado

Cliente rodando Cliente rodando

Interrupção Retorno

Mensagem
Mensagem sendo
copiada para
o buffer do enviada
kernel
 Fundamentos de
Sistemas Distribuídos

Bloqueante X Não-bloqueante
●
Resumo:
●
Envio bloqueante (processador fica ocioso durante a transmissão da
mensagem);
●
Envio não-bloqueante com cópia (processador gasta tempo para fazer uma
cópia extra);

●
Temporização (timeout):
●
Alguns sistemas permitem que o transmissor especifique um intervalo de
tempo durante o qual ele aguardará pela resposta;
●
Caso não chegue nenhuma resposta neste intervalo, um código de erro é
retornado;
 Fundamentos de
Sistemas Distribuídos

Bufferização X Sem bufferização

●
Sem bufferização: receive(addr, &msg)
●
Prepara o receptor;
●
Existe um buffer de mensagem, apontado para msg, que armazena a
mensagem;
●
Quando a mensagem chega, o kernel da máquina receptora copia a
mensagem e desbloqueia o processo receptor;
Endereço
referente a um
Cliente Servidor processo

C A S
Kernel
 Fundamentos de
Sistemas Distribuídos

Bufferização X Sem bufferização

●
Sem bufferização: receive(addr, &msg)
●
Funciona bem enquanto o servidor chamar receive antes do cliente chamar
send;
●
Como saber qual de seus processos está utilizando o endereço
especificado na mensagem e onde copiar a mensagem?
●
Situação piora quando dois ou mais clientes estão utilizando o servidor;
●
1ª solução
●
Descartar a mensagem;
●
2ª solução
●
Manter armazenadas as mensagens entrantes por alguns instantes
(primitivas com bufferização);
●
Problema: buffer precisa ser gerenciado;
 Fundamentos de
Sistemas Distribuídos

Bufferização X Sem bufferização

Cliente Servidor
Endereço
C S referente a
uma caixa
Kernel A postal

●
Caixa postal (mailbox) são finitas!
●
O kernel sabe o que fazer com a mensagem e onde guardá-la;
●
Outra opção:
●
Não deixar que um processo envie uma mensagem se não houver lugar
para armazená-la no destino. Para isso, o transmissor deve ficar bloqueado
até receber um sinal confirmando o recebimento da mensagem;
 Fundamentos de
Sistemas Distribuídos

Primitivas Bloqueantes e Não-Bloqueantes

●
Primitivas bloqueantes (síncronas):
●
No send, enquanto a mensagem está sendo enviada, o processo fica
bloqueado;
●
O receive fica bloqueado até que alguma mensagem chegue ou até um
timeout pré-definido;

●
Primitivas não-bloqueantes (assíncronas):
●
O send retorna o controle imediatamente, antes da mensagem ser
realmente enviada;
●
O receive passa para o kernel o ponteiro para o buffer e retorna
imediatamente, antes de receber a mensagem;
●
Em algumas abordagens, o receive não-bloqueante é aquele que só recebe
quando já existem mensagens e fica bloqueado até completar a recepção;
 Fundamentos de
Sistemas Distribuídos

Primitivas Bloqueantes
●
O processo fica bloqueado durante a transferência da mensagem;
●
Melhor opção para o envio de mensagens em condições normais;
 Fundamentos de
Sistemas Distribuídos

Primitivas Não-Bloqueantes
●
Primitivas não-bloqueantes com cópia
●
O kernel copia a mensagem para um buffer interno e então libera o
processo para continuar;
●
Primitivas não-bloqueantes com interrupção
●
Interrompe o processo que enviou a mensagem quando o buffer estiver
livre para reutilização;
 Fundamentos de
Sistemas Distribuídos

Confiabilidade
●
Três diferentes alternativas podem ser utilizadas:
●
Assumir que as primitivas não são confiáveis, alterando a semântica do
send;
●
O sistema não garante que as mensagens são enviadas;
●
O usuário fica responsável por implementar comunicação confiável;
●
Primitivas confiáveis com mecanismos de confirmação do tipo:
●
Request – Ack – Reply – Ack
●
Primitivas confiáveis com mecanismos de confirmação do tipo:
●
Request – Reply – Ack
●
Combinações entre os mecanismos;
 Fundamentos de
Sistemas Distribuídos

Confiabilidade
●
Request – Reply – Ack:
●
O reply serve como um Ack na comunicação;
●
O cliente fica bloqueado até a recepção da mensagem de reply;
●
Se esta demorar, o cliente reenvia a requisição;
●
Em alguns kernels, não é necessária a confirmação com Ack;
 Fundamentos de
Sistemas Distribuídos

Confiabilidade
●
Request – Ack – Reply – Ack:
●
Somente quando o Ack é recebido, o processo é liberado;
●
A confirmação é feita entre kernels (transparente ao cliente e ao servidor);
●
Um request/reply com este mecanismo necessita de 4 mensagens;
 Fundamentos de
Sistemas Distribuídos

Confiabilidade
●
Outras questões:
●
As redes têm uma tamanho máximo de pacote, mensagens maiores devem
ser quebradas;
●
As confirmações podem ocorrer por pacote ou por mensagem, dependendo
da taxa de erros da rede;
 Fundamentos de
Sistemas Distribuídos

Confiabilidade
●
Exemplos de Protocolos:
●
Pacotes normalmente utilizados:
 Fundamentos de
Sistemas Distribuídos

Confiabilidade
●
Exemplos de Protocolos:
●
Pacotes normalmente utilizados:
 Fundamentos de
Sistemas Distribuídos

Troca de Mensagens
●
Envio de dados e controle pela rede para um ou mais participantes;
●
Forma mais primitiva e comum, próxima à rede;
●
Mensagem é uma estrutura de dados;
●
Primitivas básicas são utilizadas aos pares:
●
Envio:
●
send(msg) ou send(destino, msg)

●
Recepção:
●
recv(&msg) ou recv(origem, &msg)

●
Identificação de destino
●
Processo, IP, porta;
 Fundamentos de
Sistemas Distribuídos

Troca de Mensagens
●
Serviço de envio:
●
Processo A solicita o envio de uma mensagem ao processo B;
●
Processo B solicita o recebimento das mensagens de A, ou um
procedimento em B (ex.: callback) é executado quando uma mensagem
é recebida;
 Fundamentos de
Sistemas Distribuídos

Troca de Mensagens
●
Transmissão síncrona X assíncrona:
●
Quando o remetente é desbloqueado?
●
Após a mensagem ter sido processada pelo receptor;
●
Após a mensagem ter sido entregue ao receptor;
●
Após a mensagem ter chegado ao nó receptor;
●
Após a mensagem ter partido do nó transmissor;
●
Após a mensagem ter sido copiada para os buffers do nó transmissor
imediatamente;
 Fundamentos de
Sistemas Distribuídos

Troca de Mensagens
●
Mecanismos de troca de mensagens:
●
Unicast
●
A comunicação é realizada de 1 nó origem para 1 nó destino;
 Fundamentos de
Sistemas Distribuídos

Troca de Mensagens
●
Mecanismos de troca de mensagens:
●
Broadcast
●
A comunicação é realizada de 1 nó origem para todos os nós receptores
de uma mesma rede;
 Fundamentos de
Sistemas Distribuídos

Troca de Mensagens
●
Mecanismos de troca de mensagens:
●
Multicast
●
A comunicação é realizada de 1 nó origem para um grupo específico de
nós receptores;
 Fundamentos de
Sistemas Distribuídos

Troca de Mensagens
●
Mecanismos de troca de mensagens:
●
Anycast
●
A comunicação é realizada de 1 nó origem para o nó destino mais
próximo ou melhor definido pelo roteador da rede e que pertença à um
grupo pré-definidos, similarmente ao multicast;
 Comunicação entre Processos

Processos e Threads
●
Processo:
●
Um conjunto de recursos alocados por uma tarefa para que a mesma possa
ser executada;
●
Estes recursos podem ser: memória, arquivos, conexões, etc...
●
Um processo pode conter uma ou mais tarefas;
 Comunicação entre Processos

Processos e Threads
●
Processo:
●
Durante a operação do S.O., diversos processos podem ser criados e
destruídos através de chamadas de sistemas (ex.: fork no Unix);
 Comunicação entre Processos

Processos e Threads
●
Threads:
●
Um conjunto de instruções para atender uma finalidade específica;
●
São as entidades escalonadas pelo processador;
●
User threads: tarefas dos processo de usuário;
●
Kernel threads: tarefas do kernel;
 Comunicação entre Processos

Processos e Threads
●
Comunicação:
●
Threads associadas ao mesmo processo podem trocar informações
facilmente, pois compartilham a mesma área de memória;
●
Porém, isto não é possível entre tarefas associadas a processos distintos;
●
Para solucionar isto o kernel deve prover chamadas de sistemas que
permitam a comunicação entre processos (IPC – Inter-Process
Communication);
●
Duas abordagens:
●
Memória compartilhada:
●
Uma região da memória é compartilhada entre os processo;
●
Troca de mensagens:
●
Realizada a troca de mensagens entre os processos;
 Comunicação entre Processos

RPC (Remote Procedure Call)

●
Objetivos:
●
Permitir que clientes possam realizar chamadas de procedimentos
localizados em outras máquinas (servidores);
●
Mecanismo unificado e de alto nível;
●
Faz com que uma chamada remota pareça com uma chamada local,
abstraindo a tecnologia de comunicação existente;
●
Nenhuma operação de troca de mensagens ou de entrada/saída deve ser
visível ao programador (transparência);
●
Deve-se mascarar as diferenças na representação de dados;
 Comunicação entre Processos

RPC (Remote Procedure Call)

●
Serviços:
●
Pode ser visto como um módulo com uma interface que exporta um
conjunto de procedimentos apropriados para operar sobre qualquer
estrutura de dados ou recursos;
●
Classes de sistemas RPCs:
●
O mecanismo RPC é integrado com uma linguagem de programação
particular que inclui uma notação para definição de interfaces remotas,
transparente ou não (Cedar, Argus, Arjuna);
●
Uma linguagem de definição de interface de propósito especial descreve as
interfaces entre clientes e servidores (Sun RPC, ANSA Testbench);
 Comunicação entre Processos

RPC (Remote Procedure Call)

●
Linguagem de Definição de Interface (Interface Definition Language):
●
Descreve as características dos procedimentos:
●
Nome, tipos de argumentos, tipos de retorno, exceções, etc…
●
Compiladores de interfaces para diferentes linguagem alvo geram:
●
Stubs:
●
Cada procedimento definido na interface é implementado no stub;
●
Stubs geram operações de encapsulamento (marshalling) e
desencapsulamento (unmarshalling) de dados;
IDL

Client Server
Stub Stub
Compiler
 Comunicação entre Processos

RPC (Remote Procedure Call)

●
No RPC, a especificação de interface de um servidor (interface de serviço)
descreve procedimentos, com os tipos de argumentos de entrada e saída de
cada procedimento oferecido pela interface;
●
No modelo objeto distribuído, usa-se RMI (Remote Method Invocation);
●
Temos então uma interface remota que define métodos de um objeto
remoto;
●
A grande diferença da interface que utiliza RMI de uma RPC é que objetos
podem ser passados como argumentos e resultados de métodos;
●
Java (Java RMI) tem um mecanismo de RMI integrado a própria linguagem.
●
Todas as partes comunicantes utilizam a mesma linguagem;
●
Utiliza-se a mesma linguagem para se definir métodos locais e remotos;
●
Normalmente não é este o caso. IDLs possuem sintaxe própria.
 Comunicação entre Processos

RPC (Remote Procedure Call)

●
Características das interfaces IDL de RPCs
●
Passagem de parâmetros
●
Não utilizam passagem por referência em chamadas remotas;
●
Ponteiros não fazem sentido em espaços de endereçamentos diferentes;
●
Interface de servidor
●
Descreve parâmetros de entrada (in), saída (out) ou em duplo sentido
(inout);
●
Parâmetro de entrada: C → S (argumento da requisição);
●
Parâmetro de saída: S → C (respostas);
●
Parâmetros de duplo sentido: (inout);
 Comunicação entre Processos

RPC em Aplicação Distribuída

Client Stub Server Stub

Send Receive
Ca
ll Marshalling Unmarshalling ll
Ca

Client Dispatcher Server

Re n
tu
rn Unmarshalling Receive Send tur
Marshalling Re

Network
 Comunicação entre Processos

RPC em Aplicação Distribuída

●
Dinâmica do RPC:
●
Programa cliente chama o stub como uma chamada local;
●
Stub do cliente constrói a mensagem que será enviada, realiza o
marshalling dos argumentos e adiciona um identificador;
●
Módulo de Comunicação: envia a mensagem;
●
Dispatcher: de acordo com o identificador, seleciona um dos procedimentos
do stub do servidor;
●
Stub do servidor: realiza o unmarshalling dos argumentos e chama o
procedimento do servidor.
●
Stub do servidor: realiza o marshalling dos argumentos da resposta;
●
Stub do cliente: realiza o unmarshalling dos argumentos da resposta e
entrega ao cliente;
 Comunicação entre Processos

RPC em Aplicação Distribuída

●
A instalação e funcionamento do RPC têm três fases:
●
Processamento da Interface
●
Integrar os mecanismos de RPC com os programas cliente e servidor em
uma linguagem convencional;
●
Binding (ligação)
●
Localizar um servidor para um serviço em particular;
●
Comunicação
●
A comunicação entre o programa cliente e o programa servidor utilizando
stubs para a realização de marshalling e unmarshalling formando as
requisições/respostas (modelo cliente/servidor) em nível mais baixo sobre
os protocolos de comunicação (rede);
 Comunicação entre Processos

RPC em Aplicação Distribuída

●
Processamento da Interface:
●
A informação em programas são representadas como estrutura de dados
e, quando transferidas através de mensagens são transformadas em
sequência de bytes;
●
Máquinas podem armazenar tipos primitivos diferentes formas;
●
A representação de ponto flutuante pode diferir;
●
Caracteres podem ser representados usando diferentes codificações
(ASCII, EBCDIC, UNICODE, etc…);
●
Dois métodos para a troca de dados:
●
Valores são convertidos para uma representação externa acordada antes
da transmissão e convertida para a representação local na recepção;
●
Se ambos os computadores são do mesmo tipo, o formato externo pode ser omitido;

●
Os valores são transmitidos no formato do emissor juntamente com a
indicação do formato utilizado, devendo ser convertido pelo receptor;
 Comunicação entre Processos

RPC em Aplicação Distribuída

●
Processamento da Interface:
●
Para suportar RPC e RMI qualquer tipo de dado, que pode ser passado
como argumento ou retornado como resultado, deve ser flattened;
●
A representação das estrutura de dados e valores primitivos na sequência
de bytes é chamado de representação externa ou externalização;

●
Marshalling é o processo de converter uma sequência de estrutura de
dados no formato adequado para a transmissão;

●
Unmarshalling consiste da geração de valores primitivos de sua
representação externa e a reconstrução das estruturas de dados
correspondentes;
 Comunicação entre Processos

RPC em Aplicação Distribuída

●
Binding:
●
Define a maneira como o cliente localiza o servidor;
●
Mapeamento de um nome simbólico para um objeto em particular:
identificador da comunicação;
●
Ambiente UNIX: <ip>:<porta>
●
Amoeba: identificador independente do ambiente;
●
Binder:
●
Serviço separado que mantém uma tabela que mapeia os nomes dos
serviços para as portas e endereços dos servidores. Um exemplo disto é
o serviço de nomes;
●
Registro do servidor: deve enviar uma mensagem para que o binder
tome conhecimento da sua existência;
 Comunicação entre Processos

RPC na presença de falhas

●
RPC e Falhas
●
RPC deve conviver com falhas → qualquer chamada pode falhar!!!

●
Mecanismos de tratamento de exceções
●
RPCs devem estar habilitadas para reportar erros;
●
Requer um mecanismo de tratamento de exceções
●
Exceções são levantadas;
●
Procedimentos para o tratamento das exceções;
●
Pode ser definido como parte da linguagem de interface;
●
O cliente não é capaz de localizar o servidor
●
Servidor está fora do ar ou evoluiu (nova versão da interface)?
●
Mecanismo que faz com que o erro vire um exceção;
 Comunicação entre Processos

RPC na presença de falhas

●
Mecanismo de recuperação de erros
●
Perda de uma requisição (C → S)
●
Uso de temporizador quando uma requisição é enviada;
●
Perda de uma resposta (S → C)
●
Atribuir a cada requisição um número sequencial;
●
Se o kernel (ou middleware) controla esta numeração, este poderá
diferenciar entre uma requisição original e uma retransmissão;
 Comunicação entre Processos

RPC na presença de falhas

●
Mecanismos:
●
Retransmissão de requisições
●
Retransmite até que um resultado chegue ao objeto invocador;
●
Filtros de duplicação
●
Quando retransmissões são utilizadas e operações não podem ser
executadas mais de uma vez por execução, mecanismos de filtragem
impedem re-execuções;
●
Retransmissão de resultados
●
Um histórico de resultados é mantido no servidor para retransmitir
resultados para clientes que enviam requisições já executadas;
 Comunicação entre Processos

RPC na presença de falhas

●
Semânticas de Confiabilidade:
●
Qual é o comportamento desejado em uma chamada remota?
●
A semântica de chamadas locais corresponde a uma semântica exactly
once (exatamente uma);
●
Semântica maybe
●
O chamador não terá a certeza da execução da operação;
●
Nenhum mecanismo de tolerância a falhas é utilizado;
●
Se nenhum resultado é recebido após o timeout, nenhuma retransmissão
será realizada;
●
Portanto, o método pode, ou não, ter sido executado;
●
Somente útil em aplicações onde falhas ocasionais são aceitáveis;
 Comunicação entre Processos

RPC na presença de falhas

●
Semânticas de Confiabilidade:
●
Semântica at-least-once
●
A requisição é retransmitida até que o chamador receba um resultado ou
uma exceção;
●
Não pode ser utilizada em aplicações que não sejam idempotentes;
●
Semântica at-most-once
●
Quando o chamador recebe o resultado saber que a operação foi
executada uma vez;
●
Envolve o reenvio de requisições, o uso de filtros evitando a reexecução
de operações e também o reenvio de respostas;
 Comunicação entre Processos

RPC na presença de falhas

●
Semânticas de Confiabilidade:

Retransmissão de Filtros de Retransmissão de

Semântica
Requisições Duplicações Respostas
Maybe Não Não aplicável Não aplicável
Reexecuta a
At-least-once Sim Não
operação
Retransmite a
At-most-once Sim Sim
resposta

●
Em Java RMI e CORBA, chamadas remotas de métodos utilizam a
semântica at-most-once;
●
Especificações CORBA permitem ainda a semântica maybe para métodos
on-way (sem resposta);
 Comunicação entre Processos

RPC na presença de falhas

●
Mecanismos de Recuperação de Erros:
●
Indisponibilidade do Servidor
●
Uso de semânticas de confiabilidade;
●
O cliente continua tentando até receber uma resposta (at-least-once);
●
O sistema deve garantir uma única execução (at-most-once);
●
O cliente não possui qualquer garantia de execução (maybe);

●
Indisponibilidade do Cliente
●
Pode resultar em processamento orfão:
●
Gasta o tempo do processador, pode bloquear arquivos ou ocupar
recursos escassos;
●
Solução: Novo boot do cliente e semânticas de confiabilidade;
 Comunicação entre Processos

Aspectos relativos à construção do suporte RPC

●
O sucesso de um SD pode depender do seu desempenho!!!
●
Protocolos para RCP:
●
Orientados à conexão
●
TCP → mais confiável, falhas são tratadas pela pilha de comunicação;
●
Desvantagem → desempenho menor quando comparado ao UDP;
●
Não orientados à conexão
●
UDP sobre IP
●
Confirmação é realizada a nível de suporte RCP ou kernel;

0 ACK0 Window = 1 Window > 1 0

1 ACK1 1

2 ACK2 2 ACK012
 Comunicação entre Processos

Caminho Crítico

C  Chamada de Procedimento Stub

C
 Preparação do buffer  Realização do serviço
 Serializar os parâmetros  Chamada ao servidor
Stub

Stub
 Preencher campos do cabeçalho.  Inicializar os parâmetros na pilha
 Interromper o Kernel  Deserializar os parâmetros
 Troca do contexto (kernel);  Troca do contexto (stub)
 Cópia da mensagem (kernel);  Cópia da mensagem (stub)
Kernel

 Determinação do endereço e  Verificar se o stub está esperando

Kernel
colocação no cabeçalho;  Decidir qual o stub a ser usado
 Inicializar a interface de rede;  Verificar a validade do cliente
 Inicializar o temporizador.  Interrupção do processo
 Comunicação em Grupo

RMI (Remote Invocation Method)

●
Modelo Objeto
●
Objetos
●
Conjunto de métodos (operações) e dados que interagem entre si
invocando métodos, passando argumentos e recebendo resultados;
●
Para invocar um método, uma referência e o nome de um método
devem ser apresentados, junto com os argumentos necessários;
●
Interface
●
Fornece a definição de assinaturas de métodos da interface sem
especificar suas implementações;
●
O estado de um objeto corresponde aos valores de suas variáveis de
instância. No paradigma OO, o estado de um programa é particionado em
estados de seus objetos;
 Comunicação em Grupo

RMI (Remote Invocation Method)

●
Objetos Distribuídos
●
Objetos distribuídos podem assumir o modelo cliente/servidor;
●
Objetos clientes invocam métodos em objetos servidores utilizando RMI;
●
Objetos servidores podem assumir o papel de cliente;
Remote
Invocation

Host X Host Y
C

E F
Object B
A
A
D

Remote Invocation
Processo Local Invocation
 Comunicação em Grupo

RMI (Remote Invocation Method)

●
Base de um modelo de objetos distribuídos
●
Interface Remota
●
Especifica métodos que podem ser invocados de um objeto remoto
●
Objetos locais e remotos podem invocar métodos de uma interface
especificada como remota;
●
Interfaces não definem construtores;
●
No CORBA é utilizada uma IDL própria, no JavaRMI interfaces remotas
são extensões de uma interface Remote;
●
Interfaces CORBA e JavaRMI suportam herança de interfaces;
●
Remote Object Reference
●
Para invocar um método de um objeto remoto o objeto local deve possuir
a Referência do Objeto Remoto;
 Comunicação em Grupo

RMI (Remote Invocation Method)

 Comunicação entre Processos

Middleware
●
A utilização de middlewares agiliza o processo de implementação de
aplicações distribuídas;
●
Ex.: CORBA (Common Object Request Broker Architecture) e JavaRMI;

Aplicações e Serviços

RMI e RPC

marshaling de parâmetros
middleware

Protocolo request-reply

UDP e TCP
 Comunicação entre Processos

Comunicação de Grupo
●
Assumindo que Π=( P 1 , P 2 ,... , P n ) forma um sistema distribuído que interage
por troca de mensagens utilizando comunicação em grupo;
●
As restrições ao modelo são impostas pelo tipo de sincronia (síncrono ou
assíncrono), premissas de faltas, etc…
●
Suporte de comunicação de grupo implementa garantias de confiabilidade e
de ordenação durante as comunicações de grupo;
●
Mensagens recebidas na rede a nível do suporte de grupo somente são
consideradas aceitas e passadas à aplicação quando satisfazem as
propriedades do protocolo:
●
Liberação ou engajamento de mensagens (delivery, commit);
 Comunicação entre Processos

Comunicação de Grupo
●
O modelo de comunicação multicast permite que um emissor envie uma
mensagem a um conjunto de máquinas na forma de multicast group;
●
O membro do grupo multicast faz a interface receber pacotes IP envidados
a este grupo;
●
É um grupo aberto;

●
O emissor não sabe quem são os receptores e qual é a dimensão do grupo;
●
O membership de um multicast group é dinâmico;

●
A nível de aplicação o IP multicast é disponível via datagramas UDP;
●
Um programa de aplicação envia em multicast datagramas UDP com
endereços IP multicast e números de portas normais;
 Comunicação entre Processos

Comunicação de Grupo
●
Baseado no protocolo IGMP (Internet Group Management Protocol);
●
Pacotes IP com endereço multicast podem ser difundidos em redes locais ou
na Internet;
●
Em redes locais é mais fácil a difusão que usa as características da
Ethernet, por exemplo;
●
Na Internet faz uso de roteadores de multicast, através do IGMP;
●
Pacotes IP enviados a outros roteadores sobre outras redes
●
A limitação o processo de difusão (distância de propagação) é realizado
através do campo TTL (Time To Live);
 Comunicação entre Processos

Comunicação de Grupo
●
O endereçamento multicast utiliza a antiga classe D
●
[Link] a [Link]
●
Endereços reservados pela IANA (Internet Assigned Numbers Authority)
●
[Link] a [Link] → locais
●
[Link] a [Link] → escopo administrativo
●
224.0.1.x → outros
●
Endereços locais (224.0.0.x)
●
.1: all-hosts
●
.2: all-multicast routers
●
.4: all DVMRP (Distance Vector Multicast Routing Protocol) routers
●
.5: all OSPF (Open Shortest-Path First) routers
●
.6: OSPF (Open Shortest-Path First) designated routers
●
.13: all PIM (Protocol-Independent Multicast) routers
●
.15: all CBT (Core-Based Trees) routers
 Comunicação entre Processos

Comunicação de Grupo
●
Modelo de falhas do UDP/IP multicast;
●
sofrem de falhas de omissões;
●
não garante a entrega das mensagens para todos os membros do grupo;
●
Unreliable Multicast;

Multicast no Java
●
O Java fornece uma classe MulticastSocket subclasse da
DatagramSocket capaz de se juntar ou deixar grupos IP multicast;

●
Métodos:
●
joinGroup(InetAddress mcastaddr);
●
leaveGroup(InetAddress mcastaddr);
●
setTimeToLive(byte ttl);
 Comunicação entre Processos

Multicast no Java (Exemplo)

public class MulticastPeer {

public static void main(String[] args) {

try {
int port = 50000;
InetAddress group = [Link]("[Link]");
String msg = "multicast_test";
MulticastSocket socket = new MulticastSocket(port);
[Link](group);
byte[] data = [Link]();
DatagramPacket msgOut = new DatagramPacket(data, [Link], group, port);
[Link](msgOut);

// get message from others in the group

byte[] buffer = new byte[1000];
for (int i = 0; i < 3; i++) {
DatagramPacket msgIn = new DatagramPacket(buffer, [Link]);
[Link](msgIn);
[Link]("Received: "+new String([Link]()));
}
[Link](group);
} catch (SocketException e) {[Link]("Socket: "+[Link]());}
catch (IOException e) {[Link]("IO error: "+[Link]());}
}
}
 Middlewares para SD

Middlewares
●
DCOM
●
Distributed Component Object Model;
●
Microsoft;
●
Substituída na plataforma .NET pela API .NET Remoting;
●
Java RMI
●
Remote Method Invocation;
●
Oracle;
●
Disponível no núcleo básico desde a versão JDK 1.1;
●
CORBA
●
Common Object Request Broker Architecture;
●
OMG (Object Management Group);
 Java RMI

Introdução
●
O JavaRMI permite que um objeto rodando em uma JVM invoque métodos
rodando em outra JVM;
●
Fornece comunicação remota entre programas escritos em Java;
●
Aplicações RMI comumente compreendem dois programas separados, um
servidor e um cliente;
●
O servidor cria objetos remotos, faz as referências destes objetos serem
acessíveis, e aguarda clientes para realizar invocações destes métodos;
●
O cliente obtém a referência remota de um ou mais objetos remotos de um
servidor e então invoca os seus métodos;
●
RMI fornece um mecanismo pelo qual o servidor e o cliente se comunicam,
sendo referenciada como uma aplicação de objetos distribuídos;
 Java RMI

Introdução
●
Uma aplicação de objetos distribuídos precisa realizar as seguintes tarefas:
●
Localizar objetos remotos
●
Aplicações podem obter vários mecanismo para obter as referências de
objetos remotos;
●
Uma aplicação pode registrar os seus objetos remotos no serviço de
registros (RMI Registry);
●
Comunicar com os objetos remotos
●
Detalhes desta comunicação são encapsulados pelo RMI;
●
Para o programador, a invocação de um método remoto é similar a
invocação de métodos locais;
●
Carregar as definições de classe para os objetos passados
●
Uma vez que o RMI permite a passagem e recebimento de objetos, este
fornece um mecanismo para carregar classes de objetos bem como
transmitir dados de objetos;
 Java RMI

Introdução
 Java RMI

Introdução
●
Assim como qualquer aplicação Java, uma aplicação distribuída utilizando
JavaRMI é implementada através de interfaces e classes;
●
Interfaces declaram métodos;
●
Classes implementam os métodos declarados nas interfaces e, podem,
declarar métodos adicionais;
●
Em aplicações distribuídas, algumas implementações podem residir na
mesma JVM, mas outra podem ser que não;
●
Objetos com métodos que podem ser invocados através da JVM são
chamados de objetos remotos;
 Java RMI

Introdução
●
Um objeto é tido como remoto pela implementação de uma interface remota,
a qual possui as seguintes características:
●
Uma interface remota estende a interface [Link];
●
Cada método da interface declara [Link] na sua
clausula throws, além de qualquer exceção específica;

●
RMI trata um objeto remoto diferente de um objeto local quando este é
passado de uma JVM para outra;
●
Invés de fazer uma cópia da implementação do objeto na JVM de
recebimento, o RMI passa uma stub remoto para o objeto remoto;
●
Este stub age como um representante local, ou proxy, para o objeto remoto
e basicamente é, para o cliente, a referência remota;
●
O cliente invoca o método no stub local, o qual é responsável por realizar
esta requisição ao objeto remoto;
 Java RMI

Passos
●
Os passos para o desenvolvimento de uma aplicação remota utilizando
JavaRMI basicamente são:
●
Definição e implementação dos componente da aplicação distribuída;
●
Definição da interface remota;
●
Implementação do objeto remoto;
●
Implementação do servidor;
●
Implementação do cliente;
●
Compilação
●
Criação dos Stubs;
●
Execução do RMIRegistry;
●
Execução do Servidor;
●
Execução do Cliente;
 Java RMI

Passos
●
Criar um arquivo JAR das interfaces:

javac [Link]
jar cvf [Link] [Link]

●
Compilando as classes do servidor:

javac -cp [Link] [Link]

●

●
 Java RMI

Política de Segurança
●
Uma vez que o servidor e o cliente rodam com o SecurityManager instalado,
será necessário especificar a política de segurança de cada;

●
Arquivos [Link] e [Link]

grant codeBase
“file:/home/robson/eclipse_workspace/Calculadora/src/” {
permission [Link];
};
 CORBA

CORBA
●
OMG (Object Management Group):
●
Promover a teoria e prática de tecnologias orientadas a objetos em
desenvolvimento de software;
●
Criar especificações gerais → interfaces;
●
Sistemas abertos:
●
Portabilidade;
●
Interoperabilidade;
●
Reusabilidade;
●
CORBA (Common Object Request Broker Architecture):
●
Middleware para o desenvolvimento de aplicações orientadas a objetos
distribuídos;
●
Suporte para a invocação de métodos remotos;
 CORBA

Modelo de Objetos
●
Modelo Cliente/Servidor;
●
Objetos remotos são referidos como objetos CORBA;
●
Clientes não são necessariamente objetos;
●
Pode ser qualquer programa que envie requisições;

●
Implementações correspondentes a uma interface IDL (Objetos CORBA) não
necessariamente são construídas a partir de linguagens orientas a objetos;
●
Linguagens de implementação com diferentes noções de classes ou mesmo
nenhuma implica que o conceito de classe não existe em CORBA:
●
Classes não são definidas em uma IDL o que quer dizer que instâncias de classes
não podem ser passadas como argumentos (como enviar códigos entre linguagens
diferentes);
●
Contudo, estruturas de vários tipos e complexidades são passadas como
argumentos;
 CORBA

OMA (Object Management Architecture)

●
Define os principais aspectos da arquitetura;
●
Infraestrutura sobre a qual todas as especificações da OMG estão baseadas;
●
Objetos de serviços, facilidades, aplicações e ORB (Object Request
Broker);
 CORBA

Funcionamento do CORBA
●
O componente fundamental do CORBA é o ORB (Object Request Broker)
que tem a tarefa de facilitar a comunicação entre os objetos;
●
Provendo o IOR (Interoperable Object Reference), o ORB consegue
localizar os objetos destinos e transmitir informação para ou das invocações
de métodos remotos (RMI);
●
A interface dos objetos CORBA é especificada por uma IDL (Interface
Definition Language);
●
Um compilador traduz a definição IDL em uma linguagem de programação
(ex.: C, C++, Java, Ada, COBOL, SmallTalk, Lisp, Python, PL1) gerando IDL
Stubs e Skeletons que provêm respectivamente um framework para o lado
do cliente e um proxy para o lado do servidor;
 CORBA

Funcionamento do CORBA
●
Requisições e respostas entre objetos são entregues através de um formato
padrão definido pelo GIOP (General InterORB Protocol);
●
Protocolo abstrato de comunicação utilizado entre ORBs;
●
IIOP (Internet InterORB Protocol):
●
baseado na pilha TCP/IP para ser utilizado na Internet;
●
SSLIOP (SSL InterORB Protocol):
●
Implementação do IIOP sobre SSL, permitindo criptografia de dados e
autenticação;
●
HTIOP (HyperText InterORB Protocol):
●
Implementação do IIOP sobre HTTP, permitindo transparência sob o
ponto de vista de firewalls;
 CORBA

Funcionamento do CORBA
 CORBA

Funcionamento do CORBA (Client Side)

●
Stub
●
Produzido pela IDL, trata-se de uma interface do objeto remoto para ser
utilizada pelo cliente;
●
DII (Dynamic Invocation Interface)
●
A invocação de métodos baseada na DII difere da invocação baseada em
Stubs da mesma forma que scripts diferem de programas, ou seja, são
interpretados em tempo de execução, e não compilados anteriormente;
●
ORB Interface
●
Disponibiliza acesso aos serviços do ORB com exceção às invocações dos
clientes e ativações e chamadas de objetos;
●
Dentre os serviços estão:
●
Acesso ao serviço de nomes, RootPOA, ;
●
Acesso ao IFR (Interface Repository), utilizado pela DII;
●
Políticas de acesso;
 CORBA

Funcionamento do CORBA (Server Side)

●
Skeleton
●
Produzido pela IDL, trata-se de uma interface responsável por receber as
requisições dos clientes remotos e invocar o objeto local no servidor;
●
DSI (Dynamic Skeleton Interface)
●
Permite que servidores possam implementar interfaces em tempo de
execução de forma a criar uma ponte entre clientes CORBA e objetos que
estão implementados em outra especificação (ex.: COM);
●
POA (Portable Object Adapter)
●
Trata-se de uma parte do ORB responsável por gerenciar os recursos do
servidor de forma a gerir a escalabilidade do mesmo;
 CORBA

Exemplo
●
O primeiro passo para se criar uma aplicação CORBA é especificar todos os
objetos e interfaces utilizando uma IDL;
●
A IDL da OMG possui uma sintaxe parecida com o C++;
●
Define módulos, interfaces, estrutura de dados, etc;
●
A IDL pode mapear estas informações para uma variedade de linguagens
de programação;
●
Neste exemplo utilizaremos a linguagem Java (compilador idlj);

Arquivo [Link]

module HelloApp {
interface Hello {
string sayHello();
};
};
 Sincronização em SD

Contextualização
●
Um Sistema Distribuído:
●
Processos recebem, processam e enviam mensagens;
●
Suporte de comunicação (rede de comunicação) é dotado de propriedades
estruturais e comportamento:
●
Propriedades estruturais: topologia, arquitetura, protocolos, etc;
●
Propriedades comportamentais: dinâmica de funcionamento, não
duplica de mensagens, integridade das mensagens, atraso limitado, etc;
●
Processos em S.D. não compartilham memória ou relógio, comunicam-
se através das troca de mensagens;
●
Por conta disto, existe uma dificuldade em se caracterizar um estado
global em Sistemas Distribuídos;
 Sincronização em SD

Contextualização
●
Sistemas Distribuídos Síncronos
●
Modelo de execução síncrona;
●
Caracterizam-se por apresentarem:
●
Um limite entre atrasos relativos de processamento;
●
Um limite na latência da mensagem nas comunicações;
●
Sistemas síncronos são mais simples na determinação de tempos;
●
Sistemas de tempo real críticos (Hard Real-Time Systems);
 Sincronização em SD

Contextualização
●
Sistemas Distribuídos Assíncronos
●
Sistemas ou modelos de execução caracterizados pela não existência de
limites ou atrasos relativos de processamento ou de latências de
comunicação;
●
Neste caso o processamento e comunicação evoluem em tempos
arbitrários;
●
Torna-se difícil diferenciar o atraso de uma mensagem de uma parada de
um nó (crash de processador) do sistema distribuído;
 Sincronização em SD

Ordenação e Sincronização
●
Sistemas de computação que apresentam modelos de processamento
distribuído precisam de mecanismos de sincronização e ordenação entre
eventos;
●
Sincronização em sistemas centralizados
●
São construído com base em mecanismos de exclusão mútua
implementados sobre uma memória compartilhada;
●
Sincronização em sistemas distribuídos
●
Devido a não existência de uma memória compartilhada ou relógio global
fica difícil estabelecer ordens sobre os eventos;
 Sincronização em SD

Computação Distribuída
●
A execução de um programa distribuído corresponde a uma coleção de N
processos → { p i∣i=1, 2, ... , N }
●
Cada processo p i evolui gerando eventos e i internos e externos, que
provocam mudanças de estado;
●
Eventos externos ligado a comunicação, ex: send(m) ou receive(m);
●
Histórico local ( hi ) do processo pi durante a computação é uma sequência
de eventos:
h( pi )=e1i , e 2i ,.. . hki =e 1i , e2i ,... ,eik

●
Relação happened before (“→”) introduzida por Lamport que captura duas
ordens parciais e uma regra:
k l k l(ordemlocal)
●
Se ei , ei ∈hi e k <l ,então ,ei →e i
 Sincronização em SD

Relógios
●
Além de ordenar os eventos de um Sistema Distribuídos, também faz-se
necessário atribuir a eles uma data e hora através de um carimbo de tempo
(timestamp);
●
Cada computador possui o seu relógio físico;
●
Dispositivos eletrônicos que contam as oscilações que ocorrem em um
cristal com uma frequência de oscilação bem definida;
●
Estas oscilações são contadas e armazenadas em um registrador;
●
Os dispositivos podem ser configurados para gerarem interrupções de
hardware em intervalos regulares, chamadas de clock ticks;
●
O S.O. lê o valor do relógio de hardware, H i ( t ), acerta a sua escala e
adiciona uma compensação para produzir um relógio de software que mede o
tempo físico real t do processo pi .

C i ( t )=α H i (t )+β
 Sincronização em SD

Desvio de relógio e derivação de relógio

●
A diferença instantânea entre as leituras de quaisquer dois relógio é chamada
de desvio (skew);
●
Os relógios baseados em cristal estão sujeitos a deriva de relógio (drift), que
é o resultado de variações físicas (ex.: temperatura) na geração das
frequências de oscilação dos cristais;
−6
●
Relógios normais de quartzo possuem um drift de 10 segundo/ segundo , ou
seja, 1 segundo a cada 1.000.000 segundos (11,6 dias);
−7 −8
●
Relógios de quartzo de alta precisão possuem uma variação de 10 ou 10
●
Os relógios podem ser sincronizados com fontes externas mais precisas;
●
Os relógios físicos mais precisos usam um oscilador atômico cuja a
variação é de cerca de uma parte em 1013
●
Chamado de International Atomic Time;
●
Difere do tempo astronômico, baseado na rotação da Terra;
 Sincronização em SD

Sincronização de Relógios Físicos

●
Para saber quando os eventos de processos de um sistema distribuído
ocorreram é necessário sincronizar os relógios C i dos processos com uma
fonte de tempo externa de referência, isto é chamados de sincronização
externa;
●
Se os relógios são sincronizados com um grau de precisão conhecido, então
podemos medir o intervalo entre dois eventos que ocorrem em diferentes
computadores recorrendo aos seus relógios locais, isto é chamado de
sincronização interna;
 Sincronização em SD

Sincronização de Relógios Lógicos

●
Como não podemos sincronizar perfeitamente os relógios em um sistema
distribuído, em geral não podemos usar o tempo físico para descobrir a
ordem de qualquer par de eventos arbitrários que ocorram dentro dele;
●
Utiliza o princípio de casualidade:
●
Se dois eventos ocorrem no mesmo processo, então eles ocorrem na ordem em que
o processo os observou;
●
Quando uma mensagem é enviada entre processos, o evento de envio da
mensagem ocorre antes do evento de recepção da mesma;

p1
a b

p2
c d

p3
e f
 Sincronização em SD

Sincronização de Relógios Lógicos (Lamport)

●
Relógios lógicos de Lamport:
●
Mecanismo proposto por Lamport (1978) para datar eventos em um
sistema distribuído;
●
Cada nó S de um S.D. possui um contador, a variável C S (logical clock);
●
Cada evento ou send produzido em S o relógio lógico é incrementado;
C S ( e i )=C S +1
●
Na emissão de uma mensagem m por S um timestamp TS(m) é gerado a
partir do valor de C S antes da sua emissão;
TS ( m )=C S send ( m ,TS )
●
Na recepção de uma mensagem, um nó R (receptor) usa TS(m) para
atualizar C R sendo a expressão abaixo:
C R =max [C R ,TS ( m )]+1
 Sincronização em SD

Sincronização de Relógios Lógicos (Lamport)

0 1 2
p1
a b
0 3 4
p2
c d
0 1 5
p3
e f

●
Para quaisquer dois eventos e →e ' os valores de seus relógios lógicos serão
tais que C (e)<C (e ') :
e 11 →e 21 e 21 →e 32

●
Porém, o fato de dois eventos terem C (e)<C (e ') não significa que e →e ' ;
e 21∥e 13
 Sincronização em SD

Sincronização de Relógios Lógicos (Vetoriais)

●
Os relógios vetoriais foram introduzidos por Mattern (1989) e Fidge (1991)
para superar as limitações dos relógios de Lamport;
●
Um relógio vetorial para um sistema de N processos é um vetor de N inteiros;
●
Cada processo mantém seu próprio relógio vetorial V i , o qual utiliza para
gerar timestamps dos eventos locais e adicioná-los nas mensagens;
●
A atualização do relógio segue a regra abaixo:
●
Inicialmente, V i [ j]=0 , para i, j = 1, 2, …, N;
●
Ante de pi gerar um timestamp de um evento, ele configura V i [i]=V i [i]+1 ;
● pi inclui o valor t=V i em cada mensagem que envia;
●
Quando pi recebe um carimbo de tempo t em uma mensagem, ele
configura V i [ j]=max (V i [ j], t [ j]) , para j = 1, 2, …, N;
●
Onde, V i [i] é o número de eventos de pi , e V i [ j]( j≠i) é o número de
eventos ocorridos em p j nos quais potencialmente afetou pi ;
 Sincronização em SD

Sincronização de Relógios Lógicos (Vetoriais)

(1,0,0) (2,0,0)
p1
a b
(2,1,0) (2,2,0)
p2
c d
(0,0,1) (2,2,2)
p3
e f

●
A comparação dos timestamps pode ser realizada da seguinte forma:
V =V ' sse V [ j]=V ' [ j] para j=1, 2,... , N
V ≤V ' sse V [ j]≤V ' [ j] para j=1, 2,... , N
V <V ' sse V ≤V '∧V ≠V '
●
No exemplo observamos que: a → f V (a)<V (f )
c∥e ¬(V (c)≤V (e))∧¬(V (e)≤V (c))
 Sincronização em SD

Estado Global
●
Estado local
k
●
σ ki denota o estado de pi depois de executado o evento e i
●
Estado global
● ω
denotado por S=(σ 1, ... , σ n )