Você está na página 1de 16

lOMoARcPSD|4691880

SD - Resumo de Sistemas Distribuidos

Sistemas Distribuídos (Universidade do Minho)

StuDocu no está patrocinado ni avalado por ningún colegio o universidad.


Descargado por Fre DY (afjacanamijoy@hotmail.com)
lOMoARcPSD|4691880

[O.1.1]. Explicar por palavras próprias o conceito de Sistemas Distribuídos e as propriedades que os
caracterizam, nomeadamente a existência de máquinas autónomas ligadas em redes, a não existência de
relógio global, concorrência, falhas independentes com possibilidade de evitar pontos de falha única,
heterogeneidade e prestação de funcionalidades integradas.
O SD é um sistema, constituído por várias máquinas autónomas e heterogéneas ligadas em rede, em que cada
máquina executa determinados componentes que comunicam e coordenam as suas ações apenas através da
troca de mensagens, sobre um protocolo. Assim consegue-se um melhor desempenho do sistema e uma maior
capacidade de processamento a menor custo e é possível suportar num único sistema diversos tipos de rede,
computadores, SO, linguagens de programação, etc. É, portanto, mais económico, tem maior desempenho,
heterogeneidade, robustez e escalabilidade, distribuição inerente (algumas aplicações envolvem naturalmente
computadores independentes), expansão (poder de computação pode ser adicionado gradualmente).
Caraterísticas fundamentais:
• Concorrência – um sistema distribuído partilha processamento entre vários hardwares, tem de haver
concorrência – que permite que dois processos/threads acedam simultaneamente a um recurso sem causar
problemas - que quando bem gerida aumenta o desempenho;
• Não há relógio global – se o processamento é distribuído entre várias máquinas, e estas têm diferentes
localizações claro que o mecanismo de sincronização não poderá ser o relógio da máquina, existirão outros;
• Falhas independentes – uma das principais vantagens; se um componente de um SD falhar, pode não afetar
outros sistemas e/ou componentes no mesmo;
• Heterogeneidade – qualquer máquina, com qualquer hardware pode incorporar um SD, devido à utilização de
protocolos preparados etc…;
• Prestação de funcionalidades integradas – apesar de quando o utilizador solicita uma funcionalidade a um SD,
este ter que distribuir o processamento por várias máquinas, esta funcionalidade aparece ao utilizador como se
tivesse corrido apenas na máquina que ele correu a funcionalidade;

1.Explique o que significa conceber um Sistema Distribuído sem pontos de falha única.
É conceber o sistema distribuído sem um componente que seja crucial ao funcionamento do sistema. Se falha o
serviço de mensagens, não falha o serviço de contactos. Por exemplo, No Skype, ao falhar o serviço central não dá
para fazer login. Ao replicarmos, o sistema é mais escalável e tolerante a faltas e peers-to-peers.

[O.1.2]. Perante a descrição de um sistema informático caracterizá-lo do ponto de vista da sua abordagem à
distribuição, identificando quais as partes desse sistema que correspondem de alguma forma ao conceito de
Sistema Distribuído.
Distinguir um sistema distribuído de um sistema centralizado:
• SC – Informação numa única maquina. Servidor faz tudo;
• SD – Recursos divididos pelas varias maquinas. Há comunicação com varias entidades.
Os sistemas informáticos podem estar distribuídos em vários componentes, mas estes não são autónomos. Um
sistema informático caracteriza-se por ser constituído por um programa que é escrito utilizando uma linguagem
de programação e guardado na memória secundária, sendo depois carregado para a memória principal e utilizado
pelo CPU originando um ou mais processos que podem interagir através da troca de mensagens. A memória e o
processador são os elementos destes sistemas que podem ser distribuídos

[O.1.3]. Identificar os principais desafios ao desenvolvimento de Sistemas Distribuídos, nomeadamente


Heterogeneidade, Abertura, Segurança, Escalabilidade, Tolerância a faltas, Concorrência e Transparência, e
para cada um deles explicar por palavras próprias o seu significado e as suas implicações para o
desenvolvimento de sistemas informáticos.
• Heterogeneidade – suportar várias máquinas com diverso hardware e SO’s. Implica suportar diferentes redes,
computadores, sistemas operativos linguagens de programação, componentes. Para ultrapassar isto usam-se
middlewares, tipos de dados conformes, protocolos de comunicação, abstração de dados.
• Abertura – o sistema pode ser estendido e reimplementado de muitas formas, ou seja, cada um pode
desenvolver uma implementação dos componentes do sistema, desde que mantenha a conformidade, para poder
comunicar com os outros componentes existentes. Provoca reduções de custos, efeito de rede, concorrência
entre fabricantes, inovação. Mas implica boa documentação.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

• Segurança – o risco é acrescido em SD’s, podem haver vários tipos de ataque, para os quais o sistema tem de
estar preparado. Tem de garantir: confidencialidade, integridade, autenticação, não-repúdio, disponibilidade.
Utiliza-se frequentemente: criptografia, certificados, sumários, etc…;
• Escalabilidade – consegue manter o seu funcionamento mesmo com um aumento de escala muito grande em
termos de recursos e utilizadores. Utiliza-se frequentemente: replicação e caching;
• Tolerância a faltas – capacidade para manter o seu funcionamento, ainda que parcial, quando ocorre uma falta,
ou seja, uma falha num dos componentes. Se uma falha num componente implicar uma falha no sistema, então
quanto mais distribuído mais frágil. Num SD as falhas têm de ser independentes e parciais, um componente
falhou, mas os outros podem funcionar (houve uma falta no sistema e não uma falha). Graceful degradation é o
caso em que se há uma falha num ou mais componentes, os outros continuam a funcionar, mas o desempenho
do sistema distribuído diminui. Técnicas habituais: replicação, redundância, desenhar o sistema sem pontos de
falha únicos (falha um componente, falha tudo).
• Concorrência – aceder concorrentemente a recursos, logo tem de haver programação concorrente. Técnicas
utilizadas: semáforos, funções sincronizadas.
• Transparência – capacidade de mostrar as suas funcionalidades como se estas tivessem sempre integradas e
não partilhadas. O utilizador não deve ter a necessidade de lidar com os detalhes de distribuição do sistema. Tipos
de transparência: acesso, localização, concorrência, replicação de dados, faltas, mobilidade (recursos movidos
sem se dar por ela), desempenho (mudar configuração para melhor desempenho), escalabilidade. Técnicas
habituais: organização por camadas, API’s;

[O.1.4]. Explicar por palavras próprias o sentido das várias formas de transparência, nomeadamente de acesso,
de localização, de concorrência, de replicação, de faltas, de mobilidade, de desempenho e de escala. Tipos de
transparência:
• Acesso - recursos locais e remotos podem ser acedidos com as mesmas operações;
• Localização - recursos podem ser acedidos sem se conhecer a sua localização;
• Concorrência - diferentes entidades podem usar recursos comuns sem interferirem;
• Replicação de dados - diversas réplicas de um recurso são utilizadas sem que as entidades que as usem se
apercebam do número e localização das réplicas;
• Faltas - a ocorrência de faltas é disfarçada de modo a que as operações possam ser realizadas na mesma, sem
que o utilizador se aperceba e possa continuar a utilizar o SD;
• Mobilidade - recursos podem ser movidos sem afetar o funcionamento e sem se dar por ela;
• Desempenho - a configuração pode ser mudada para melhorar o desempenho; • Escalabilidade - pode-se juntar
novas máquinas/recursos sem ser necessário mudança

[O.2.1]. Explicar por palavras próprias os modelos de software mais comuns em sistemas distribuídos,
nomeadamente os baseados diretamente nos sistemas operativos e os baseados em middleware.
Os modelos baseados diretamente nos SO utilizam os recursos que o SO nos disponibiliza: gestão de processos,
canais de comunicação, etc. Este facto obriga o programador a implementar um protocolo de comunicação, a
definir formas de representação dos dados, a fazer o Marshaling e unmarshling (serialização e deserialização) dos
dados. Tudo isto revela-se trabalhoso, requere tempo e esforço que se perde na hora de pensar nas
funcionalidades da aplicação em si, o negócio. Contudo, quando bem planeado e implementado, é mais eficiente
que o software baseado em middleware. Por sua vez, um software baseado em middleware utiliza os recursos do
SO, cobrindo com uma camada aplicacional que simplifica o método como a comunicação é feita, o processo de
serialização e representação externa de dados. Este método poupa esforços neste campo e é o mais eficaz, mas
nem sempre o mais eficiente, visto que pode haver perdas de desempenho.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

Race conditions: • Situação em que um ou mais threads manipulam concorrentemente os dados e em que o
resultado final vai depender da ordem em que as respetivas instruções são executadas. • O acesso concorrente a
variáveis partilhadas pode resultar na inconsistência dos dados. • Para garantir a consistência dos dados, são
necessários mecanismos para assegurar a correta execução (sincronização) de processos cooperantes.
Como evitar race conditions: 1. Exclusão mútua no acesso à secção crítica. Se um processo esta a executar uma
secção critica mais nenhum outro pode executar essa secção critica. 2. Progresso. Nenhum processo a executar
fora da secção critica pode bloquear outro processo que esteja a entrar na sua secção critica. 3. Tempo de espera
limitado. Nenhum processo, apos requisitar a execução da sua secção critica pode ficar indefinidamente a espera.

[O.2.2]. Explicar por palavras próprias o modelo de programação cliente-servidor e as suas variantes, e.g. uso
de proxy ou clusters de servidores.
O modelo de programação cliente-servidor estrutura o SD em dois grupos de processos:
• servidores: processos que oferecem serviços;
• clientes: processos que requerem serviços.
Neste modelo, os serviços são acedidos através de uma interface partilhada por todos os clientes (e.g. browser),
sendo que todas as interações entre clientes e servidores são especificadas num protocolo que estabelece as
regras de comunicação, definindo que mensagens podem ser trocadas, qual o conteúdo e o formato das
mensagens (e.g. TCP/UDP). Já a especificação das invocações a realizar ao servidor encontra-se disponível em
bibliotecas (API) ou através de middleware. Uma variante deste modelo é a estrutura cliente – servidor com proxy
– que é um intermediário na interação com o servidor – particionado.
Uma segunda variante deste modelo é a estrutura cliente – servidor com cluster de servidores – em que um
cliente comunica não só com um servidor, mas com vários – replicado.

O.2.3]. Explicar por palavras próprias o modelo de programação distribuída peer-to-peer (P2P).
No modelo de programação peer-to-peer todas as entidades desempenham um papel semelhante e interagem de
forma cooperativa sem distinção entre clientes e servidores. Os padrões de interação podem variar em função
das circunstâncias ou da tarefa. Um exemplo de uma aplicação peer-to-peer é o Skype – todos as aplicações de
chat.

[O.2.4]. Perante a descrição de um sistema distribuído caracterizá-lo do ponto de vista do seu modelo de
distribuição – dizer se é peer-to-peer ou cliente-servido
• Código móvel – variação do modelo cliente-servidor em que o cliente começa por descarregar o código do
servidor para aceder às funcionalidades do serviço. Os pedidos são feitos ao código transferido. Exemplos:
javascript, java applets, jini.
• Agentes móveis – programa em execução que pode ser transferido de um computador para outro (código +
dados = estado). É o modelo ideal para tarefas que envolvam muitas máquinas, em que cada uma delas manipula
muitos dados. O agente é lançado e regressa com os resultados. A implementação é complexa, devido à
segurança e controlo de acesso aos recursos.
• Modelo de comunicação em grupo – processos podem entrar ou sair de um grupo e a comunicação é feita para
todos os membros do grupo. • Modelo de objetos distribuídos (abstração de invocação remota aplicada a
métodos de objetos).
• Produtor-subscritor

[O.2.5]. Explicar as abstrações representados pelos modelos fundamentais (modelo de interação, modelo de
falhas e modelo de segurança) e o seu papel na formulação de soluções para problemas centrais dos sistemas
distribuídos
Os três modelos enunciados são os modelos fundamentais, que definem um conjunto de abstrações que nos
permitem abordar problemas semelhantes com soluções semelhantes, ou seja, definem pressupostos mínimos e
fazem um conjunto de generalizações sobre o que é ou não possível de fazer.
Modelo de interação – lida com as dificuldades em estabelecer limites de tempo: ordenação de eventos - cada
processo executa sequencialmente ações que podem ser ordenadas pelo relógio local; não existe relógio global,
pelo que o relógio local só consegue ordenar eventos nos processos dessas máquinas;

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

Modelos de coordenação - a ordem de ocorrência de eventos é o que interessa e não o tempo exato – Relação
causal diz que: um evento pode não ter causado outro apesar de ter ocorrido antes deste; eventos ocorrem pela
mesma ordem em que são observados; o envio de uma mensagem acontece antes da receção.: relógio lógico -
cada processo mantem um contador que é incrementado a cada evento; ao enviar uma mensagem envia o valor
do contador junto; totally ordered logical clock - inclui identificadores dos vários processos e regras de ordenação
em caso de não causalidade; vector clocks - implica trocas de vetor de contadores dos vários processos. Variantes:
SD síncronos - onde podem existir limites de tempo – diálogo direto; SD assíncronos - não possui limites de
tempo; não se consegue garantir o tempo de entrega de uma mensagem
Modelo de falhas Tipos de falhas: Por omissão - não entrega mensagens ao destino; Arbitrárias - envia valores
incorretos ou respostas erradas; tipos: fail-stop – bloqueou e esse facto pode ser detetado; crash –
aparentemente bloqueou, mas não é possível garantir que apenas deixou de responder por estar muito lento, ou
porque as mensagens que enviou não chegaram; omission – mensagem colocada no buffer de emissão nunca
chega ao buffer de receção; send-omission – perde-se entre o emissor e o buffer de emissão; receive-omission -
perde-se entre o buffer de receção e o recetor.
Modelo de segurança – define direitos de acesso, isto é, define que entidades podem aceder, e de que forma, a
que recursos.

([O.2.6]. Explicar as relações causais e as razões pela qual a coordenação entre componentes não se pode
basear em noções de tempo.)
Problema de ordenação de eventos – cada processo executa sequencialmente ações que podem ser ordenadas
pelo relógio local; um algoritmo distribuído terá de abranger os vários processos das várias máquinas autónomas
ligadas que trocam mensagens assíncronas (num só sentido); o relógio local só consegue ordenar eventos nos
processos dessas máquinas, mas e se for necessário ordenar os processos das várias máquinas? Não há relógio
global. Aqui entram os modelos de coordenação, que defendem que o tempo exato nem sempre é o mais
importante, mas sim a ordem dos eventos, tempo real vs tempo lógico ou relação temporal vs relação causal. A
relação causal assenta nestes dois pressupostos: dois eventos do mesmo processo ocorrem pela ordem em que
são observados nesse processo; quando uma mensagem é enviada entre processos (máquinas diferentes ou
processos na mesma máquina), o envio acontece sempre antes da receção. Existem 3 modelos de coordenação:
• Relógios lógicos (Lamport) – cada processo mantem um contador que incrementa a cada evento; ao enviar uma
mensagem o valor do contador é enviado juntamente; ao receber a mensagem, e antes de incrementar o valor do
contador do recetor, o contador do recetor é alterado de modo a corresponder ao máximo entre o seu contador
e o contador da mensagem.
• Totally ordered logical cloks – igual ao anterior, mas inclui identificadores dos processos e regras de ordenação
em caso de não causalidade;
• Vector clocks – implica trocas de vetor de contadores dos vários processos.
Duas variantes no modelo de Interação:
• Sistemas distribuídos síncronos: Sistemas onde podem existir limites máximos de tempo;
• Sistemas distribuídos assíncronos: Não possui limites de tempo. Quanto ao modelo de falhas temos: Como
modelar e lidar as falhas que ocorrem a vários níveis nos sistemas reais? No envio de uma mensagem entre
processos, desde o output buffer até ao input buffer, passando pelo canal de comunicação, podem haver várias
falhas.
Tipos de falhas …
Quanto ao modelo de segurança temos: Principal – entidade identificada através de processo de autenticação
(Bob e Alice);
Inimigo – pode enviar qualquer mensagem para qualquer processo e ler ou copiar mensagens entre dois
processos.
Define direitos de acesso, isto é, definem que entidades podem aceder, e de que a forma, a que recursos. O
servidor e responsável por verificar a identidade de quem faz o pedido e verificar se tem direitos de acesso para
realizar a operação pretendida. O cliente deverá verificar a identidade de quem lhe enviou a resposta, para ver se
esta veio da entidade esperada. • Ataques aos processos: protocolo de rede não oferece proteção para que o
servidor saiba a identidade do emissor e o cliente também não dispõe de métodos para validar as repostas de um
servidor; • Ataques aos canais de comunicação: um processo inimigo pode intercetar as mensagens na rede; •
Negação de serviço: um processo intruso pode fazer com que seja ultrapassada a capacidade de resposta.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

[O.3.1]. Explicar por palavras próprias o paradigma de comunicação dos sockets e a respetiva interface de
acesso aos serviços de comunicações TCP/IP, seja na versão UDP ou TCP.
Os sockets situam-se entre a camada de Aplicação e o TCP/IP. É uma abstração baseada no paradigma de troca de
mensagens e que representa um ponto terminal no canal de comunicação entre dois processos. Foi inspirado nos
sockets telefónicos. Fornece uma API para o TCP e outra para o UDP, disponível em quase todos os SO. Como
funciona?
• A comunicação realiza-se através de portas virtuais nos quais a interface de rede fica dividido;
• Apenas existe um processo associado a uma porta;
• Vários processos enviam mensagens para uma porta;
• Em cada comunicação são usadas duas portas; As portas vão de 1 a 65535, sendo que de 1 a 1023 são
reservados para os serviços mais comuns (SMTP, HTTP, etc..). Para cada porta está associado o protocolo UDP ou
TCP, e a mesma porta pode ser usada simultaneamente no UDP e TCP, porque são diferentes nos dois protocolos.
Analogia ao cliente-servidor
• Um processo cliente tem uma dada porta qualquer;
• Um servidor atua numa porta estabelecida (é essa porta que os clientes conhecem para se ligar);
• Envia uma mensagem para o servidor, indicando a porta estabelecida;
Sockets para UDP
• Existe uma API para o protocolo UDP, é não fiável na entrega das mensagens. Cada mensagem carrega consigo
o destino onde deve ser entregue. Usa normalmente nonblobking send e blocking receive. Neste protocolo as
aplicações têm de ter os seus próprios mecanismos de deteção de falhas.
O UDP é menos fiável, mas mais rápido, pois não há acordos de estabelecimento de ligações, nem confirmações.
NonBlocking send – emissor continua a executar após o envio da mensagem (primitiva assíncrona, não espera por
confirmação); Blocking receive – o processo recetor bloqueia até a chegada de uma mensagem (primitiva
síncrona, pede algo e aguarda confirmação/resposta);
Sockets para TCP
• Existe uma API para o protocolo de transporte TCP, em que o serviço é fiável, orientado à ligação: conect, send,
receive, close. Garante a entrega de todos os pacotes. Normalmente usa nonblocking send e blocking receive.
Fornece um paradigm de stream onde se escrevem e leem bytes. Este protocolo esconde os seguintes aspetos: •
Tamanho e nº de mensagens; • Mensagens perdidas, duplicadas e trocadas; • Controlo de fluxo; • Destino das
mensagens;

[O.3.3]. Explicar por palavras próprias o significado e a necessidade da representação externa de dados e dos
respetivos processos de serialização
A representação externa de dados consiste em standardizar o tipo de dados que o sistema utiliza para comunicar,
para que num componente um dado signifique exatamente o mesmo que noutro componente. Como a
comunicação por sockets só permite envio de sequências de bytes, a representação externa de dados nos SD é
uma necessidade, na medida em que os componentes do sistema estão distribuídos por diferentes máquinas, e
contêm inúmeros componentes que podem, ou não, ser desenvolvidos em diferentes linguagens. Para isto é
necessário standardizar o tipo de dados para que todo o sistema e até partes externas ao sistema compreendam
o que aqueles dados representam, de modo a que após a receção da sequência de bytes possam ser
corretamente reconstruídos.
Este processo é idêntico ao guardar estruturas de dados em ficheiros e depois recuperar, em que temos que
saber que estruturas lá foram guardadas.
Marshalling – transformar um conjunto de dados numa sequência de bytes adequada para transmissão
(flattening, serialização) Unmarshelling – transformar uma sequência de bytes em estruturas de dados
equivalente aos originais.
Estes dois processos podem ser feitos via middleware, mas se a aplicação trabalhar diretamente com sockets
temos que ser nós a gerir este processo.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

O grande problema Sistemas diferentes podem usar diferentes representações de dados (o que para um é uma
String x para outro pode ser uma String y), pelo que os formatos usados pelo SO não podem ser considerados.
Para isso existem duas soluções: • Converte-se os dados para um formato externo comum (representação
externa de dados, com CDR – Corba Common Data Representation, Java Serialization Formats, ou documentos e
schemas XML); • Transmissão no formato do emissor, juntamente com uma indicação do formato; Uma
representação de dados em corba não indica o tipo de dados porque pressupõe que o protocolo já conhece (se o
parâmetro do método é String, então é uma String) Em java tudo isto se resolve com a clausula Serializable
indicada no cabeçalho da classe. Apenas o estado (valores) do objeto é serializado, porque se pressupõe que a
classe existe no outro lado. Assim já podemos escrever o objeto e todos os outros objetos que ele referencia
(todos têm que estar serializados, isto é, um carro é serializable, mas se tem uma variável da classe roda o objeto
roda também tem que ser serializable). Em java é indicado o tipo do objeto serializado que ele está a enviar, para
o recetor conseguir fazer o cast para a classe adequada.

[O.3.4]. Descrever os principais protocolos básicos pedido-resposta e as suas implicações para a semântica das
interações cliente-servidor. Tem de existir um protocolo de comunicação para governar a comunicação entre um
cliente e servidor, de modo a especificar as mensagens que podem ser enviadas e o comportamento perante as
várias situações.
Protocolo de pedido-resposta:
• Identificação das mensagens;
• Histórico;
• Modelos de falha:
• Mensagens perdidas, trocadas, duplicadas;
• Falhas nos processos
• Timeouts
• Modelos de interação:
R
RR
RRA

[O.3.5]. Explicar por palavras próprias os mecanismos de comunicação em grupo disponíveis no API sockets.
A comunicação em grupo é importante para: replicação das mensagens por um grupo; descobrir quem está no
grupo; propagação de eventos;
Modelos de comunicação:
• Unicast – um para um;
• Multicast – um para muitos;
• Broadcast – um para todos;
• Anycast – um de um conjunto para um outro de outro conjunto; Multicast IP Os IP vão desde 224 a 235 (são
endereços de grupos). As máquinas juntam-se a um grupo com um dos endereços desta gama e passam a receber
mensagens. Não há garantia de fiabilidade nem ordem das mensagens.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

[O.4.1]. Explicar por palavras próprias o conceito de Middleware e o seu papel no desenvolvimento de
aplicações distribuídas.
Os sockets são uma abstração de muito baixo nível, pelo que dá muito trabalho para os programadores, e não
suportam transparência de acesso nem de localização.
A finalidade do middleware é generalizar as funcionalidades envolvidas na maior parte dos programas:
representação externa de dados, marshalling/unmarshalling, protocolos de pedido-resposta. Estas
funcionalidades representam um processo complexo e com elevados custos. Assim utilizamos o middleware que é
uma solução de mais alto nível, baseado numa linguagem de programação existente, que possa ser usado em
várias aplicações e esconda toda a heterogeneidade das entidades envolvidas na comunicação. Vantagens
Middleware: • Abstrai o que é comum a muitas aplicações; • Mais alto nível; • Desenvolvimento facilitado
(desenvolvimento mais rápido, menos propicio a erros, e complexidade reduzida)
Desvantagens: • Menos flexível; • Menos desempenho; • Consome mais recursos;

[O.4.2]. Explicar por palavras próprias o modelo de objetos distribuídos e o paradigma de invocação de
métodos remotos (RMI). O modelo de objetos distribuídos é basicamente uma implementação do modelo de
objetos locais, mas em que vários objetos usufruem das características dos sistemas distribuídos, nomeadamente
a distribuição por várias máquinas autónomas ligadas em rede.
O RMI estende o modelo de objetos de modo a suportar a invocação de métodos de outros processos (mesma
máquina ou máquinas distribuídas), de forma transparente.
O RMI (Remote Method Invocation) é uma interface de programação que permite a execução de chamadas
remotas no estilo RPC em aplicações desenvolvidas em Java. É uma das abordagens da plataforma Java para
providenciar as funcionalidades de uma plataforma de objetos distribuídos.
O Java Remote Method Invocation (Java RMI) é uma API Java que executa a chamada de um método remoto, o
equivalente a RPC (orientado a objetos). O mecanismo de Remote Method Invocation (RMI) para a linguagem
Java permite a um objeto numa Java Virtual Machine (JVM) invocar os métodos de um objeto numa outra JVM; a
comunicação entre objetos é feita através de uma invocação de um método, sendo “quase” transparente para o
programador que se trata de um método remoto.
• O cliente invoca o método no stub – Função do stub: Quando um objeto local invoca um método num objeto
remoto, o "stub" fica responsável por enviar a chamada ao método para o objeto remoto. - Um objeto capaz de
receber invocações remotas designa-se por objeto remoto, que implementa uma interface remoto (define a

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

assinatura dos métodos que podem ser invocados). Exemplos: CORBA, Java RMI. • O stub serializa (marshall) o
pedido e envia ao servidor • O servidor assegura-se que o objeto está ativo: • Cria se necessário um processo
para correr o objeto • Carrega o objeto nesse processo • Invoca a inicialização do objeto, etc... • O pedido é
reestruturado (unmarshall) pelo skeleton do objeto e o método pretendido é invocado no objeto – Função
Skeleton: stub do lado servidor, responsável por reestruturar (unmarshall) as invocações e serializar (marshall) e
enviar os resultados • O resultado da invocação ao objeto é serializado (marshall) e enviado de novo ao cliente •
O stub reestrutura o resultado e passa-o ao cliente.
RMI Registry - O java RMI fornece um serviço de nomes, sem hierarquia, o RMI Registry. Permite associar nomes a
objetos, numa dada máquina. Cada objeto remoto regista-se no RMI Registry da máquina onde se encontra.
O RMI serve de interface que permite que o utilizados apenas se aperceba do 3º e 9º passos. O grande beneficio
desta é, portanto, a transparência.

[O.4.3]. Explicar por palavras próprias o paradigma de invocação de procedimentos remotos (RPC).
Remote Procedure Cal consiste numa chamada remota de um procedimento presente noutra maquina: •
Maquina A chama um procedimento remoto na maquina B (empacota parâmetros); • O processo na máquina A é
suspenso; • A execução do procedimento é feita na máquina B; • A máquina B devolve o resultado e o processo
na maquina A retoma a execução.
Os parâmetros são passados por valor e existe uma Interface Definition Language (IDL) que especifica os
procedimentos oferecidos pelo servidor aos clientes. Os stubs de cliente e servidor são gerados automaticamente
pela IDL.
O binding consiste em associar a invocação de um procedimento remoto a um servidor em execução. Se o binding
for dinâmico a associação é em runtime.
Tratamento de falhas: • Cliente não localiza o servidor – tratamento de exceções; • Pedido do cliente para o
servidor é perdido – retransmissão e gestão de timeouts; • O servidor interrompe a execução após receber o
pedido; • A resposta do servidor para o cliente é perdida – retransmissão e gestão de timeouts (ter que ter
atenção em operações sensíveis – descontar stocks – portanto é melhor numerar sequencialmente os pedidos);
Vantagens: • Envio de mensagens é transparente ao utilizador; • Transparência de acesso; • Sincronização
facilitada entre cliente e servidor;
Desvantagens: • Falhas (propicio a algumas falhas especificas); • Representação de tipos (não deixa de haver a
questão da representação externa de dados) • Variáveis globais e apontadores (os parâmetros são passados por
valor, então não podemos passar referencias; temos que ordenar os pedidos para garantir que não há falhas);
Exemplos: SUN RPC: • RPCGEN – para gerar os stubs apartir de uma IDL em c; • XDR (external Data
Representation) – utiliza big-endian para ordenar bytes e 32 bits como tamanho mínimo para qualquer campo; •
Runtime Library; • Portmapper – serviço de bind local, armazenando a porta de cada serviço.

[O.4.4]. Explicar por palavras próprias o paradigma de comunicação baseado na distribuição de eventos.
Neste modelo as aplicações são construídas com base nas reações de determinados objetos a eventos gerados
por outros objetos. A notificação de eventos é normalmente assíncrona e originada pelo lançador do evento.
Estes sistemas de eventos distribuídos permitem estender os modelos existentes para várias linguagens de
programação, de modo a que eventos possam ser recebidos por objetos de vários sistemas diferentes.

[O.4.6]. Relacionar os protocolos de pedido-resposta usados pelo middleware com as possíveis semânticos de
invocação dos métodos remotos.
Num middleware o que circula “por baixo” são mensagens, portanto deve-se definir: • Tipos e formatos das
mensagens; • Semântica de invocação: • semântica “pelo menos uma vez” - RR • semântica “no máximo uma
vez” – Identificar mensagens + R • semântica “não é prometido nada” - R • semântica “exatamente uma vez” -
Identificar as mensagens + RR • Protocolo a usar para suportar essa semântica (protocolo em termos de interface
apenas – IDL, não em termos de como se gere a comunicação, mas em termos do que se pode fazer na
comunicação)

[O.4.7]. Perante uma arquitetura de referência de um middleware RMI descrever o papel desempenhado pelos
vários componentes que o constituem, nomeadamente os stubs (ou proxies), skeleton, dispatcher, módulo de
referências remotas, módulos de comunicações (ou runtime), e objeto remoto.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

• Stubs (proxies) – representa no lado do cliente o papel do objeto remoto (servidor), atuando como um proxy
para aceder ao mesmo. Por conseguinte, a invocação não é verdadeiramente remota, mas sim local no proxy for
B, que implementa o skeleton & dispatcher for B class. O stub recebe invocações e depois incia o processo da
verdadeira invocação no objeto remoto: • Inicia uma ligação na JVM do objeto remoto; • Serializa os dados e
envia a mensagem; • Aguarda resposta (lidando com falhas e timeouts que possam haver); • Interpreta os dados
recebidos e faz o unmarshlling e retorna o valor resultado; O stub esconde todo este processamento remoto
• Skeleton & dispatcher – está no lado do servidor por desempenhar o papel de um cliente que invoca métodos
remotos no objeto remoto (IDL interface de B). Quando chega um pedido de um cliente é necessário: •
Interpretar e fazer o unmarshlling; • Invocar o método localmente no servidor, onde contem a implementação do
mesmo; • Fazer o marshlling do resultado e responder ao cliente;
• Módulo de Referências Remotas – a invocação de um objeto remoto implica a existência de uma referência
para o mesmo (normalmente gerada no construtor da classe). Quando um objeto é remoto nem existe referência
local nem é possível usar o construtor da classe. Uma referência remota é uma referência de um objeto existente
noutra JVM. Referências remotas não são apontadores de memórias, mas sim apontadores para outros objetos.
No caso do RMI o remote reference module é implementado pelo RMIRegistry: • Nomes dos objetos -
rmi://host:port/name • Cada objeto remoto regista-se no RMI Registry da máquina onde se encontra • Para
invocar os métodos de um objeto remoto, requer-se o RMIRegistry da maquina onde o objeto remoto se
encontra, indicando o nome do objeto, e depois obter a respetiva referencia. • Object A e B – são os processos
referentes à instância dos Objetos da classe A e B
• Módulo de Comunicação (runtime) – módulos responsáveis pelo envio e receção das mensagens. Fornece
serviços básicos às aplicações, tais como: localização de servidores, localização de agentes e transporte de
agentes.
• Objeto Remoto – Servidor (objeto que está do outro lado e que implementa a lógica.)

[O.4.8]. Descrever as implicações para o programador resultantes da invocação de métodos remotos em


comparação com a invocação de métodos locais.
RPC vs Procedimentos locais: • Servidor e cliente têm cada um o seu espaço de execução, pelo que o
programador tem que se preocupar com a representação externa de dados, caso não use middleware. Tem que
se preocupar também com armazenamento da informação corretamente, distinguindo bem o que deve ser
enviado e o que deve ser armazenado localmente; • Desempenho pode ser afetado no RPC, devido a
processamento adicional ou a tempos de transmissão, o que obriga o programador a esforços extra de otimização
de código, para tentar (quase impossível, senão impossível) igualar o desempenho local; • A execução pode falhar
por causas que não ocorrem localmente, o que obriga a um cuidadoso tratamento de exceções; • Pode ser
necessário autenticar-se, o que obriga a mecanismos de autenticação; • É necessário conhecer a localização do
servidor, pelo que deve ser um valor parametrizável e bem documentado e rastreado, de modo a ser passível
alterações futuras com facilidade; Web service e o seu papel no conjunto das tecnologias de middleware É um
acesso programático que permite que as aplicações comuniquem usando protocolos web (http tipicamente). As
mensagens são codificadas em XML. A comunicação entre clientes e servidores web passa a ser mais estruturada
e pode ocorrer sem intervenção humana. É um modelo RPC (Remote Prcoedure Call) orientado para sistemas
loosely-coupled (pouco dependentes de entidades externas, exigem pouco i/o, comunicam pouco com o
exterior), logo são especialmente adequados para interoperabilidade à escala da internet. Um dos objetivos mais
comuns num middleware de SD é a transparência, tentando fazer com que as invocações remotas sejam
semelhantes a locais. Contudo os web services não oferece diretamente nenhum paradigma de invocação
remota, nós temos que definir tudo em SOAP (Simple Object Access Protocol)/XML. Os web services também não
escondem a representação externa de dados, nós é que temos de definir todos os tipos de dados das mensagens
em XML. Contudo existem bibliotecas para muitas linguagens de programação par aintegrar web servives em
ambiente de programação, gerando automaticamente o código através da descrição WSDL (Web Service
Definition Language) do webservice (mensagens, marshalling, etc…) Desvantagens: - Pouca eficiência
Vantagens: - Ligações lousely-coupled; - Protocolos web são cada vez mais comuns e fáceis de implementar; -
Firewalls - Ótima interoperabilidade, facilitando comunicação entre sistemas de domínios diferentes, ou sistemas
de diferentes características dentro da mesma empresa

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

[O.5.1]. Explicar o modelo genérico de ameaças aplicável a uma comunicação por um canal partilhado.
É o ponto de partida para a implementação da politica de segurança. Devemos assumir sempre que o pior pode
acontecer. Um modelo realista ajuda a equilibrar riscos e proteção. Considerar todas as motivações dos atacantes
para o caso e definir ações a ser tomadas. As respostas são diferentes de sistema para sistema, levando a técnicas
diferentes de segurança.
Ameaças gerais no acesso aos recursos:
• Leakage – acesso por parte não autorizada;
• Tampering – alteração não autorizada dos recursos;
• Vandalism – interferir na operação normal de um sistema, sem benefícios próprios;
Ameaças no acesso ao canal de comunicação:
• Eavesdropping – copiar mensagens sem autorização;
• Masquerading – enviar ou receber mensagens usando a identidade de um principal (entidade autorizada a
aceder aos recursos);
• Message tampering (Man-in-the-middle-attack) – alteração das mensagens antes de enviar ao destinatário;
• Replaying – guardar mensagens intercetadas e envia-las mais tarde;
• Denial of Sevice (DoS) – sobrecarregar um sistema com pedidos de forma a inviabilizar a sua operação.
Ameaças de código móvel (ex. Java):
• Programas podem ser carregados a partir de servidores remotos e integrados em processos locais;
• Interfaces e recursos internos são expostos a ataques desses programas
• Estas situações são normalmente geridas por gestores de segurança local (ex. Java security manager) que
restringe o acesso por programas externos aos recursos locais.

[O.5.2]. Explicar os serviços de segurança correspondentes a autenticação, confidencialidade, integridade e


não-repúdio.
• Autenticação – garantir identidade (quem enviou algo foi mesmo quem diz ser);
• Confidencialidade – só quem é autorizado é que acede à mensagem;
• Integridade - o conteúdo da mensagem não pode ser alterado;
• Não-repúdio – evitar que alguém não autorizado possa negar o envio ou receção da mensagem;
• Controlo de acesso – só quem é autorizado acede aos recursos;
• Disponibilidade – a disponibilidade de um recurso não pode ser intencionalmente posta em causa.

[O.5.3]. Explicar os princípios básicos da criptografia de chave simétrica e o modo como esta pode ser aplicada
para obter serviços de segurança.
A criptografia significa escrita secreta, consiste em codificar uma mensagem de forma a que não seja acessível a
qualquer entidade, substituindo símbolos ao nível do bit, byte, kbyte, e em diante. Baseia-se na posse de
segredos (chaves criptográficas). É a base de muitas tecnologias de segurança. Técnica utilizada para a
confidencialidade, integridade e não-repúdio. A criptanálise dedica-se a quebrar a criptografia e a criptologia a
aplicar fórmulas matemáticas às duas anteriores.
Existem dois tipos de criptografia:
• Algoritmo secreto – dá mau resultado, porque quando descoberto o algoritmo conseguese desencriptar todas
as mensagens, sendo necessário um novo algoritmo;
• Algoritmo conhecido com chave secreta – toda a gente pode tentar quebrar o algoritmo, se alguém conseguir é
porque não é seguro. Mas a base está na constante alteração das chaves.
Criptografia de chave secreta (simétrica) é quando o emissor e recetor partilham a mesma chave que não pode
ser revelada a ninguém. Isto implica confiança e um canal de comunicação seguro. A necessidade de transmitir a
chave secreta aumenta o risco de ser descoberta. A mesma chave é usada para encriptar e desencriptar
mensagens.
A segurança depende do tamanho da chave (keyspace), que deve ser suficientemente longa para prevenir
ataques por tentativa de erro, mas não muito longa porque exige mais tempo para cifrar/decifrar a mensagem.
Escolher o tamanho adequado à necessidade de segurança. Garante:
• Integridade; • Autenticação; • Não repúdio.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

Os algoritmos de chave simétrica são normalmente muito rápidos: • Block ciphers – a grande maioria; cifram
dados em blocos; • Stream ciphers – cifram á medida que vão sendo gerados Exemplos de algoritmos: DES (Data
Encryption standard); IDEA (International Data Encryption Algorithm); AES (Advanced Encryption Standard).

[O.5.5]. Explicar os princípios básicos de uma assinatura digital e a forma como pode ser produzida com base
em sumários e técnicas de criptografia. Cifrar mensagens longas com criptografia assimétrica é pouco eficaz
porque exige muito tempo. A assinatura digital introduz o conceito de produzir um sumário (resumo) da
mensagem e assinar apenas o sumário (Message Digest). O sumário pode ser produzido com:
• One way hash functions, em que é feita num único sentido, em que o sumario tem sempre o mesmo tamanho
qualquer que seja o tamanho da mensagem. Uma alteração num único bit da mensagem deve ser suficiente para
calcular um MD (message digest) substancialmente diferente.
• Dado P é difícil calcular MD(P);
• Dado MD(P) é muito difícil calcular P (ou impossível);
• Não há sumários iguais para mensagens diferentes (MD(P) <> MD(P´))
Um sumário deve ter pelo menos 128 bits, de preferência mais. Exemplos de algoritmos para gerar sumários:
MD5 e SHA1
Assinaturas digitais com chaves públicas: combina assinatura digital com criptografia assimétrica:
• O sumário é gerado;
• O sumário é codificado com a chave privada de quem envia e constituía a assinatura.
• O recetor descodifica a assinatura/resumo com uso da chave pública atribuída pelo emissor.
Assinatura digital chave privada, combina assinatura digital com criptografia simétrica: o sumario é gerado; o
sumario é codificado com a chave privada de quem envia e constituía a assinatura, a chave privada é partilhada
com o recetor que a descodifica com uso da mesma.

[O.5.6]. Explicar o conceito de certificado digital e a forma como estes podem ser validados numa
infraestrutura de certificação.
Já estudamos as chaves assimétricas, e sabemos que para encriptar algo para enviar a um certo destinatário
temos que saber a sua chave pública, mas onde vamos busca-la:
• Pagina web; • Serviços de diretoria;
Os certificados digitais asseguram-nos que a chave pública pertence de facto à pessoa com quem queremos
comunicar. São documentos digitais que atestam a associação entre uma chave pública e uma entidade,
introduzindo também informações complementares (nome da entidade, nome da autoridade certificadora, nº de
serie, data de emissão e validade, auto assinatura, BI, foto, assinatura digital da entidade emissora do certificado).
Têm de existir entidades para distribuir os certificados, servidores para os armazenar. Existem infraestruturas
organizadas, designadas por PKI (Publik Key Infrastructure) que gerem os certificados: atribuem, revogam,
armazenam, recuperam, emprestam. Existem então as autoridades de certificação, que se regem pelo standard
X.509, e o conjunto formado por estas autoridades designa-se de hierarquia de certificação:
Como podemos gerar um certificado? 1. Gerar um par de chaves (Kpub e Kpri); 2. Enviar a chave pública para uma
CA (Certification Authority); 3. Provar a identidade junto da CA; 4. A CA assina e disponibiliza o certificado; 5. O
utilizador solicita-o (por e-mail ou serviço web); 6. O utilizador usa-o para garantir a legitimidade da sua chave
pública.

[O.5.7]. Descrever o essencial do modo de funcionamento dos protocolos SSL e HTTPS e o tipo de garantias
oferecidas na utilização da Web.
SSL (Secure Sockets Layer) Permite criar um canal seguro sobre um meio de comunicação não-seguro. Muito
usado para garantir a autenticidade de sites e confidencialidade na comunicação com os mesmos. O TLS é uma
versão estendida do SSL. O SSL suporta a autenticação do servidor e do cliente (Servidor é mais comum).
Tem duas fases principais:
• Estabelecimento da comunicação (SSL handshake); • Cliente e servidor trocam os seus certificados (X.509) para
assegurar identidade; • O cliente gera um conjunto de chaves para cifragem dos dados; • É negociado o algoritmo
usado na cifragem e a função de hash a utilizar para verificação da integridade dos dados.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

• Comunicação (SSL Record Protocol).


Garante: • Confidencialidade; • Integridade; • Autenticação
Nota: É como se fosse uma camada nova no modelo OSI (Segurança) que fica entre a de transporte e aplicação.
HTTPS Combina o HTTP com o SSL. Podemos na mesma página ter um servidor HTTP (porta 80 por defeito) e
HTTPS (aceita conexões normalmente na porta 443). A informação é de acesso restrito no servidor HTTPS e os
sites que correm num servidor destes começam por https://
Comunicação: • Utilizador acede a um site seguro (https:) • O browser envia dados iniciais (versão SSL, ...) • O
servidor responde com o seu certificado digital • O browser verifica se:
• O certificado é válido
• CA é reconhecido
• A assinatura do CA é válida
• O domínio do servidor corresponde ao do certificado
• Em caso de sucesso o browser gera uma chave de sessão • O browser envia a chave de sessão para o servidor
(codificada) • O inicio da sessão SSL é negociado e as mensagens passam a ser codificadas com a chave de sessão
• No final a chave é eliminada
Nota: Quando dizemos que um site é seguro (que têm um certificado correto) apenas afirmamos que a
informação associada ao site está correta e que para ele podemos enviar dados sensíveis, pois a ligação é
encriptada e os dados não são acessíveis por terceiros. Não afirmamos que a operação que o site realiza (vendas,
alugueres, etc) seja correta.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

[O.6.1]. Explicar o conceito de escalabilidade e os desafios gerados a vários níveis pelos aumentos de escala do
sistema.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

A escalabilidade é um desafio de um sistema distribuído que consiste em conseguir manter o seu funcionamento
efetivo sem que para isso implique quebras significativas no seu desempenho, mesmo que haja um aumento
significativo no número de utilizadores e de recursos. Os desafios pelos aumentos de escalas do sistema são: •
distribuição, operações a realizar pelo sistema que podem ser distribuídas por diversas entidades; • replicação
consiste em replicar partes do sistema por várias entidades de forma a melhor o seu desempenho; • cache: partes
do sistema que contêm os dados estáticos de um sistema, ou seja que não se alteram, contêm dados que são só
de leitura. Ex: sites universidades, das juntas de freguesias.

[O.6.2]. Identificar em que circunstâncias será mais viável uma abordagem de escalabilidade horizontal ou
vertical.
Escalabilidade Vertical: aumentar os recursos disponíveis investindo num sistema de maior capacidade (ex. passar
para um servidor mais potente); o crescimento de custos é muito maior do que crescimento de desempenho.
Existe sempre um limite correspondente à máquina mais potente do momento. Não implica alterações na
arquitetura do sistema.
Escalabilidade Horizontal: aumentar os recursos disponíveis investindo em maior número de sistemas do mesmo
tipo (ex: clusters de PCs). Crescimento normalmente sublinear, mas o custo de manter muitas máquinas pode ser
elevado, sobretudo se as máquinas não forem todas iguais, para além do potencial subaproveitamento do
hardware. É também necessário conceber software para lidar com vários aumentos de escalabilidade, podendo
estes não se concretizar se houver uma grande necessidade de coordenação entre nós.
Balanceamento de carga: permite distribuir esforço por várias réplicas no cado de mecanismos de
escalabilidade horizontal.

[O.6.3]. Explicar os mecanismos de distribuição, replicação e cache e o seu papel como técnicas de
escalabilidade.
Distribuição: Operações a realizar pelo sistema podem ser distribuídas por diversas entidades. A administração
de diferentes partes do sistema pode ser atribuída a diversas entidades e a informação pode ser distribuída para
ficar mais próxima dos locais onde é mais utilizada. Deve-se evitar pontos centralizados que limitem o
crescimento e evitar a necessidade de conhecimento global do sistema. A distribuição deve permitir à
organização gerir os seus recursos implicando uma função de distribuição que permita determinar qual a
entidade à qual um recurso está associado. Para sabermos onde estão os recursos necessários utiliza-se a
localidade de referência, que nos diz que se devem distribuir os recursos para ficarem mais próximos daqueles
locais que são usados com mais frequência. Podemos encontrar os recursos através de broadcasting (encontrar
impressoras), tabelas, serviços de diretoria (dns).
Replicação: consiste em replicar partes do sistema por várias entidades de forma a melhor o seu desempenho,
mantendo réplicas de um recurso usado extensivamente em sistemas distribuídos. Onde colocar as réplicas? As
réplicas devem ser colocadas o mais dispersas possível por todos os sistemas, tendo em atenção as características
da rede. Objetivos: melhorar o desempenho através da distribuição da carga, aumentar a robustez e
disponibilidade do serviço, permitindo o seu funcionamento mesmo em caso de falha de um servidor. Cache:
partes do sistema que contêm os dados estáticos de um sistema, ou seja que não se alteram, contêm dados que
são só de leitura. ex: sites universidades, das juntas de freguesias. Mecanismos: Time outs, em que a renovação é
feita ao fim de determinado tempo; Hints que a renovação é feita quando se conclui que a informação não está
atualizada; Check on use em que a validade e verificada antes de ser utilizada; Callback em que a fonte informa a
cache das atualizações; Leases a utilização da cache é acordada previamente.

[O.6.4]. Explicar os modelos de replicação Master-Slave e Master-Master e as circunstâncias em que cada um


deve ser aplicado.
Master Master ou Active Replication: é o que recebe os pedidos, é o que tem de ter todas as atualizações. Existe
mais do que uma réplica que aceita pedidos de alterações de estado (escritas). Tem 2 abordagens: 1) os pedidos
são enviados para o conjunto de todas as réplicas, 2) o pedido é enviado para uma das réplicas que depois
propaga as alterações para as restantes. Tem de garantir que a ordem das atualizações é sempre a mesma. Detêm
maior complexidade.
Master Passive Slaves: não desempenha qualquer função a menos que o primeiro tenha uma falha, apenas
introduz mecanismo de tolerância a faltas, diminui a escalabilidade.

Descargado por Fre DY (afjacanamijoy@hotmail.com)


lOMoARcPSD|4691880

Master Active Slaves: não suportam pedidos de escrita, apenas leitura (aumenta escalabilidade), ex: Servidor
WEB.

[O.6.5]. Explicar o conceito consistência de dados replicados, e em particular o princípio de loose consistency,
indicando o seu papel nos mecanismos de replicação e as circunstâncias em que pode ser utilizado.
• Replicação pode causar inconsistência entre várias cópias do mesmo objeto de dados
• Consistência total (tight consistency) implica que:
• uma operação de leitura resulte sempre no mesmo valor independentemente de qual a réplica utilizada
• uma operação de escrita seja realizada como uma única operação (ou transação) que atualiza todas as
cópias de forma atómica
• Mecanismos para manter consistência entre réplicas implicam processamento adicional
• O esforço necessário para manter a consistência de dados depende de vários fatores essenciais:
• Rácio leituras/atualizações
• % dados que são “estáticos”
• Número de réplicas
• Requisitos de consistência
• Loose consistency admite que:
• Réplicas podem não estar sempre totalmente consistentes porque algumas têm atualizações que ainda não
foram recebidas por todas
. • Adequado quando uma consistência total não for essencial:
• Aceitáveis atrasos na propagação das alterações para as várias réplicas
• Pode ser possível detetar a incorreção de uma informação
• Se deixar de haver atualizações, ao fim de algum tempo, todas as réplicas irão convergir para um mesmo estado
(eventually).
• Atualizações são possíveis mesmo em caso de falha de uma réplica ou de falha nas ligações.
• Necessário gerir conflitos originados por atualizações concorrentes em réplicas diferentes.
• Consenso por quórum:
• Operações podem-se realizar se obtiverem a aprovação de determinado conjunto de réplicas (grupo de
quórum)
• Principal questão é evitar grupos disjuntos.

Descargado por Fre DY (afjacanamijoy@hotmail.com)