Apresentação
Cap. 2 - Sistemas
Distribuídos e Paralelos
Modelos de Sistemas

Um modelo de arquitetura de SD está preocupado com a localização das partes e o
relacionamento entre elas. Os exemplos incluem os modelos de processos
cliente/servidor e processos ponto a ponto.

Modelos fundamentais estão preocupados com a descrição mais formal das
propriedades que são comuns à todos as arquiteturas. É discutidos três modelos
fundamentais:
–
–
–
O modelo de interação, negocia com o desempenho e a dificuldade de ajuste de relógio
limitado dos SD. Ex: Entrega de msg;
O modelo de falhas, dá uma especificação precisa de falhas que podem ser exibidas pelo
processo e canais de comunicações;
O modelo de segurança, discute as possíveis ameaças para os processo e canais de
comunicações. É introduzido o conceito de canal seguro.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Sistemas que têm a intenção de serem usados no mundo real devem ser
projetados para funcionar corretamente sob uma grande variedade de
circunstâncias, problemas e ameaças possíveis.

Neste capítulo, estudaremos os modelos e suas principais propriedades.

O Sistema de Arquitetura são estruturados em termos de componentes
especificados separadamente. Sempre tendo em vista a preocupação de
garantir, confiabilidade, desempenho, segurança, gerenciamento a um custo
razoável.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Camadas de Software
–
Arquitetura de Software, era o
termo utilizado para estrutura de
camadas ou módulos de
software para um único
computador. Atualmente é
utilizado para definir serviços
oferecidos e requisitados entre
processos localizados em um
mesmo ou diferentes
computadores.
Applic ations, services
Middleware
Operating s ys tem
Platform
Computer and network hardware
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Camadas de Software
–
Conceito de Plataforma, é o termo utilizado para fazer referência de camadas
de baixo nível de hardware e software que dão serviços a camadas superiores.
–
Normalmente, em termos de computadores, uma plataforma está relacionada ao
tipo de arquitetura de processador e o sistema operacional utilizado. Ex:
Intel/Windows, Intel/Linux, Sun/Sparc/SunOS, Intel/Solaris, PowerPC/MacOS, etc.
–
MIDDLEWARE, pode ser representado por processos ou objetos em um conjunto
de computadores que interagem entre si para providenciar suporte para
comunicação e compartilhamento de recursos para as aplicações distribuídas.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Camadas de software
–
Em outras palavras, um Middleware em SD se preocupa em oferecer serviços de
forma eficiente de comunicação e de compartilhamento de recursos, simplificando
seu uso através da abstração da plataforma de baixo nível, oferecendo um
modelo de comunicação em grupo, notificação de eventos, a replicação de dados
compartilhados e transmissão de dados multimídia e tempo real.
–
RPC - Remote Procedure Calling, ou chamada de procedimentos remotos é o
termo utilizado para definir o método utilizado por determinado Middleware para
fazer chamadas de serviços oferecidos pelos processos ou objetos.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Camadas de software
–
Um dos mais conhecidos Middleware que providencia serviços de acesso
orientado a objetos é o CORBA - Common Object Request Broker Archicteture.
–
Outros:



Java-RMI, Java Remote Object Invocation;
DCOM, Microsoft’s Distributed Component Object Model e
RMODP (ISSO/ITU-T’s), Reference Model for Open Distributed Processing.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Camadas de software
–
Problemas com o uso de Middleware:



Embora os Middleware tentem sempre oferecer transparência para os
programadores, nem sempre isso é bom.
Algumas situações podem exigir que os problemas de comunicação, por
exemplo, devam ser tratados no nível da aplicação. Ex: E-mail.
Outra situação é os Middleware o intuito de garantir confiabilidade, traz
menos desempenho numa comunicação de rede. Ex: UDP vs TCP.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Arquitetura de sistemas
–
Modelo Cliente-Servidor:


É a arquitetura mais comum e frequentemente utilizada como exemplo de SD;
Os processos clientes invocam serviços aos servidores. Neste modelo, um servidor pode
se tornar um cliente para solicitar serviços de outro servidor.
Client
invocation
result
invocation
Server
result
Server
Client
Key:
Proc ess :
Professor: Arlindo Tadayuki Noji
Computer:
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Arquitetura de sistemas
–
Ex:

Um servidor web pode se tornar um cliente para o sistema de arquivos do S.O, para os
servidores DNS;
Client
invocation
result
invocation
Server
result
Server
Client
Key:
Proc ess :
Professor: Arlindo Tadayuki Noji
Computer:
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Arquitetura de sistemas
–
Servic e
Serviços providenciados por
Múltiplos Servidores:
Server


Nesta categoria, os serviços são
implementados em vários
servidores que interagem entre si
para oferecerem os serviços
solicitados pelos processos
clientes.
Ex: Servidores Web, BDs, DNS e
etc.
Professor: Arlindo Tadayuki Noji
Client
Server
Client
Server
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Arquitetura de sistemas
–
Servidores Proxy e de Caches


A técnica de cache é recente, e é utilizada em servidores que mantêm cópias de dados
solicitados anteriormente. Quando um cliente faz uma solicitação a um proxy, primeiro
ele verifica se os dados estão presente localmente, caso contrário ele busca a
informação efetivamente na rede.
Ex: Servidores de Proxy Web.
Web
s erver
Client
Proxy
s erver
Client
Professor: Arlindo Tadayuki Noji
Web
s erver
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Arquitetura de sistemas
–
Servidores Proxy e de Caches


–
A técnica de cache permite criar servidores Proxy Web, o que permite que dados em
cache possam ser compartilhados para muitos clientes;
a técnica de cache pode ser inserida nos clientes, de modo que possa beneficiar as
várias aplicações no acesso aos dados.
O propósito geral é garantir desempenho e disponibilidade de dados sem
aumentar a carga ou tráfego na rede utilizada.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Arquitetura de sistemas
–
Processo Ponto a Ponto


Nesta arquitetura todos os processo interagem com regras semelhantes. Trabalham de
forma cooperativa para desempenhar atividades computacionais. Não há processo
clientes ou servidoras. Cada processo mantêm controle de seus recursos e o modo de
interação com outros processos.
Ex: games.
Applic ation
Applic ation
Coordination
c ode
Coordination
c ode
Applic ation
Coordination
c ode
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Algumas variações deste modelo decorrem de razões listadas abaixo:



Uso de Códigos Móveis e Agentes Móveis;
Possibilidade de baixar cursos de recursos de hardware;
Flexibilidade para adicionar e remover dispositivos móveis.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Códigos Móveis

Os applets são bom exemplo de códigos móveis. Seu funcionamento é
baseado de modo a permitir que os códigos sejam transferidos do servidor
Web para os browsers, onde são executados.
a) c lient reques t res ults in the downl oadi ng of applet c ode
–
Vantagens:


Sem delay;
sem tráfego;
Client
Applet c ode
Web
s erver
b) c lient interac ts with the appl et
Client
Professor: Arlindo Tadayuki Noji
Applet
Web
s erver
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Através de códigos móveis é possível oferecer serviços que não podem
ser dado normalmente pela Web.

Ex:
–
–
–
–
Serviços de mensagens do tipo Push;
Atualização do relógio por parte do servidor;
HomeBrokers;
Interação automática com outros servidores.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Agentes Móveis

São programas executáveis (códigos e dados) que trafegam de um
computador ao outro para executar alguma tarefa.
–
Ex: Aplicações que necessitem coletar diversas informações em muitas
máquinas. A vantagem é a redução do tráfego de rede, devido a
redução de número de chamadas remotas por parte de códigos fixos;
–
Deve ter alta preocupação em relação a segurança. O Ambiente deve
preocupar em como e quais recursos ele poderá dar aos códigos
móveis. Por outro lado, os agentes tb podem sofrer problemas e não
completarem duas tarefas, pois não conseguiram ter acesso autorizado
aos recursos necessários.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Computadores de Rede



“Network Computers” tem arquitetura baseado de modo que o sistema
operacional, aplicativos e dados são sempre armazenados em servidores,
porém sua execução é realizados nos computadores clientes.
A premissa é que o gerenciamento dos recursos é feita sempre pelos
servidores, trazendo como vantagem a facilidade de utilização desses
computadores por parte dos usuários, pois desta forma eles não tem que se
preocupar com espaço em disco, atualização, instalação e remoção de
aplicativos.
Outra vantagem é que os computadores de rede tem preço muito baixo, pois
eles não precisam manter grande espaço em disco.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Thin Clients
O termo “thin Client” é o termo utilizado para fazer referência a uma
arquitetura que providencia através de camada de software, suporte a uma
Compute server
interface gráfica aos aplicativos que estão sendo executados em um Servidor
Network
computer or PC
Remoto.

Thin
Client
Professor: Arlindo Tadayuki Noji
network
Application
Process
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Thin Clients

Características:
–
–
–
–
Os servidores devem ser poderosos, capazes de executar diversos processos em
paralelo para atender inúmeros clientes;
Diferente da arquitetura de computadores de rede, os aplicativos são todos
executados nos servidores;
Sua principal desvantagem é quando se utiliza aplicativos gráficos. Ex: CADs e
processamento de imagens;
Exemplo de sistema: X11 (UNIX).
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Conexão espontânea

Trata de um conceito importante para utilização de dispositivos móveis. Ela
se preocupa na forma como devem ser integrados os diversos dispositivos
móveis com outros dispositivos não móveis com a infra-estrutura de rede
disponível.

A idéia básica é oferecer facilidade de conexão de dispositivos para os
usuários, de modo que eles não tenham que configurar ou instalar novos
softwares para acessar um serviço.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Conexão espontânea
gateway
Music
service
Alarm
service
Internet
Hotel wireless
network
Discovery
service
Camera
TV/PC
Professor: Arlindo Tadayuki Noji
Laptop
PDA
Guests
devices
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Exemplo de Cenário para Conexão espontânea:

Providenciar facilidades no acesso de Serviços, tais como:
–
–
–
–
–
–
–
Serviços de Música;
Sistema de alarme;
Acesso a Web, via TV/PC;
Serviço de Impressão de Fotos via TV ou Impressora;
Controle Remoto via PDA, para controlar o ambiente;
Fax;
etc.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Desafios para a Conexão espontânea:

Facilidade para conexão para Rede Local, deve permitir a capacidade de não ficar
limitado a uma localidade;

Facilidade para integração e acesso aos serviços Locais, deve ter a
capacidade de descobrir automaticamente quais serviços um determinado ambiente possui;

Conectividade Limitada,

Segurança e Privacidade,
deve ter a capacidade de continuar trabalhando mesmo que a
conexão seja interrompida momentaneamente;
deve evitar que o ambiente e o usuário sejam atacados ou
tenham sua privacidade invadida de alguma maneira.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Descobrindo Serviços

A primeira idéia é colocar em um PDA ou outro dispositivo qualquer, um processo que
monitora constantemente os ambientes que visita. Mas como garantir que os diferentes
dispositivos se comuniquem adequadamente para que possam passar os serviços que o
usuário realmente necessita?
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Variações no modelo Cliente Servidor
–
Descobrindo Serviços

O mecanismo de descoberta de serviços deve ter duas interfaces definidas:
–
Um serviço de Registro, para conseguir o aceite do acesso por parte do servidor e obter os
serviços disponíveis no seu banco de dados;
–
Um Serviço de Pesquisa, para permitir acesso detalhado e padronizado aos dados através
de um mecanismo definido de pesquisa;

Ex: Conseguir ver através do seu PDA, quantas TVs um apartamento tem e quais canais
ele pode sintonizar;
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas


Modelos Fundamentais
–
Qualquer modelo de sistema por mais diferente que possa parecer, irá apresentar
algumas propriedades fundamentais;
–
Todos eles são composto por processos que se comunicam entre si através da
troca de mensagens pela rede.
Nesta seção estudaremos mais especificamente as
propriedades fundamentais e os problemas relacionadas com
falhas e riscos de segurança
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Um modelo apresenta apenas as características básicas de um sistemas,
normalmente ele deve responder as seguintes perguntas:



–
Quais são as principais entidades envolvidas;
Como eles se interagem;
Quê características podem afetar seus comportamentos individuais e coletivos?
Um propósito de qualquer modelo deve:


Fazer ser explicito toda as premissas relevantes sobre o sistema que está sendo modelado;
Fazer generalizações que sejam capazes de dizer o que é ou não é possível fazer com o modelo.
Essa generalização garante a manter forma e as propriedades desejáveis para um modelo.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Saber com funciona um modelo é importante pois nos ajuda melhor a
definir como nosso sistema deverá funcionar. Através do modelo é possível
definir o que é possível e o que não é.
–
Além disso, um modelo permite abstrair os detalhes do hardware e
software, apresentando apenas as propriedades mais importantes do
sistema para uma análise.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
A definição de um modelo de SD pode nos ajudar em verificar
propriedades comuns, tais como:

Interação,

Falhas, Uma falha ocorrida em qualquer das máquinas ou software que estão distribuído um
A computação ocorre nos processos e os processos se comunicam-se através da troca
de mensagem para coordenar suas ações. Desta forma, atrasos de comunicação podem atrapalhar a
coordenação entre os processos. Dependendo da aplicação do SD, o nível de precisão de tempo será
mais ou menos importante em um projeto. Neste sentido, um modelo pode ajudar na análise de qual
modelo é mais adequado para o desenvolvimento de um SD.
sistema, pode ameaçar o funcionamento de um SD. Portanto, um modelo pode definir e até classificar
os tipos de falhas que poderão ocorrer em seu sistema.

Segurança, Um SD pode sofrer ataques tanto de agentes externos como internos. Através de um
modelo, é possível fazer uma análise das fragilidades e projetar um sistema resistente aos problemas
conhecidos para cada modelo.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Modelo de Interação


O modelo de interação informa de que maneira é realizada a interação entre os
processo com vista a complexidade que envolve um SD.
Essa complexidade envolve:
–
–
–
–
Trabalhar com algoritmos Distribuídos;
Delays na troca de mensagens;
Complexidade no acesso aos dados dos processo.
Há dois fatores significantes que afetam a interação entre processos em SDs:


Desempenho na Comunicação;
Impossibilidade de manter uma noção global de tempo sincronizado.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Canal de Desempenho de Comunicação

Um canal de comunicação pode ser implementado de várias formas: através de stream
ou de simples pacotes de mensagens.

Normalmente um canal de comunicação enfrenta os seguintes e característicos
problemas:
–
–
–
Latência;
Langura de Banda;
Jitter.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Latência: é o tempo levado por uma mensagem para sair do transmissor até chegar
ao receptor.
–
A latência pode ocorrer por vários motivos, os principais são:



Da infra-estrutura de rede utilizada. Ex comunicação de satélites. A latência neste caso é o
tempo levado pelo sinal de onda para chegar e retornar do satélite;
Do tipo da rede. Ex: A rede Ethernet trabalha com uma tecnologia que retarda o envio de
mensagem quando há outras comunicações em andamento no meio compartilhado;
Atrasos no software. Ex: aplicativos, protocolos e S.O. precisam de tempo para processarem as
informações antes de enviarem as informações.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Largura de Banda


–
Largura de banda é a quantidade de dados que pode ser transmitido em um
dado tempo;
Em uma mesma rede, o aumento de canais acaba compartilhando a largura
de banda, o efeito disso é a redução da quantidade de dados que é trafegado
por canal;
Jitter

É a variação na taxa de entrega de dados durante uma transmissão de
dados. Em outras palavras é a variação na velocidade de entrega de dados.
Este parâmetro é importante para transmissões multimídia.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Relógio de CPU e sincronização de Eventos

Para tratar eventos entre processos é importante, por exemplo, determinar
qual evento ocorreu primeiro. Mas a diferença existente entre os relógios
dificulta bastante saber com que precisão de quando um evento ocorreu.

Todo computador tem um relógio que pode ser consultado pelas aplicações.
Mesmo em SD cada processo pode fazer suas consultas locais para ver a
hora. Porém, quando os processos fazem a consulta, sempre existirá um
diferença de tempo entre computadores. Mesmo que você ajuste até o último
picossegundo, os processos tenderão a apresentar diferenças ao longo do
tempo devido a clock drift rate.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Clock Drift Rate

É a diferença apresentada por qualquer relógio real em relação a um relógio
perfeito. O Clock Drift Rate define que qualquer relógio irá funcionar mais
lento ou mais rápido de modo que ficará diferente do tempo real.

Alguns estudos mais promissores para tentar resolver este problema está
sendo feito através da sincronização de tempo por GPS. Através de ondas de
rádio, computadores podem possuir antenas de rádio para sincronizar com
diferença de apenas 1 microsegundos. O único problema é o custo para
equipar cada computador com GPS.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Duas variantes para o Modelo de Interação


–
Modelo de SD Síncrono;
Modelo de SD Assíncrono.
O Modelo de SD Síncrono

Foi definido pelo Hadzilacos e Touegs [1994] e apresenta um modelo onde segue alguns
limites bem definidos:
–
–
–
Deve ser conhecido o tempo máximo e mínimo de execução de cada passo ou etapa de um
processo;
Cada mensagens transmitida deve chegar em um tempo tolerável conhecido dentro do sistema;
Devemos conhecer o cada Clock Drift Rate dos processos envolvido no sistema.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Na prática é muito difícil definir os valores limites sugeridos em um SD
síncrono. A menos que possamos garantir que os valores estipulado
estejam corretos, qualquer projeto não teria a menor confiabilidade.
–
De qualquer forma, este modelo é útil para estudarmos como um SD
síncrono deverá funcionar e verificarmos os desafios que serão
enfrentadas para implementá-lo.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Os SD Assíncronos


Os SD assíncronos por sua vez apresentam um modelo muito
comum no mundo real. Um bom exemplo é a Internet, onde diversos
serviços úteis podem ser implementadas sem a necessidade de se
preocupar muito com a sincronização e precisão de tempo entre
processos.
Neste modelo não há limites definidos:
–
–
Os processos podem ter diferentes velocidades;
Permite que atrasos arbitrários possam ocorrer na transmissão de
dados
– Não se importa com os Drift rate dos processos.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Usando essa premissas de modelo SD assíncrono, é possível resolver muitos
dos problemas do mundo real.
–
Desta forma, como exemplo, sistemas de FTP podem funcionar apesar dos
atrasos na comunicação. Os e-mail podem ser entregues até com dias de atraso.
O ponto é que permitem que as aplicações possam tratar os problemas inerentes
de atraso e sincronização.
–
Ex: Um browser pode demorar bastante para apresentar uma página, porém ele
permitirá que o usuário possa fazer outras coisas enquanto espera.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Uma das razões para que a maioria dos SD estejam utilizando o modelo
assíncrono é devido a necessidade dos processo compartilharem os
recursos. O que implica que os recursos tais como: CPUs e Redes de
dados respondam cada vez mais devagar as solicitações à medida que
aumenta o número de usuários.
–
Porém, este modelo não consegue atender bem as aplicações que
requeiram executar a transmissão de dados multimídia em tempo real.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Ordenando Eventos

Em muitos casos é importante sabermos em que ordem ocorreram os eventos. Um
exemplo interessante é quando um usuário X envia uma msg para os usuários Y, Z e A.
Neste exemplo, Y recebe a mensagem e responde primeiro que os outros, mandando
cópias para X e Z e A. Devido à atrasos na rede, o processo A poderá receber as mesg da
seguinte forma:
s end
receive
receive
X
1
m1
2
Y
4
s end
3
m2
receive
Physic al
ti me
receive
s end
Z
receive
m3
A
t1
Professor: Arlindo Tadayuki Noji
receive
t2
m1
m2
receive receive receive
t3
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais

Se considerarmos que os relógios, de alguma forma, estejam
sincronizados, é fácil verificar qual mensagem foi enviado primeiro,
bastando para isso verificar as horas em que foram enviadas. Mas
como isso nem sempre é possível, existem outras técnicas que
permitem descobrir utilizando apenas a lógica.

Conforme a figura, podemos verificar a ordem apenas usando a
lógica:
–
X envia m1 antes de Y receber m1
– Y envia m2 antes de X receber m2
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelos Fundamentais
–
Conforme a figura, podemos verificar a ordem da seguinte forma:


X envia m1 antes de Y receber m1
Y envia m2 antes de X receber m2
Sabemos também que as respostas são enviadas depois de receberem
as mensagens, portanto nós temos a seguinte ordem lógica para Y:

Y recebe m1 antes enviar m2
Algumas deduções são possíveis para perceber quais ordem realmente
as mensagem foram enviadas.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de falhas
–
O modelo de falhas pode ser extremamente útil para nos ajudar a prever
como as falhas poderão ocorrer em um dado sistema.
–
Hadzilacos e Toueg providenciaram uma taxonomia para classificar as
várias formas de falhas que podem ocorrer nos processos e nas
comunicações. Eles classificaram como:



falhas por omissão
falhas arbitrárias
falhas de sincronização
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de falhas
–
Falhas por omissão


As falhas por omissão são chamados assim quando os processos
ou os canais de comunicações falham na execução das ações que
eles deveriam desempenhar.
É dividido em:
–
Falhas por omissão do processo
– Falhas por omissão da comunicação
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de falhas
–
Falhas por omissão do Processo

Uma das falhas mais conhecidas é a ocorrência do crash.
Quando um sistema entra em crash, ele pára totalmente de
desempenhar qualquer de suas funções, permanecendo
assim por um tempo indeterminado. Em outras palavras, um
sistema que sofre um crash não executa nenhuma atividade a
mais;
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de falhas
–
Um crash é fácil de ser detectado em sistemas síncronos apenas verificando se o
mesmo consegue responder antes de um time out especificado;
–
Mas em sistemas assíncronos, o fato de um processo externo não responder a
uma eventual chamada não significa que este sistema esteja em crash. De fato,
ele pode estar apenas sofrendo de um lentidão muito grande no envio de uma
reposta;
–
Um processo em crash pode ser chamado de fail-stop se um processo externo for
capaz de detectar seguramente que o sistema está totalmente parado. Ex: uso de
timeout em sistemas síncronos com msg com entrega garantida.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de falhas
–
Podemos identificar três tipos de falhas por omissão de comunicação:

Falha por omissão por perda de mensagem “dropping messages” , ocorre
devido ao canal de comunicação que apresenta problemas no buffer de
entradas de msg, erros de transmissão ou devido a problemas nos Gateways.
proc es s p
proc es s q
se nd
m
re ce iv e
Communic at ion c hannel
Outgoing mess age buffer
Professor: Arlindo Tadayuki Noji
Incoming mess age buffer
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas
–
Falha por omissão do envio, ocorre quando uma falha acontece entre o
processo emissor e o buffer de saída.
–
Falha por omissão do recebimento, ocorre quando uma falha acontece
entre o buffer de entrada e o processo receptor;
proc es s p
proc es s q
se nd
m
re ce iv e
Communic at ion c hannel
Outgoing mess age buffer
Professor: Arlindo Tadayuki Noji
Incoming mess age buffer
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas
Class of failure
Fail-stop
Description
Process halts and remains halted. Other processes may
detect this state.
Crash
Process Process halts and remains halted. Other processes may
not be able to detect this state.
Omission
Channel A message inserted in an outgoing message buffer never
arrives at the other end’s incoming message buffer.
Send-omission Process A process completes a send, but the message is not put
in its outgoing message buffer.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary
Process or Process/channel exhibits arbitrary behaviour: it may
(Byzantine)
channel send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.
Professor: Arlindo Tadayuki Noji
Affects
Process
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Falhas arbitrárias
–
O termo para falhas arbitrárias é usado para definir as piores falhas que
podem ocorrer, na qual qualquer tipo de erro é possível.
–
Um bom exemplo é quando um processo seta um valor errado para um
dado ou variável ou quando ele retorna valores errados em chamadas
remotas.
–
As falhas arbitrárias podem omitir passos de um processo ou executar
passos não solicitados. Falhas arbitrária não permitem ser detectados
facilmente pelas chamadas e respostas, devido a possibilidade de falhas
ocorrerem e impedirem que uma resposta seja enviada adequadamente.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Falhas arbitrárias
–
As falhas arbitrárias podem ocorrer tb na comunicação de rede. Dados
podem ser corrompidos ou apresentarem duplicatas na entrega da
mensagem. De qualquer forma é raro a detecção de falhas arbitrárias na
comunicação, pois os software (protocolos) são eficientes em detectar e
corrigir esses problemas através do uso de checksums e mecanismos de
numeração de ordem de chegada de pacotes é possível evitar esses
problemas.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Falhas de Sincronização
–
–
As falhas de Sincronização são comuns em SD síncronos e são caracterizados pelas
infrações cometidas aos limites de tempos estabelecidos para a execução dos
processos, entrega de mensagens e clock drift rate.
O aspecto da sincronização é particularmente importante para aplicações multimídias.
Class of Failure
Clock
Affects
Process
Performance
Process
Performance
Channel
Professor: Arlindo Tadayuki Noji
Description
Process’s local clock exceeds the bounds on its
rate of drift from real time.
Process exceeds the bounds on the interval
between two steps.
A message’s transmission takes longer than the
stated bound.
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Confiabilidade na comunicação Um para Um:
–
Conhecendo alguns desses problemas, é possível construir um SD utilizando mecanismos que
evitem as falhas mais frequentes na comunicação de dados.
–
Para garantir uma comunicação de dados confiável é necessário definirmos os termos Validação e
Integridade:


–
Validação, significa que qualquer msg inserida no buffer de saída será eventualmente entregue para o buffer
de entrada do outro processo;
Integridade, significa que a msg recebida é idêntica ao enviado. Também não há duplicações de msg no
processo.
A tarefa para preservar a Integridade vem de duas premissas:


Protocolo que retransmitam as msgs sem rejeitar as msg duplicadas;
Evitar que usuários maliciosos injetem msgs espúrios na rede com o objetivo de quebrar a integridade da
msgs.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
O estudo de um modelo de segurança para Sistemas Distribuídos é
baseado em três tipos de preocupações bem definidas:



Proteção ao processos;
Proteção canal utilizados para interação entre processos;
Proteção dos objetos encapsulados contra acesso não autorizados.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
Protegendo Objetos

A proteção de objetos é importante pois define quem ou o quê poderá acessar recursos
armazenados em um dado servidor.
Acc es s right s
Objec t
invocation
Client
result
Princi pal (us er)
Professor: Arlindo Tadayuki Noji
Network
Server
Princi pal (s erver)
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
Na figura abaixo podemos observar, como exemplo, um servidor mantendo e
gerenciando uma coleção de objetos. Dependendo da finalidade, os objetos podem
oferecer serviços com acesso restritos ou não, como podemos verificar nesses casos:


Muitos serviços providenciados pelos objetos podem ser dados privados. Ex:Emailbox.
Outros serviços podem ser dados que podem e devem ser públicos para serem
compartilhados na rede. Ex: páginas Web.
Acc es s rights
Objec t
invocation
Client
result
Princi pal (us er)
Professor: Arlindo Tadayuki Noji
Network
Server
Princi pal (s erver)
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
O modelo de segurança define por exemplo, que um servidor deve verificar a
identidade do processo invocante e também assegurar os direitos de acesso para
cada processo solicitante. Os processos clientes também devem se preocupar em
assegurar a identidade do servidor.
Acc es s right s
Objec t
invocation
Client
result
Princi pal (us er)
Professor: Arlindo Tadayuki Noji
Network
Server
Princi pal (s erver)
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
O modelo de segurança está preocupa em identificar as principais ameaças sofridas
pelos SDs. Muitos SD são utilizados atualmente para realização de transação
bancárias, negócios, transmissão de documentos confidenciais.etc.
–
Encontramos vários fontes de desafios/riscos, tais como:



–
Usuários mau intencionados;
Processos mau intencionados;
Problemas de falhas na comunicação;
O objetivo do estudo deste tipo de modelo é conhecermos suas características para
evitarmos essas possíveis ameaças.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança

O Inimigo
–
Alguém capaz de enviar qualquer msg para qualquer processo, ler, escrever
ou copiar qualquer informação entre um par de processos.
Copy of m
The enemy
Process
p
m’
m
Process
q
Communication channel
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
Algumas técnicas de defesas básicas são usados como:



Criptografia
Autenticação
Canal Seguro de comunicação
Principal B
Principal A
Process p
Professor: Arlindo Tadayuki Noji
Secure channel
Process q
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
Ataques podem vir de qualquer computador legítimo na
rede ou de uma máquina que está conectado de maneira
não autorizada na rede.
–
As ameaças de um potencial inimigo é discutidos em três tópicos:



Ameaças para o processo;
Ameaças para o canal de comunicação;
Serviços bloqueados.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
Ameaças para Processos, trata da questão onde os processos são incapazes de identificar
com precisão a identidade de qualquer outro processo. Mesmo com o IP, é fácil para um inimigo
gerar pacotes com endereçamentos falsos para esconder sua identidade.
–
A falta de confiabilidade é verificada tanto nos processos servidores como
nos clientes:

É extremamente difícil para um processo servidor identificar a origem de cada
solicitação recebida. Para processos que conseguem implementar um meio de
identificação, ainda sim eles podem ser burlado pelo inimigo através de uma
identidade falsa.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF
Modelos de Sistemas

Modelo de segurança
–
É extremamente difícil para um processo cliente também
identificar se a mensagem que recebida pelo servidor é
realmente do servidor original. Uma msg pode ser
falsamente gerada pelo inimigo e encaminhada para o
cliente.
Professor: Arlindo Tadayuki Noji
Instituto de Ensino Superior Fucapi - CESF