RESUMAO ARQUITETURA E SISTEMAS DISTRIBUIDOS

Prévia do material em texto

1.) INTRODUÇÃO AOS SISTEMAS DISTRIBUIDOS Pontos: 0,5 / 0,5 
Quanto aos modelos de sistemas distribuídos, encontramos os Sistemas de Computação em 
Grade , que caracterizam-se por: 
R) recursos de diferentes organizações são reunidos para permitir a colaboração de um grupo 
de pessoas sob a forma de uma organização virtual. 
 
 
 
 
2.) CONCEITOS BÁSICOS; SISTEMAS DISTRIBUÍDOS Pontos: 1,0 / 1,0 
Sobre o processamento paralelo e distribuído, assinale a afirmação correta 
R) A computação paralela é caracterizada pelo uso de vários processadores para executar 
uma computação de forma mais rápida, baseando-se no fato de que o processo de resolução 
de um problema pode ser dividido em tarefas menores, que podem ser realizadas 
simultaneamente através de algum tipo de coordenação. 
 
 
3.) CLASSIFICAÇÃO DE FLYNN Pontos: 0,5 / 0,5 
Assinale abaixo a frase que melhor explica o conceito da "Classificação de Flynn" 
R) Classifica os sistemas de acordo com a forma como acontecem os fluxos de dados e os 
fluxos de instrução 
 
 
 
 
4.) COMPONENTES Pontos: 0,0 / 1,0 
A denominação SMP refere-se tanto à arquitetura de hardware do computador quanto ao 
comportamento do sistema operacional que reflete esta arquitetura. Um SMP é um sistema de 
computador independente sobre o qual é INCORRETO afirmar que 
R) para resolver o problema de coerência de cache, utiliza um único cache para todos os 
processadores e adota a política de escrita direta onde as operações de escrita são 
usualmente efetuadas apenas sobre a cache, sendo a memória principal atualizada somente 
quando a linha correspondente é removida da cache. 
 
 
 
 
5.) MIDDLEWARE Pontos: 1,0 / 1,0 
O objetivo de uma camada de Middleware em um sistema multicamadas é: 
R) disponibilizar classes utilitárias e serviços independentes de plataforma que permitam a 
obtenção de computação distribuída em ambientes heterogêneos. 
 
 
6.) ARQUITETURA CLIENTE-SERVIDOR Pontos: 1,0 / 1,0 
Sobre a arquitetura cliente-servidor, analise as seguintes afirmativas: 
1. A maior capacidade de processamento encontra-se geralmente no lado cliente. 
2. No contexto da Internet, os navegadores Web são exemplos de programas servidores de 
páginas HTML. 
3. O protocolo HTTP é uma das formas de comunicação entre clientes e servidores. 
Assinale a alternativa correta: 
R) Apenas as afirmativas 1 e 2 são falsas. 
 
 
7.) SISTEMAS DISTRIBUIDOS Pontos: 0,5 / 0,5 
O tipo clustering de um sistema operacional distribuído no qual somente um dos seus nós 
esteja trabalhando, enquanto os outros entram como reserva, denomina-se cluster de 
R) alta disponibilidade. 
 
 
8.) CARACTERÍSTICAS DOS SISTEMAS DISTRIBUÍDOS Pontos: 0,0 / 1,0 
Sabendo que tolerância a falhas significa que um sistema pode prover seus serviços mesmo na 
presença de falhas, ou seja, o sistema pode tolerar falhas e continuar funcionando 
normalmente. Com base nessa definição assinale Verdadeiro ou Falso nas afirmações a 
seguir. 
R) V - As definições para falha, erro e defeito, respectivamente são: Falha: estão associadas 
ao universo físico, Erros : estão associadas ao universo da Informação e Defeitos: estão 
associadas ao universo do usuário 
F - A classificação de falhas em relação à sua persistência são: Física, de projeto e de 
interação 
V - A classificação de falhas em relação à sua persistência são: transiente, intermitente e 
permanente 
V - Podemos classificar redundância como: redundância da informação, redundância de tempo 
e redundância física. 
V - As definições para falha, erro e defeito, respectivamente são: Falha: estão associadas às 
falhas originadas pelo usuário, Erros: estão associadas aos erros do hardware e Defeitos: 
estão associadas ao universo da Informação 
 
 
 
 
9.) CARACTERÍSITICAS DOS SISTEMAS DISTRIBUÍDOS Pontos: 0,5 / 0,5 
Podemos definir sistema distribuído como uma coleção de computadores independentes que 
aparecem para os usuários do sistema como um único computador. De acordo com esta 
definição analise as afirmativas a seguir e assinale a alternativa INCORRETA. 
R) Concorrência: significa que recursos locais e remotos são acessados pelas mesmas 
operações 
 
 
 
 
10.) GRIG - COMPUTAÇÃO EM GRADE Pontos: 0,0 / 1,0 
Analise as seguintes afirmações sobre a computação em grade (grid): 
I. Toda colaboração é realizada sob a forma de uma organização virtual. 
II. A camada de conectividade deve compreender protocolos para a autenticação de usuários e 
recursos. 
III. Os sistemas computacionais envolvidos têm um alto grau de heterogeneidade. 
Assinale a opção correta. 
R) As afirmações I, II e III são verdadeiras. 
 
 
 
 
 
 
 
 A interface entre um programa aplicativo e os protocolos de comunicação em um sitema 
operacional é conhecida como Interface de Aplicativos, ou API. A API de sockets é um padrão 
de facto. 
A comunicação realizada a partir da utilização de sockets é um mecanismo de comunicação 
entre processos – Inter Process Comunication (IPC) – através da rede, que pode ser utilizado 
em processos na mesma máquina. 
Os protocolos de comunicação geralmente não especificam a API que as aplicações devem 
utilizar. Ao contrário disso, os protocolos especificam quais são as operações que devem ser 
fornecidas e permitem que cada sistema operacional defina a API específica wur uma 
aplicação deve usar para executar suas operações. 
A API de sockets originou-se como parte do sistema operacional BSD UNIX. Tanto neste 
quanto nos sistemas que dele derivam, as funções de sockets são parte do próprio sistema 
operacional. 
Para um programador, seu programa chama procedimentos de sockets, que são, então, 
providos por procedimentos do sistema operacional ou por rotinas de biblioteca. 
Desse modo, um aplicativo que usa sockets pode ser copiado para um novo computador 
compilado, carregado junto com a biblioteca de sockets do computador, e então, executado. 
Originalmente, os sockets foram desenvolvidos como parte do sistema operacional UNIX e 
utilizam diversos conceitos que são implementados em outras partes desse sistema. 
Um programa vê os sockets como um mecanismo de entrada e saída de dados, pois eles 
seguem o paradigma open-read-write-close, usado pela maioria das operações de entrada e 
saída. 
Sendo assim, um socket deve ser criado, usado e, só então, destruído. Por isso, quando uma 
aplicação se comunica através de uma rotina similar ao socket, forma um caminho para a 
aplicação transferir dados a um arquivo. Dessa forma, a compreensão dos sockets exige o 
entendimento das características de entrada e saída do UNIX. 
 Por exemplo, um aplicativo deve primeiro chamar open para preparar um arquivo para acesso. 
O aplicativo chama, então, read ou write para recuperar ou armazenar dados no arquivo. 
Finalmente, o aplicativo chama close para especificar que terminou de usar o arquivo. 
A comunicação através de sockets utiliza também a abordagem de descritor. Quando a 
aplicação solicitar ao sistema operacional para criar um socket, o aplicativo passará o descritor 
como um argumento para a chamada de procedimentos na transferência de dados através da 
rede. 
O sistema operacional fornece um único conjunto de descritores para arquivos, dispositivos, 
comunicação entre processos e comunicação de rede. Como resultado, procedimentos como 
read e write são bem gerais - uma aplicação pode usar o mesmo procedimento para enviar 
dados para outro programa ou um arquivo atravésde uma rede. 
Em terminologia corrente, o descritor representa um objeto e o procedimento write, o método 
aplicado aquele objeto. 
A programação por socket difere da entrada e saida convencional de dados porque um 
aplicativo deve especificar diversos detalhes para utilizar um socket. 
Por exemplo, um aplicativo deve escolher um protocolo de transporte em particular, fornecer o 
endereço de protocolo de uma máquina remota e especificar se o aplicativo é cliente ou 
servidor. 
Para acomodar todos os detalhes, cada socket tem diversos parâmetros e opções - um 
aplicativo pode fornecer valores para cada um deles. 
Para evitar que exista uma única função de socket com argumentos separados para cada 
opção, os desenvolvedores das APIs de sockets definiram diversas funções. Essencialmente, 
um aplicativo cria um socket e, então, invoca funções para especificar, em detalhes, como ele 
será usado 
A vantagem da abordagem de sockets respalda-se no fato de que a maioria das funções tem 
três ou menos argumentos. 
A desvantagem, por sua vez, indica que um programador deve lembrar-se de chamar múltiplas 
funções sockets. 
Conheça, agora, os procedimentos que implementam a API de sockets: 
 
Procedimento Socket: cria um socket e retorna um descritor inteiro. Conheça o procedimento 
socket: 
sockfd = socket (protofamily, type, protocol); 
 
Procedimento bind: Uma vez que tenha um socket, você deve associá-lo a uma porta em sua 
máquina. Um servidor usa o procedimento bind para prover um número de porta de protocolo 
em que o servidor esperará por contato. 
bind (sockfd, localaddr, addrlen); 
 
Procedimento connect: os clientes usam o procedimento connect para estabelecer uma 
conexão com um servidor específico: connect (sockfd, saddress, saddresslen); 
 
Procedimento Listen: Depois de especificar uma porta de protocolo, o servdor deve instruir o 
sitema operacional para colocar um socket em modo passivo, para que este possa ser usado 
para esperar pelo contato de clientes: listen(sockfd, backlog); 
 
Procedimento Accept: Os servidores iniciam-se chamando socket (criar) e bind (especificar 
número de porta). Após executar as duas chamadas, o servidor que usa um protolo de 
transporte sem conexão está pronto para aceitar mensagens. No caso de o servidor utilizar um 
protocolo de transporte orientado a conexão, é necessário chamar o procedimento listen para 
colocar o socket em modo passivo, para só então aceitar uma conexão. 
Accept (sockfd, caddress, caddresslen); 
 
Procedimentos send, sendto e sendmsg: Os cliente e servidores precisam enviar 
informações. Geralmente, um cliente envía uma requisição e um servidor envia uma resposta. 
Se o socket está conectado, o procedimento send pode ser usado para transferir dados: send 
(sockfd, data, length, flags); 
O procedimento sendto e sendmsg permite que o cliente ou servidor envie uma mensagem 
usando um socket não conectado, mas ambos exigem que um destino especificado. O sendto 
possui o endereço de destino como argumento. 
sendto (sockfd, data, length, flags, destaddress, addresslen); 
sendmsg (sockfd, msgstruct, flags) 
 
Procedimento recv, recvfrom e recvmsg: O cliente e o servidor precisam receber dados 
enviados pelo outro. Para tal, a API de sockets fornece vários procedimentos que podem ser 
usados. Por exemplo, um aplicativo pode chamar recv para receber dados de um socket 
conectado. 
recv (sockfd, buffer, length, flags) 
recvfrom (sockfd, buffer, length, flags, sndraddr, sddrlen) 
recvmsg (sockfd, msgstruct, flags) 
 
Procedimento close: informa ao sistema para finalizar o uso do socket: 
close (sockfd); 
 
Comunicação UDP: socket, bind, recvfrom, sendto, close. 
Comunicação TCP: socket, bind, listen, accept, recv, send, close. 
 
Chamada de Procedimento Remoto (RPC): Além das tarefas habituais, o programador que 
constrói qualquer aplicação cliente-servidor deve, também, lidar com os detalhes complexos de 
comunicação. 
Mesmo que muitas das funções necessárias sejam fornecidas por uma API padrão (como a 
interface de socket, por exemplo), é necessário que sejam especificados os nomes, os 
endereços, os protocolos e as portas, entre outros detalhes. 
O ponto positivo é que muitos sistemas cliente-servidor seguem uma mesma lógica de 
arquitetura básica e usam a API de sockets para comunicação. 
 As similaridades entre as aplicações permitiram que um conjunto de ferramentas de software 
fosse criado para gerar, automaticamente, o código para muitas das tarefas de comunicação, 
deixando o programador livre para se concentrar em partes da programação que não podem 
ser automatizadas. 
 
Paradigma de chamada remota de procedimento – Remote Procedure Call (RPC) 
Muitos sistemas distribuídos são baseados em troca explícita de mensagens entre processos. 
Contudo, os procedimentos send e receive não escondem absolutamente nada da 
comunicação, o que é importante para obter transparência de acesso em sistemas distribuídos. 
Esse problema é conhecido há muito tempo, mas pouco tinha sido feito para resolvê-lo, até que 
um artigo de autoria de Birrell e Nelson (1984) propôs um modo completamente diferente de 
manipular a comunicação. A proposta foi permitir que programas fossem capazes de chamar 
procedimentos localizados em outras CPUs. 
Quando um processo em uma máquina chama um procedimento em uma máquina remota, o 
processo chamador (cliente) é suspenso, e a execução do procedimento chamado (servidor) 
ocorre na máquina remota. 
 A informação pode ser transportada, nos parâmetros, do cliente para o servidor e pode voltar 
no resultado do procedimento. Nenhuma troca de mensagem ou entrada e saída é visível ao 
programador e tem servido de base a muitos softwares para multicomputadores. 
Em sua forma mais simples, para chamar um procedimento remoto, o programa cliente deve 
ser ligado a um pequeno procedimento de biblioteca chamado de stub do cliente, que 
representa o procedimento servidor no espaço de endereçamento do cliente. Da mesma 
maneira, o servidor é ligado a um procedimento denominado stub do servidor. 
Esses procedimentos escondem o fato de uma chamada de procedimento do cliente para o 
servidor não ser local. 
 
São componentes da RPC: 
CLIENTE: Faz a chamada com o sistema remoto 
STUB DO CLIENTE: Faz a interface com o runtime system (esconde chamadas de baixo nível 
da aplicação) 
RPC RUNTIME: Comunicação entre dois computadores, que esconde os detalhes da 
comunicação de rede, retransmissões e comunicações, etc. 
SERVIDOR: Faz o atendimento a requisição 
STUB DO SERVIDOR: Faz o mesmo que o stub do cliente. 
 
Tratamento de falhas com RPC: 
O cliente não é capaz de localizar o servidor: isso ocorre devido a uma falha de hardware e 
em função de o servidor não estar efetivamente disponível. O tratamento específico desse erro 
elimina a transparência; 
Perda de mensagem solicitando serviço: nesse caso, devemos usar um contador de tempo; 
se o tempo expirar e a resposta não chegar, retransmita a mensagem 
Perda de mensagem com resposta: o que torna a mensagem idempotente 
Quedas do servidor: definir semântica - mínimo uma vez que garante que a chamada remota 
ao procedimento será executada no mínimo uma vez ou no máximo uma vez que garante que 
a chamada remota foi executada no máximo uma única vez. 
Queda do cliente: trata-se da situação em que o cliente manda uma requisição e, antes de 
receber a resposta, sai do ar. Essa situação causa dois problemas: a geração de processos 
órfãos (zombie) e o tempo de CPU gasto desnecessariamente pelo servidor. 
 
Em relação à RPC, a localização física e a arquitetura do servidor são TRANSPARENTES. 
 
1.Em relação à comunicação utilizando RPC, podemos afirmar que: 
Assinale a opção CORRETA. 
I – A troca de informações é realizada através de parâmetros da chamada. 
III – Clientes chamam procedimentos remotos como se fossem locais. 
IV – A localização física e a arquitetura do servidor são transparentes. 
2. De acordo com a nossa aula, quando tratamos da comunicação utilizando sockets, qual é o 
procedimento que associa uma porta ao socket? 
Assinale a opção CORRETA 
4) Bind 
 
3. Em relação à comunicação por sockets o procedimento close possui a seguinte função: 
2) Encerra o socket ou a conexão 
 
O modelo de comunicação Peer-to-Peer (P2P) é implementado em uma rede de computadores 
cuja comunicação não está baseada em servidores dedicados – como no modelo cliente-
servidor –, e sim na comunicação direta entre cada nó da rede (peers). 
Cada computador conectado tem a capacidade de atuar como servidor – realizando tarefas 
para outros usuários da rede – ou como cliente – requisitando a realização dessas tarefas. 
 Na comunicação P2P, indivíduos que constituem um grupo livre podem comunicar-se com 
outros participantes do grupo. Em princípio, toda pessoa pode se comunicar com uma ou mais 
pessoas – não existe qualquer divisão estrita entre clientes e servidores. 
 Diversos sistemas P2P – como o BitTorrent (COHEN, 2003) – não possuem qualquer 
informação centralizada. Ao contrário, esses sistemas mantêm suas informações locais e 
compartilham uma lista dos peers vizinhos que os compõem. 
 Quando uma nova consulta é realizada a um membro do sistema, é possível retornar com os 
nomes de seus outros membros, para que a busca por mais conteúdo e mais nomes seja 
possível. Esse processo de pesquisa pode ser repetido indefinidamente, até que se crie um 
grande banco de dados. 
Normalmente, a comunicação P2P é usada para compartilhar diferentes tipos de arquivos. 
Essa comunicação alcançou o auge por volta do ano 2000, com a criação do Napster por 
Shawn Fanning para o compartilhamento de músicas entre amigos da faculdade. 
Esse serviço foi encerrado depois daquilo que, provavelmente, foi a maior exposição sobre a 
violação de direitos autorais em toda a história da tecnologia. 
 
 
REDES P2P: Há uma grande dificuldade em montar uma rede de entrega de conteúdo – 
Content Delivery Networks (CDN) – de 1000 nós no mundo inteiro para distribui-lo. 
 
Na verdade, não é difícil alugar 1000 máquinas virtuais no mundo inteiro, devido à indústria de 
hospedagem bem desenvolvida e altamente competitiva. Entretanto, conseguir os nós é só o 
início da montagem de uma CDN. 
 
Mas, felizmente, existe uma alternativa para o restante de nós, que é simples de usar e pode 
distribuir uma quantidade tremenda de conteúdo com uma rede P2P. 
 
A tecnologia P2P pode ser usada de diversas maneiras. Com seu desenvolvimento e grande 
interesse por parte dos usuários, o tráfego P2P tornou-se, rapidamente, responsável por uma 
grande fração de todo o tráfego na internet. 
Comunicação P2P: As redes P2P são autoescaláveis, e sua capacidade de upload útil cresce 
em conjunto com as demandas de download que podem ser feitas por seus usuários. Em certo 
sentido, essas redes sempre são grandes o suficiente, sem a necessidade de alguma 
infraestrutura dedicada. Ao contrário disso, a capacidade até mesmo de um site Web grande é 
fixa e será ora muito grande ora muito pequena. 
Considere, por exemplo, um site com apenas 100 clusters, cada um capaz de trabalhar a 10 
Gbps. Essa capacidade enorme não ajuda quando existe um pequeno número de usuários. O 
site não pode receber informações de N usuários em uma taxa mais rápida que N Mbps, pois o 
limite está nos usuários, e NÃO no site. 
 
Quando existe mais de 1.000.000 de usuários a 1 Mbps, o site Web não pode bombear dados 
com rapidez suficiente para manter todos ocupados fazendo download. Esse pode parecer um 
número considerável de usuários, mas grandes redes BitTorrent (como, por exemplo, o Pirate 
Bay) afirmam ter mais de 10 milhões de usuários. De acordo com essa abordagem, isso 
significa algo em torno de 10 terabits/s. 
Bittorrent: O protocolo BitTorrent foi desenvolvido por Brahm Cohen, em 2001, para permitir 
que um conjunto de peers compartilhasse arquivos rápida e facilmente. Existem dezenas de 
clientes disponíveis gratuitamente que entendem esse protocolo. 
 Em um sistema P2P típico, como o BitTorrent, cada um dos usuários tem a mesma 
informação, que pode ser de interesse de outros usuários. Essa informação pode ser um 
software gratuito, uma música, vídeos, fotografias etc. 
 Existem três problemas que precisam ser resolvidos para compartilhar o conteúdo nesse 
ambiente. Veja, a seguir, cada um deles. 
O surgimento dos sistemas P2P: O surgimento das redes de compartilhamento de arquivos 
P2P motivou a comunidade de pesquisa. A essência dos sistemas P2P está no fato de que 
evitam as estruturas gerenciadas, de forma central, das CDNs e de outros sistemas. Essa pode 
ser uma vantagem significativa. 
 Quando o sistema fica muito grande, os componentes gerenciados de forma central tornam-se 
um gargalo e correspondem a um ponto de falha isolado. Contudo, os primeiros sistemas P2P 
eram apenas parcialmente descentralizados – se fossem totalmente descentralizados, seriam 
ineficazes. 
Distributed Hash Tables (DHTs): Criar um índice de posse de cada um é simples, mas é 
centralizado. Fazer com que cada par mantenha seu próprio índice também não soluciona o 
problema. Entretanto, exige bastante trabalho para manter atualizados os índices de todos os 
peers – pois o conteúdo é movimentado pelo sistema –, o que não compensa o esforço. 
 A principal questão a ser respondida pela comunidade de pesquisa foi: seria possível criar 
índices P2P que fossem totalmente distribuídos, mas que possibilitassem um bom 
desempenho? 
O bom desempenho pode ser interpretado da seguinte forma: Cada nó mantém apenas uma 
pequena quantidade de informação sobre outros nós, o que significa que não será caro manter 
o índice atualizado. 
 Cada nó pode pesquisar, rapidamente, entradas no índice. Caso contrário, esse não será um 
índice muito útil. 
 Cada nó pode usar o índice ao mesmo tempo, ainda que outros nós apareçam e 
desapareçam. Essa propriedade indica que o desempenho do índice aumenta com o número 
de nós. 
 
A resposta para essa pergunta foi SIM. Para tal, foram desenvolvidas, em 2001, quatro 
soluções. São elas: 
Chord (STOICA et al., 2001); 
Can (RATNASAMY et al., 2001); 
Pastry (ROWSTRON; DRUSCHEL, 2001); 
Tapestry (ZHAO et al., 2004). 
 Essas soluções são conhecidas como Distributed Hash Tables (DHTs), pois a funcionalidade 
básica de um índice é mapear uma chave a um valor. Isso representa uma tabela de hash, e, 
naturalmente, as soluções são versões distribuídas. 
 
As DHTs realizam seu trabalho impondo uma estrutura regular sobre a comunicação entre os 
nós. Esse comportamento é muito diferente daquele das redes P2P tradicionais, que usam 
quaisquer conexões que os peers façam. 
 
Por esse motivo, as DHTs são chamadas de redes P2P estruturadas. Os protocolos P2P 
tradicionais montam redes P2P desestruturadas (ou não estruturadas). 
 
Como exemplo, utilizaremos a solução DHT Chord. Vamos conhecê-la? 
Pensando em um cenário, considere como substituir o tracker centralizado tradicionalmente – 
usado no BitTorrent – por um tracker totalmente distribuído. A solução DHT Chord pode ser 
usada para resolver esse problema. 
Nesse cenário, o índice geral é uma listagem de todos os swarms aos quais o computador 
pode-se juntar para baixar conteúdo. A chave usada para pesquisar o índice é a descrição do 
conteúdo pela torrent. Ela identificaum swarm exclusivamente, do qual o conteúdo pode ser 
baixado como os hashes de todos os chunks de conteúdo. 
O valor armazenado no índice para cada chave é a lista de peers que compreendem o swarm. 
Esses peers são os computadores que entram em contato para baixar o conteúdo. Uma 
pessoa que espera baixar conteúdo (como um filme, por exemplo) tem apenas a descrição da 
torrent. 
A pergunta que a DHT precisa responder é: como, sem um banco de dados central, uma 
pessoa descobre de quais peers (entre os milhões de nós BitTorrent) ela deve copiar o 
conteúdo? 
Uma DHT Chord consiste em N nós participantes. Eles são nós que executam BitTorrent em 
nosso cenário. Cada nó tem um endereço IP pelo qual pode ser comunicado. 
O índice geral está espalhado pelos nós. Isso significa que cada um armazena bits e pedaços 
do índice para uso por outros. A parte central da Chord navega pelo índice usando 
identificadores em um espaço virtual, e não os endereços IP dos nós ou os nomes de 
conteúdo. 
 
Para transformar um endereço de nó em um identificador, ele é mapeado para um número de 
M bits, usando uma função de hash. Sendo assim, podemos usá-lo para converter qualquer 
endereço IP em um número de 160 bits – chamado de identificador de nó. 
 
Solução DHT Chord - Chave 
Uma chave também é produzida pela execução do hashing de um nome de conteúdo com 
hash para gerar um número de 160 bits (nome = torrent). Sendo assim, para converter o 
arquivo de descrição de torrent para sua chave, calculamos: chave = hash(torrent). 
Para iniciar um novo swarm, um nó precisa inserir um novo par chave-valor, que consiste no 
índice (torrent, meu-endereço-IP). Para conseguir isso, o nó pede ao sucessor – hash(torrent) – 
para armazenar meu-endereço-IP. Desse modo, o índice é distribuído pelos nós 
aleatoriamente. 
Com a DHT construída, quando outro nó desejar encontrar uma torrent de modo a se juntar ao 
swarm e baixar o conteúdo, um nó pesquisará a torrent primeiro, calculando seu hash para 
obter a chave. Depois, esse nó usará o sucessor(chave) para encontrar o endereço IP do nó 
que armazena o valor correspondente. 
 
Solução DHT Chord IP: Para possibilitar a localização do endereço IP do nó correspondente a 
certa chave, cada nó precisa manter determinadas estruturas de dados administrativas. Uma 
delas é o endereço IP de seu nó sucessor junto ao anel identificador de nó. Por exemplo, na 
apresentada anteriormente, o sucessor do nó 4 é 7, e o sucessor do nó 7 é 12. 
Agora, a pesquisa pode prosseguir da seguinte forma: 
 
O nó solicitante envia um pacote a seu sucessor, contendo seu endereço IP e a chave que está 
procurando. O pacote é propagado pelo anel até que localize o sucessor do identificador de nó 
procurado. Esse nó verifica se possui qualquer informação que combine com a chave; caso 
haja, ele retorna a informação diretamente ao nó solicitante, cujo endereço IP possui. 
 Entretanto, a busca linear de todos os nós é ineficaz com um grande sistema P2P, pois o 
número médio de nós exigido por consulta é N/2. Para agilizar a busca, cada nó também 
mantém o que a Chord chama de tabela de fingers, que contém M entradas, indexadas de 0 
até M - l, cada uma apontando para um nó real diferente. 
Visto que os nós entram e saem o tempo todo, o DHT Chord precisa de uma forma de lidar 
com essas operações. Assumimos que, quando o sistema iniciou sua operação, ele era 
pequeno o suficiente para que os nós pudessem apenas trocar informações diretamente para 
criar o primeiro anel e tabelas de fingers. 
 Depois disso, um procedimento automatizado é necessário. 
Quando um novo nó (r) deseja-se conectar, ele precisa entrar em contato com um nó existente 
e pedir que este pesquise o endereço IP do sucessor(r) para ele. Em seguida, o novo nó pede 
o predecessor do sucessor(r). Por fim, o novo nó pede a ambos para inserir r entre eles e o 
anel. 
Contudo, muitas tabelas de fingers podem estar erradas. Para corrigi-las, cada nó executa um 
processo em segundo plano que recalcula, periodicamente, cada finger, chamando o sucessor. 
Quando uma dessas consultas alcança um novo nó, a entrada de finger correspondente é 
atualizada. 
Quando um nó sai de modo controlado, ele entrega suas chaves a seu sucessor e informa a 
seu predecessor sobre sua saída, para que ele possa se vincular ao sucessor do nó que está 
saindo. 
Quando um nó falha, surge um problema, pois seu predecessor não tem mais um sucessor 
válido. Para aliviar esse problema, cada nó registra não apenas seu sucessor direto mas 
também seus sucessores diretos, para permitir que ele pule até s - l nós consecutivos (com 
falhas) e reconecte o anel – em caso de queda 
Alguns clientes BitTorrent utilizam DHTs para fornecer um tracker totalmente distribuído do tipo 
que descrevemos. Grandes serviços de computação em nuvem, como o Dynamo da Amazon, 
por exemplo, também incorporam técnicas de DHT 
1. O arquivo torrent possui os seguintes tipos de informação: 
5) Tracker e chunks 
2. O servidor que auxilia a comunicação entre dois computadores que utilizam o protocolo P2P 
BitTorrent é: 
3) Tracker 
3. A aplicação P2P que utiliza servidores centrais para a indexação de arquivos é: 
1) Emule 
 
Os sistemas de arquivos distribuidos (DFS) sao a vase para muitas aplicações distribuidas, 
já que permitem que vários processos compartilhem dados, de modo seguro e confiável, por 
longos pedíodos. 
Um sistema de arquivos fornece serviços de arquivo para clientes. O componente primário de 
hardware que um servidor de arquivos controla é um conjunto de dispositivos locais de 
armazenamento secundário (geralmente, dicos magnéticos), nos quais arquivos são 
armazenados e recuperados, de acordo com as solicitações dos clientes. Em um DFS, a 
atividade de serviço deve ser realizada através da rede- 
Esse sistema pode ser implementado como parte de um sistema operacional distribuido ou 
alternativamente por uma camada de software, cua tarefa é gerenciar a comunicação entre 
sistemas operacioais e convencionais e sistemas de arquivo. 
As características que diferenciam um DFS são a multiplicidade e a autonomia de clientes e 
servidores no sistema. 
 
Funções DFS: O DFS deve aparecer para seus clientes como um sistema de arquivos 
convencional centralizado. Portanto, é de sua responsabilidade localizar os arquivos e 
providenciar o transporte dos dados. 
Essa transparência facilita a mobilidade do usuário, trazendo seu ambiente para onde quer que 
ele se conecte. 
O referido sistema também possui, como importante medida de desempenho, a quantidade de 
tempo necessária para o atendimento das requisições de serviço. 
Em sistemas convencionais, esse tempo consiste no tempo de acesso ao disco e em um 
pequeno intervalo de tempo de processamento da CPU. 
Entretanto, em um DFS, um acesso remoto possui o overhead adicional atribuído à estrutura 
distribuída. 
Por fim, o DFS gerencia um conjunto de dispositivos de armazenamento dispersos. 
Um DFS fornece os seguintes serviços: 
Serviço de Armazenamento: Serviço relacionado à alocação e ao gerenciamento de espaço e 
operações para armazenamento e recuperação de dados. 
Serviço de Arquivo: Serviço que trata das operações com arquivos independentes, incluindo: 
- Modos de acesso; 
- Políticas de caching; 
- Semântica de compartilhamento; 
- Replicação; 
- Controle de concorrência; 
- Consistência dos dados etc. 
Serviço de Nomeação: Serviço que fornece mapeamento entre nomes de arquivos e seus 
identificadores. 
 
Nomeação e transparência 
Em DFS, a nomeação é um mapeamento entre objetos lógicos e físicos. Já a transparência 
oculta o local em que o arquivo está localizado na rede. 
Dado um nome de arquivo,o mapeamento retorna um conjunto de localizações dessas réplicas 
do arquivo. 
Nessa abstração, ficam ocultas tanto a existência de múltiplas cópias quanto sua localização. 
 
Estruturas de Nomeação 
Veja, a seguir, as noções relacionadas aos mapeamentos de nomes em um DFS: 
Transparência de localização – nesse caso, o nome de um arquivo não revela qualquer 
indicação de sua localização física de armazenamento; 
Independência de localização – nesse caso, o nome de um arquivo não precisa ser alterado 
quando da mudança de sua localização física de armazenamento. 
Um esquema de nomeação independente de localização é um mapeamento dinâmico, já que 
se pode mapear o mesmo nome de arquivo para diferentes locais em dois momentos distintos. 
Portanto, a independência de localização é uma propriedade mais forte do que a transparência 
de localização. 
Na prática, a maioria dos DFS atuais fornece um mapeamento estático e transparente de 
localização para nomes no nível do usuário. Entretanto, esses sistemas não suportam a 
migração de arquivos. Em outras palavras, a mudança automática da localização de um 
arquivo é impossível. Portanto, a noção de independência de localização é irrelevante para 
esses sistemas. 
Os arquivos são associados permanentemente a um conjunto específico de blocos de disco. 
Arquivos e discos podem ser manualmente movimentados entre máquinas, mas a migração de 
arquivos implica uma ação automática iniciada pelo sistema operacional. 
 
Esquemas de Nomeação 
Abordagem mais simples 
Nesse tipo de abordagem, o arquivo é identificado com alguma combinação de seu nome de 
host e seu nome local, o que garante um nome exclusivo em todo o sistema. 
Esse esquema de nomeação não é transparente quanto à localização nem independente de 
localização. Entretanto, as mesmas operações de arquivo podem ser utilizadas tanto para 
arquivos locais quanto para arquivos remotos. 
Abordagem popularizada pelo Network File System (NFS) 
O NFS fornece um meio de anexar diretórios remotos a diretórios locais, dando, assim, a 
aparência de uma árvore de diretórios coerente. 
Abordagem de única estrutura global de nomes 
Nesta abordagem, uma única estrutura global de nomes abrange todos os arquivos do sistema. 
A estrutura de sistema de arquivos composta é igual à estrutura de um sistema de arquivos 
convencional. Entretanto, na prática, os diversos arquivos especiais tornam esse objetivo difícil 
de ser atingido. 
 
 
Modelos de acesso 
A forma como uma requisição será tratada dependerá do modelo de acesso do sistema de 
arquivos que será dado aos arquivos. 
Em um DFS, dois modelos de acesso podem ser utilizados: 
Modelo de serviço remoto: um usuário solicira acesso a um arquivo remoto, o servidor 
armazena o arquivo será localizado pelo esquema de nomeação, e então, realizará a 
transferência dos dados. Uma das maneiras mais comuns para implementar o serviço remoto é 
o paradihma da RPC. 
Modelo de Caching: Se os dados necessários para atender à solicitação de acesso ainda não 
estiverem armazenados em cache, uma cópia desses dados do servidor será trazida para o 
sistema cliente. Dessa forma, seus acessos serão executados na cópia do cache. A ideia é 
reter no cache blocos de disco recentemente acessados, de modo que acessos repetidos às 
mesmas informações possam ser manipulados localmente, sem tráfego de rede adicional. 
 Os arquivos ainda são identificados com uma cópia-mestra – residindo na máquina do 
servidor e mais cópias (ou partes) do arquivo disseminadas em diferentes caches. Quando 
uma cópia do cache for modificada, as mudanças precisarão se refletir na cópia-mestra para 
preservar a semântica de consistência relevante. 
A granularidade dos dados do cache de um DFS pode variar de blocos de um arquivo a um 
arquivo inteiro. 
 
Comparação entre armazenamento em cache e serviço remoto 
Quando o armazenamento em cache é utilizado, o cache local pode manipular eficientemente 
um número substancial dos acessos remotos. 
O aproveitamento da localidade nos padrões do acesso a arquivos torna o armazenamento em 
cache ainda mais atraente. 
A maioria dos acessos remotos será atendida tão rapidamente quanto os acessos locais. Além 
disso, os servidores são contatados apenas ocasionalmente. Consequentemente, a carga no 
servidor e o tráfego na rede são reduzidos, e a possibilidade para a escalabilidade aumenta. 
 
Por outro lado, quando o método de serviço remoto é utilizado, cada acesso remoto é 
manipulado através da rede. O prejuízo é associado ao aumento de tráfego na rede, à carga no 
servidor e à redução no desempenho. 
Quando transmitimos grandes porções de dados (conforme é feito no armazenamento em 
cache), o overhead total da rede é mais baixo do que quando transmitimos séries de respostas 
a solicitações específicas (como no método de serviço remoto). 
Além disso, as rotinas de acesso a disco no servidor podem ser mais otimizadas quando 
sabemos que as solicitações envolverão sempre grandes segmentos de dados contíguos – em 
vez de blocos aleatórios de disco. 
 
O problema da consistência do cache é a principal desvantagem do armazenamento em cache. 
Quando os padrões de acesso exibem gravações não frequentes, o armazenamento em cache 
é superior. 
Entretanto, quando as gravações são frequentes, os mecanismos empregados para resolver o 
problema da consistência incorrem em overhead significativo em termos de desempenho, 
tráfego na rede e carga no servidor. 
Para que o armazenamento em cache traga benefícios, a execução deve ser levada a efeito 
em máquinas que tenham discos locais ou memórias principais de grande capacidade. O 
acesso remoto em máquinas com memória de pouca capacidade e sem discos deve ser 
realizado por meio do método de serviço remoto. 
 
No armazenamento em cache, como os dados são transferidos em massa entre o servidor e o 
cliente – em vez de em resposta às necessidades específicas de uma operação de arquivo -, a 
interface de mais baixo nível entre máquinas é diferente da interface de mais alto nível do 
usuário. 
Por outro lado, o modelo do serviço remoto é apenas uma extensão da interface local do 
sistema de arquivos através da rede. Sendo assim, a interface entre máquinas espelha a 
interface do usuário. 
 
Stateful (serviço com estado) versus stateless (serviço sem estado) 
Existem duas abordagens para o armazenamento de informações no lado do servidor, quando 
um cliente acessa arquivos remotos, quais sejam: 
 
 O servidor busca cada arquivo que estiver sendo acessado pelo cliente; ou 
 O servidor simplesmente fornece blocos conforme são solicitados pelo cliente, sem saber 
como esses blocos estão sendo utilizados. 
No primeiro caso, o serviço fornecido tem estado (stateful); no outro, o serviço não tem estado 
(stateless). 
 
Stateful (serviço com estado): No serviço de arquivos com estado, um cliente deve executar 
uma operação open () sobre um arquivo antes de acessá-lo. O servidor, então, extrai 
informações sobre o arquivo em seu disco, armazena essas informações em memória e 
fornece ao cliente um identificador de conexão único para o cliente e o arquivo aberto. 
Em termos do UNIX, o servidor extrai o I-node e fornece ao cliente um descritor de arquivo, que 
serve como um índice para a tabela de inodes em memória. 
No stateful, o servidor deve reclamar o espaço de memória principal utilizado pelos clientes que 
não estão mais ativos. 
O ponto chave relacionado à tolerância a falhas em uma abordagem de serviço com estado é 
que o servidor mantém informações sobre seus clientes na memória principal. 
 
Stateless (serviço sem estado): O serviço de arquivos sem estado evita informaçõesde 
estado, tornando cada solicitação autossuficiente. Em outras palavras, cada solicitação 
identifica completamente o arquivo e sua posição no arquivo (para acessos de leitura e 
gravação). 
No stateless, o servidor não precisa manter uma tabela de arquivos abertos na memória 
principal. Além disso, não há necessidade de estabelecer e terminar uma conexão por 
operações open () e close (). 
Um processo-cliente abre um arquivo, e essa abertura não resulta no envio de uma mensagem 
remota. 
Leituras e gravações são realizadas como mensagens remotas (ou consultas ao cache). O 
fechamento final pelo cliente, por sua vez, resulta novamente em apenas uma operação local. 
 
Vantagens e distinção entre satateful e stateless 
VANTAGENS: A vantagem de um serviço com estado sobre um serviço sem estado é o 
aumento do desempenho. Informações de arquivo são armazenadas em cache na memória 
principal e podem ser facilmente acessadas via identificador de conexão, evitando, assim, 
acessos ao disco. 
Além disso, um servidor com estado sabe se um arquivo está aberto para acesso sequencial e 
pode, portanto, ler os próximos blocos à frente. Servidores sem estado não podem fazer isso, 
pois não conhecem o objetivo das solicitações do cliente. 
 
DISTINÇÃO: distinção entre stateful e stateless torna-se mais evidente quando consideramos 
os efeitos de uma queda durante uma atividade de serviço. Nessa situação, um servidor com 
estado perde todos os seus estados voláteis. 
A garantia de recuperação sem prejuízo desse servidor implica a restauração de seu estado, 
normalmente realizada por um protocolo de recuperação baseado em um diálogo com os 
clientes. 
 
STATEFULL: Do ponto de vista do cliente, não há diferença entre um servidor lento e um 
servidor em recuperação. Se não receber resposta, o cliente continuará a retransmitir sua 
solicitação. 
Em alguns ambientes, o stateful é uma necessidade. Se o servidor empregar o método iniciado 
para validação do cache, não poderá oferecer serviço sem estado, pois deverá manter um 
registro dos arquivos que foram armazenados em cache e dos clientes que os armazenaram. 
STATELESS: Um problema diferente é causado por falhas dos clientes. O servidor precisa 
tornar-se consciente dessas falhas, de modo que possa reclamar o espaço alocado para 
registrar o estado dos processos-clientes que falharam. 
 
O stateless evita esses problemas, pois um servidor recentemente recuperado pode responder 
a uma solicitação autossuficiente sem qualquer dificuldade. Portanto, os efeitos de falhas e de 
recuperações do servidor são quase imperceptíveis. 
 
Replicação de arquivos 
Replicação Explícita: Quando a responsabilidade fica a cargo do programador. Nesse caso, o 
serviço de diretórios pode permitir diversos índices de arquivos para cada arquivo. 
Esse tipo de replicação é de difícil implementação e não permite a aplicação da transparência. 
Replicação Atrasada (lasy): Quando apenas uma cópia é realizada em um servidor. Nesse 
caso, o servidor possui a responsabilidade de propagar as atualizações e de garantir que outro 
servidor responda no caso de sua impossibilidade. 
Replicação em grupos: Quando a operação de escrita é realizada em todos os arquivos ao 
mesmo tempo (multicast atômico). 
 
SEMÂNTICA DE COMPARTILHAMENTO 
Na semântica Unix, as alterações são visíveis instantaneamente. 
Em sistemas de um único processador, normalmente, a semântica declara que, quando uma 
operação read vem depois de uma operação write, aquela retorna o valor que acabou de ser 
escrito. Veja, a seguir, uma figura que representa uma semântica Unix: 
De maneira semelhante, quando duas operações write ocorrem em rápida sucessão, seguidas 
por uma read, o valor lido é o valor armazenado pela última write. Na verdade, o sistema impõe 
uma ordenação de tempo absoluto a todas as operações e sempre retorna o valor mais 
recente. 
Em um sistema distribuído, a semântica Unix pode ser alcançada com facilidade, contanto que 
haja somente um servidor de arquivos e que os clientes não os armazenem. 
Todas as operações read e write vão diretamente para o servidor de arquivos, que as processa 
estritamente em sequência. Essa abordagem gera a semântica Unix, exceto pelo pequeno 
problema de que atrasos de rede podem fazer com que uma read que ocorreu em um 
microssegundo após uma write chegue antes ao servidor e, por isso, obtenha o valor antigo. 
 
SEMÂNTICA DE SESSÃO: Em vez de requerer que uma read veja os efeitos de todas as 
operações write anteriores, podemos estabelecer uma nova regra em que: As alterações em 
um arquivo aberto sejam incialmente visíveis apenas para o processo, que modificou a 
maquina. As alterações devem ficar visíveis para outros processos ou máquinas, somente 
quando o arquivo for fechado. 
 
Arquivos Imutáveis: 
Um um sistema distribuído, uma abordagem completamente diferente da semântica de 
compartilhamento de arquivos é tornar imutáveis todos eles. 
 Dessa forma, não existe nenhum modo de abrir um arquivo para escrita. Na verdade, as 
únicas operações em arquivos são create e read. 
 O que se permite é criar um arquivo inteiramente novo e passá-lo para o sistema de diretório 
sob o nome de um arquivo previamente existente, que, agora, se tornará inacessível (ao 
menos sob esse nome). 
 Por isso, embora seja impossível modificar o arquivo específico, continua possível substituir, 
atomicamente, esse arquivo por um novo. Em outras palavras, embora arquivos não possam 
ser atualizados, os diretórios podem. 
Uma vez decidido que os arquivos não podem ser alterados de jeito algum, o problema de 
como lidar com dois processos – como escrever em um arquivo e ler esse arquivo – 
simplesmente desaparece, o que simplifica, consideravelmente, o projeto. 
 
Resta, então, o problema que ocorre quando dois processos tentam substituir o mesmo arquivo 
simultaneamente. Como acontece com a semântica de sessão, a melhor solução para esse 
caso seria permitir que um dos novos arquivos substituísse o antigo – seja este o último, seja a 
substituição não determinística. 
Um problema um pouco mais desagradável diz respeito a como prosseguir se um arquivo for 
substituído enquanto outro processo estiver ocupado, lendo esse mesmo arquivo. 
Uma solução é dar um jeito de o processo leitor continuar usando o arquivo antigo, mesmo que 
este não esteja mais em nenhum diretório, comparado ao modo como o Unix permite a um 
processo que tenha um arquivo aberto continuar a usá-lo, mesmo depois de esse arquivo ter 
sido apagado de todos os diretórios. 
Outra solução é detectar se o arquivo foi alterado e fazer com que as tentativas subsequentes 
de ler esse arquivo falhem. 
 
Network File System (NFS) : O padrão NFS mais recente é a Versão 4 que difere 
fundamentalmente das versões anteriores. Essa versão apresenta uma mudança significativa, 
em que o protocolo tem estado, o que significa que o servidor mantém o estado da sessão do 
cliente do momento em que o arquivo remoto é aberto até que ele seja fechado. 
Sendo assim, o protocolo NFS fornece operações open() e close(). As versões anteriores do 
NFS – que não têm estado – não fornecem tais operações. 
Além disso, as versões anteriores especificam protocolos separados para a montagem de 
sistemas de arquivos remotos e para o trancamento (lookup) desses arquivos. Em particular, o 
protocolo de montagem foi eliminado, permitindo que o NFS funcionasse com firewalls de rede. 
 
A Versão 4 do NFS aprimorou a capacidade de os clientes armazenarem em cache local os 
dados dos arquivos, melhorando o desempenho do DFS, já que os clientes são capazes de 
resolver mais acessos a arquivos a partir do cache local do que passando pelo servidor.Outro benefício dessa versão permite que os clientes solicitem locks de arquivos aos 
servidores. Se o servidor atender à solicitação, o cliente manterá o lock até que ele seja 
liberado ou que sua concessão expire. 
 
Tradicionalmente, os sistemas baseados no Unix oferecem trancamento aconselhável de 
arquivos, enquanto os sistemas operacionais Windows utilizam o trancamento obrigatório. 
Para permitir que o NFS funcione bem com sistemas não Unix, ele também fornece 
trancamento obrigatório. 
Os novos mecanismos de trancamento e armazenamento em cache são baseados no conceito 
de delegação. O cliente delegado mantém em cache a versão corrente do arquivo, e outros 
clientes podem solicitar a ele o acesso ao lock e o conteúdo do arquivo, até que o cliente 
delegado desista do lock e da delegação. 
 
Finalmente, enquanto as versões anteriores do NFS são baseadas no protocolo de rede UDP, 
a Versão 4 é baseada no TCP, que permite melhor adaptação a cargas variadas de tráfego na 
rede. A delegação dessas responsabilidades aos clientes reduz a carga no servidor e melhora 
a coerência do cache. 
É desejável ocultar os detalhes de replicação dos usuários. O mapeamento de um nome de 
arquivo copiado em uma réplica específica é tarefa do esquema de nomeação. 
A existência de réplicas deve ser invisível aos níveis mais altos. Nos níveis mais baixos, 
entretanto, as réplicas devem ser diferenciadas umas das outras por distintos nomes de mais 
baixo nível. 
Outro requisito de transparência é fornecer controle de replicação nos níveis mais altos. 
 
1. O armazenamento em cache com gravação direta é denominado: 
R) Write-through 
 
2. Quando o nome de um arquivo não revela qualquer indicação de sua localização física de 
armazena¬mento, podemos afirmar que o DFS implementa: 
R) Transparência de localização 
3. Com relação aos serviços com estado e os serviços sem estado, indique, dentre as 
afirmativas a seguir, quais são verdadeiras (V) e quais são falsas (F), assinalando a opção 
CORRETA: 
I. No serviço com estado, o servidor fornece ao cliente um identificador de conexão utilizado 
para acessos subsequentes até que a sessão termine. 
III. No serviço sem estado, o servidor não precisa man¬ter uma tabela de arquivos abertos na 
memória principal. 
 
Os serviços web (web services) abrangem um conjunto de padrões relacionados que podem 
habilitar quaisquer duas aplicações de computador a se comunicarem e a trocarem dados, via 
internet, por meio de protocolos padrões. 
Para um sistema distribuído funcionar corretamente, componentes de aplicações que executam 
em computadores diferentes por toda a rede devem poder comunicar-se. 
Tecnologias como DCOM e CORBA habilitam a comunicação entre componentes distribuídos. 
Entretanto, impõem um custo para viabilizar essa comunicação. Muitas vezes, seus 
componentes se comunicam via uma ponte entre COM e CORBA. 
 
Funcionamento: Os serviços web funcionam a partir do uso de padrões abertos (não 
proprietários). 
Em outras palavras, teoricamente, esses serviços podem habilitar a comunicação entre 
quaisquer dois componentes de software – independentemente das tecnologias utilizadas para 
criar os componentes ou as plataformas nas quais residem (interoperabilidade). 
 
Os web services fornecem, de forma mais genérica, uma interface de serviços para a interação 
com os servidores. 
Sendo assim, as aplicações podem utilizar sua própria linguagem, que será traduzida para uma 
linguagem comum: o formato XML. 
 
Os serviços web melhoram o desenvolvimento de software colaborativo, permitindo que 
desenvolvedores criem aplicações combinando códigos escritos em qualquer linguagem de 
qualquer plataforma. 
Esses serviços também promovem programação modular. Cada função específica de uma 
aplicação pode ser apresentada como um serviço web separado. 
Indivíduos ou empresas podem criar suas próprias aplicações exclusivas, mesclando e 
compatibilizando os web services que fornecem a funcionalidade de que precisam. 
 
Arquitetura (SOA), caracterízada pela as seguintes propriedades: Visão Lógica, Orientação à 
mensagem, orientação à descrição, Granularidade, orientação à rede, plataforma neutra. 
 
Componentes da arquitetura SOA 
Os componentes da arquitetura SOA representam uma coleção de serviços que se comunicam 
da troca de mensagens XML: 
 
Provedor de Serviço WEB: Responsável pela descrição das informações de conexão na 
chamada ao serviço e pela publicação e descrição do web service no registro dos serviços. 
Registros de Serviços: Manutenção de diretório com as informações sobre os serviços. Na 
SOA, o padrão adotado para registro é o Universal Description, Discovery and Integration 
(UDDI). 
Consumidor de Serviço: Responsável pela descoberta de um serviço, pelo recebimento de 
sua descrição e por sua utilização para a conexão a um provedor. Seu objetivo é chamar um 
serviço web. 
 
Plataforma .NET da Microsoft 
A iniciativa .NET inclui o ambiente de desenvolvimento integrado Visual Studio .NET, que 
habilita programadores a desenvolverem serviços web em uma variedade de linguagens – 
incluindo C++, C# e Visual Basic .NET. 
 
Os serviços web .NET – fundamentais da iniciativa .NET – estendem o conceito de reutilização 
de software à internet, permitindo que desenvolvedores reutilizem componentes de software 
que residam em outras máquinas ou plataformas. 
 
Empregando serviços web como blocos de construção reutilizáveis, os programadores podem-
se concentrar em suas especialidades, sem ter de implementar cada componente de uma 
aplicação. 
 
Por exemplo, uma empresa que está desenvolvendo uma aplicação de e-commerce pode 
assinar serviços web que processam pagamentos e autenticam usuários, o que habilita o 
programador a se concentrar em outros aspectos mais exclusivos daquela aplicação. 
 
Em .NET, um serviço web é uma aplicação armazenada em uma máquina que pode ser 
acessada por uma outra através de uma rede. 
 
Em sua forma mais simples, um serviço web criado em .NET é uma classe – ou um 
agrupamento lógico – de métodos de dados que simplificam a organização do programa. 
 
As classes de serviço web da .NET contêm certos métodos – denominados métodos de 
serviços web – que são especificados como parte do web service. Esses métodos podem ser 
invocados remotamente, usando RPC. 
 
O web service é definido pela W3C como um sistema de software projetado para fornecer 
INTEROPERABILIDADE entre máquinas em determinada rede. 
 
1. A linguagem baseada em XML que descreve o que um web service pode fazer, onde ele reside e como 
chamá-lo é denominada: 
R) WSDL 
 
2. O protocolo baseado em XML para troca de informação estruturada com web services em redes de 
computadores é chamado de: 
R) SOAP 
 
3. A especificação para publicar e localizar informações sobre web services denomina-se: 
R) UDDI 
 
Computação ubiqua, que tem como foco operações voltadas para a tarefa, e não para a 
ferramenta. Nesse caso, a computação está embutida em nosso dia a dia. 
 
De acordo com Loureiro: A computação ubiqua é um novo paradigma no qual dispositivos com 
capacidade de processamento e comunicação são embutidos nos elementos do dia a dia, 
provendo serviços de forma transparente aos usuários. 
 
A computação ubíqua está posicionada entre a computação móvel e a computação pervasiva, 
conforme apresenta a figura ao lado: 
Nesse tipo de computação, há: 
 Integração entre mobilidade e presença distribuída; 
 Inovação em interfaces – tendência para as interfaces naturais; 
 Determinados problemas, tais como de segurança, complexidade e 
 privacidade. 
 
A computação ubíquapode ser aplicada nos seguintes sistemas: 
 Ambientes inteligentes; 
 nterfaces hands-free (sem as mãos) – reconhecimento de voz, liveboards, pads e tabs; 
 Consciência de contexto – além da interação física do usuário a partir da utilização de 
sensores; 
 Computação de vestir (wearable) – tecnologia que utiliza acessórios como interfaces; 
 Computação sensível à posição; 
 Computação desagregada – reconfiguração automática; 
 Realidade aumentada – combinação de computadores wearable com informações de sensores 
de posição; 
 Interfaces sensíveis a objeto – Radio-Frequency IDentification (RFID). 
 
Exemplos 
Veja um exemplo de aplicação da computação ubíqua: 
 
A computação em nuvens consiste na utilização de recursos de processamento e 
armazenamento de computadores compartilhados e interligados por meio da internet. 
A cloud computing segue os moldes da computação em grid. Nesse caso, o acesso aos dados 
e às aplicações é permitido a partir de qualquer computador que tenha conexão com a internet, 
independente de sua plataforma. 
Clique aqui para ver uma figura que apresenta as vantagens da computação em nuvem. 
 
Serviços da computação em Nuvens 
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos: 
Software as a Service (SaaS) – Software como Serviço 
Trata-se do uso de um software através da internet. Em outras palavras, o usuário utiliza o 
software como serviço sem a necessidade de aquisição ou instalação local. 
São exemplos do modelo SaaS: 
Google Docs; HP SaaS; 
Microsoft Sharepoint Online; IBM SaaS. 
 
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos: 
Platform as a Service (PaaS) – Plataforma como Serviço 
Trata-se da utilização apenas da plataforma como: 
 Um banco de dados; 
 Um web service; 
 Serviços para desenvolvimento, testes etc. 
Normalmente, as aplicações desenvolvidas em uma PaaS ficam vinculadas ao fornecedor. 
São exemplos do modelo PaaS: Windows Azure e Google App Engine. 
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos: 
Trata-se de ferramentas de desenvolvimento utilizadas como: 
 Ferramentas compartilhadas; 
 Ferramentas de desenvolvimento web-based; 
 Serviços baseados em mashup. 
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos: 
Infrastructure as a Service (IaaS) – Infraestrutura como Serviço 
Trata-se da entrega de infraestrutura como serviço. 
Em outras palavras, o foco está na estrutura do hardware ou de máquinas virtuais, no 
armazenamento, o que permite uma ampla diversidade de softwares. 
São exemplos do modelo IaaS: 
Amazon EC2; 
GoGrid. 
 
 
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos: 
Trata-se da solução terceirizada em comunicação. 
 
Os fornecedores desse tipo de serviço são responsáveis pelo gerenciamento de hardwares e 
softwares, entregando serviços como VoIP e serviços de mensagens instantâneas, além da 
capacidade de gerenciar videoconferências. 
Um exemplo do modelo CaaS é o Microsoft Lync. 
 
Existem quatro tipos de implementação em cloud computing, quais sejam: 
 
De acordo com o artigo da Computeworld (2008), há sete princípios de segurança em uma 
rede em nuvem. São eles: 
Acesso privilegiado de usuários : A sensibilidade de informações confidenciais nas 
empresas as obriga a controlar o acesso dos usuários e a informação bem específica de quem 
terá privilégio de administrador. 
O objetivo é que esse administrador possa controlar os referidos acessos. 
Compliance com regulamentação: As empresas são responsáveis pela segurança, pela 
integridade e pela confidencialidade de seus próprios dados. 
Sendo assim, os fornecedores de cloud computing devem estar preparados para auditorias 
externas e certificações de segurança. 
Localização dos dados: A empresa que usa cloud provavelmente não sabe onde os dados 
estão, de fato, armazenados – talvez nem o país no qual as informações estejam guardadas. 
Portanto, o fornecedor deve estar disposto a se comprometer a armazenar e a processar dados 
em jurisdições específicas, assumindo um compromisso – em contrato – de obedecer aos 
requerimentos de privacidade que o país de origem da empresa exige. 
Segregação dos dados: Geralmente, uma empresa divide um ambiente com dados de 
diversos clientes. 
Nesse caso, precisamos entender o que é feito para a separação de dados e que tipo de 
criptografia é seguro o suficiente para o funcionamento correto da aplicação. 
Recuperação dos dados: O fornecedor em cloud deve saber onde estão os dados da 
empresa e o que é preciso para recuperá-los em caso de catástrofe. 
 Qualquer aplicação que não faça réplica dos dados e da infraestrutura em diversas localidades 
estará vulnerável à falha completa. Por isso, é importante ter um plano de recuperação 
completo e um tempo estimado para esse plano. 
Apoio à investigação: A auditabilidade de atividades ilegais pode-se tornar impossível em 
cloud computing, uma vez que há uma variação de servidores em função do tempo em que 
estão localizados os acessos e os dados dos usuários. 
Diante disso, é importante obter um compromisso contratual com a empresa fornecedora do 
serviço e uma evidência de sucesso no passado para esse tipo de investigação. 
Viabilidade em longo prazo: No mundo ideal, o fornecedor de cloud computing jamais vai falir 
ou ser adquirido por uma empresa maior. 
 Por isso, a empresa precisa garantir que seus dados estarão disponíveis caso o fornecedor de 
cloud computing deixe de existir, ou seja, caso seja migrado para uma empresa maior. 
 Nesse sentido, é importante haver um plano de recuperação de dados e um formato específico 
para que esse plano possa ser utilizado em uma aplicação substituta. 
 
1.São características da computação em nuvem, EXCETO: 
R) Baixa escalabilidade 
 
2. O uso de um software através da internet pode ser classificado como: 
R) SaaS 
 
 
 
O primeiro problema existe porque nem todos os peers terão todo o conteúdo, pelo 
menos inicialmente. 
A técnica usada no BitTorrent é a de que cada provedor de conteúdo possa criar uma 
descrição de conteúdo – chamada torrent. 
A torrent é muito menor que o conteúdo e é usada por um peer para verificar a 
integridade dos dados que ele baixa de outros peers. Outros usuários que querem 
baixar o conteúdo precisam primeiro obter a torrent, encontrando-a, digamos, em 
uma página Web que anuncia o conteúdo. 
A torrent é apenas um arquivo, em formato especificado, que contém dois tipos de 
informação: o nome de um tracker e os chuncks 
O arquivo de torrent contém o nome de cada chunk, dado como um hash 
SHA-1 de 160 bits do chunk. Dado o tamanho dos chunks e dos hashes, o arquivo de torrent 
é, 
pelo menos, três ordens de grandeza menor que o conteúdo, de modo que pode ser 
transferido rapidamente. 
Para realizar o download do conteúdo descrito em uma torrent, primeiramente, um 
peer entra em contato com o tracker para a torrent. O tracker é um servidor que 
mantém uma lista de todos os outros peers que estão ativamente fazendo download 
e upload do conteúdo. Esse conjunto de peers é chamado de swarm. 
 
Os membros do swarm entram em contato com o tracker regularmente para 
informar que ainda estão ativos, bem como ao saírem do swarm. Quando um novo 
peer entra em contato com o tracker para se juntar ao swarm, o tracker lhe informa 
sobre outros peers no swarm. 
 
Modelo de caching: esquema básico de armazenamento emcache 
O armazenamento em cache do DFS poderia ser facilmente chamado de 
memória virtual de rede. 
Isso porque esse armazenamento atua de modo semelhante à memória virtual 
paginada por demanda, exceto pelo fato de a memória de retaguarda não ser, 
normalmente, um disco local, e sim um servidor remoto. 
O NFS permite que o espaço de permuta seja montado remotamente. Dessa 
forma, ele pode implementar, realmente, a memória virtual sobre uma rede, 
apesar da perda em desempenho. 
 
Caches em disco possuem uma clara vantagem sobre os caches na memória 
principal: eles são confiáveis. 
Se o cache for mantido em memória volátil, em caso de queda do sistema, 
modificações nos dados do cache serão perdidas. Se os dados do cache forem 
mantidos em disco, eles ainda estarão ali durante a recuperação, e não será 
preciso extraí-los novamente. 
Muitas implementações de acesso remoto podem ser pensadas como híbridos 
de armazenamento em cache e serviço remoto. 
No NFS, por exemplo, a implementação é baseada em serviço remoto, mas é 
ampliada, por razões de desempenho, com o armazenamento em cache de 
memória para clientes e servidores. 
O protocolo NFS e a maioria das implementações não oferecem 
armazenamento em cache de disco. Implementações recentes do NFS no Solaris (a partir do 
Solaris 2.6) incluem uma opção de armazenamento em 
cache de disco no lado do cliente: o sistema de arquivos cachefs. 
Tão logo o cliente NFS leia os blocos de um arquivo a partir do servidor, ele os 
armazenará em cache na memória, assim como em disco. Se a cópia da 
memória for removida ou mesmo se o sistema for reinicializado, o cache em 
disco será referenciado. 
Se um bloco requerido não estiver em memória nem no cachefs em disco, uma 
RPC será enviada ao servidor para recuperar o bloco, que será gravado no 
cache em disco e armazenado no cache da memória para utilização por parte 
do cliente. 
Modelo de caching: política de atualização de cache 
A forma utilizada para gravar blocos de dados modificados na cópia-mestra do 
servidor tem implicação direta sobre o desempenho e a confiabilidade do 
sistema. 
Conheça, a seguir, algumas maneiras de gravar blocos de dados: 
Write-through (gravação direta) 
A write-through (gravação direta) é a forma mais simples de gravar os dados 
diretamente no disco tão logo sejam colocados em algum cache. 
Sua vantagem é a confiabilidade: poucas informações são perdidas quando um 
sistema-cliente cai. 
 
É necessário que cada acesso de gravação espere até que as informações 
sejam enviadas ao servidor, o que provoca um fraco desempenho de gravação. 
O armazenamento em cache com gravação direta é equivalente ao uso do 
serviço remoto para acessos de gravação e à exploração do cache somente 
para acessos de leitura. 
Write-back (gravação retardada) 
Na write-back (gravação retardada), as atualizações na cópia-mestra são 
adiadas. 
 
As modificações são gravadas no cache para, então, serem gravadas no 
servidor, em um momento posterior. 
Essa política tem duas vantagens sobre a gravação direta, quais sejam: 
 Em primeiro lugar, como as gravações são feitas no cache, os acessos 
de gravação completam-se muito mais rapidamente; 
 Em segundo lugar, os dados podem ser sobrepostos antes de serem 
gravados de volta no servidor – caso em que apenas a última 
atualização precisa ser completamente gravada. 
Os esquemas de gravação retardada introduzem problemas de confiabilidade, 
pois dados não gravados são perdidos sempre que uma máquina de usuário 
cai. 
As variações da política de gravação retardada diferem quanto ao momento 
em que os blocos de dados modificados são descarregados para o servidor. 
No NFS com cachefs, quando as gravações são executadas no servidor, elas 
também são executadas na área de cache do disco local, para manter todas as 
cópias consistentes. 
Sendo assim, o NFS com cachefs melhora o desempenho em relação ao NFS 
padrão em uma solicitação de leitura bem-sucedida do cache do cachefs, mas 
diminui o desempenho para solicitações de leitura ou gravação, com uma 
falha no cache. 
Write on close (gravação ao encerrar a sessão) 
Outra variação da gravação retardada é gravar os dados de volta no servidor 
quando o arquivo é fechado. 
Essa política de gravação ao encerrar a sessão (write on close) é utilizada no 
Andrew File System (AFS). 
 
Em caso de arquivos que sejam abertos por curtos períodos ou raramente 
modificados, a referida política não reduz, de modo significativo, o tráfego na 
rede. 
A write on close requer que o processo de fechamento aguarde enquanto o 
arquivo está sendo gravado por uma operação de gravação direta, o que reduz 
as vantagens de desempenho das gravações retardadas. 
 
Para arquivos que fiquem abertos por longos períodos e sejam modificados 
com frequência, são claras as vantagens de desempenho dessa política em 
relação à gravação retardada – com descargas mais frequentes. 
Modelo de caching: consistências 
Uma máquina-cliente enfrenta o problema de decidir se uma cópia dos dados 
armazenada em cache local é consistente com a cópia-mestra. 
Se a máquina-cliente determinar que seus dados no cache estejam 
desatualizados, os acessos não poderão mais ser atendidos para esses dados. 
Sendo assim, uma cópia atualizada dos dados precisará ser armazenada no 
cache. 
Existem duas abordagens para verificar a validade de dados no cache, quais 
sejam: 
Abordagem iniciada pelo cliente 
Nesta abordagem, o cliente inicia uma verificação de validade, na qual 
contata o servidor, e observa se os dados locais estão consistentes com a 
cópia-mestra. 
A frequência da verificação de validade é o ponto-chave dessa abordagem e 
determina a semântica de consistência resultante. 
Essa frequência pode variar de uma verificação antes de cada acesso a uma 
verificação somente no primeiro acesso a um arquivo. 
Dependendo de sua frequência, a verificação de validade pode sobrecarregar 
tanto a rede quanto o servidor. 
Abordagem iniciada pelo servidor 
Nesta abordagem, o servidor registra, para cada cliente, os arquivos (ou 
partes dos arquivos) armazenados em seu cache. Quando o servidor detectar 
uma inconsistência, ele deverá reagir. 
A ocorrência da inconsistência pode ser causada quando dois clientes 
diferentes, em modalidades conflitantes, armazenam um arquivo em cache. 
 
Se a semântica do UNIX for implementada, poderemos resolver a 
inconsistência fazendo o servidor desempenhar um papel ativo. 
O servidor deve ser notificado sempre que um arquivo for aberto, e a 
modalidade pretendida (leitura ou gravação) deverá ser indicada para cada 
abertura. 
O servidor poderá agir, então, quando detectar que um arquivo foi aberto 
simultaneamente em modalidades conflitantes, desabilitando o 
armazenamento em cache para esse arquivo em particular 
 
Como os peers encorajam uns aos outros para que façam upload do conteúdo 
para outros, além do download de conteúdo para eles mesmos? 
No terceiro problema, os nós da CDN são preparados exclusivamente para fornecer 
conteúdo aos usuários. Os nós P2P, por sua vez, não o são. Esses nós são os 
computadores dos usuários, que podem estar mais interessados em conseguir um 
conteúdo específico do que em ajudar outros usuários com seus downloads. 
Os nós que capturam recursos de um sistema sem contribuir com nada em troca são 
chamados de free-riders ou leechers. Se houver muitos deles, o sistema não 
funcionará bem. Os primeiros sistemas P2P eram conhecidos por hospedar os freeriders, de 
modo que o BitTorrent procurou minimizá-los (SAROIU et al., 2003). 
A técnica usada nos clientes BitTorrent é recompensar os peers que mostram bomcomportamento de upload. Cada peer seleciona aleatoriamente os outros, 
capturando seus chunks enquanto faz o upload de chunks para eles. 
O peer continua a trocar chunks apenas com um pequeno número de peers que 
oferecem o desempenho de download mais alto, embora também experimentem 
aleatoriamente outros peers para encontrar bons parceiros. Esse experimento 
aleatório também permite que os novos usuários obtenham chunks iniciais que 
podem trocar com outros peers. Os peers com os quais um nó está trocando chunks 
são considerados como unchoked. 
Com o tempo, esse algoritmo deverá combinar peers, uns com os outros, com upload 
comparável e taxas de download. Quanto mais um peer estiver contribuindo com os 
outros, mais ele poderá esperar em retorno. 
Usar um conjunto de peers também ajuda a saturar a largura de banda de um peer 
para aumentar o desempenho. Ao contrário, se um peer não estiver fazendo upload 
de chunck para outros peers ou se estiver fazendo isso muito lentamente, ele será, 
mais cedo ou mais tarde, cortado ou choked. 
 
Evolução: 
Primeiros computadores: grandes e caros. 
Anos 50-60: spooling, multiprogramação. 
Início dos anos 60: sistemas time sharing. 
Final dos anos 60 e início dos anos 70: surgimento de redes de computadores. 
A partir dos anos 70: inicia-se a pesquisa em sistemas distribuídos. 
 
Sistemas podem ser divididos em: 
 Fortemente acoplados - quando os processadores compartilham uma mesma memória 
principal. 
 Fracamente acoplados – os diversos processadores/estações presentes no sistema utilizam 
sua memória local individualmente. 
 Sistemas centralizados - Multiprocessador de memória compartilhada é um sistema de 
computador no qual duas ou mais CPUs compartilham acesso total a uma memória principal 
comum. Multiprocessadores são populares e atrativos, porque oferecem um modelo de 
comunicação simples, e a sincronização é possível mediante o emprego de diversas técnicas 
bem definidas. Uma desvantagem é que os multiprocessadores de grande porte são difíceis de 
construir e, por isso, são caros. 
 Sistemas distribuídos - Uma solução alternativa que tem sido empregada com sucesso para 
solucionar esse problema é a utilização de multicomputadores, que são CPUs que não 
compartilham memória principal. Cada CPU tem sua própria memória e é gerenciada por um 
sistema operacional individualmente. Esses sistemas também são conhecidos como cluster – 
COWS (cluster of workstations - aglomerados de estações de trabalho). 
 
• Sistema distribuído permite uma nova forma de fazer ciência 
–Teoria -> experimentos 
–Teoria -> simulações 
 
•Vantagens 
–Possibilidade de repetição de eventos 
–Manipulação de parâmetros 
–Estudo de sistemas onde não há teorias exatas 
 
•Problemas 
–Muito grandes: modelagem da terra/clima, simulações de reservatórios de petróleo, 
problemas com grandes escalas (cosmologia). 
–Muito pequenos: projeto de remédios, projetos de chips, biologia estrutural, física de 
partículas. 
–Muito complexos: física de partículas, dinâmica de fluidos, modelagem de comportamento de 
pessoas. 
–Muito caros: produção e exploração de petróleo, simulação de acidentes. 
–Muito perigosos: tolerância a falhas em aviões, teste de dispositivos nucleares, simulação de 
estratégias de defesa. 
 
PARALELISMO X COMPUTAÇÃO PARALELA 
 Paralelismo 
 Projeto de uma CPU 
 Projeto de uma arquitetura paralela 
 E/S sobreposta ao processamento 
 Computação paralela 
 Coleção de elementos de processamento 
 Trabalhando em conjunto para a realização de uma tarefa 
Paralelismo 
Dentro de um processador 
1. Busca a informação 
2. Decodifica Instrução 
3. Busca Operandos 
4. Executa Instrução 
 
Clusters 
 Definição: Conjunto de computadores independentes conectados, usados como recurso 
unificado para computação. Sistema com imagem única (SSI). 
 Benefícios 
o Custo/benefício: redução de custo para se obter processamento de alto desempenho. 
o Escalabilidade: possibilidade de adição de novos computadores, sendo adicionados a medida 
que cresça a carga. 
o Alto Desempenho: possibilidade de resolver problemas complexos através de programação e 
processamento paralelo. 
o Independência de Fornecedores: utilização de hardware aberto, livre de uso de licenças. 
o Tolerância a Falha: o aumento da confiabilidade do sistema como um todo, caso alguma parte 
falhe. 
 
Computação centralizada 
 Mainframe 
Termo utilizado para se referenciar a um grande computador, normalmente produzido por uma 
grande empresa. O nome tem origem na forma com que estes computadores eram 
construídos. Todos os componentes (processador, memória...) do computador principal (main) 
são colocados em uma única estrutura (frame). 
o Características 
 Sistemas multiusuários 
 Sistemas proprietários -> hardware, software, rede 
 Instalação e manutenção feita pelo fabricante -> confiabilidade X custo 
 
 Microcomputadores e redes de computadores 
Ampliação do parque computacional, em função de: 
o Processadores mais rápidos e mais baratos. 
o Redes mais rápidas e acessíveis. 
o Liberdade de escolha. 
o Menor custo de manutenção. 
o Necessidade inerente de conectividade. 
o Aplicação básica: compartilhamento de recursos. 
Evolução: Os terminais foram sendo substituídos pelos primeiros microcomputadores que 
começavam a ficar obsoletos. Em geral, o uso de um programa emulador de terminais e de 
uma unidade de disquete era suficiente para que um simples PC-XT executasse essa tarefa, 
uma vez que só precisaria executar o emulador. A partir deste ponto, o micro passaria a se 
comportar como um terminal. Em alguns casos, era necessário o uso de uma placa que 
compatibilizasse a forma de comunicação serial entre os dois computadores. 
 
 
 
 Sistemas Distribuidos 
Utilização das redes de computadores para execução colaborativa e cooperativa de aplicações 
e não somente para compartilhamento de recursos. 
Sistemas Distribuidos = computadores + rede + aplicação 
o Conceito: É um sistema em que os computadores estão conectados em rede e coordenam 
suas ações através de troca de mensagens. 
o Denifição de sistema distribuido: 
 Colouris: Um sistema no qual os componentes de hardware ou software, localizados em 
computadores interligados em rede, se comunicam e coordenam suas ações apenas enviado 
mensagens entre sí. 
 Tanenbaum: Um sistema distribuido é um conjundo de computadores independetes que se 
apresenta a seus usuários como um sistema único e coerente. 
 Siberschatz: Coleção de processadores que não compartilham memória ou relógio. 
o Principais motivações: necessidade pelo compartilhamento de recursos e 
o Características de um sistema distribuído: 
 baixo acoplamento e atrasos na comunicação; 
 processos em sistemas computacionais distintos com probabilidade de falhas 
 Comunicação geralmente não confiável, onde existem atrasos, variação de atrasos, perdas e, 
em alguns casos, baixas larguras de banda 
 dificuldade em definir a ordem dos eventos e estado global do sistema, uma vez que a 
comunicação acontece pela troca de mensagens 
 Ambiente geralmente marcado pela heterogeneidade 
o Comparação com sistemas centralizados 
 Vantagens 
 Melhor relação preço/desempenho 
 Capacidade de crescimento incremental (escalabilidade) 
 T olerância a falhas 
 Desvantagens 
 Falta de padronização para desenvolvimento de software 
 Falta de uma divisão clara entre sistema/aplicação 
 Latência e possibilidade