Sistemas Distribuídos

(1)

Sistemas Distribuídos

Revisão de redes

Modelos e arquitecturas

12/13 Sistemas Distribuídos 1

Departamento de Engenharia Informática

Objectivo das aulas desta semana

• Rever o modelo de arquitectura das redes

• Rever a forma de programação distribuída

baseada em mensagens (aulas práticas)

• Compreender o modelo cliente-servidor e suas

evoluções

• Perceber as limitações do modelo de

programação baseado em mensagens e a

evolução para o RPC

Ca

(2)

Aplicações

Middleware

Sistema Operativo Bibliotecas (DLL) Protocolos Servidores Hardware Plataformas

Os Sistemas Distribuídos são suportados por diversas componentes frequentemente designadas por plataformas de Middleware

P la ta fo r m a s d e M id d le w a r e

Nova camadas de software

Middleware

A rede que interliga o

sistema distribuído

Revisão

(3)

Programação da comunicação: modelo

Processo

Canal de comunicação

porto

Processo

API da

comunicação

modo utilizador modo sistema

rede

porto

tr a n s p o rt e re d e ló g ic o fí s ic o 12/13 Sistemas Distribuídos 5

Redes de Dados

• Fornecer uma base mínima de compreensão

das redes de dados

– Arquitectura

– Organização

– Protocolos

• Identificar os aspectos relevantes das redes de

dados na concepção de sistemas distribuídos

Revisão

(4)

Características habituais das Arquitecturas

Físicas

•Redes de Larga Escala

–Transmissão ponto a

ponto

–Banda passante com

limitações mas

tecnologias tradicionais

–Topologia malhada

com redundância

–Necessidade de

encaminhamento

–Grande escalabilidade

–Menor tolerância a

faltas

•Redes Locais

–Transmissão em

difusão

–Largura de Banda

muito grande

–Topologias de bus ou

anel

–Encaminhamento

trivial

–Menor escalabilidade

–Maior tolerância a

faltas

Modelo OSI

(5)

Modelo OSI

Do nível físico ao nível transporte

Bus Anel (ring)

Malha (mesh)

Ethernet

ATM

Frame

Relay

GPRS

UMTS

Rede IP

Rede TCP

Processo Utilizador Processo Utilizador

• Funções: conseguir transmitir 1 bit de

informação sobre meio físico de interligação

– Velocidade de propagação, atenuação, imunidade ao ruído, etc.

• Nível Físico define:

– Níveis eléctricos do sinal, características temporais

– Protocolos de codificação, baseados no funcionamento da rede (taxa de erros, recuperação de relógio, …)

– Placas de interface (network cards) • Interface eléctrica

• Aspectos mecânicos dos conectores

Bus

Anel (ring)

Malha (mesh)

OSI - Nível Físico

(6)

• Funções: transmissão de pacotes, ou

tramas, entre máquinas ligadas à

mesma rede física

• Nível Lógico define:

– Delimitadores de trama – Endereço físico do destinatário – Multiplexagem do meio de

transmissão (emissor) – Detecção do endereço do

destinatário (receptor) – Definição da unidade básica de

informação (bit, octeto) – Recuperação de erros de transmissão – Controlo de fluxo

Ethernet

ATM

Frame

Relay

GPRS

UMTS

OSI - Nível Lógico ou

Ligação de Dados

OSI - Nível Rede

• Funções: interligar máquinas independentemente da rede física a que estão ligadas

• Uma rede lógica passa a ser composta pela interligação de várias redes físicas

• Nível Rede define:

– Formato dos pacotes de dados

– Mecanismos de encaminhamento entre redes

• Fundamental para redes malhadas

• Normalmente baseados em tabelas de encaminhamento

– Protocolo de rede OSI: X.25

• Com ligação, sequencialidade, controlo de fluxo

– Protocolo de rede Internet: IP

• Sem ligação nem garantias de qualidade

Rede IP

(7)

• Funções: oferecer um serviço de

transmissão de informação que permita

a comunicação entre utilizadores finais

• Características

– Com ou sem ligação – Comunicação fiável • Garantia de entrega • Garantia de ordem – Segmentação – Controlo de fluxo – Notificação de excepções na comunicação

Nível Transporte

Rede TCP

Processo Utilizador Processo Utilizador 12/13 Sistemas Distribuídos 15

A Internet como um Relógio de Areia

IP TCP / UDP

Ethernet GPRS 802.11 Satélite Bluetooth

Web Audio VoIP Web Services

Mail Video IM Difícil de alterar Passível de alterações Maior inovação 12/13 Sistemas Distribuídos 16

(8)

Interfaces de Comunicação

• Interacção baseada na troca de mensagens

• Facilidade de transporte para múltiplos sistemas

• Exploração das APIs normais de comunicação

• Tipicamente da API de transporte (sockets)

• Cada aplicação possui um

protocolo próprio

• Dificulta a utilização do

protocolo por terceiros

• Desempenho porque é

executado em modo utilizador

• telnet, rlogin,

Winrdp-aplicações de terminal

remoto

• ftp, samba – Transferência

de ficheiros

• SMTP – Correio electrónico

Exemplos

Problemas?

Interfaces de Comunicação

Máquina A

OS kernel

Níveis 7 a 5 Sockets, TLI Níveis 3 a 1 Níveis 3 a 1 Máquina B

OS kernel

Níveis 7 a 5 aplicação Sockets, TLI Níveis 3 a 1 Níveis 3 a 1 aplicação Nível 4 Transporte Nível 4 Transporte Nível 4 Transporte Nível 4 Transporte 12/13 Sistemas Distribuídos 18

(9)

Caracterização do canal de Comunicação

• Com ligação

– Normalmente serve 2 interlocutores

– Normalmente fiável, bidireccional e garante sequencialidade

• Sem ligação

– Normalmente serve mais de 2 interlocutores

– Normalmente não fiável: perdas, duplicação, reordenação

• Canal com capacidade de armazenamento em fila de Mensagens

– Normalmente com entrega fiável das mensagens

Tipos de canais

Portos – Extermidades do Canal de

Comunicação

• Portos

– São extremidades de canais de comunicação

• Em cada máquina são representados por objectos do

modelo computacional local

– Possuem 2 tipos de identificadores:

• O do objecto do modelo computacional

– Para ser usado na API pelos processos locais – Ex.: File descriptors, handles

• O do protocolo de transporte

– Para identificar a extremidade entre processos (ou máquinas) diferentes

– Ex.: Endereços TCP/IP, URL

(10)

Aula Prática – 1º Semana

Interface sockets

• Domínio do socket: define a família de protocolos

associada a um socket

– INET: família de protocolos Internet

– Unix: comunicação entre processos da mesma máquina

– Outros…

• Tipo do socket: define as características do canal de

comunicação

– Stream: canal com ligação, bidireccional, fiável, interface tipo

sequência de octetos

– Datagram: canal sem ligação, bidireccional, não fiável,

interface tipo mensagem

– Raw: permite o acesso directo aos níveis inferiores dos

protocolos (ex: IP na família Internet)

(11)

Sockets sem Ligação

socket socketsocket socket bind bindbind bind recvfrom recvfrom recvfrom recvfrom sendto sendto sendto sendto socket socket socket socket bind bindbind bind sendto sendto sendto sendto recvfrom recvfrom recvfrom recvfrom Cliente Servidor

Sockets UDP em Java (Cliente)

• import java.net*; • import java.io*; • public class UDPClient{

• public static void main(String args[]){

• // args give message contents and server hostname • DatagramSocket aSocket = null;

• try {

• aSocket = new DatagramSocket(); • byte [] m = args [0].getBytes();

• InetAddress aHost = InetAddress.getByName(args[1]); • Int serverPort = 6789;

• DatagramPacket request =

• new DatagramPacket(m, args[0].length(),

aHost, serverPort);

• aSocket.send(request);

• byte[]buffer = new byte[1000];

• DatagramPacket reply = new DatagramPacket(buffer, buffer.length);

• aSocket.receive(reply);

• System.out.println(“Reply:” + new String(reply.getData()));

• } catch (SocketException e){System.out.println(“Socket:” + e.getMessage());

• } catch (IOException e){System.out.println(“IO:” + e.getMessage());

• } finally { if(aSocket ! = null) aSocket.close();}

• }

Conversão do nome DNS para endereço IP Constrói um socket datagram

(associado a qualquer porto disponível)

Cada mensagem enviada tem que

levar junto identificador do processo destino:

(12)

Sockets UDP em Java (Servidor)

• import java.net*; • import java.io*; • public class UDPServer{

• public static void main(String args[]){ • DatagramSocket aSocket = null;

• try{

• aSocket = new DatagramSocket(6789); • byte[] buffer = new byte [1000]; • while(true){

• DatagramPacket request = new DatagramPacket(buffer, buffer.legth);

• aSocket.receive(request);

• DatagramPacket reply = new

DatagramPacket(request.getData(),

• request.getLength(); request.getAddress(), request.getPort());

• aSocket.send(reply);

• }

• } catch (SocketException e){System.outprintln(“Socket:”+ e.getMessage());

• } catch (IOException e){System.out.println(“IO:” + e.getMessage());

• } finally {if(aSocket ! = null) aSocket.close();}

• }

Constrói um socket datagram (associado ao porto 6789) Recebe mensagem Extrai da mensagem o IP e porto do processo origem para responder

Sockets com Ligação

socket bind listen socket connect accept read write read write Cliente Servidor Cliente Servidor Socket Cliente Socket Escuta Socket Ligação bytes bytes

(13)

• import java.net*; • import java.io*; • public class TCPClient{

• public static void main(String args[]){ • // args: message and destin. hostname • Socket s = null;

• try{

• int server Port = 7896;

• s = new Socket (args[1], serverPort);

• DataInputStream = new

DataInputStream(s.getInputStream());

• DataOutputStream out =

• newDataOutputStream (s.getOutputStream()); • out.writeUTF(args[0]);

• String data = in.readUTF();

• System.out.prtintln(“Received: ” + data); • }catch (UnknownHostException e){

• System.out.println(“Sock:” + e.getMessage()); • }catch (EOFException

e){System.out.println(“EOF:”e.getMessage()); • }catch (IOException

e){System.out.println(“IO:”e.getMessage());

• }finally {if(s!=null) try{s.close();}catch (IOException e}

• }

• classe Socket – suporta o socket cliente. Argumentos: nome DNS do servidor e o porto.

• Construtor não só cria o socket como efectua a ligação TCP

Métodos getInputStream / getOutputStream – permitem aceder aos dois streams definidos pelo socket WriteUTF / readUTF – para Universal transfer format / para as cadeias de caracteres

Sockets Stream em Java (Cliente)

• import java.net*; • import java.io*; • public class TCPServer{

• public static void main(String args[]){

• try{

• int server Port = 7896;

• ServerSocket listenSocket = new ServerSocket(serverPort);

• while(true){ • Socket connectionSocket = listenSocket.accept(); • myConnection c = new myConnection(connectionSocket); • }

• }catch (IOException e){System.out.println(“Listen:”

• +e.getMessage());}

• }

Bloqueia até cliente estabelecer ligação. Cria socket servidor que fica à

escuta no porto “serverPort”

Sockets Stream em Java (Servidor)

Cria novo socket servidor com quem é estabelecida ligação com o cliente e

(14)

Aula prática

• SocketClient.java

• SocketServer.java

Integração da Comunicação no Sistema

Operativo

(15)

Integração da Comunicação no Sistema

Operativo

• As aplicações invocam uma API que lhes permite aceder

ao mecanismos de transporte

• A API deve ser conceptualmente independente de uma

determinada pilha de protocolos de transporte

• Alternativas de implementação

– Funções de ES genéricas

• Ex: sockets – parcialmente

– Funções de comunicação específicas

• Ex: Algumas funções dos sockets • Ex: TLI

– Mecanismo básico de comunicação entre processos do sistema

operativo

• Ex: IPC dos micro-núcleos

Winsock Implementation

Application

Mswsock.dll

SPI

Service Providers

NtReadFile, NtWriteFile,

NtCreateFile,

NTDeviceloControlFile

Kernel mode

User mode

\Device\AFD

AFD FSD

TCP/IP

IPX/SPX

TDI IRPs

NetBEUI

TDI

Protocol drivers

Wshtcpip.dll Ntdll.dll

Msafd.dll

(16)

Três gerações de sistemas distribuídos

• Sistemas distribuídos iniciais

– Final da década de 70, início da década de 80

– 10-100 nós ligados por uma rede local, ligação limitada à internet – Poucos serviços oferecidos (partilha de ficheiros, impressoras, email)

• Sistemas à escala da Internet

– Década de 90

– Sistema global de larga escala, composto por redes de redes – Altamente heterogéneo

– Nós são essencialmente servidores e desktops

• Sistemas contemporâneos

– Inclui nós móveis (laptops, smart phones, etc)

– Inclui nós embebidos em “coisas” (e.g. máquinas de lavar, smart homes)

– Nós autónomos substituídos por grupos de nós que oferecem serviços na Cloud

Três gerações de sistemas distribuídos

(17)

Modelos arquitecturais

Quem são as entidades que comunicam

através da rede num sistema distribuído?

• Processos ou tarefas

• Nós

– Em alguns sistemas primitivos não existe a abstracção de

processo ou tarefa

– Exemplo: redes de sensores

• Objectos

– Exemplo: objecto Java invoca método de outro objecto remoto

– Veremos mais adiante na cadeira

• Web Services

– Veremos mais adiante na cadeira

• Componentes

– (Fora do âmbito da cadeira)

Por omissão, assumiremos

sistema distribuído de processos

(18)

Como comunicam estas entidades?

E

st

u

da

re

m

os

am

bos

e

m

br

ev

e

Comunicação directa

• Interface de comunicação entre-processos

• Invocação remota

– Protocolos de pedido-resposta

• Exemplo: HTTP

– Chamada remota de procedimentos

• Programador define conjunto de procedimentos que servidor oferece

• Cliente pode invocar esses procedimentos como se tratassem de chamadas locais

– Invocação remota de métodos

• Semelhante a chamada remota de procedimentos, mas no mundo OO

(19)

Comunicação directa

Exemplo: chamada remota de procedimentos

CLIENTE SERVIDOR

Cliente bloqueado Bloqueia-se

Chamada ao procedimento remoto:

envio dos parâmetros

Execução do procedimento

pedido

Retoma a execução

Retorno do procedimento remoto:

devolução dos resultados

Sistemas Distribuídos 2009/10

Comunicação directa

Exemplo: invocação remota de métodos

• As potencialidades da noção de objecto tornaram-na

atractiva para descrever diversos conceitos em Eng.

Informática

– dando origem a uma tendência de evolução que se designa por

OO de Object Oriented

• Diferenças entre a aproximação baseada em objectos e

uma arquitectura cliente-servidor:

– No RPC invocam-se funções, os dados são entidades separadas

– Num sistema de objectos invoca-se uma função num

determinado objecto que, como contém o seu próprio estado,

torna indissociável a invocação da operação dos dados a que

se aplica

(20)

m4 m5 m6 Interface Remota m1 m2 m3 Código dos métodos Dados

Objecto remoto

Comunicação directa

Exemplo: invocação remota de métodos

• Exemplos de Plataformas

– RMI do Java

– DCOM – Distributed Component Object Model - Microsoft

– Common Object Request Broker Architecture (CORBA) - Object Management Group (OMG)

Comunicação indirecta

• Em comunicação directa, em geral:

– Emissor tem de conhecer receptor

– Emissor e receptor têm de existir simultaneamente

• Paradigmas de comunicação indirecta

introduzem terceira entidade para permitir:

– Desacoplamento espacial

• Emissor de mensagem não precisa conhecer receptor(es)

– Desacoplamento temporal

• Emissor e receptor não têm de existir simultaneamente

(21)

Comunicação indirecta: paradigmas

• Comunicação em grupo

– Suporte a comunicação um-para-muitos

– Emissor envia mensagem a um identificador de grupo

• Não precisa saber quem são os membros do grupo

• Sistemas publicador/subscritor (publish-subscribe)

– Publicadores emitem mensagens (chamadas eventos)

– Subscritores registam-se e expressam interesse em

determinados eventos

– Cada mensagem publicada é disseminada aos subscritores

interessados

Comunicação indirecta: paradigmas

• Filas de mensagens

– Troca de mensagens ponto-a-ponto em que há desacoplamento espacial/temporal

– Emissor coloca mensagem em fila (mantida por um servidor central -broker), receptor retira mensagem de uma fila

– As mensagens recebidas pelo broker podem ser reformatadas, combinadas ou modificas por forma a serem entendidas pelo sistema de destino

– Normalmente não é necessário modificar os sistemas envolvidos. Os Message Brokers fornecem adaptadores para as aplicações mais comuns (SAP, Baan, PeopleSoft, etc.).

(22)

Comunicação indirecta: paradigmas

• Partilha de memória distribuída

– Permitem que processos que não partilham

memória física escrevam e leiam estruturas de

dados em memória distribuída

– Sistema mantém cópias locais da memória

partilhada e sincroniza alterações através de troca

de mensagens

• Tudo transparentemente à aplicação

– Variante recente deste paradigma: espaços de

tuplos

Papéis e responsabilidades

(23)

Modelo Cliente-Servidor

• Servidores mantêm recursos e servem pedidos de operações sobre

esses recursos

• Servidores podem ser clientes de outros servidores

• Simples e permite distribuir sistemas centralizados muito

directamente

• Mas pouco escalável: limitado pela capacidade do servidor e pela

rede que o liga aos clientes

Server Client Client invocation result Server invocation result Process: Key: Computer: 12/13 Sistemas Distribuídos 58

Modelo Entre-Pares (Peer-to-Peer)

• Todos os processos têm

papéis semelhantes, sem

distinção entre clientes e

servidores

• Mais ampla distribuição

de carga (computação e

rede)

– Maior escalabilidade – Sistema expande-se acrescentando mais pares

• Coordenação mais

complicada que

cliente-servidor

Application Application Application Peer 1 Peer 2 Peer 3 Peers 5 .... N Sharable objects Application Peer 4 12/13 Sistemas Distribuídos 59

(24)

Entre-Pares (Peer-to-Peer)

Como mapear objectos e serviços no

modelo físico?

(25)

Serviço Oferecido por Múltiplos Servidores

• Distribui carga do

servidor por múltiplos

servidores

• Duas opções:

– Particionamento: cada

servidor mantém uma

partição do conjunto

de objectos

– Replicação: todos os

servidores mantêm

réplicas do mesmo

conjunto de objectos

Server Server Server Service Client Client 12/13 Sistemas Distribuídos 62

Serviço Oferecido por Múltiplos Servidores

(26)

Servidores Proxy e Caches

• Mantêm cópias de sub-conjunto dos objectos num

computador mais próximo dos clientes

• Melhor desempenho e disponibilidade

• Outros objectivos: por exemplo, acesso ao exterior

através de firewall

Client Proxy Web server Web server server Client 12/13 Sistemas Distribuídos 64

Servidores Proxy e Caches

(27)

Código Móvel (Applets)

• Parte do código do servidor é transferido para o cliente e

executado localmente

• Execução não sofre com atrasos de rede e variações de largura de

banda

• Bom desempenho de aplicações interactivas

a) client request results in the downloading of applet code Web server

Client Applet _serverWeb Applet code

Client

b) client interacts with the applet

Código Móvel (Applets)

(28)

Agentes móveis

• Programa em execução (código+dados) que viaja de um

computador para outro na rede

• Executa alguma tarefa em nome de alguém

• Em cada computador, invoca serviços locais (e.g. acesso

a BD local para consultar informação local)

• Comparado com a solução de ter um cliente remoto a

invocar os mesmos serviços remotamente:

– Menor custo e tempo de comunicação

Modelos fundamentais

(29)

Modelos fundamentais

• Explicitam quais são as entidades e características

essenciais de um sistema

• Permitem-nos:

– Generalizar o o que é possível e impossível resolver nesse

modelo (por provas matemáticas

– Desenhar soluções mais facilmente, pois não pensamos nos

detalhes de hardware, etc

– Provar matematicamente propriedades das nossas soluções

• fiabilidade, desempenho, escalabilidade, segurança

– Determinar facilmente se determinada solução funciona num

sistema em particular

• basta verificar se os pressupostos do modelo usado para a solução se verificam no sistema em particular

Modelos fundamentais

• Logo, antes de desenhar qualquer solução, é

muito boa prática definir os modelos

fundamentais!

• Três modelos fundamentais:

– Modelo de interacção

– Modelo de faltas

– Modelo de segurança

(30)

Modelo de Interacção

• Pressupostos sobre o canal de comunicação?

– Latência, que inclui:

• Tempo de espera até ter acesso à rede + • Tempo de transmissão da mensagem pela rede +

• Tempo de processamento gasto em processamento local para enviar e receber a mensagem

– Largura de banda

• Quantidade de informação que pode ser transmitida simultaneamente pela rede

– Jitter

• Que variação no tempo de entrega de uma mensagem é possível?

– Canal assegura ordem de mensagens?

– Mensagem pode chegar repetida?

• E sobre os relógios locais?

– Taxa com que cada relógio local se

desvia do tempo absoluto

Mais à frente no semestre, analisaremos modelos de interacção em maior detalhe