Resumos FSD

Índice
Introdução aos Sistemas Distribuídos .............................................................................. 3
Caracterização dos Sistemas de Informação Distribuídos ............................................. 3
Principais desafios na conceção de sistemas distribuídos: ........................................ 3
Sistema Informático (modelo base)............................................................................... 3
Criação e Execução de Programas ................................................................................ 4
Programação Sequencial .......................................................................................... 4
Programação Concorrente ........................................................................................ 4
Aplicações multi-processo ........................................................................................ 4
Sistemas Operativos Distribuídos .............................................................................. 5
Definição (I) .................................................................................................................. 5
Definição (II) ................................................................................................................. 6
Características dos Sistemas Distribuídos .................................................................... 6
Principais Características Distinticas dos Sistemas Distribuídos: .............................. 6
Principais Desafios dos Sistemas Distribuídos ........................................................... 6
Principais fontes de diversidade que originam a heterogeneidade em sistemas
distribuídos ............................................................................................................... 6
UT1: Objetivos pedagógicos (em que se podem basear as perguntas do teste) ............ 13
Modelos de Sistemas ..................................................................................................... 13
UT2: Objetivos pedagógicos (em que se podem basear as perguntas do teste) ............ 13
Modelos de Sistemas .................................................................................................. 14
Modelos físicos ....................................................................................................... 14
Modelos arquiteturais ............................................................................................. 14
Modelos fundamentais............................................................................................ 23
Comunicação Remota entre Processos .......................................................................... 31
UT3: Objetivos pedagógicos (em que se pode basear as perguntas do teste)................ 31
Serviços de Comunicações ........................................................................................ 31
Organização em Camadas ...................................................................................... 32
Modelo de Referência OSI ....................................................................................... 33
Serviços de Comunicações nos SO ......................................................................... 33
Interface sockets nos SO ......................................................................................... 33
Sockets ................................................................................................................... 34
Como endereçar processos .................................................................................... 34
Portas dos Sockets .................................................................................................. 34
Endereço dos Sockets ............................................................................................. 35
Sincronização no envio e receção de mensagens..................................................... 35
Representação externa de dados ............................................................................ 36
Exemplo XDR .......................................................................................................... 38
Representação de Dados ........................................................................................ 39
Resumo .................................................................................................................. 41
Modelos de Comunicação....................................................................................... 42
Protocolos de Comunicação ................................................................................... 42
Idempotência.......................................................................................................... 43
Protocolos de pedido-resposta ............................................................................... 43
 Introdução aos Sistemas Distribuídos
Caracterização dos Sistemas de Informação Distribuídos
Principais desafios na conceção de sistemas distribuídos:
Heterogeneidade;

Sistemas abertos;

Segurança;

Escalabilidade;

Lidar com faltas;

Concorrência;

Transparência e Qualidade de Serviço.

Sistema Informático (modelo base)

Para descrever uma determinada funcionalidade, escreve-se um programa que é

carregado da memória secundária para a memória principal para execução, dando origem
a um processo. As suas instruções vão sendo lidas de memória para o CPU onde são
executadas originando no processo entradas e saídas de dados, leitura e escrita de dados
nas memórias principal e secundária.
 Criação e Execução de Programas

Programação Sequencial
Um programa é executado por um único processo, que segue uma única linha de
execução.

Implicações:

» Não há possibilidades de suportar atividades concorrentes.

» Pouco adequado para aplicações interativas, servidores ou quaisquer aplicações

que tenham de responder a eventos extremos.

Programação Concorrente
Um programa é executado por um único processo, com múltiplas linhas de
execução concorrentes (Threads)

Implicações:

» Acesso concorrente aos dados;

» Race conditions;

» Necessidade de sincronizar execução das threads.

Aplicações multi-processo
A execução de um programa gera múltiplos processos numa mesma máquina
Implicações:

» Coordenaçáo e partilha de recursos entre processos é limitada e complexa.

Sistemas Operativos Distribuídos

Um programa é executado num único ambiente de execução, que proporciona
acesso a serviços distribuídos.

Sistemas de ficheiros distribuídos. BD distribuídas, impressora de rede.

Implicações:

» Aplicação não necessita de suporte específico para funcionamento distribuído

mas fica dependente dos serviços oferecidos pelo respetivo ambiente de execução.

Definição (I)
Um sistema distribuído é uma coleção de máquinas autónomas ligadas em rede, e
em que cada máquina executa determinados componentes que interagem entre si com
vista à prestação de uma funcionalidae computacional que apareça ao utilizador como
sendo um sistema integrado.
 Definição (II)
Um sistema distribuído é um sistema em que os diversos componentes, situados
em diversas máquinas ligadas à rede, comunicam e coordenam as suas ações apenas
através da troca de mensagens.

Características dos Sistemas Distribuídos

O mais importante é reconhecer as propriedades que caracterizam os sistemas
distribuídos e perceber as suas implicaçóes (características e desafios fundamentais).

Principais Características Distinticas dos Sistemas Distribuídos:

Máquinas autónomas;

Falhas independentes dos componentes;

Comunicação por troca de mensagens;

Ausência de relógio global;

Ausência de estado global do sistema;

Principais Desafios dos Sistemas Distribuídos

Heterogeneidade:
» Diverso, não uniforme;

Máquinas autónomas ligadas em rede -> Heterogeneidade:

» Um sistema distribuído é composto por máquinas autónomas , ou seja, não

podemos assumir que são todas iguais, ou sequer que são todas geridas pela mesma
entidade;

Principais fontes de diversidade que originam a heterogeneidade em

sistemas distribuídos
» Diferentes Sistemas Operativos;

» Diferentes tipos de computador;

» Diferentes tipos de rede;

» Componentes implementados em diferentes linguagens de programação;

» Implementações autónomas das componentes;

Quais são as implicações da heterogeneidade para o desenvolvimmento de sistemas
distribuídos?

Minimizar pressupostos sobre o ambiente de execução dos componentes do

sistema para que estes possam funcionar, se possível, em qualquer ambiente de
execução.

Mitigar problemas originando por pressupostos que cada componente pode ter
sobre o funcionamento dos outros componentes:

» Diferentes representações de dados, necessidade de versões dos

componentes para cada SO.

Técnicas habituais para lidar com desafios da heterogeneidade dos sitemas:

Middleware;

Tipos de dados comuns;

Protocolo de comunicação;

Máquinas virtuais, e.g. javascript ou java.

Sistemas Abertos
Um sistema aberto permite que novos componentes possam ser desenvolvidos e
acrescentados ao sistema por muitas entidades;

Um sistema aberto não tem de ser open source;

Um sistema aberto não é um sistema em qualquer pessoa pode entrar sem precisar
de conta.

Vantagens de sistemas que podem ser facilmente estendidos por qualquer entidade:

» Redução de custos;

» Efeito de rede gerado por cada nova entidade que implementa

componentes ou os utiliza;

» Concorrência entre fabricantes e inovação rápida;

» Maior escrutínio do funcionamento do sistema a nível de falhas e de

segurança;

Técnicas habituais para criar sistemas abertos:

Protocolos de interação entre componentes são públicos;

 Qualquer entidade pode desenvolver a sua própria implementação de
componentes do sistema;

Qualquer entidade pode associar novos componentes ao sistema.

Segurança
Num sistema distribuído existem riscos acrescidos em termos de segurança;

Comunicação entre componentes é feita por troca de mensagens;

Mensagens são transmitidas através de um canal de comunicação (a rede) que se

assume não ser seguro.

A comunicação através de um canal não seguro abre a porta para diversos tipos de
risco:

Alguém pode ver as mensagens trocadas entre A e B;

Alguém pode alterar as mensagens trocadas entre A e B;

Alguém se pode fazer passar por A ou B.

Serviços que permitem garantir segurança, usando um meio de comunicação que não
é seguro:

» Confidencialidade;

» Integridade;

» Autenticação;

» Não – repúdio;

» Garantia de disponibilidade (evitar denial-of-service);

» Segurança de código móvel.

Técnicas para lidar com os desafios de segurança:

» Diversas tecnologias de criptografia;

» Autoridades de certificação;
 » Protocolos que suportam serviços de segurança;

» Atualização e segurança do software;

» Políticas de segurança.

Escalabilidade
Um sistema escalável é um sistema que consegue manter um funcionamento
efetivo mesmo quando confrontado com aumentos muito grandes no nº de recursos e de
utilizadores.

Os sistemas distribuídos têm, à partida, um forte potencial para serem altamente

escaláveis, mas para isso precisam ser concebidos de modo a poderem lidar com os
desafios resultantes do aumento de escala do sistema.

Quais são ao certo os efeitos que um aumento muito significativo de escala pode ter
num sistema distribuído?

» Efeitos na robustez do sistema;

» Efeitos no desempenho do sistema;

» Efeitos administrativos;

» Efeitos de Heterogeneidade;

» Efeitos no utilizador.

Técnicas de Escalabilidade em Sistemas Distribuídos

» Distribuição de responsabilidades entre componentes;

» Replicação de componentes para distribuição de carga;

» Protocolos abertos;

» Gestão distribuída;

» Redução (nas formas de interação).

Tolerância a faltas
Um sistema distribuído é composto por múltiplos componentes, sendo expectável
que, ocasionalmente, possam ocorrer falhas em algum desses componentes.

Como num sistema distribuído os componentes estão em máquinas autónomas,

diz-se que as falhas dos componentes são independentes, ou seja, a falha de um
componente não está relacionada com potenciais falhas de outros componentes que, em
princípio, continuarão a funcionar.

Falta: Uma falha de um componente significa para o sistema uma falta (desse
componente).

Falha Parcial: Quando ocorre uma falta de um dos seus componentes, o sistema
entra em falha parcial se continuar operacional mas com as suas funcionalidades
afetadas.

Degradação graciosa: Manter as funcionalidades possíveis quando confrontado

com faltas que impeçam uma operação normal.

Falha do Sistema: Quando perante a falta de um ou mais componentes, o sistema

deixa de funcionar como um todo (ficou inoperacional ainda que alguns dos seus
componentes possam continuar operacionais).

Tolerância a faltas: Um sistema diz-se tolerante a faltas se, perante a falta de um

dos seus componentes, conseguir manter um funcionamento efetivo, ainda que parcial.

Ponto único de falha (ou ponto crítico): Componente que em caso de falha
implica a falha do todo o sistema distibuído, mesmo que os restantes components
continuem todos operacionais.

Os sistemas distribuídos têm à partida um forte potencial para serem altamente

tolerantes a faltas, desde que concebidos para lidar adequadamente com essas faltas.

Técnicas habituais para lidar com a falta de componentes:

Replicação;

Redundância;

Desenhar o sistema sem pontos únicos de falha.

Concorrência
Num sistema distribuído diferentes clientes podem querer aceder
concorrentemente a recursos partilhados (impressoras, documentos,...). Servidores têm
de gerir acesso a esses recursos de modo a evitar inconsistências.

Num sistema distribuído há sempre eventos relevantes a acontecer

concorrentemente nos vários processos que o compõem. É provável que nenhum dos
processos tenha uma visão global do estado atual do sistema.
 Técnicas habituais para suporte à concorrência

Servidores multi-threaded ou multi-processo.

Recursos partilhados com funções sincronizadas.

Princípios gerais de programação concorrente.

Modelos de consistência.

Transparência
Um desafio dos sistemas distribuídos é o custo da complexidade que resulta da
própria distribuição do sistema.

A transparência de um sistema distribuído traduz-se na capacdade de oferecer as

suas funcionalidades como um todo integrado, escondendo do utilizador ou aplicações os
detalhes da distribuição e separação dos seus componentes.

Permite beneficiar do potencial da distribuição sem necessidade de lidar com os

detalhes e complexidade que lhe são inerentes.
 Transparência é tornar invisíveis as complexidades do sistema que não sejam
relevantes para a execução de uma determinada tarefa.

» Transparência não é o sistema estar numa caixa transparente e portanto

todos os seus detalhes estarem sempre visíveis. É o oposto: são os detalhes que não
precisam de ser visíveis poderem ser ignorados e portanto transparentes ao
desenvolvimento ou à utilização do sistema.

Técnicas habituais:

» Organização por camadas e APIs de acesso.

Qualidade de Serviços
Para além dos desafios funcionais, um sistema distribuído também precisa de
responder adequadamente a nível de:

» Fiabilidade;

» Adaptabilidade;

» Desempenho;

» Disponibilidade de recursos.

Técnicas habituais para garantia de qualidade de serviço:

» Replicação de recursos;
 » Reserva de recursos;

» Comunicação com suporte para QoS;

» Service Level Agreement (SLA).

UT1: Objetivos pedagógicos (em que se podem basear as perguntas do

teste)
1.1) Explicar o Conceito de Sistemas Distribuídos, 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).
1.2) Identificar os principais desafios ao desenvolvimento de Sistemas Distribuídos
(nomeadamente Heterogeneidade, Sistemas abertos, Segurança, Escalabilidade,
Lidar com faltas, Concorrência, Transparência e Qualidade de Serviço) e, para cada
um deles, explicar o seu significado e as suas implicações para o
desenvolvimento de sistemas informáticos.
1.3) 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).

Modelos de Sistemas
UT2: Objetivos pedagógicos (em que se podem basear as perguntas do
teste)
1.1) 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;
1.2) Explicar por palavras próprias o modelo de programação distribuída peer-to-
peer (P2P) e as suas variantes, e.g. puro ou híbrido;
1.3) Analisar em que cenários o modelo cliente servidor ou P2P poderão ser a
solução mais adequada.
1.4) Explicar as abstrações representadas 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.
1.5) Explicar as relações causais e as razões pelas quais a coordenação entre
componentes não se pode basear em noções de tempo.
 Modelos de Sistemas
Sistemas distribuídos podem ser muito variados e diversos, mas há muitas
propriedades comuns que originam desafios semelhantes.

Modelos proporcionam uma forma simplificada e abstrata, mas também

consistente de representar aspetos comuns do funcionamento dos sistemas distribuídos.

Permitem pensar o concreto em termos de conceitos abstratos já bem conhecidos.

3 formas distintas, mas complementares, de pensar a organização e o

funcionamento de sistemas distribuídos:

Modelos físicos
Representam dispositivos concretos e as redes que os ligam.

Foco no hardware, mas abstraindo dos detalhes tecnológicos da rede ou dos

computadores envolvidos.

Modelos fortemente marcados pelas tendências tecnológicas.

Modelos arquiteturais
Descrevem o sistema na perspetiva das tarefas desempenhadas pelos seus
componentes e as interações entre esses componentes.

Num sistema distribuído a funcionalidade do sistema está repartida por várias

entidades:

» Quais são as entidades que comunicam entre si para formar o sistema

distribuído.

» Qual o paradigma de comunicação em que se baseia.

» Que papéis e responsabilidades é que cada componente tem na

arquitetura.

A arquitetura de sistema define a sua estrutura em termos de distribuição de

responsabilidade pelos componentes e as suas interligações.
 Paradigma de Comunicação Direta:

» Entidades comunicam diretamente entre si;

» Strongly coupled (tempo/ espaço partilhado);

» Modelos mais comuns: Cliente-servidor, P2P e código móvel.

Modelo Cliente Servidor

Servidores: Processos que oferecem serviços;

Clientes: Processos que requerem serviços.

Os servidores oferecem uma interface bem definida que é partilhada por todos os clientes;
Existe uma especificação de um protocolo de comunicação que define exatamente que
tipo de pedidos é que o servidor aceita e quais as respostas que deve gerar;

Os termos cliente e servidor correspondem aos papéis definidos à partida para cada um
dos componentes do sistema;

Um processo servidor pode ele próprio funcionar ocasionalmente como cliente de outros
serviços. Por exemplo, um servidor web pode consumir informação de outros serviços
para gerar as suas páginas.

Modelo Cliente-Servidor com Proxy

Proxy funciona como intermediário na interação cliente-servidor;

Aplicação mais comum é como cache permitindo diminuir a carga na rede e nos
servidores;

Também usado em firewalls.

Modelo Peer-to-Peer (P2P)

Semelhante ao cliente-servidor em quase tudo, a grande diferença é que não existem, à
partida, papéis diferenciados para os componentes;

Todos os elementos desempenham um papel semelhante e interagem de forma

cooperativa sem distinção entre clientes e servidores;

Qualquer componente pode ter a iniciativa de pedir serviços a qualquer outro.

Vantagens do sistema P2P:

Escalabilidade do sistema não é limitada pela capacidade de servidores;

Cada novo peer acrescenta capacidade;

Maior redundância pode permitir maior resiliência.

Desvantagens:

Maior dificuldade de controlo;

Dificuldade de encontrar peers obriga quase sempre a modelos híbridos que

combinam cliente-servidor com peer-to-peer.

Modelo Código Móvel

Cliente começa por transferir de um servidor o código que depois utilizará para
aceder às funcionalidades do serviço;

Após a transferência, o cliente efetua os pedidos diretamente no código transferido;

Exemplo: javascript e java applets.

Modelo de Objetos Distribuídos
Abstração de invocação remota aplicada a métodos de objetos.

Limitações da Comunicação Direta

Modelos de comunicação direta são os mais comuns em sistemas distribuídos,

mas algumas características podem fazer com que modelos diretos não sejam
necessariamente a melhor solução.

» Entidades trocam explicitamente mensagens entre si;

» Entidades têm de saber com quem estão a trocar mensagens (precisam de

se conhecer para poderem comunicar);

» Entidades têm de estar ambas ativas no momento de troca de mensagens.

Paradigma da Comunicação Indireta:

» Entidades comunicam através de intermediário;

 » Loosely coupled (tempo/ espaço esparados);

» Modelos mais comuns: Publish-subscriber, Message-Oriented Middleware

(MOM), Tuple Spaces.

Modelos de Comunicação Indireta:

Comunicação Indireta é um modelo em que a comunicação entre entidades de um

sistema distribuído se faz através de um intermediário.

Não precisa de existir uma relação direta entre emissor e recetores.

Podem existir múltiplos recetores para a mesma mensagem.

Comunicação de um para muitos é uma característica natural da comunicação

indireta.

Maior independência entre componentes, diminui pressupostos, permite maior

heterogeneidade nas implementações.

Separação no Espaço (Space Uncoupling)

Emissor não precisa de conhecer a identidade do recetor e vice-versa.

Entidade intermediária é que faz a mensagem chegar aos recetores adequados.

Proporciona grande capacidade de lidar com mudanças significativas nas entidades que
compõem o sistema distribuído.

Separação no Tempo (Time Uncoupling)

Emissor e recetor podem ter ciclos de vida distintos e não precisam de estar ativos
em simultâneo para poderem comunicar. Mensagem pode ser guardada pela entidade
intermediária e pode ser recuperada mais tarde.
Aplicações de Comunicação Indireta
Modelos da comunicação indireta são especialmente adequados nas situações
que:

» Seja expectável haver mudanças frequentes na composição, configuração

ou funcionamento do sistema;

» Exista forte mobilidade de componentes, que em função disso vão

aparecendo e desaparecendo;

» Exista informação para disseminar por um conjunto alargado e

potencialmente muito variável de destinatários;

» Exista necessidade de uma autoridade intermédia.

Modelos de Comunicação
Comunicação com grupos de Processos:

Suporte à replicação:

» Pode ser necessário que todas as réplicas recebam as mesmas

mensagens ou nenhuma recebe;

Descoberta de entidades na rede:

» Quem corresponder ao desejado pode mostrar-se respondendo por

unicast;
 Propagação de eventos:

» Entidades interessadas não precisam de ser conhecidas;

Comunicação em Grupo:

Emissor envia para o grupo, independentemente da atual lista de membros;

Processos podem entrar (join) para um grupo para receber as respetivas

mensagens.

Questões de Conceção e Implementação:

» Grupos de processos vs grupos de objetos;

» Grupos abertos vs fechados;

» Grupos sobrepostos vs não soprepostos;

» Robustez e ordem na comunicação;

» Gestão de membros do grupo.

Produtor-Subscritor

Subscritores registam interesse em receber determinadas mensagens;

Produtores enviam eventos estruturados para o sistema;

Eventos são enviados para subscritores interessados.

 Principais áreas de Aplicação:

» Live feeds de dados com vários consumidores;

» Sistemas colaborativos baseados na partilha de eventos;

» Sistemas de sensores e monitorização.

Message Queues

Produtores enviam para uma quele;

Receive bloqueia à espera que cheguem mensagens;

Poll devolve mensagem se existir, ou aviso de que não há mensagens;

 Notify avisa que existe mensagem para ler.

Message-Oriented Middleware (MOM)

Principal área de aplicação é na interoperabilidade entre sistemas

organizacionais;

Mensagens usam formatos normalizados para transportar os dados de

modo a serem independentes de vários sistemas;

MOM oferecem abstração, interoperabilidade, fiabilidade e persistência.

Exemplos: IBM, WebSphere MQ, Amazon SQS, RabbitMQ, JMS.

Modelos fundamentais
Abstrações para os problemas fundamentais de sistemas distribuídos.

Proporcionam soluções adequadas para problemas complexos.

Modelos simplificados do sistema que incluem apenas os conceitos necessários

para entender um determinado tipo de comportamento do sistema, e.g. segurança,
interação, falhas.

Conjunto de abstrações que nos permitem abordar problemas semelhantes com

soluções semelhantes:
 » Apresenta explicitamente os pressupostos fundamentais do sistema de
modo que as soluções e propriedades definidas para o modelo sejam aplicáveis a
qualquer sistema no qual esses pressupostos sejam válidos.

» Generalizam o que pode ou não ser feito, tendo em conta os pressupostos

identificados, e definindo propriedades ou algoritmos que permitam atingir determinados
comportamentos.

Modelo de Falhas
Faz uma especificação dos vários tipos de falhas potenciais e define os
requisitos de comunicação fiável;

Em sistemas reais, podem ocorrer falhas a vários níveis:

» Como modelar essas falhas?

» Como lidar com essas falhas?

O modelo de falhas define as formas como essas falhas podem ocorrer de

modo a proporcionar um entendimento mais claro dos efeitos dessas falhas.

Num sistema distribuído, as falhas podem ocorrer a nível dos processos e

dos canais de comunicação (buffer+rede).

Falhas por omissão: Um processo ou canal de comunicação não faz algo

que era suposto fazer.

» Exemplo: Canal de comunicação deixa de entregar no destino uma

mensagem que lhe foi entregue: ‘dropping messages’.

Falhas arbitrárias (ou bizantinas): Um processo ou canal envia valores

incorretos ou respostas erradas a pedidos
 » Exemplo: Canal de comunicação corrompe os dados de uma
mensagem;

» Exemplo: Servidor envia uma resposta incorreta.

Deteção de Falhas:

Falhas por omissão são facilmente detetáveis, mas pode ser difícil
identificar o ponto de falha;

Não se recebeu uma resposta a um pedido mas pode existir

muitas causas para isso, a nível dos processos, dos sistemas operativos ou dos canais de
comunicação.

Falhas arbitrárias são muito difíceis de detetar:

Fez-se um pedido, recebeu-se uma resposta. Como distinguir uma

resposta errada de uma resposta genuína?

Modelo de Segurança
Especifica os vários tipos de ameaças à comunicação e define o conceito de
canal seguro;
 Devido à sua inerente distribuição, os sistemas distribuídos estão expostos a
um nº potencialmente muito grande de riscos de segurança, por agentes internos
ou externos.

O modelo de segurança define as possíveis formas desses ataques e

proporciona uma base para a análise das ameaças e para a conceção de um
sistema capaz de resistir a essas mesmas ameaças.

Conceitos Chave:

Principal:

Entidade que pode ser identificada e cuja identidade pode ser

verificada através de um processo de autenticação.

Pessoas ou aplicações.

Inimigo:

Pode enviar qualquer mensagem para qualquer processo e ler

ou copiar qualquer mensagem entre um par de processos.

Representa uma ameaça para os processos e para os canais

de comunicação.

Pode fazer-se passar por um dos processos que legitimamente

fazem parte do sistema.

Um ataque pode ser realizado a partir de um computador que

faz legitimamente parte do sistema ou de um computador ligado de forma não
autorizada.
 Técnicas para Segurança:

Autenticação;

Criptografia;

Canais Seguros.

Modelo de Interação
Lida com as dificuldades em estabelecer limites de tempo na troca de
mensagens;

Algoritmos Distribuídos:

O comportamento de um algoritmo sequencial executado num único

processo é previsível em função dos inputs que recebe;

Num sistema distribuído o comportamento é o resultado de um

algoritmo distribuído, executado em partes por cada um dos processos pelos quais o
sistema é composto.

Mensagens são transmitidas entre processos para transferir

informações entre eles e coordenar a sua atividade;
 É difícil descrever o estado de um algoritmo distribuído, pois ele deve
lidar com as falhas de um ou mais dos processos envolvidos e com falhas ou atrasos na
transmissão de mensagens.

Duas variantes de modelos de interação:

Sistemas distribuídos síncronos, definem pressupostos sobre

tempo, como por exemplo limites para o tempo entre o envio e receção de mensagens
numa rede;

Sistema distribuídos assíncronos, não definem pressupostos sobre

tempo.

Sistemas distribuídos baseados na Internet têm de assumir um

paradigma de comunicação assíncrona.

Transmissor e recetor não têm relógios sincronizados:

Cada computador num sistema distribuído tem o seu próprio

relógio interno que é partilhado por todos os processos nessa mesma máquina.

Relógios tendem a desviar-se de um tempo exato (clock drift),

e fazem-no a um ritmo variável. Se 2 processos em máquinas distintas lerem
simultaneamente o tempo, irão obter resultados distintos.

Comunicação ocorre com atrasos variáveis e tempo de execução dos

processos também variável.

A velocidade com que um processo progride na sua execução e o

tempo de transmissão de uma mensagem entre processos não podem ser geralmente
previstos.

Existem fundamentalmente dois fatores que afetam os processos

num sistema distribuído:

O desempenho dos canais de comunicação entre processos;

Não é possível manter uma noção global de tempo.

Principais pressupostos do modelo de interação (assíncrono):

Reflete o facto de que a interação entre processos vai ser

afetada pelos atrasos nas mensagens, podendo originar problemas de sincronização;
 Mesmo quando não se considera a possibilidade de falhas de
comunicação, irão existir problemas de sincronização que envolvem coordenação
temporal;

Tempo não é um proxy perfeito para a ordenação de eventos a

nível do sistema como um todo.

Não Existe “Agora”: Apesar dos ambientes computacionais

serem normalmente descritos como virtuais, eles têm de funcionar no mundo físico, cujos
desafios não podem ignorar.

Normalmente, o que é verdadeiramente importante num sistema não é o

tempo absoluto em que os eventos acontecem, mas sim a ordem pela qual acontecem.

Independentemente de como é calculada a ordenação de eventos deve ser a

mesma em todo o sistema:

Tempo real vs Tempo Lógico;

Relação temporal vs Relação causal;

A relação causal significa que A ocorreu antes de B:

1) A e B são eventos no mesmo processo e A foi

observado antes de B;
2) A é um evento de envio de mensagem num
processo e B é o evento correspondente à chegada
dessa mensagem a outro processo;
3) Se A->B e B->C, então A->C, ou seja, a relação de
causalidade é transitiva;

A ideia que A pode ter causado B está implícita na relação

causal A->B, mas não tem de existir mesmo uma relação
direta entre ambos, apenas essa possibilidade.

Ordenação Causal
Ordenação de eventos não tem de corresponder à
ordem temporal, apenas se espera que sejam sempre a
mesma, coerentemente, em todo o sistema;
 Um algoritmo distribuído pode permitir ordenar eventos
que ocorrem em processos distintos;

Ordenação parcial é quando há eventos para os quais

se assume que não será possível estabelecer nenhuma
relação causal entre eles e, portanto, não será possível definir
a sua ordem;

Ordenação total é se as regras existentes permitirem

garantir a ordem de todos os eventos, ainda que por
convenção.

Algoritmos de Ordenação Causal

Relógios lógicos [Lamport]

Cada processo mantém um contador que é

incrementado a cada evento;

Ao enviar uma mensagem o valor do contador é

enviado também;

Ao receber uma mensagem (e antes de

incrementar o valor) o contador local é alterado de modo a
corresponder ao máximo de (contador local, contador na
mensagem).

Tottaly ordered logical clocks

 Inclui identificadores dos vários processos e
regras de ordenação em caso de não causalidade.

Vector clocks

Implica troca de vetor de contadores dos vários

processos.

Relógios lógicos como solução para ordenação de eventos sem

utilização de tempo.

Comunicação Remota entre Processos

UT3: Objetivos pedagógicos (em que se pode basear as perguntas do
teste)
1) Explicar por palavras próprias o conceito de organização por camadas utilizado
nos serviços de comunicações e as suas implicações para o desenvolvimento
de sistemas distribuídos ligados em rede.
2) Explicar por palavras próprias a interface para o serviço de comunicações
oferecido pelos sockets, seja na versão TCP, UDP ou Multicast.
3) Criar pequenas aplicações distribuídas cuja comunicação seja feita através do
uso direto do API sockets (trabalho prático).
4) Explicar por palavras próprias o significado e a necessidade da representação
externa de dados e dos respetivos processos de serialização.
5) Descrever os principais protocolos básicos pedido-resposta e as suas
implicações para a semântica das interações cliente-servidor.

Serviços de Comunicações
A comunicação entre processos é um dos principais pressupostos dos sistemas
distribuídos;

A possibilidade de comunicação assenta na existência de uma rede de

comunicações que interliga os componentes do sistema;

Sistemas operativos incluem as funcionalidades genéricas de suporte aos serviços

de comunicações;

Para acederem aos serviços de comunicações, os processos utilizam as respetivas

primitivas de acesso a disponibilizadas pelos sistemas operativos;
 Organização em Camadas
Software de comunicações é dividido em camadas:

Cada camada lida com um aspeto de comunicação e oferece serviços à

camada imediatamente acima;

A interface é definida pelo conjunto de operações e serviços que a camada

oferece;

Modularidade -> A implementação de uma camada pode ser facilmente

substituída;

Protocolos correspondem a um conjunto bem definido de regras e formatos

para serem usados na comunicação entre módulos ao mesmo nível.
 Modelo de Referência OSI

Serviços de Comunicações nos SO

Os sistemas operativos oferecem aos processos chamadas ao sistema (system
calls) para acesso aos seus serviços internos como gestão de processos, memória,
ficheiros, etc. e também para acesso aos serviços de comunicações;

Processos utilizam essas chamadas ao sistema para trocaram as mensagens que

necessitam de trocar para poderem operar como um sistema distribuído;

Primitivas básicas são send (enviar mensagem) e receive (receber mensagem).

Interface sockets nos SO

 Sockets
Abstração baseado no paradigma de troca de mensagens;

Um socket representa um ponto terminal na comunicação entre dois processos;

Fornece um API para o TCP e outro para o UDP;

Criado originalmente como API do BSD UNIX;

Disponível em quase todos os tipos de SO;

Ideia inspirada nos sockets dos sistemas de comutação telefónica com operador
humano;

Como endereçar processos

Para processos poderem comunicar entre si, têm de poder identificar qual o
processo a que uma mensagem se destina;

Utilizar um nome (ou número) de processo seria uma forma de endereçamento

explícita, mas pouco flexível:

» Uma alteração na identificação de um processo implícita a alteração de

todas as referências para esse processo.

Sockets utilizam um conceito de endereçamento implícito:

» Mensagens são endereçadas para o endereço de uma mailbox, designada

porta (ou porto numa tradução, mas literal do termo inglês: port)

Os processos referenciam-se implicitamente:

Send (A,message) – envia mensagem para porta A;

Receive (A,message) – retira uma mensagem da porta A;

Portas dos Sockets

Múltiplos processos podem enviar mensagens para a mesma porta;

Apenas pode existir um processo associado a cada porta:

» Porta onde mensagem chega determina processo que a vai receber;

Cada porta é identificada por um nº entre 1 e 65 535.

As portas 1 a 1023 (well-known ports) são reservadas a serviços comuns

» 25 SMTP, 110-POP, 80-HTTP, 20-FTP

 Cada porta está associada a um protocolo (TCP ou UDP):

» Mesmo nº pode estar a ser usado simultaneamente por protocolos TCP e

UDP (Porta 20 do UDP é diferente de Porta 20 do TCP).

Endereço dos Sockets

Uma ligação por sockets envolve 2 endereços IP e duas portas, uma em cada um
dos processos;

Porta usada por quem tem a iniciativa do contato (cliente) não é relevante;

Porta do servidor tem de ser pré-definida e conhecida dos clientes para que estes
possam iniciar o contacto com o servidor;

Sincronização no envio e receção de mensagens

Processos em comunicação precisam de sincronizar as suas trocas de informação:

Blocking send – emissor bloqueia até a mensagem ser recebida com

sucesso pelo recetor (primitiva síncrona);

Nonblocking send – emissor continua a sua execução logo após o envio da

mensagem (primitiva assíncrona);

Blocking receive - o processo recetor bloqueia até à chegada de uma

mensagem (primitiva síncrona);

Nonblocking receive – retorna imediatamente ao processo recetor caso

existam mensagens ou não (primitiva assíncrona)

Normalmente é utilizada o nonblocking send e o blocking send.

 Representação externa de dados
Um protocolo de comunicação especifica a sequência e o formato das mensagens
que os processos vão trocar entre si.

Os processos, durante a sua execução, utilizam diversas estruturas de dados que

são suportadas pelas linguagens de programação.

» Indicação de um tipo na instanciação das variáveis define a sua

representação interna, Objetos, Strings, Arrays, etc.

Os processos que compõe um sistema distribuído vão ter de trocar entre si alguma
da informação que consta nas suas estruturas de dados internas.

Têm de o fazer através da troca de mensagens pela rede.

Os serviços de rede apenas permitem a transmissão de sequências de bytes:

» Não é possível enviar diretamente representações correspondentes a

estruturas internas de dados como int, string ou objetos.

Para os dados poderem ser transferidos pela rede, as suas estruturas internas
precisam de ser transformadas em sequências de bytes e depois reconstruídas ao chegar
ao destino.

A representação externa de dados específica a forma como os processos

representam em bytes os dados que têm de enviar nas mensagens que vão trocar entre si.

Diferentes computadores ou linguagens de programação podem usar

representações internas de dados diferentes:

» Nº de bytes usado para representar a informação;

» Formato de representação, e.g. strings, floating point;

» Códigos de caracteres;

» Ordenação dos bytes: bing-endian, little-endian.

Não pode existir comunicação se cada componente usar a sua própria

representação interna.

Serialização/ Marshalling/ Coding:

» Transformar um conjunto de estruturas internas de dados numa sequência

de bytes adequada para transmissão pela rede.
 Desserialização/Unmarshalling/Decoding:

» Reconstruir as estruturas de dados a partir de uma sequência de bytes

transmitida por uma mensagem.

Estes processos podem ser feitos com código próprio, com bibliotecas ou de forma
transparente por software de middleware.

Processo é em tudo idêntico ao processo de guardar estruturas de dados em

ficheiros para posteriormente as recuperar.

Especificação byte a byte do formato de uma mensagem é uma estratégia que

permite eliminar ambiguidade.

Muito utilizada em protocolos de sistemas abertos que vão ser implementados de

muitas formas diferentes, por muitas entidades diferentes, e com um nº de operações pré-
definido.

Protocolo e representação são definidos em conjunto. Solução pouco flexível,

apenas adequada a protocolos muito genéricos.

A representação externa de dados é um formato comum de serialização de dados.

Permite a transferência de dados entre sistemas com representações internas

muito diversas.

Entidades que vão comunicar devem acordar previamente num formato externo a
utilizar por ambas.
 Normalmente os formatos não incluem informação sobre o tipo de dados; este terá
sido publicado na interface do serviço.

Exemplos:

» eXternal Data Representation (XDR);

» Corba Common Data Representation (CDR);

» JAVA Serialization formats;

» XML documents e schemas;

» JSON.

Exemplo XDR
Tipos de dados enviados são implícitos;

Em XDR os dados em formato externo não incluem a indicação do respetivo tipo de

dados;

Há o pressuposto que as entidades envolvidas na comunicação conhecem ambas

a ordem e o tipo dos dados a transferir (protocolo).

Exemplo: Argumentos de um método.

Tipos de dados XDR:

 Representação de Dados
Mensagem em CORBA CDR
Serialização de Objetos em JAVA

Objeto é uma instância de uma classe (com estado)

Objeto que implementa interface serializable significa que pode ser serializado:

» Apenas o estado é serializado;

» Assume-se que a classe existe no destino;

Argumentos passados em métodos remotos têm de ser serializable pois é como

sequências de bytes que irão ser transmitidos.

Para serializar um objeto pode-se escrever o objeto para uma stream, associada a
um socket ou a um ficheiro.

Referências podem ir mas objetos referidos tem de ser incluídos e referências tem
de ser transformados em handles internos.

Exemplo serialização

Exemplo de serialização (marshalling) em Java com base nas classes Stream

Exemplo de serialização inversa (unmarshalling) em Java com base nas classes Stream

Java assume que deve ser possível ler um objeto serializado em relação ao qual não se
conhece o tipo.

Formato de serialização inclui indicação de qual a classe que se encontra serializada.

Isto permite carregar a classe adequada.

Resumo
Processos usam variáveis que representam diversos tipos de dados e utilizam diversas
estruturas internas.

Comunicação por mensagens implica o envio de dados na forma de sequências de bytes.

Processos diferentes podem ter formas diferentes de representar como sequências de
bytes (formato serializado) o mesmo tipo de estrutura de dados (e.g. int, string, long, list)

Um tipo de dados que é enviado numa mensagem tem de poder ser corretamente
reconstruído do destino.

Um formato externo de representação de dados evita que essas diferenças na

representação de dados possam gerar interpretações incorretas das sequências de bytes
trocadas entre processos.

Modelos de Comunicação
Modelo cliente-servidor pressupõe uma troca de mensagens na qual cliente solicita
operação ao servidor.

Protocolo de comunicação especifica que mensagens devem ser enviadas e que

comportamento devem ter as entidades perante as várias situações que podem ocorrer.

Dependendo das necessidades concretas deve-se escolher um protocolo com as

propriedades adequadas.

Protocolos de Comunicação
Principais questões a considerar:

» Identificação das mensagens;

» Histórico das mensagens (e resultados);

» Modelos de falha:

» Semânticas de alto nível para lidar com falhas;

» Mensagens perdidas, trocadas, duplicadas;

» Falhas nos processos, Timeouts.

A semântica de invocação de uma operação remota corresponde aquilo que

consideramos ser verdade quando a invocação local não origina qualquer erro.

» Semântica “não é prometido nada”;

» Semântica “pelo menos uma vez”;

» Semântica “no máximo uma vez”;

» Semântica “exatamente uma vez”;

 Idempotência
Uma operação idempotente é uma operação que não provoca qualquer alteração no
estado do sistema se for invocada mais do que uma vez com os mesmos parâmetros de
entrada.

Uma operação idempotente pode ser executada mais do que uma vez sem que isso seja
fonte de problemas.

Protocolos de pedido-resposta
Independentemente das muitas especificidades dos muitos protocolos que existem, há 3
modelos fundamentais de protocolo de pedido-resposta.

Protocolo R (Request)

Não se espera resposta do servidor;

Não há necessidade de confirmação de execução pelo servidor;

Cliente envia mensagem e continua;

Semântica “não é prometido nada”;

Exemplo: Serviços de atualização periódica (heartbeat, sensos update,…)

Protocolo RR (Request/Reply)

É suposto servidor responder ao pedido;

 Resposta do servidor serve como confirmação da receção do pedido (implicit
acknowledgment);

Timeout determina falha no pedido e origina repetição do pedido para o servidor;

Semântica “pelo menos uma vez”;

Semântica “exatamente uma vez” se se filtrar os pedidos repetidos através de um id

de pedido.

Protocolo RRA (request/reply/acknowledged reply)

Cliente confirma explicitamente a correta receção da resposta do servidor;

Como mensagem ACK se pode perder, servidor tem de aplicar ordenação nos
pedidos para poder identificar ACKs fora de ordem ou usar ACK implícitos.

Não interfere nas semânticas de invocação, mas permite ao servidor confirmar que
pedido foi recebido e, portanto, pode ser fechado, libertando recursos que lhe estejam
associados.

Por exemplo, um pedido pode originar cálculos complexos e demorados que seria
pouco eficiente estar a repetir se por acaso a mensagem de resposta se perdesse.