Projetos de Redes e Sistemas Distribuídos PDF

Projetos de
redes e sistemas
distribuídos
Projetos de redes e
sistemas distribuídos
Adriane Aparecida Loper

Nathalia dos Santos Silva
Giancarlo Michelino Gaeta Lopes
© 2019 por Editora e Distribuidora Educacional S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser reproduzida ou transmitida de qualquer
modo ou por qualquer outro meio, eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo
de sistema de armazenamento e transmissão de informação, sem prévia autorização, por escrito, da Editora e
Distribuidora Educacional S.A.
Presidente
Rodrigo Galindo
Vice-Presidente Acadêmico de Graduação e de Educação Básica

Mário Ghio Júnior
Conselho Acadêmico
Ana Lucia Jankovic Barduchi
Camila Cardoso Rotella
Danielly Nunes Andrade Noé
Grasiele Aparecida Lourenço
Isabel Cristina Chagas Barbin
Lidiane Cristina Vivaldini Olo
Thatiane Cristina dos Santos de Carvalho Ribeiro
Revisão Técnica
Vanessa Cadan Scheffer
Editorial
Camila Cardoso Rotella (Diretora)
Lidiane Cristina Vivaldini Olo (Gerente)
Elmir Carvalho da Silva (Coordenador)
Letícia Bento Pieroni (Coordenadora)
Renata Jéssica Galdino (Coordenadora)
Dados Internacionais de Catalogação na Publicação (CIP)
Loper, Adriene Aparecida

L864p Projeto de redes e sistemas distribuídos / Adriene
Aparecida Loper, Nathália dos Santos Silva, Giancarlo
Michelino Gaeta Lopes. – Londrina : Editora e Distribuidora
Educacional S.A., 2019.
152 p.
ISBN 978-85-522-1335-2
1. Redes de computadores. I. Loper, Adriene Aparecida.

II. Silva, Nathália dos Santos. III. Lopes, Giancarlo
Michelino Gaeta. IV. Título.
CDD 001.61
2019
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
e-mail: editora.educacional@kroton.com.br
Homepage: http://www.kroton.com.br/
Sumário
Unidade 1 | Conceitos e características dos sistemas distribuídos 9
Seção 1 - Conceitos, características e exemplos dos

sistemas distribuídos 12
1.1 | Redes de Computadores - Breve Histórico até hoje 12
1.2 | Definição de sistemas distribuídos 13
1.3 | Características/ metas de sistemas distribuídos 15
1.4 | Exemplos de sistemas distribuídos 22
1.4.1 | Internet – exemplo 1 22
1.4.2 | Internet das Coisas (IOT) - Exemplo 2 23
1.4.3 | Intranets - Exemplo 3 23
1.4.4 | Computação móvel e ubíqua - Exemplo 4 24
1.5 | Finalizando a seção 25
Seção 2 - Modelos e arquitetura de sistemas distribuídos 27
2.1 | Tipos de Sistemas Distribuídos 27
2.1.1 | Computação de Cluster (cluster computing) 27
2.1.2 | Computação em grade (gride computing) 28
2.2 | Introdução de arquiteturas 30
2.2.1 | Estilos arquitetônicos 30
2.2.2 | Arquiteturas de sistemas 33
2.2.3 | Arquiteturas híbridas 40
Unidade 2 | Redes e sistemas distribuidos 49
Seção 1 - Introdução à comunicação entre processos 53

1.1 | Arquitetura de comunicação dos sistemas distribuídos 54
1.1.1 | Arquitetura em camadas 54
1.1.2 | Arquitetura baseadas em objetos 57
1.1.3 | Arquiteturas centradas em dados 59
1.1.4 | Arquiteturas baseadas em eventos 60
1.2 | A camada middleware 60
1.3 | Características da comunicação entre processos 64
Seção 2 - Comunicação cliente-servidor e comunicação
em grupo 67
2.1 | Cliente-servidor 67
2.2 | Comunicação em grupo 71
Unidade 3 | Tecnologias de implementação 81
Seção 1 - Objetos distribuídos, RMI 84

1 | Princípios fundamentais de orientação a objetos 84
1.1 | Objeto - definições 84
1.2 | Sistemas distribuídos – definições 85
1.3 | Sistemas distribuídos baseados em objetos 86
1.4 | Objetos distribuídos 86
1.5 | Comunicação 88
1.5.1 | RPC (Remote Procedure Call) –
Chamada de procedimento remoto. 88
1.6 | Middleware 90
1.6.1 | Middleware de objetos distribuídos 90
1.6.2 | Middleware baseado em componentes 91
1.7 | RMI (Remote Method Invocation) -
Invocação de método remoto 92
1.7.1 | Exemplos: Tecnologia RMI Java e CORBA 92
1.7.1.1 | Java RMI - Modelos de objetos
distribuídos e invocações em Java 93
1.7.2 | CORBA Common Object Request
Broker Architecture 94
1.7.2.1 | RMI CORBA 95
1.7.2.2 | Modelo de objeto do CORBA 96
Seção 2 - Sistemas de Arquivos Distribuídos,

Serviços de nomes (DNS) 100
2.1 | Sistemas de arquivos distribuídos 100
2.2 | Arquitetura de sistemas de arquivos distribuídos. 101
2.2.1 | Arquiteturas cliente-servidor 101
2.2.2 | Modelo de sistema de arquivos distribuídos 104
2.2.2.1 | Modelo de sistema de arquivos
distribuídos baseado em clusters 106
2.3 | Comunicação 107
2.3.1 | RPCs em NFS 107
2.4 | Requisitos do sistema de arquivos distribuído 108
2.5 | Serviço de nomes DNS (Domain Name System) 110
Unidade 4 | Gerenciamento de redes 117
Seção 1 - Projeto de redes 120

1.1 | Meios físicos de conexão à rede e seus dispositivos 120
1.2 | Hardware de computadores e servidores 126
Seção 2 - Projeto e gerenciamento de redes 131
2.1 | Introdução ao estudo de caso 131
2.2 | Arquitetura de projeto 134
2.3 | Algoritmos de coordenação e gerenciamento 140
Apresentação
A evolução é constante na computação, não poderia deixar de
ser em sistemas distribuídos. Estamos utilizando cada vez mais
grande quantidade de computadores, conectados a uma grande
rede de alta velocidade e repartindo recursos. Os usuários estão
trabalhando em um sistema único com rapidez e eficiência. Assim,
na primeira unidade, trabalhamos com as definições básicas de
sistemas distribuídos e a forma de trabalhar com eles mantendo a
transparência das operações e preocupando-se com a segurança
das informações. Vamos ver como garantimos uma boa usabilidade
deles para os usuários? Saibam que já usamos sistemas distribuídos
quando estamos conectados à Internet. Como se adequar à melhor
arquitetura para sistemas distribuídos? Vamos fazer essa jornada
juntos, entendendo as possibilidades que temos.
Além de entender os aspectos visíveis dos sistemas distribuídos,
tais como as principais aplicações, a experiência do usuário e como
eles têm evoluído, como profissional da área você também precisa
conhecer o funcionamento que garante a operação desse tipo de
sistema. Quando pensamos em um sistema distribuído a primeira
pergunta que pode nos vir à mente é “quem controla os aspectos
de comunicação? ” ou “onde seriam centralizadas as informações?”.
A resposta para essas perguntas se dá pela arquitetura definida
pelo projetista, conhecida como cliente-servidor ou comunicação.
A partir da definição da arquitetura, você verá as implicações nos
protocolos de comunicação e na organização das requisições.
Adicionalmente, você irá entender como é a organização, em
camadas, dos sistemas distribuídos. Tais assuntos você irá encontrar
na Unidade 2 do livro.
O conceito de orientação a objetos tem crescido muito nos
últimos anos, pela facilidade de sua programação. E se aliarmos
orientação a objetos com sistemas distribuídos, o que acontecerá?
Descobriremos como usar esses chamados objetos distribuídos,
sempre com o foco no usuário, fazendo com que ele ache que está
trabalhando localmente, porém, vários objetos estão circulando
pela rede trazendo facilidades ao nosso cliente. E quanto aos
arquivos distribuídos, como podemos organizá-los da melhor forma,
principalmente nas intranets e na grande internet? Como nomear
esses arquivos e achá-los? Vamos estudar esse aspecto no Unidade
3 deste livro.
Além de conhecer o funcionamento de um sistema distribuído,
sabendo como ele opera a nível de software, é importante saber
também como projetar um sistema distribuído e quais dispositivos
de hardware são utilizados para isso. Assim, a última unidade do
livro tem como função apresentar quais dispositivos são utilizados
para montar a infraestrutura física dos sistemas distribuídos, tratando
do cabeamento utilizado, dispositivos de rede e hardware dos
computadores e servidores. Além disso, ela mostra, por meio de
um estudo de caso, como é a arquitetura de hardware e software,
de um sistema distribuído, permitindo que você tenha parâmetros
para projetar tais sistemas. Não bastando, são apresentados ainda
conceitos relacionados ao gerenciamento desses sistemas, expondo
algoritmos que podem ser utilizados para esse fim.
Perceba que este material tem o objetivo de tornar você apto
a trabalhar com os sistemas distribuídos de uma forma geral,
capacitando-o para a sua vida profissional. Então, vamos começar a
estudar esses sistemas?
Ótimos estudos!
Unidade 1
Conceitos e características
dos sistemas distribuídos
Objetivos de aprendizagem
Compreender o que são sistemas distribuídos, conhecer
os modelos de arquitetura de sistemas distribuídos e como
trabalhar com eles com maior flexilbilidade, disponibilidade
e agilidade para seus usuários. Além de compreender como
nos comunicamos e executamos serviços que são acessados
por milhares de usuários diariamente, tal como e-mails, sites,
entendendo uma pequena parte dessa estrutura gigantesca.
Seção 1 | Conceitos, características e exemplos dos

Aqui discorreremos sobre um breve histórico abordando as
redes de computadores para chegarmos a sistemas distribuídos.
Nosso enfoque serão as metas a serem alcançadas na construção
de um sistema distribuído, afinal, temos que assegurar que o usuário
cumpra todas as suas necessidades, imaginando que está operando
em um único sistema.
Seção 2 | Modelos e arquitetura de sistemas distribuídos

As necessidades dos usuários são as mais distintas. Nessa seção,
apresentaremos as diversas arquiteturas e como elas podem
minimizar os problemas, sempre com foco no usuário final.
Introdução à unidade
A partir da literatura de vários autores, os sistemas distribuídos são
compostos por multiprocessadores fracamente acoplados e têm
memória fisicamente distribuída. Esses sistemas foram motivados
por uma necessidade de vários computadores compartilharem
recursos. E, assim, iniciou-se uma nova forma de trabalho com os
recursos existentes.
Seção 1
Conceitos, características e exemplos dos
Introdução à seção
Caro aluno, nesta seção terá contato com um breve histórico

das redes de computadores para podermos discutir os sistemas
distribuídos. Vamos nos focar nas metas que devem ser atingidas ao
construirmos um sistema distribuído, pois temos que garantir que o
usuário consiga realizar todas as suas necessidades, de forma que
imagine estar operando um único sistema.
1. | Princípios fundamentais de sistemas distribuídos

1.1 | Redes de Computadores - Breve Histórico
até hoje
Na década de 1980, com a introdução dos microcomputadores

pessoais no mercado, pelas grandes empresas, como IBM, Apple e
outros, surgiu um novo modelo de computadores para empresas,
o computador pessoal (PC), que era uma opção de baixo custo
em comparação aos mainframes antigos. Com essa mudança,
já se pensava em interligar esses computadores pessoais, com
o crescimento dos editores de texto e planilhas eletrônicas. No
ambiente dos mainframes, eles se comunicavam e como fazer a
comunicação dos comutadores pessoais entre si?
Dessa demanda surgiram as primeiras redes locais baseados no
uso de cabos coaxiais para interligar computadores. Começaram
a surgir definições, como a de Sousa (1999, p. 21), de que rede é
“um conjunto de equipamentos interligados de maneira a trocarem
informações e compartilharem recursos como arquivos de dados
gravados, impressoras, modens, softwares e outros equipamentos”.
Com a rede, começam a surgir os novos sistemas de banco
de dados baseados em rede. A base centralizada de dados
12 U1 - Conceitos e características dos sistemas distribuídos

em um servidor permite garantir segurança e confiabilidade
das operações.
Inicialmente, viu-se que uma das finalidades principais da rede não
eram apenas o compartilhamento de recursos, mas a comunicação
de dados e a troca de mensagens entre os usuários. Surgiu após as
redes de computadores, o correio eletrônico, trazendo às empresas
uma grande economia de papel.
Das redes locais (LANs) passamos a expandir os horizontes com
as redes de longa distância (WANs).
Mas um dos maiores avanços na cultura organizacional, com o
conceito de redes, foi a Internet, disponibilizando às empresas e
usuários, acesso, envio e requisição de documentos de parceiros
comerciais ao redor do mundo.
Pessoas tiveram acesso a redes domésticas, as empresas
montaram suas redes corporativas, as universidades construíram
redes em seus campi, com a tecnologia, surgiram os telefones
móveis e suas redes, a Internet globalizou o planeta terra e a internet
das coisas aprimorou o conceito de rede e de internet.
Como nos afirma Coulouris (2007, p. 1), “todas elas, tanto
separadamente como em conjunto, compartilham as características
básicas que as tornam assuntos relevantes para estudo sob o título
sistemas distribuídos”.
Partimos da premissa de que a computação distribuída não é o
mesmo que redes de comunicação.
1.2 | Definição de sistemas distribuídos
Para Tanenbaum (2007, p. 1), “um sistema distribuído é um

conjunto de computadores independente que se apresenta a seus
usuários como um sistema único e coerente”.
Nos traz Coulouris (2007, p. 2) que “um sistema distribuído
como aquele no qual os componentes de hardware ou
software, localizados em computadores interligados em
rede, comunicam-se e coordenam suas ações apenas
enviando mensagens.
U1 - Conceitos e características dos sistemas distribuídos 13

Figura 1.1 | Princípio dos sistemas distribuídos
Computador pessoal Servidor
Rede de
comunicação
Estação de trabalho Impressora

Fonte: elaborada pela autora.
A partir dessas definições, podemos observar que só os

computadores ligados em rede não caracterizam sistemas
distribuídos. E também, quando falamos em hardware, estamos nos
referindo a máquinas autônomas e, quando falamos em software,
referimo-nos aos programas de computador, os quais os usuários
entendem que todos eles estão instalados na máquina que eles
estão usando.
Atualmente, os sistemas distribuídos, em particular os serviços e
aplicações baseados na Web e Internet, de forma geral, vêm crescendo
muito. Para você saber quando estamos trabalhando com sistemas
distribuídos, trago um cientista da Computação, Leslie Lamport (1978,
p. 558), que afirma que “[v]ocê sabe que tem um sistema distribuído
quando a falha de um computador do qual você nunca ouviu falar faz
com que você pare completamente de trabalhar”.
Para Tanenbaum (2007), devemos considerar alguns pontos
importantes em sistemas distribuídos:
a) Os componentes (computadores) devem ser autônomos de
qualquer tipo ou indiferente da forma como são conectados.
b) Os usuários enxergam um único sistema, sejam esses pessoas
ou programas.

c) Tanto pessoas como programas têm que colaborar.
Para construirmos sistemas distribuídos, temos alguns
grandes desafios, como a heterogeneidade em relação aos seus
componentes, a capacidade de funcionar corretamente com o
aumento de usuários e ocultar dos usuários o que cada um faz em
relação ao todo. Traremos na próxima seção esses desafios em
detalhes para melhor compreensão.
1.3 | Características/ metas de sistemas distribuídos
Tanenbaum (2007, p. 2) nos traz, “a meta principal de um

sistema distribuído é facilitar aos usuários e às aplicações o acesso
a recursos remotos e seu compartilhamento de maneira controlada
e eficiente”.
Quando nos referimos à recursos, falamos, por exemplo,
de impressoras de diversos tipos (matricial, a laser, jato de tinta,
jato de cera, 3D), plotters, armazenamentos que poderiam ser
magnéticos, ópticos, eletrônicos ou nuvem, dados em diversos
formatos, redes em quaisquer configurações, servidor de
e-mail, servidor de arquivo, páginas web, sistemas operacionais,
entre outros.
Para Tanenbaum (2007), desenvolver sistemas distribuídos
não é fácil, adotamos alguns princípios de regras básicas da
engenharia de software. Contudo, sistemas distribuídos diferem
do software tradicional, pois seus componentes estão espalhados
por uma rede.
Tanenbaum (2007) diz que algumas características/desafios são
primordiais na construção de sistemas distribuídos. São elas:
a. Heterogeinidade.
b. Sistemas abertos.
c. Segurança.
d. Escalabilidade.
e. Tratamento de falhas.
f. Concorrência.
g. Transparência.

Discorreremos, agora, um pouco mais sobre cada um dos itens
necessários para cumprir nossas metas em um sistema distribuído.
a) Heterogeinidade
A palavra já representa diversidade, diferenças. Para que essas
diferenças não sejam notadas pelos usuários, para que eles tenham
a visão de um sistema único, podemos organizar os sistemas
distribuídos por meio de uma camada de software, essa em
especial é denominada middleware, conforme Figura 1.2 trazida por
Tanenbaum (2007).
Figura 1.2 | Middleware
Fonte: Tanenbaum (2007, p. 2).
Só relembrando que alguns middleware suportam apenas uma

linguagem, por exemplo, Java RMI.
b) Sistemas abertos
Como definição de sistemas abertos temos a determinação se
esse sistema pode ser estendido e implementado de diversas formas.
Segundo Tanenbaum (2007), um sistema distribuído aberto é um
sistema que oferece serviços de acordo com regras padronizadas
que descrevem sua sintaxe e semântica. Como um exemplo de
sucesso do uso de sistemas distribuídos abertos, pode-se citar a
Internet, que utiliza protocolos de comunicação conhecidos e
que normalizam a troca de informações na rede. As suas principais
interfaces devem ser publicadas.
Como um exemplo de abertura em relação ao software é permitir
a introdução de novos serviços e a reimplementação dos velhos. Para
sistemas distribuídos, pode-se utilizar independência de fornecedores.

c) Segurança
O tipo de serviço prestado por um sistema distribuído é de alto
valor. A segurança de recursos de informação se baseia nos três
pilares da segurança da informação: confidencialidade, integridade
e disponibilidade.
A respeito da confidencialidade, descrita por Campos (2007,
p. 17), “esse princípio é garantido quando apenas as pessoas
explicitamente autorizadas podem ter acesso à informação”.
A integridade (CAMPOS, 2007, p. 18) é “esse princípio é garantido
quando a informação acessada está completa, sem alterações e
portanto completa”.
A disponibilidade, nos afirma Campos (2007, p. 19), que “esse
princípio é garantido quando a informação está acessível, por
pessoas autorizadas, sempre que necessário”.
Temos que ter a clareza de que toda a comunicação em um sistema
distribuído ocorre sobre redes. O desafio é enviar informação sensível
em mensagens de forma segura. Outra questão a que devemos
estar atentos é a garantia da identidade do emissor e do receptor de
mensagens. Com o avanço dos ciberataques, aumentou o ataque de
negação de serviço (DOS) o que fere o princípio da disponibilidade e a
ação possível é procurar responsáveis depois do ataque ter ocorrido,
deixando serviços indisponíveis, o que poderá causar prejuízos.
A falta de criptografia das mensagens torna as mensagens
inseguras. Outro problema é que quanto maior a conectividade,
maiores os spams. Entre outros ataques que podem ocorrer nas
redes, que são diversos.
d) Escalabilidade
Sabemos que podemos conversar on-line com qualquer pessoa,
em qualquer lugar do mundo via conectividade mundial pela
Internet. Em função dessa globalização, a escalabilidade é uma das
mais importantes metas para os projetistas de sistemas distribuídos.
Coulouris (2007) define que a escalabilidade de um sistema
distribuído representa a potencialidade do seu funcionamento em
diferentes escalas.
Um sistema distribuído deve operar de forma eficiente e
independente da escala, por exemplo, desde uma pequena intranet

até a Internet. Um sistema é escalável se continuar efetivo após
acréscimo significativo de recursos e usuários.
Neuman (1994) mostra que a escalabilidade pode ser medida
em três dimensões distintas: em relação ao tamanho, em recursos
geográficos e em domínios administrativos.
d1) Dimensões
d1.1) Dimensão em relação ao tamanho
Acrescentar usuários e recursos infinitamente é o nosso desejo.
Mas, na prática, não funciona assim. Tanto serviços quanto dados e
algoritmos centralizados possuem suas limitações.
Quando analisamos os sistemas distribuídos, sabemos que
alguns serviços são centralizados, ou seja, são implementados
por meio de apenas um servidor em uma máquina específica.
Se os usuários e aplicações aumentam, esse servidor não terá a
mesma performance.
Quando os dados são centralizados, como os dados telefônicos
de 40 milhões de assinantes, o armazenamento não seria problema,
mas o banco de dados suportaria todas as linhas de comunicação
que o acessam? Não, não suportaria.
Os algoritmos centralizados também são difíceis em um sistema
distribuído. Por exemplo, em um sistema distribuído de grande
porte, as mensagens têm que ser roteadas por muitas linhas. Se o
algoritmo coletar informações de diversos sites e enviar para uma
máquina apenas fazer seu processamento, não é viável pois as
respostas seriam lentas. Devemos usar algoritmos descentralizados.
Assim, resolvemos os problemas em pequenas partes do sistema e
qualquer falha não afetaria o algoritmo todo.
d1.2) Dimensão em relação aos recursos geográficos
Para Tanenbaum (2007), quanto à escalabilidade geográfica,
temos uma dificuldade conceitual. Para ampliação de sistemas
distribuídos com redes que foram originalmente criadas para serem
redes locais (LANs), a dificuldade é que elas foram construídas
baseadas em comunicação síncrona. E o conceito original de
comunicação síncrona seria a parte que requisita um serviço fica
bloqueada até receber uma mensagem de resposta. Isso torna
os sistemas distribuídos mais lentos. Além da diminuição de
confiabilidade em redes de longas distâncias.

O desenvolvimento de sistemas distribuídos com base em
braoadcast é importante.
d1.3) Dimensão em relação aos domínios administrativos.
Essa dimensão traz à tona os problemas de políticas conflitantes
em relação à utilização e pagamento dos recursos, gerenciamento
e segurança.
e) Tratamento de falhas
Os componentes dos sistemas distribuídos podem falhar,
nosso eterno questionamento é quando eles falharão? Coulouris
(2007) diz que, quando falhas no hardware ou software ocorrem,
podem trazer resultados errados ou encerrar o processo antes de
fornecer respostas.
As falhas em sistema distribuído, não são totais, dificultando
seu tratamento.
e1) Técnicas de tratamento de falhas
As técnicas de tratamento de falhas, para Coulouris (2007), são:
Detecção de falhas, Mascaramento de falhas, Tolerância a falhas,
Recuperação de falhas e Redundância.
e1.1) Detecção de falhas
Poderemos fazer a detecção através de checksum (ou soma de
verificação), uma técnica usada para detectar erros, alterações de
pacotes na rede ou dados danificados em uma mensagem ou em
um arquivo. Há ainda falhas quase impossíveis de identificar, como
o crash de servidores.
e1.2) Mascaramento de falhas
Pode-se eliminar uma mensagem danificada retransmitindo-a
e a ocultado fazendo com que ela seja menos severa; pode-se
armazenar dados em discos diferentes. Nesses casos, devemos
trabalhar com a pior das hipóteses, em que todos os discos estejam
corrompidos e não poderemos fazer o armazenamento ou a
mensagem não poder ser retransmitida em tempo hábil.
e1.3) Tolerância a falhas
Deve-se aplicar técnicas de tolerância a falhas nos sistemas
distribuídos, pois, pela composição dos sistemas distribuídos,
possuímos muitos equipamentos e pode-se ter redundância. O
sistema deverá funcionar mesmo tendo alguns componentes

falhos. Por exemplo, na Internet, quando um servidor está fora do ar,
o navegador enviará uma mensagem ao usuário em pouquíssimo
tempo e o mesmo decidirá se tentará novamente ou não.
e1.4) Recuperação de falhas
Como exemplo, temos o rollback (rolar para trás) no servidor.
Se estivermos fazendo uma transação, que por algum motivo não
se completa, o sistema é obrigado a recuperar os dados. Isso pode
deixar os dados incompletos ou diferente dos valores corretos.
e1.5) Redundância
Para Weber (1990), redundância para aumento de confiabilidade
deve sempre ser verificada, pois, havendo redundância de software,
hardware, tempo e informação, isso impactará em custos adicionais. Se
colocarmos um outro processador idêntico, duplicando e comparando
sinais de saída, podem ser detectadas falhas naquele processador.
f) Concorrência
Tanenbaum (2007) descreve como estamos em um sistema
distribuído, há grande possibilidade de um recurso ser acessado
por vários clientes ao mesmo tempo e o servidor de um recurso
pode atender um cliente de cada vez. Por exemplo, uma estrutura
de dados que registre lances em um leilão. Temos um limitador
nessa situação que é a quantidade de dados processados em
um determinado espaço de tempo, por isso processamos
concorrentemente. Quando se tratar de concorrência em sistemas
distribuídos, deve-se tratar os aspectos relacionados à sincronização.
Sempre as respostas devem ser coerentes e consistentes.
g) Transparência
A transparência trabalha como sendo uma ocultação dos
componentes independentes em um sistema distribuído, fazendo
com o usuário tenha a visão do todo.
Tanenbaum (2007) apresenta que a ANSA (Advanced Network
Systems Architecture) e a ISO (International Standards Organization)
definem oito formas de transparência:
• Transparência de acesso: devem ser acessados com as mesmas
operações, sem que o usuário saiba se o recurso acessado é local
ou remoto.

• Transparência de localização: não há necessidade de saber a
localização física ou endereço de IP do recurso acessado.
• Transparência de concorrência: vários processos acessam os
mesmos recursos compartilhados sem interferência.
• Transparência de replicação: múltiplas instâncias de recursos são
usadas com a finalidade de melhor desempenho e/ou confiabilidade
sem usuários ou programadores tomarem conhecimento de
suas réplicas.
• Transparência de falhas: permite aos usuários finalizarem suas
tarefas, mesmo havendo falhas em software ou hardware e as
mesmas serem tratadas.
• Transparência de mobilidade: permite a movimentação de
recursos e clientes sem afetar qualquer operação do usuário.
• Transparência de desempenho: permite ao sistema ser
reconfigurado conforme as necessidades para aumento
de desempenho.
Transparência de escalabilidade: permite mudanças de escala
(aumento dos recursos computacionais) sem alteração de
aplicações ou algoritmos.
A transparência de rede é uma combinação de transparência de
acesso e transparência de localização.
Para saber mais

vamos analisar algumas inovações em sistemas distribuídos? Então leia:
Inovação e coragem, ingredientes para o sucesso.
<https://fabiogferreira.com.br/inova%C3%A7%C3%A3o-e-
coragem-ingredientes-para-o-sucesso-6970e50d45df>. Acesso
em: 24 set. 2019.
Questão para reflexão

Será que teremos um limite nas inovações sobre
sistemas distribuídos?

1.4 | Exemplos de sistemas distribuídos
Temos diversos exemplos de sistemas distribuídos, por exemplo,

a Internet, internet das coisas, as intranets das empresas ou de
universidades, bancos com diversas agências e diversos caixa
eletrônicos, sistema operacional unix, computação móvel e ubíqua.
1.4.1 | Internet – exemplo 1
A Internet, como podemos entender, trata-se de um grande

sistema distribuído. Carvalho (2005) a define como uma grande rede
de computadores, roteadores e demais componentes que têm como
objetivo levar a informação de uma localidade à outra. Ela fornece
serviços para seus usuários, como WWW, e-mail, FTP, que são acessíveis
da mesma maneira em qualquer lugar, deixando-o à vontade para fazer
uso deles onde, quando e com a máquina que desejar.
Lembrando que FTP (file transfer protocol) é um protocolo da família
TCP/IP capaz de transferir, renomear e remover arquivos e diretórios
entre dois sistemas. Para isso, o FTP baseia-se no estabelecimento de
duas conexões: uma de controle e outra de dados, ambas sobre o
TCP, o que garante a confiabilidade na transmissão.
Figura 1.3 | Uma parte típica da Internet
Fonte: Coulouris (2007, p. 17).

Estrutura Física: Máquinas (hosts) são conectadas a um provedor
de serviços (ISP) ou rede local, metropolitana, sem fio etc. Essas
redes são interligadas por redes de longa distância públicas (ex.:
Internet) ou privadas.
Provedores fornecem o acesso aos usuários domésticos ou de
empresas, sendo possível a manipulação de arquivos de diversos
formatos, como texto, imagem, música, televisão, participar de
reuniões, fazer ligações de redes telefônicas.
Outro aspecto interessante da Internet é que ela possui
transparência de escala, permitindo que ela cresça bastante. E
o e-mail, que quando os enviamos, não conseguimos ver seu
roteamento, ou seja, a rede destino não diz em que máquina está
o destinatário.
1.4.2 | Internet das Coisas (IOT) - Exemplo 2
A internet das coisas (do inglês Internet of things) – IOT surgiu

com os avanços de várias áreas como sistemas embarcados,
microeletrônica, comunicação e tecnologia de informação.
A internet das coisas é um sistema distribuído, com comunicação
e coordenação, o que a torna muito interessante.
Para Evans (2011, p. 2):
A IoT (Internet of Things, internet das coisas), algumas

vezes referida como a Internet dos objetos, mudará tudo,
inclusive nós mesmos. Isso pode parecer uma declaração
arrojada, mas considere o impacto que a Internet já teve
na educação, na comunicação, nos negócios, na ciência,
no governo e na humanidade. Claramente, a Internet é
uma das criações mais importantes e poderosas de toda a
história humana.
1.4.3 | Intranets - Exemplo 3
Várias empresas e universidades possuem intranets, que,

para Coulouris (2007), é uma parte da internet administrada,

separadamente, cujo limite pode ser configurado para possuir planos
de segurança locais. Elas podem ou não estar ligadas à grande rede.
Figura 1.4 | Uma intranet típica
Servidor de
Computadores
e-mail
Servidores de de mesa
impressão e outros
Rede local
Servidor web
Servidor de
e-mail
Impressão
Servidor de
arquivos Outros
servidores
Outras porções
da internet
Roteador/firewall
1.4.4 | Computação móvel e ubíqua - Exemplo 4
Couloures (2007) define que consiste da integração de

pequenos dispositivos móveis e/ou embutidos no ambiente, com
capacidade de computação e comunicação, como em rede sem
fio, interagindo diretamente com o usuário (pessoa). Entre esses
equipamentos temos notebooks, telefones móveis e câmeras de
vídeo e digitais, assistentes digitais pessoais (PDAs), dispositivos
embutido em geladeiras, carros, aparelhos como relógio de pulso
inteligentes, entre outros exemplos.
A computação móvel é possível por sua portabilidade de seus
dispositivos e a capacidade de conexão com redes em lugares
distintos. Ela também pode ser chamada de computação nômade.
A computação ubíqua também pode ser chamada de computação
pervasiva, é realizada por vários dispositivos computacionais,
pequenos e baratos, que estão acessíveis nos ambientes físicos
dos usuários, como casa, escritório ou rua. O termo sugere que a
computação será utilizada tão comumente que sequer a notaremos,
ou seja, seu comportamento será invisível. Será visto na Figura 1.5.

Figura 1.5 | Equipamentos portáteis em um sistema distribuído
Internet
Intranet anfitriã Intranet doméstica

Rede local sem fio
Telefone Sinal de satélite GPS

móvel
Rede de telefonia 3G
Impressora Notebook
Câmera Site anfitrião
1.5 | Finalizando a seção
E concluindo esta seção, a transparência é um fator muito

importante em sistemas distribuídos, porém, como nos traz
Tanenbaum (2007), em alguns casos quando o usuário não
consegue acessar o que deseja, é melhor deixá-lo optar por tentar
novamente ou não.
A internet das coisas é uma possibilidade de revolução
tecnológica, com seus sensores interligados em rede e diversas
possibilidades dentro da computação.
Fique ligado
Até aqui estudamos sistemas distribuídos, em suas definições e
metas com embasamento principalmente em Tanenbaum (2007)
que nos traz desafios são primordiais na construção de sistemas
distribuídos. São elas:
a. Heterogeinidade.
b. Sistemas abertos.
c. Segurança.
d. Escalabilidade.
e. Tratamento de falhas.

f. Concorrência.
g. Transparência.
Encerramos esta seção com exemplos do nosso cotidiano, que

talvez não soubéssemos que se tratavam de sistemas distribuídos.
Atividades de aprendizagem
1. Aplicada em: 2010
Banca: FUNCAB
Órgão: SES-GO
Prova: Analista de Sistemas
<https://www.qconcursos.com/questoes-de-concursos/disciplinas/
tecnologia-da-informacao-arquitetura-de-computadores/sistemas-
distribuidos>
Em relação à replicação de dados nos sistemas de dados distribuídos,

aquela que é uma DESVANTAGEM da sua aplicação:
a) degradação do desempenho das aplicações.
b) limitação da disponibilidade das aplicações.
c) propagação de atualizações.
d) dependência do hardware.
e) dependência do SGBD.
2. Segundo Tanenbaum (2007), alguns desafios são primordiais na

construção de sistemas distribuídos. Analise as afirmativas abaixo e assinale
a alternativa correta:
I. Heterogeinidade.
II. Segurança.
III. Transparência.
a) Apenas a afirmativa I está correta.

b) Apenas as afirmativas I e II estão corretas.
c) Apenas as afirmativas I e III estão corretas.
d) Apenas as afirmativas II e III estão corretas.
e) Todas as afirmativas estão corretas.

Seção 2
Modelos e arquitetura de sistemas distribuídos
Antes de discutirmos estilos arquitetônicos e a arquitetura

de sistemas distribuídos, vamos entender os alguns tipos de
sistemas de computação distribuídos tendo embasamento em
Tanembaum (2007).
2.1 | Tipos de Sistemas Distribuídos
2.1.1 | Computação de Cluster (cluster computing)
Segundo Buyya (1999), computação de cluster é um sistema

de computação distribuído composto por um conjunto de
computadores independentes (elementos) que trabalham de
forma integrada como se fosse um recurso computacional único.
Para Tanenbaum (2007), consiste em um conjunto de estações
de trabalho ou computadores semelhantes, conectados por
uma rede local de alta velocidade e cada nó executará o mesmo
sistema operacional.
Em função do menor custo e desempenho dos computadores
pessoais e estações de trabalho, viu-se que era mais fácil montar
um supercomputador conectando-se esses computadores, investir
em uma excelente rede de computadores e executar programas de
forma paralela.
Um exemplo de um computador de cluster é formado pelos
clusters Beowulf, baseados em sistema operacional Linux,
conforme mostrado na Figura 1.6. Cada cluster consiste em
um conjunto de nós de computação controlados e acessados
por meio de um único mestre. O mestre executa o middleware
necessário para a execução de programas e o gerenciamento do
cluster, enquanto para os nós de computação é suficiente um
sistema operacional padrão.

Figura 1.6 | Exemplo de um sistema computacional de cluster
Nó mestre Nó de computação Nó de computação Nó de computação
Aplicação de
gerenciamento Componente Componente Componente
da aplicação da aplicação da aplicação
Bibliotecas paralela paralela paralela
paralelas
SO local SO local SO local SO local
Rede de Rede padrão

acesso remoto
Rede de alta velocidade
Para saber mais

Para saber mais: Vamos analisar algumas inovações em arquitetura
sistemas distribuídos? Que tal uma rede baseada no caos da
natureza? <http://www.inovacaotecnologica.com.br/noticias/
noticia.php?artigo=computador-sistemico&id=010150130220#.
W05YwCh97IU>. Acesso em? 24 set. 2018.

Quanto efetivo será um sistema que nunca falha? Conseguiremos
alcançar essa meta?
2.1.2 | Computação em grade (gride computing)
Para Foster (2002), uma grade computacional é uma infraestrutura

de hardware e software capaz de prover dependabilidade,
consistência e pervasividade de baixo custo para computação
de alto desempenho. Na computação em grade temos grande
heterogeneidade, teremos diferentes hardwares, softwares,
tecnologia de rede empregada e diferentes domínios administrativos.
Para Tanenbaum (2007), é formada uma organização virtual,
fazendo com que os direitos de acesso aos recursos da organização

à qual você pertence, sejam compartilhados, oferecendo
facilidades de armazenamento e banco de dados, além de sensores.
Podemos ter um exemplo na Figura 1.7. Essa arquitetura consiste
em quatro camadas. A camada base provê interfaces para recursos
locais em um site específico, permitem o compartilhamento de
recurso dentro de uma organização virtual. Temos como exemplo
travar recursos. A camada conectividade, composta de protocolos
de comunicação para suportar transações da grade, contém
protocolos de segurança para autenticar usuários e recursos.
A camada de recursos, responsável pelo gerenciamento de um
único recurso, é encarregada pelo controle de acesso e, por isso,
depende da autenticação realizada pela camada de conectividade.
A camada coletiva manipula o acesso a múltiplos recursos e
normalmente consiste em serviços para descoberta de recursos,
alocação e escalonamento de tarefas para múltiplos recursos e
replicação de dados. Ela é constituída de protocolos diferentes
para muitas finalidades diferentes, que reflitam o amplo espectro
de serviços que ela pode oferecer a uma organização virtual. A
camada de aplicação consiste em aplicações que funcionam
dentro de uma organização virtual e que fazem uso do ambiente
de computação em grade.
Figura 1.7 | Arquitetura em camadas para sistemas de computação em grade
Aplicações
Camada coletiva
Camada de conectividade Camada de recurso
Camada base

2.2 | Introdução de arquiteturas
As arquiteturas de software de sistema distribuído nos esclarecem

como os componentes de software devem ser organizados e como
devem interagir entre si e com os demais componentes.
Para Tanenbaum (2007), a realização efetiva de um sistema
distribuído implica que sejam especificados e colocados
componentes de software em máquinas reais. A especificação final
de uma arquitetura de software é também denominada arquitetura
de sistema.
Nosso estudo se baseará nas arquiteturas centralizadas,
descentralizadas e híbridas.
2.2.1 | Estilos arquitetônicos
Tanenbaum (2007) afirma que, para iniciarmos nossa discussão

sobre estilos arquitetônicos, devemos considerar a organização
lógica de sistemas distribuídos quanto aos componentes de software,
ao qual chamamos de arquitetura de software. Analisaremos
componentes, a interconexão entre os componentes, os dados
trocados entre eles e a suas configurações, isso tudo para analisar
como é formado o sistema como um todo.
Traremos algumas definições importantes, sendo a primeira
a definição do que é um componente, unidade modular com
interfaces requeridas e fornecidas, muito bem definidas e que pode
ser substituída a qualquer momento dentro do sistema, sempre
respeitando suas interfaces. Os componentes estão localizados em
diversas máquinas. A segunda definição, um pouco mais complexa,
é a de conector, que é um mecanismo que serve de mediador da
comunicação ou da cooperação entre componentes.
Com a junção de componentes e conectores, foram definidos,
em especial, quatro estilos arquitetônicos:
a) Arquiteturas em camadas.
b) Arquiteturas baseadas em objetos.
c) Arquiteturas centradas em dados.
d) Arquiteturas baseadas em eventos.

Analisaremos cada uma delas a seguir.
a) Arquiteturas em camadas
As arquiteturas foram pensadas em termos de camadas, as
quais delimitam que componentes podem ser chamados ou
não, indo de camada a camada. Observamos na Figura 1.8, que
o fluxo, seguido pelas requisições, passa pelas camadas de cima
para baixo e o fluxo de repostas, inicia-se na camada inferior e
seguem para cima.
Figura 1.8 | Estilo arquitetônico em camadas
Camada N
Camada N-1
Fluxo de Fluxo de
requisição resposta
Camada 2
Camada 1
(a)
Fonte: Tanembaum (2007, p. 21).
b) Arquiteturas baseadas em objetos

Nessa arquitetura, os objetos são tratados como componentes e
esses componentes são conectados por meio de uma chamada de
procedimento remota, como veremos na Figura 1.9. A arquitetura
em camadas e baseada em objetos são os modelos mais utilizados
para software de grande porte.

Figura 1.9 | Estilo arquitetônico baseado em objetos
Objeto Objeto
Chamada de
Objeto método
Objeto
Objeto
c) Arquiteturas centradas em dados

Ela foi projetada com o princípio de que processos se comunicam
por meio de um repositório comum, esse repositório pode ser passivo
ou ativo. Podemos observar, na Figura 1.10, essa configuração em
aplicações de rede que dependem de um sistema distribuído de arquivos
compartilhados e também os sistemas distribuídos baseados na web.
Figura 1.10 | Estilo arquitetônico baseado em dados compartilhados
Componente Componente
Entrega de dados Publicar
Espaço de dados (persistente)

compartilhado
(b)
d) Arquiteturas baseadas em eventos

Nessa arquitetura, os processos se comunicam por meio da
propagação de eventos, que em sistemas distribuídos tem sido
associada ao sistema publicar/subscrever. Podemos observar,

na Figura 1.11, que os eventos só serão direcionados a quem se
subscreveu. Os processos são fracamente acoplados ou chamados
referencialmente desacoplados. Pode haver uma combinação de
arquitetura baseada em eventos e centrada em dados, que são
denominados de espaços compartilhados de dados.
Figura 1.11 | Estilo arquitetônico baseado em eventos
Componente Componente
Entrega de evento
Barramento de eventos
Publicar
Componente
Esses modelos de arquitetura de software são importantes para

sistemas distribuídos pois têm como objetivo a transparência de
distribuição. Para isso, requer-se também facilidade de programação,
desempenho e tolerância a falhas.
2.2.2 | Arquiteturas de sistemas
Tanenbaum (2007) define como a decisão sobre componentes

de software, sua interação e sua colocação, em que temos uma
arquitetura de software. Possuímos em especial três tipos de
arquitetura de sistemas as arquiteturas centralizadas, distribuídas e
híbridas. Discorreremos ao longo dessa seção esses três tipos.
a) Arquiteturas centralizadas
Coulouris (2007) diz que as arquiteturas centralizadas expressam
o conceito de que clientes solicitam serviços oferecidos por
servidores. Esse tipo de arquitetura cliente-servidor é mais utilizado
e menos complexo para implantação e administração comparado a
outras arquiteturas. Em determinado momento, o servidor também

pode desempenhar papel de cliente em relação a outros servidores,
como apresentado na Figura 1.12.
Figura 1.12 | Arquitetura Cliente - Servidor
Cliente
Solicitação
Processo
Servidor Servidor
Solicitação
Resultado
Processo Processo
Resultado
Cliente
Processo
Também podemos ver a relação cliente-servidor, trazida por

Tanenbaum (2007), no qual ele determina que um servidor é um
processo que implementa um serviço específico, por exemplo, um
serviço de banco de dados e cliente é um processo que requisita
um serviço de um servidor enviando a requisição e esperando a
resposta do servidor. Essa interação é chamada de comportamento
de requisição-resposta, ilustrada na Figura 1.13.
Figura 1.13 | Comportamento de requisição-resposta
Espera resultado
Cliente
Requisição Resposta
Servidor
Fornece serviço
Tempo
Descrevendo um pouco das arquiteturas centralizadas, a

comunicação entre um cliente e servidor pode ser implementada
por meio de um protocolo simples, sem conexão, por uma rede
confiável, como acontece normalmente em muitas redes locais.
Um cliente requisita um serviço, ele empacota uma mensagem para

o servidor identificando o serviço desejado e os dados de entrada
necessários e o servidor processará e empacotará os resultados em
uma mensagem de resposta ao cliente.
Na teoria funciona bem, mas na prática podemos ter problemas
se a mensagem da requisição falhou ou na transmissão. Para
resolver esses problemas, muitos sistemas cliente-servidor usam um
protocolo confiável orientado à conexão.
No modelo cliente-servidor, há algumas dificuldades, como
demonstra Tanembaum (2007), em saber quem é o cliente e quem
é o servidor.
Considerando que muitas aplicações cliente-servidor visam
dar suporte ao acesso de usuários a banco de dados, seguindo
o estilo arquitetônico de camadas, possuímos três níveis, sendo
eles: nível de interface do usuário, elaborado em programas que
permitam aos usuários finais interagir com as aplicações, como
gerenciamento de exibição; nível de processamento, o qual
contém as aplicações; e o nível de dados que gerencia os dados
sobre os quais está sendo executada alguma ação. Como exemplo
desses três níveis, mostraremos na Figura 1.14, um mecanismo de
busca na Internet.
Figura 1.14 | Organização simplificada de um mecanismo de busca na Internet em

três camadas diferentes
Nível de
Interface de usuário Interface de
usuário
Expressão da Página HTML que
palavra-chave contém a lista
Gerador
de HTML Nível de
Gerador de Lista ordenada processamento
consultas de títulos de
Algoritmo de páginas
Consultas ao banco ordenação
de dados
Títulos de páginas Web Nível de

com metainformação dados
Banco de dados
com páginas web

Na arquitetura cliente-servidor, há diversas configurações e
a organização mais simples seria a de ter três níveis lógicos com
apenas dois tipos de máquina (organização física), uma máquina
cliente que abrange apenas o nível de interface do usuário e uma
máquina servidor responsável pelo nível de processamento e dados,
em que tudo é manipulado pelo servidor. Para organizar clientes
e servidores, uma solução é distribuir os programas presentes na
camada de aplicação, considerando que muitas aplicações cliente-
servidor visam a dar suporte ao acesso de usuários a banco de
dados, como ilustraremos na Figura 1.15.
Figura 1.15 | Alternativas de organizações Cliente-Servidor

Máquina cliente
Interface de Interface de Interface de Interface de Interface de
usuário usuário usuário usuário usuário
Aplicação Aplicação Aplicação
Banco de
dados
Interface
de usuário
Banco de dados Banco de dados Banco de dados Banco de dados Banco de dados
Máquina servidora
(a) (b) (c) (d) (e)
Esclarecendo a Figura 1.15, no item (a), teremos a máquina

cliente só a parte de interface do usuário, que é dependente do
terminal. As aplicações controlam remotamente a apresentação
dos dados.
No item (b), é mostrada a possibilidade de colocar todo software
de interface de usuário no lado cliente. Assim sendo, o software
cliente não faz nenhum processamento, apenas os necessários para
apresentar à interface da aplicação.
No item (c), deslocamos parte da aplicação na máquina cliente
e na máquina servidor, por exemplo, um formulário que precise ser
completamente preenchido antes de poder ser processado.
No item (d), pode-se usar quando a máquina cliente é um
computador pessoal ou estação de trabalho, conectado por uma
rede a um sistema de arquivo distribuído ou a um banco de dados.

Aqui a aplicação é executada na máquina cliente, porém todas as
operações com arquivos ou entrada em banco de dados serão
feitas pela máquina servidor. Temos como exemplo algumas
transações bancárias.
O item (e) representa a situação em que o disco local do
cliente contém parte dos dados. Como exemplo, pode-se trazer
que ao consultar a web com seu browse, um cliente pode
construir aos poucos uma cache em disco local com páginas web
recentemente consultadas.
Temos que observar que aqui mostramos apenas as divisões
claras em máquinas clientes e máquinas servidor. Mas há situações
em que um servidor necessita agir como cliente, conforme
mostrado da Figura 1.16 e, como exemplo, temos o processamento
de transações.
Figura 1.16 | Servidor que age como cliente
Esperar resultado
Interface
de usuário Operação Retornar
(apresentação) de requisição resultado
Servidor de
Esperar dados
aplicação
Requisitar Retornar
dados dados
Servidor de
banco de dados
Tempo
b) Arquiteturas descentralizadas
Nessa arquitetura, os componentes não estão mais orientados
a requisições. Outra característica é colocar componentes
logicamente diferentes em máquinas diferentes.
c) Arquiteturas par a par ou em inglês peer-to-peer (P2P)

Dentro deste contexto, Brito (2005) diz que a tecnologia
peer-to-peer (P2P) vem se destacando como uma das grandes

topologias de sistemas distribuídos da atualidade. Essa tecnologia
vem recebendo maior atenção tanto de pesquisadores quanto
de empresas, uma vez que oferece benefícios com um
baixo custo operacional. Dentre esses benefícios, destaca-
se o compartilhamento de recursos, que pode ser mais
objetivamente referenciado como o compartilhamento de
serviços e conteúdos.
Basicamente, a arquitetura é formada, segundo Tanenbaum
(2007), de uma perspectiva de alto nível, os sistemas que constituem
a p2p são todos iguais, significando que as funções que precisam
ser realizadas, são representadas por todo processo que constitui o
sistema distribuído.
Cada processo agirá como um cliente e um servidor ao
mesmo tempo, em função disso, arquiteturas peer-to-peer,
desenvolvem-se em como organizar os processos em uma
rede de sobreposição, ou seja, uma rede na qual os nós são
formados pelos processos e os enlaces representam os canais
de comunicação possíveis, que geralmente são realizados como
conexões TCP.
Tanenbaum (2007) classifica a arquitetura peer-to-peer em dois
tipos básicos: a estruturada e a não estruturada.
d) Arquiteturas par a par ou em inglês peer-to-peer

(P2P) estruturada
Nesse modelo, a rede de sobreposição é construída com a
utilização de um procedimento determinístico. É usada uma tabela
de hash distribuída.
Conforme apresentado na Figura 1.17, a arquitetura estrururada
é aquela que contém um servidor central, responsável pelo
mecanismo de busca e manutenção da infraestrutura, deixando
a cargo dos peers participantes o compartilhamento de recursos,
serviços e conteúdos de forma distribuída. Um exemplo de um
sistema deste tipo é o Napster, usado para o compartilhamento
de músicas.

Figura 1.17 | Arquitetura P2P estruturada
Peer
Central
Peer
Cliente
Peer
Cliente
Peer
Cliente
Peer
Cliente
Fonte: Brito (2005, p. 21).
Para Brito (2005), basicamente todos os clientes se conectam

ao servidor central e confirmam quais dentre seus arquivos serão
compartilhados. Assim, quando um peer quer encontrar um
arquivo, envia uma solicitação para o servidor. O servidor informa
qual peer possui o arquivo desejado e inicia-se o tráfego de dados
entre os peers. No entanto, se este peer central ficar inoperante
ou falhar, a rede não funcionará mais, com exceção dos peers
conectados no momento em que o peer central falhou, isto é, que
estavam transferindo dados entre si, permanecendo até a completa
transferência dos dados.
e) Arquiteturas par a par ou em inglês peer-to-peer (P2P)

não estruturadas
Os sistemas peer-to-peer não estruturadas, dependem, em grande
parte de algoritmos aleatóriospara construir uma rede de sobreposição.
Brito (2005) diz que é aquela que possui todos os seus peers
participantes de forma descentralizada, caracterizando-se assim,
pela completa descentralização de seu funcionamento. Conforme
a Figura 1.18.

Não existe um peer central e os mecanismos de busca e
manutenção da infraestrutura, assim como o compartilhamento
de recursos, serviços e conteúdos estão distribuídos pela rede, em
cada peer. Nessa arquitetura, cada peer é responsável por manter
informações sobre seus próprios dados e, consequentemente, ao
receber uma solicitação de consulta, respondê-la e/ou reescreve-
la aos peers a ele conectado. Para isso, essa arquitetura faz uso
da técnica de “flooding” ou inundação, que consiste em “inundar”
a rede com a consulta e retornar os resultados encontrados ao
peer solicitante. Porém, para evitar que a rede fique saturada, as
consultas são limitadas a um número máximo de peers. Pode-
se observar então que, mesmo que um peer esteja “on-line”
e possua a resposta à consulta, ele pode não ser consultado
podendo a resposta à consulta ficar incompleta, diminuindo assim
a confiabilidade do sistema.
Figura 1.18 | Arquitetura P2P não estruturada
Peer
Servent
Peer
Servent
Peer
Servent
Peer
Servent
Peer
Servent
Fonte: Brito (2005, p. 22).
2.2.3 | Arquiteturas híbridas
Essa arquitetura utiliza arquiteturas cliente-servidor combinadas

com arquiteturas descentralizadas.

a) Sistemas de servidor de borda
Conforme Tanembaum (2005), esses sistemas são
disponibilizados na Internet onde servidores são colocados “na
borda” da rede. Essa borda é formada pela fronteira entre as redes
corporativas e a Internet propriamente dita, por exemplo, como
fornecida por um provedor de serviços de Internet (ISP).
Esse sistema está na Figura 1.19.
Figura 1.19 | Visão da internet como rede composta por um conjunto de servidores
de borda
b) Sistemas distribuídos colaborativos

O início pode ser como um esquema cliente-servidor tradicional,
tão logo o nó se junte ao sistema, ele poderá usar um esquema
totalmente descentralizado para colaboração. Se considerarmos o
sistema de compartilhamento de arquivos BitTorrent (Cohen, 2003),
trata-se de um sistema peer-to-peer de transferência (download) de
arquivos. Seu funcionamento está na Figura 1.20.
Figura 1.20 | Funcionamento principal do BitTorrent

Nó cliente
k de N nós
Nó 1
Lockup (F)
Nó 2
Uma página Arquivo Lista de nós que
Web BitTorrente Ref. a .torrent para F Ref. a armazenam F
servidor de rastreador
Servidor Web arquivo Servidor de Rastreador
arquivo Nó N

A ideia básica é de que, quando um usuário final estiver
procurando um arquivo, ele transfira pedaços do arquivo de outros
usuários, até que os pedaços transferidos possam se montados em
conjunto, resultando no arquivo completo.
Estudamos que os estilos arquitetônicos e arquitetura de sistemas

distribuídos têm como objetivo possuir baixo custo operacional, como
o compartilhamento de serviços e conteúdos. Assim, cada vez que
necessitarmos implementar mais nossos sistemas distribuídos devemos
não perder o foco de nosso objetivo ao projetar nosso sistema.
1. Tanenbaum (2007) nos traz algumas definições quanto aso sistemas
distribuídos. Complete a lacuna.
_________________________, é formada uma organização virtual, fazendo com
que os direitos de acesso aos recursos da organização à qual você pertence
sejam compartilhados, oferecendo facilidades de armazenamento e banco
de dados, além de sensores.
Assinale a alternativa correta:

a) Computação em cluster.
b) Computação em grade.
c) Computação em rede.
d) Computação em cliente.
e) Computação em servidor.
2. Quanto à arquitetura de sistemas, possuímos alguns tipos. Analise as

afirmativas abaixo:
I. Centralizadas.
II. Híbridas.
III. Completas.


Fique ligado
Aqui estudamos sistemas distribuídos em seus estilos
arquitetônicos, que são:
a) Arquiteturas em camadas.
b) Arquiteturas baseadas em objetos.
c) Arquiteturas centradas em dados.
d) Arquiteturas baseadas em eventos.
Na sequência, vimos as arquiteturas centralizadas, distribuídas e
híbridas. Relembrando que os componentes a serem usados são de
extrema importância, o modo como eles se conectam e os dados
trocados entre os componentes são a base para nossas arquiteturas
de sistemas distribuídos.
Para concluir o estudo da unidade

Quando definir uma arquitetura de sistemas distribuídos,
devemos elencá-la de acordo com o objetivo, funcionamento e
características do sistema proposto.
Atividades de aprendizagem da unidade

Banca: CESPE
Órgão: INMETRO
Prova: Analista Executivo em Metrologia e Qualidade - Desenvolvimento
de Sistemas (adaptada)
distribuidos>. Acesso em: 25 set. 2018.
Quanto à programação distribuída, analise as afirmativas abaixo:

I. Faz-se uso de passagem de mensagens síncronas.
II. Faz-se uso de passagem de mensagens assíncrona.
III. Embora o compartilhamento de memória possa ser realizado por meio
do uso de sistemas centrados em bancos de dados cliente-servidor.


Banca: CESGRANRIO
Órgão: TJ-RO
Prova: Agente Judiciário - Analista de Sistemas (Desenvolvimento)
distribuidos>. Acesso em: 25 set. 2018.
Analise as afirmativas a seguir, a respeito de sistemas distribuídos.
I - Uma das principais diferenças entre um sistema distribuído e um sistema

em rede é que, do ponto de vista do usuário, o sistema distribuído se
comporta como uma única máquina, enquanto o sistema em rede expõe
ao usuário as diversas máquinas separadamente.
II - Em um sistema distribuído, uma migração de processo entre nós do
sistema pode ser feita para proporcionar balanceamento de carga ou
aceleração da computação, sendo esta através da divisão do processo em
subprocessos que executem em paralelo.
III - Os nós de um sistema distribuído podem executar diferentes
sistemas operacionais.
Está(ão) correta(s) a(s) afirmativa(s)

a) I, apenas.
b) II, apenas.
c) I e II, apenas.
d) II e III, apenas.
e)I, II e III.

Banca: CESGRANRIO
Órgão: Petrobras
Prova: Analista de Sistemas Júnior - Infra-Estrutura
Sobre o processamento paralelo e distribuído, assinale a afirmação correta.

a) 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 por meio
de algum tipo de coordenação.
b) A execução de tarefas em um ambiente de processadores distribuídos
com acoplamento fraco prevê que a memória seja compartilhada entre os
processos trabalhadores.
c) Em programação paralela, não é necessário se conhecer a arquitetura
de comunicação entre processadores para elaborar os programas.
d) Um grid computacional pode ser formado por diversos computadores,
heterogêneos, que não podem estar distribuídos via web por problemas
de segurança.
e) Um sistema distribuído fortemente acoplado é formado por um
ambiente de computadores dotados de memória e sistema operacional
próprios, que se comunicam via switch.

Banca: CESGRANRIO
Órgão: Petrobras
Prova: Analista de Sistemas Pleno - Infra-estrutura
Um sistema distribuído é definido como uma coleção de computadores
independentes que se apresenta ao usuário como um sistema único e
consistente. Baseado nos conceitos definidos para sistemas distribuídos,
identifique a afirmativa ERRADA:
a) O modelo de computação distribuída peer-to-peer é uma tecnologia
que estabelece uma espécie de rede virtual de computadores, em que
cada estação tem capacidades e responsabilidades equivalentes.
b) Um sistema distribuído fortemente acoplado provê um nível de
integração e compartilhamento de recursos mais intenso e transparente
ao usuário, em que vários processadores compartilham uma memória, e
são gerenciados por apenas um sistema operacional.
c) Um sistema distribuído fracamente acoplado permite que máquinas e
usuários do ambiente sejam fundamentalmente independentes, bem como
a interação de forma limitada, quando isso for necessário, compartilhando
recursos como discos e impressoras, entre outros.
d) Uma vantagem dos sistemas distribuídos sobre os sistemas centralizados
é a disponibilidade de software para este tipo de ambiente.
e) Uma aplicação cliente-servidor é um caso especial de processamento
distribuído no qual existe uma forma de cooperação entre dois ou mais

processos, sendo essa cooperação realizada por meio de requisições dos
componentes alocados ao cliente e das respostas que são fornecidas
pelos componentes alocados ao servidor.

Banca: CESGRANRIO
Órgão: Petrobras
Prova: Analista de Sistemas Pleno - Infra-estrutura
Um sistema distribuído é definido como uma coleção de computadores
independentes que se apresenta ao usuário como um sistema único e
consistente. Baseado nos conceitos definidos para sistemas distribuídos,
identifique a afirmativa ERRADA:
a) O modelo de computação distribuída peer-to-peer é uma tecnologia
que estabelece uma espécie de rede virtual de computadores, em que
cada estação tem capacidades e responsabilidades equivalentes.
b) Um sistema distribuído fortemente acoplado provê um nível de
integração e compartilhamento de recursos mais intenso e transparente
ao usuário, em que vários processadores compartilham uma memória, e
são gerenciados por apenas um sistema operacional.
c) Um sistema distribuído fracamente acoplado permite que máquinas e
usuários do ambiente sejam fundamentalmente independentes, bem como
a interação de forma limitada, quando isso for necessário, compartilhando
recursos como discos e impressoras, entre outros.
d) Uma vantagem dos sistemas distribuídos sobre os sistemas centralizados
é a disponibilidade de software para este tipo de ambiente.
e) Uma aplicação cliente-servidor é um caso especial de processamento
distribuído no qual existe uma forma de cooperação entre dois ou mais
5. Provas: CESGRANRIO - 2011 - TRANSPETRO - Analista de Sistemas

Júnior (adaptada)
Disciplina: Arquitetura de Software (TI) - Assuntos: Arquitetura
Cliente-Servidor
Em aplicações distribuídas, dois modelos usados são o cliente/servidor
(cliente-server, C/S) e o ponto a ponto (peer-to-peer, P2P). Nesse
contexto, analise as afirmações abaixo.
I) Assim como no modelo C/S, no modelo P2P, qualquer nó pode iniciar
uma conexão com qualquer outro nó.
II) Diferente do modelo C/S, o modelo P2P se caracteriza por apresentar a
mesma largura de banda nas conexões entre dois nós quaisquer da rede.
III) Processamento relativo à sincronização e à comunicação entre nós
pode sobrecarregar tanto uma rede C/S quanto uma rede P2P.

São corretas APENAS as afirmativas:
a) I e II.
b) I e III.
c) II e III.
d) II.
e) III.

Referências
BRITO, G. A. D. D.; MOURA, A. M. de C. Integração de dados: dos sistemas
tradicionais a sistemas P2P. Relatório Técnico n o RT112/SE9/ABR05. IME -
Instituto Militar de Engenharia, Rio de Janeiro, abril 2005.
BUYYA, R. High Performance Cluster Computing, v. 1, Architectures and Systems.
Upper Saddle River, NJ: Prentice Hall PTR, 1999.
CAMPOS, A. Sistemas de segurança da informação: controlando os riscos. 2 ed.
Florianópolis: Visual Books, 2007.
CARVALHO, G.; LOTITO, A. Tecnologias de acesso à internet. São Paulo: Novatec
Editora Ltda., 2005.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Sistemas distribuídos: conceitos
e projeto. Bookman Companhia Ed., 2007
EVANS, D. A internet das coisas como a próxima evolução da Internet está
mudando tudo. Chefe da Cisco para o Cisco IBSG. 2011. Disponível em: <https://
www.cisco.com/c/dam/global/pt_br/assets/executives/pdf/internet_of_things_
iot_ibsg_0411final.pdf>. Acesso em: 5 ago. 2018.
FOSTER, I.; KESSELMAN, C.; NICK, J.; TUECKE, S. The physiology of the grid: An
open grid services architecture for distributed systems integration. Open Grid
Service Infrastructure. WG, Global Grid Forum, 2002.
CAMPOS, R. S. A utilização de uma grade computacional para um problema
inverso da eletrofisiologia cardíaca. <https://www.researchgate.net/
publication/272785590_A_utilizacao_de_uma_grade_computacional_para_um_
problema_inverso_da_eletrofisiologia_cardiaca>. Acesso em: 25 set. 2018.
INFSO D.4 NETWORKED ENTERPRISE & RDID INFISO G.2 MICRO & NANOSYSTEMS.
Internet of things in 2020. EPoSS, v. 3, 2008.
LAMPORT, L. Time, clocks, and the ordering of events in a distributed system.
Communications of the ACM 21, p. 558-565. 1978.
MORAES, A. F. de. Redes de computadores. São Paulo: Ética, 2014.
NAPSTER. WEB site oficial. Disponível em: <http://www.napster.com>. Acesso
em: 25 set. 2018.
NEUMAN, B. C. Scale in distribuited systems. Readings in distributed Computing
Systems. p. 463-489. 1994.
SOUSA, L. B. de. Redes de computadores: dados, voz e imagem. São Paulo:
Editora Érica. 1999.
TANENBAUM, A. S. STEEN, M. van. Sistemas distribuídos: principios e paradigmas.
São Paulo: Pearce Prentice Hall, 2007.
WEBER, T.; Jansch-Pôrto, I.; Weber, R. Fundamentos de tolerância a falhas.
Vitória: SBC/UFES, 1990. (apostila preparada para o IX JAI - Jornada de Atualização
em Informática, no X Congresso da Sociedade Brasileira de Computação).
Unidade 2
Redes e sistemas
distribuidos
Nathalia dos Santos Silva Nolepa
Nesta unidade você será apresentado aos conceitos
que compõem a base da comunicação entre processos de
componentes autônomos e desacoplados, ou seja, como
funcionam os protocolos, serviços e a troca de mensagens
que garante a interação dos componentes, para que os
sistemas distribuídos operem como conhecemos, como um
sistema único e coerente, seja na perspectiva cliente-servidor
ou em grupo.
Assim, a partir do conhecimento desse esquema de
organização, hierarquia e funcionamento, você entenderá
tanto como os processos se comunicam de maneira remota
quanto como funcionam internamente os sistemas com
essas características.
Para o usuário, o sistema distribuído se comporta como
um sistema tradicional, unificado, mesmo que ele possua seus
recursos fisicamente distribuídos em diversos computadores.
O nosso desafio, enquanto projetista de sistemas, consiste
basicamente em gerenciar as trocas de mensagens para o
compartilhamento seguro e coerente de recursos.
As propostas de arquitetura e organização discutidas
nesta unidade em geral são comuns aos mais diversos
sistemas distribuídos, pois embora eles possuam variação
em sua aplicação ao usuário final e os tipos de recursos que
compartilham, a comunicação entre os dispositivos e o acesso
a métodos internos é definida e implementada de maneira
padronizada, dentro de 4 tipos arquitetônicos definidos. A partir
do aprendizado dessas técnicas de comunicação remota, já
consolidadas, você poderá melhorar rotinas já existentes e
ainda criar novas aplicações.
Seção 1 | Introdução à comunicação entre processos

A Seção 1 trata da comunicação entre processos, especificamente
da camada middleware, em que são definidos os serviços prestados
para garantir as chamadas remotas de processos. Nesta seção,
além da descrição como as camadas de redes estão organizadas
para atender os sistemas distribuídos, serão apresentados também
outros tipos de arquiteturas.
Seção 2 | Comunicação cliente-servidor e comunicação em grupo

A Seção 2 apresenta as características da comunicação cliente-
servidor, essa topologia possui diversas aplicações, como os meios
que um cliente tem para acessar à conta bancária, via aplicativo
de celular e caixa eletrônico, que de maneira similar consultam
um servidor sobre os dados desejados. O principal conceito nessa
topologia é que clientes e servidores possuem responsabilidade
e ações diferentes. Na mesma seção também é apresentado o
conceito de comunicação em grupo, quais são os papéis dos nós e
qual a complexidade envolvida na troca de mensagens do grupo de
sistemas distribuídos. Essa disposição, em grupo, também influencia
nas aplicações a que se destina essa topologia, por exemplo, a
internet como a conhecemos é um tipo dessa comunicação.
O nosso mundo está cercado de informações que são
compartilhadas pelas pessoas e organizações, e de maneira similar,
os sistemas distribuídos compartilham dados, recursos e interagem
como se formassem um sistema único e conciso. As pessoas trocam
informações de maneira natural, quando se faz necessário, por
meio de códigos escritos e orais, mas você já se perguntou como
os elementos dos sistemas distribuídos se comunicam? Ou como
tecnicamente é possível que um dispositivo acesse um recurso físico
ou lógico em um outro objeto, mantendo a integridade, segurança
e operação de si mesmo e do outro?
E do ponto de vista financeiro, você concorda que compartilhar
uma impressora em um escritório é mais econômico do que cada
colaborador necessitar de uma impressora particular? Nesse caso,
a impressora e os computadores envolvidos formam uma rede de
sistemas distribuídos.
As redes de comunicação estão densamente presentes no nosso
contexto atual, como a internet, os bancos de dados distribuídos,
os aplicativos de celulares que trocam informações entre si, e
outros que discutiremos adiante os quais operam como sistemas
distribuídos, ou seja, seu funcionamento está integrado por meio
da troca de mensagens. Algumas têm maior grau de dependência
entre os dispositivos envolvidos, outras menos, e em geral isso ajuda
a definir se elas atuam em conjunto ou separadamente. Além disso,
mesmo que suportando diferentes níveis de exigência, as redes de
sistemas distribuídos precisam ser transparentes ao usuário final, e
essa característica também influencia na fidelidade desses sistemas.
Além dos aspectos apresentados existem outros importantes e
também interessantes, e como impactam diretamente na forma
como as mensagens são trocadas entre os dispositivos, nós
discutiremos esses assuntos na nossa Unidade!
Num mundo onde muito se discute sobre internet das coisas (IoT)
e suas mais variadas aplicações, é essencial conhecer as formas de
implementação desses sistemas, as técnicas já consolidadas, suas
limitações, a complexidade envolvida no aumento de dispositivos,
os desafios, e os pontos a serem melhorados. Ao mesmo tempo
vivemos na era da informação e o armazenamento de dados é visto
como parte importante das aplicações. Cada dispositivo, com sua
arquitetura e seus recursos de hardware, interfere no projeto da
rede quanto ao compartilhamento de memória ou não.
O capítulo está definido da seguinte maneira:
Na Seção 1 veremos como está organizada a camada
middleware, quais são as requisições que ela atende e como ela
endereça essas requisições aos protocolos TCP e UDP das camadas
inferiores. Estudaremos como os blocos básicos de comunicação
são configurados para atuar em uma comunicação por datagramas
ou por fluxo (stream), e também discutiremos suas diferenças. Além
da comunicação por meio da arquitetura em camadas, iremos
estudar outros estilos arquitetônicos para sistemas distribuídos e
seus respectivos middlewares.
Na Seção 2 entenderemos como funciona a comunicação
cliente-servidor, quais suas aplicações e como são caracterizados
os papéis dessas duas classes. Em geral, as mensagens de requisição
e resposta fornecem a base para a definição cliente-servidor na
comunicação remota. Aprenderemos, ainda, os conceitos envolvidos
na comunicação em grupo, quais suas aplicações e como essa rede
é caracterizada. Nosso estudo também inclui como uma mesma
mensagem é enviada para vários processos e as consequências
dessa troca de mensagens na complexidade da rede.
Seção 1
Introdução à comunicação entre processos
A arquitetura é uma abordagem utilizada para estudo e descrição

de diversas áreas da Computação, seja envolvendo software ou
hardware. Quando buscamos entender o funcionamento de um
sistema ou um equipamento, o primeiro passo é entender sua
arquitetura, ou seja, como se dá a sua descrição, organização e o
fluxo de dados internos.
Os estilos arquitetônicos mais importantes para os sistemas
distribuídos são classificados em arquiteturas em camadas,
arquiteturas baseadas em objetos, arquiteturas centradas em dados
e arquiteturas baseadas em eventos (TANENBAUM; STEEN, 2007).
Para sistemas distribuídos e redes em geral, a arquitetura mais
conhecida é a arquitetura em camadas, nesta proposta as camadas
mais superiores, próximas ao usuário, solicitam ações, recursos
ou dados das camadas inferiores, e essas camadas inferiores, mais
próximas dos Sistemas Operacionais e do hardware, executam
as solicitações das camadas de cima e fornecem a elas os
dados solicitados.
No contexto de Sistemas Distribuídos, independentemente
da arquitetura, as estruturas que garantem a comunicação entre
processos são:
• As interfaces de alto nível para programar os sistemas.
• As características dessas interfaces para os protocolos TCP e
UDP, Transmission Control Protocol (Protocolo de Controle
de Transmissões) e User Datagram Protocol (Protocolo de
Datagrama de Usuário) respectivamente.
• A camada intermediária entre elas, chamada middleware,
que garante uma operação de comunicação comum aos
diversos nós, conforme os tipos de arquiteturas.
Consideramos um conjunto de sensores atuando em um mesmo
contexto para cuidar de um processo como redes de sensores,
U2 - Redes e sistemas distribuidos 53

redes corporativas, redes domésticas ou redes veiculares, cada
um, de todos esses nós envolvidos, deve ter uma mesma camada
middleware para oferecer uma mesma interface à aplicação
desejada. Independentemente da arquitetura definida, umas das
premissas é definir:
• Se a comunicação deve ser TCP ou UDP, pelo compromisso
confiabilidade x rapidez, lembrando que o protocolo TCP
controla e garante a completude da transmissão e, por
suas verificações, acaba sendo mais lento, já o protocolo
UDP, ao contrário do TCP, é mais rápido por não garantir
retransmissões em caso de erro, nesse caso é a aplicação
que deve tomar esse cuidado.
• Se a comunicação será do tipo cliente-servidor, também
chamada de comunicação centralizada, ou em grupo, que é
conhecida como comunicação descentralizada.
E a partir dessas definições, implementar os componentes de

interface e de middleware, conforme o estabelecido para a troca
de mensagens.
Cada uma dessas formas de comunicação tem uma série de
mecanismos para garantir acesso e compartilhamento de maneira
controlada de seus recursos, para os nós solicitantes e solicitados.
1.1 | Arquitetura de comunicação dos sistemas

distribuídos
Dependendo de como são os modos de operação dos sistemas

distribuídos e da conexão entre seus componentes podemos
classificá-los em quatri tipos de arquitetura:
1.1.1 | Arquitetura em camadas
Assim como em Redes de Computadores tradicionais, nós

temos o sistema de camadas conhecido como OSI (Open Systems
Interconnection), que significa Sistema Aberto de Interconexão,
um padrão largamente utilizado e consolidado do ponto de vista
54 U2 - Redes e sistemas distribuidos

conceitual. Essa estrutura descreve como é a organização das
camadas envolvidas na comunicação para solicitação e troca
de mensagens, visando a prestação de serviços finais, ou seja, a
comunicação dos dispositivos distribuídos na rede.
Da mesma forma que em redes de computadores, o modelo
é conceitual e cada tecnologia possui suas técnicas e estratégias
de funcionamento, possibilidade de adaptação/flexibilização de
camadas e implementação. Uma descrição exemplificada dessa
organização é descrita no Quadro 2.1. De forma natural, quanto mais
baixa a camada, mais interação e controle do hardware ela tem, e
quanto mais acima, mais de alto nível é seu acesso, os aplicativos
são as plataformas visíveis responsáveis pela interação direta com os
usuários ou outros sistemas.
As camadas superiores fazem requisições às camadas inferiores
e as camadas inferiores respondem às camadas superiores,
considerando cada camada L descrita no modelo, a camada Ln
requisita serviços à camada Ln-1 .
Quadro 2.1 | Modelo OSI com exemplos de técnicas
Camada Descrição Exemplos

Aplicativo Nível em que os protocolos são HTTP, FTP,
definidos para uma interface de serviço. SMTP
Apresentação Nível para transmissão de dados Segurança TLS,
em que a representação de redes é CORBA Data Rep.
independente das utilizadas em cada
computador envolvido na transmissão.
Sessão Nível para confiabilidade, detecção de SIP

falhas e recuperação automática.
Transporte Nível mais baixo de tratamento TCP, UDP
de mensagens antes de serem
organizadas em pacotes. As
mensagens são endereçadas para
portas de comunicação associadas aos
processos. Seus protocolos podem ser
orientados à conexão ou não.
Rede Nível em que os pacotes de dados são IP, circuitos
transferidos pela rede, por meio de virtuais ATM
roteamento e tabelas de rotas ou ainda
de maneira local.

Enlace Nível responsável pela transmissão de MAC Ethernet,
pacotes em uma conexão física, por PPP
meio de roteadores ou hosts.
Física Nível em que estão os circuitos e o Sinalização
hardware da rede, modulando os sinais de banda-base
em dados binários sequenciais que Ethernet, ISDN
trafegam no meio sendo sinais elétricos,
luminosos ou eletromagnéticos de
uma forma geral.
Fonte: adaptado de Coulouris, Dollimore e Kindberg (2007, p. 81).
Na comunicação entre os dispositivos distribuídos, assim como

em qualquer comunicação em rede, temos uma organização
também em camadas, como pode-se observar na Figura 2.1.
Figura 2.1 | Arquitetura em camadas
Fonte: adaptada de Tanenbaum e Steen (2007, p. 21).
O estilo em camadas é importante porque em outros estilos

arquitetônicos também são adotados os conceitos de camada,
partindo do modelo OSI mais básico, o estilo em camadas se
estende para a organização interna dos outros estilos.

1.1.2 | Arquitetura baseadas em objetos
A arquitetura baseada em objetos é considerada a arquitetura

mais solta entre as existentes, cada objeto é um componente e eles
se comunicam por meio de chamadas de procedimentos remotas
(TANENBAUM; STEEN, 2007).
Exemplos clássicos de aplicação são:
• O Java RMI (Remote Method Invocation), que significa a
invocação de método remoto.
• O RPC (Remote Procedure Call), que siginifica a chamada de
procedimento remoto.
• O CORBA (Common Object Request Broker Architecture),
uma arquitetura para comunicação de objetos distribuídos.
Nessas técnicas, é permitido que seja chamado um método ou
um procedimento de outro objeto, similar ao que conhecemos na
Programação Orientada a Objetos.
Uma ilustração de como está disposta essa arquitetura é
encontrada na Figura 2.2.
Figura 2.2 | Arquitetura baseada em objetos

Juntamente com a arquitetura baseada em camadas, as duas
fornecem os conceitos mais importantes para a descrição dos
sistemas distribuídos. Internamente, a arquitetura baseada em
objetos também possui uma organização em camadas, juntamente
com sua interface, camada middleware descrita ao longo desta
seção e camada de protocolos.
Essa organização pode ser visualizada na Figura 2.3.
Figura 2.3 | Arquitetura baseada em objetos e sua organização interna
Aplicativos
RMI e RPC
Fluxo de Protocolos e Fluxo de

requisição resposta
empacotamento
TCP e UDP
Sistemas Operacionais
Quando um cliente invoca um método em um objeto remoto,

uma mensagem de invocação é enviada para o processo no servidor
que contém o objeto remoto, essa mensagem deve especificar qual
o objeto terá seu método executado (TANENBAUM; STEEN, 2007). O
identificador é responsável por especificar qual objeto deve ser ativado,
ele é uma referência de objeto remoto e costuma utilizar-se de dados de
IP, porta e horário para obtenção de um identificador único. Podemos
visualizar o esquema de criação no identificador na Figura 2.4.

Figura 2.4 | Representação de uma referência de objeto remoto
Fonte: adaptada de Coulouris, Dollimore e Kindberg (2007, p. 146).
1.1.3 | Arquiteturas centradas em dados
Quando consideramos sistemas distribuídos que compartilham

arquivos de um repositório em comum, essa arquitetura é chamada
arquitetura centrada em dados. Uma das aplicações muito
conhecida desta arquitetura é a Web, a internet como conhecemos
e utilizamos.
O esquema gráfico representando essa arquitetura é visto na
Figura 2.5.
Figura 2.5 | Arquitetura centrada em dados

1.1.4 | Arquiteturas baseadas em eventos
Uma arquitetura também considerada fracamente acoplada é a

arquitetura baseada em eventos, como encontramos em Tanenbaum
e Steen (2007). Nessa arquitetura os processos se comunicam por meio
da propagação de eventos e eventualmente transmitem dados também,
esses sistemas também são chamados de sistemas publicar/escrever. O
funcionamento dessa arquitetura está descrito na Figura 2.6.
Figura 2.6 | Arquitetura baseada em eventos
Ao combinar arquitetura centrada em dados com arquitetura

baseada em eventos, surgem os espaços compartilhados de dados,
que têm como principal característica serem desacoplados no tempo,
não precisam estar ambos ativos quando ocorre a comunicação.
1.2 | A camada middleware
O propósito da camada middleware é mascarar a heterogeneidade

das camadas inferiores, bem como fornecer um modelo de
programação conveniente para os programadores, já que é por

meio dessa camada que a implementação da comunicação será
dada (COULOURIS; DOLLIMORE; KINDBERG, 2007). A Figura 2.7
ilustra como é o esquema da camada middleware nas arquiteturas
de sistemas distribuídos.
Adotar uma camada de middleware significa simplificar as
atividades de comunicação, como invocação de métodos remotos,
notificações de eventos e recuperação de objetos de dados. Para
cada estilo arquitetônico adotado existem middlewares específicos
e adequados.
Figura 2.7 | Camada middleware
Computador 1 Computador 2 Computador 3 Computador 4
Aplicação A Aplicação B Aplicação C
Camada do sistema distribuído (middleware)
Sistema Sistema Sistema Sistema

Operacional Operacional Operacional Operacional
Local 1 Local 2 Local 3 Local 4
Em geral uma das desvantagens dos middlewares é que nem

sempre o programador consegue que essa camada atenda
exatamente o sistema conforme ele tinha planejado, já que
estas estruturas não costumam ser adaptáveis ou moldáveis
(TANENBAUM; STEEN, 2007). Quando características de outras
arquiteturas são adicionados a determinados estilos arquitetônicos,
por necessidade de adaptação, o middleware resultante certamente
será inchado, o que não é adequado do ponto de vista conceitual e
de implementação (TANENBAUM; STEEN, 2007).
Algumas estratégias são desenvolvidas para que o comportamento
do middleware possa ser modificado e, assim, ele passa a atender
às necessidades da aplicação, entre elas estão os softwares
interceptores de fluxos que, como o próprio nome descreve, estão
inseridos entre a aplicação solicitante e o middleware e também

entre o middleware e o sistema operacional (TANENBAUM; STEEN,
2007). Para que você visualize como esa estratégia é implementada,
considere a Figura 2.8. Pode-se observar que a chamada é
interceptada em dois momentos: nível de requisição e nível de
mensagem, esses dois momentos em que a chamada é interceptada
permitem que aplicação e o Sistema Operacional, em conjunto,
atendam a demanda pretendida, sem que seja necessário alterar
os parâmetros/funcionalidades do middleware. A interceptação
consegue executar as ações, do Objeto, por meio da função Ação
e os parâmetros indicados, que seriam inviáveis ou impossíveis sem
a interceptação, devido à falta de flexibilidade que o programador
tem junto ao middleware.
Figura 2.8 | Implementação dos softwares interceptadores
Aplicação Cliente
Objeto.Acao(parametro)
Chamada
interceptada
Chamada não
interceptada
Interceptação: nível
de requisição
Middleware Objeto
Interceptação: nível
de mensagem
Sistema Operacional Local
Send(Objeto, Acao(parametro))
Fonte: Tanenbaum e Steen (2007, p. 34).

A principal vantagem dessa estratégia é que ela é transparente
ao middleware, porém, a principal desvantagem é que o ambiente
no qual as aplicações distribuídas estão sendo executadas está
sempre mudando e isso impacta no QoS (Quality of Service), que
é a qualidade de serviço, no hardware defeituoso e no rápido
esgotamento da bateria.
Uma outra estratégia para adaptar o comportamento do
middleware para a aplicação desejada é conhecida como Software
Adaptativo, desenvolvido e ainda estudado com o objetivo de
melhorar os aspectos de confiabilidade, desempenho e segurança
(TANENBAUM; STEEN, 2007). Entretanto, devido à complexidade
de estender essas adaptações em grande escala, a ineficiência e
incoerência de se adotar as estratégias somente a alguns módulos,
não é uma estratégia que seja consolidada e amplamente aceita.
Mediante as características expostas, quando se trata de sistemas
distribuídos de grande escala, o ideal para desenvolvê-los é conhecer
as técnicas já existentes nos estilos arquitetônicos, como RMI, RPC,
CORBA, e adotar a mais propícia conforme a aplicação desejada, já
que o processo de adaptação, aumenta em complexidade à medida
que aumenta o número de dispositivos envolvidos. Essas camadas
intermediárias, precisamente a camada de RMI e RPC em conjunto
com os protocolos de empacotamento (TCP e UDP) fazem parte da
camada de middleware.
As camadas TCP e UDP e de Sistemas Operacionais são as
camadas que fornecem as características de comunicação comuns
a quaisquer outros sistemas que utilizam TCP e UDP, já que
fisicamente são padronizadas. Quando adotado o protocolo TCP, a
interface de comunicação na camada superior irá operar conforme
um fluxo (stream) bidirecional entre os pares de processos, é
como se a informação não tivesse fragmentos, é um fluxo com
início e fim (COULOURIS; DOLLIMORE; KINDBERG, 2007). Essa
abordagem, também é conhecida como produtor-consumidor.
Os itens a serem transmitidos são enfileirados pelo produtor, e o
consumidor quando pronto começa a recebê-los, o consumidor se
abastece até que acabe os itens. Se não houver nenhum item na fila,
o consumidor aguarda, em compensação, se o armazenamento da
fila estiver cheio é o produtor quem aguarda.

A transmissão também pode adotar como protocolo o UDP,
nesse caso a comunicação é por mensagens, essa é considerada
a forma mais simples de comunicação, já que as informações
são encapsuladas em um único pacote para envio, chamado de
datagrama. Esse datagrama é direcionado para o destino conforme
um soquete, que é a referência à porta de comunicação escolhida.
Já que utilizam TCP ou UDP, em geral as mensagens entre
sistemas distribuídos são trocadas por meio do IP e do número
da porta, considerando ainda que um processo pode receber
mensagens por meio de várias portas.
A técnica que garante essa funcionalidade são os soquetes, que
basicamente são um ponto de destino na comunicação. Para que
um processo receba mensagens, seu soquete deve estar vinculado
a uma porta local e a um dos endereços IP do computador em que
é executado (TANENBAUM, 2007).
1.3 | Características da comunicação entre processos
Em sistemas distribuídos, os processos (programas em execução)

formam blocos de construção, porém, observou-se que ao utilizar
múltiplas threads de controle por processo, isso tornava o sistema mais
eficiente (TANENBAUM; STEEN, 2007). Assim, garante-se múltiplas
conexões lógicas de forma simultânea, o que faz com que não seja
mais necessário aguardar uma resposta do servidor, permitindo que o
sistema execute outras tarefas nesse intervalo de tempo.
As mensagens trocadas entre um par de processos em geral são
send e receive, que em uma livre tradução significa enviar e receber.
Essa comunicação pode ser síncrona ou assíncrona.
No formato de comunicação síncrona, os processos remetente e
destino são sincronizados a cada mensagem (TANENBAUM; STEEN,
2007). A partir de uma mensagem de envio, o processo (ou thread) é
bloqueado até que de fato ocorra o recebimento dessa mensagem.
Da mesma forma, quando uma recepção é realizada, o processo (ou
thread) é bloqueado enquanto a mensagem não chegar.
Já na comunicação assíncrona, a mensagem enviada é copiada
para um buffer e o remetente não fica bloqueado, podendo
prosseguir em paralelo com o processo destino. A mensagem

recebida pode ser configurada para bloquear ou não bloquear o
destino, sendo que nos sistemas mais recentes normalmente atuam
de forma não bloqueante.
As mensagens podem ser armazenadas ou não pelo middleware,
a comunicação é chamada de persistente quando a mensagem é
armazenada durante o tempo necessário para entregá-la ao receptor,
enquanto na comunicação conhecida por transiente a mensagem é
armazenada somente durante a execução do remetente e do receptor.
Um outro ponto a ser destacado é a camada de empacotamento
de dados, representado conforme visto na Figura 2.3. Embora
os programas em execução armazenem suas informações em
estruturas de dados, para a comunicação esses dados precisam ser
representados de maneira mais simplificada, como uma sequência
de bytes, e entre as estratégias para esse empacotamento estão
(TANENBAUM; STEEN, 2007):
• Representação de dados comum do CORBA.
• Serialização de objetos da linguagem Java.
• XMl (Extensible Markup Language), a linguagem de marcação
extensível, elaborada para aplicações web.

Considerando a arquitetura baseada em objetos no Java RMI, como
deve ser a passagem de objetos nas mensagens (funções), por valor ou
por referência?
Para saber mais

A comunicação entre processos depende muito de como o
middleware para os protocolos adotados está configurado. Você pode
conhecer mais sobre esse assunto em: <https://www.youtube.com/
watch?v=Ip6bTK6_C0U>. Acesso em: 9 nov. 2018.
1. Os sistemas distribuídos estão cada vez mais presentes no nosso dia a

dia e embora seja uma área em constante evolução e melhoria de práticas,

existem alguns conceitos já consolidados para sua caracterização. Analise
as afirmações a seguir sobre os sistemas distribuídos e classifique-as em
verdadeiro ou falso:
( ) Os sistemas distribuídos são implementados somente em software,
atuando de maneira virtualmente distribuída.
( ) As arquiteturas baseadas em camadas e orientada a objetos são mais
utilizadas nos modelos de sistemas distribuídos, principalmente pela sua
proximidade aos conceitos que os originaram.
( ) Os sistemas distribuídos possuem uma camada de interface comum,
chamada middleware.
( ) Nos nós que atuam de maneira distribuída não existe distinção definida
de responsabilidade entre as camadas middleware, RPC/RMI e protocolos.

a) V; V; V; F.
b) V; F; V; F.
c) F; V; V; F.
d) F; F; V; F.
e) V; V; F; F.
2. Explique por que as aplicações RMI e RPC na implementação com TCP/

IP têm bloqueio.

Seção 2
Comunicação cliente-servidor e comunicação
em grupo
Na seção anterior estudamos as características da arquitetura
e organização interna da comunicação dos sistemas distribuídos,
nesta seção vamos estudar essa comunicação pensando em seu
dinamismo, na forma com que ocorre as trocas de mensagens.
Esse estudo naturalmente envolve as aplicações a que se destinam,
em um contexto prático são as especificidades delas que determinarão
se a arquitetura será centralizada, descentralizada ou híbrida.
A arquitetura centralizada é também chamada de cliente-servidor,
enquanto a arquitetura descentralizada é também conhecida como
comunicação em grupo.
2.1 | Cliente-servidor
A arquitetura é definida como cliente-servidor quando ela

possui um nó com um papel bem diferente dos outros envolvidos
na comunicação. Em geral, esse nó é o servidor, que costuma ser
o mantenedor dos dados, aquele que presta o serviço ou retorna
um processamento. Já os outros nós são os nós clientes, que
normalmente são os nós que requisitam serviços ao servidor, por esse
motivo, também, essa interação é conhecida como comportamento
de requisição-resposta (TANENBAUM; STEEN, 2007).
Você já deve ter pensado nisso quando se trata de sistemas
distribuídos, ao fazer a pergunta: quem controla tudo isso? Bem, o
servidor não necessariamente controla os nós, as falhas ou como a
comunicação ocorre.
O papel bem definido do servidor é manter a aplicação com
seus dados e funções à disposição dos clientes. Você viu na
unidade anterior que se o sistema tivesse um controle centralizado
ele não seria distribuído, certo? Então sempre observe o Servidor
como aquele nó que, normalmente, é o nó com mais recursos

de processamento, armazenamento e redundância, em geral
envolvendo hardware e software.
Se considerarmos aplicações como uma provedora global de
filmes e séries de televisão via streaming, bancos, redes sociais,
fica nítido quem são os servidores e quem são os clientes. Observe
que os clientes são os dispositivos que fazem requisição de dados/
processamento ao servidor.
Essa arquitetura costuma ser dividida em três níveis:
• Nível de interface de usuário.
• Nível de processamento.
• Nível de dados.
Esses níveis são equivalentes às organizações em camadas,
conforme estudamos na seção anterior.
A Figura 2.9 representa como é a comunicação entre cliente-
servidor ao longo do tempo.
Figura 2.9 | Interação entre cliente e servidor
Permanece
Cliente Aguardando
tempo
Servidor
tempo
Fornece
serviço
A comunicação entre eles pode ser feita por meio de um

protocolo não orientado à conexão, o UDP no caso, se a rede
for confiável. O cliente empacota a requisição, envia e aguarda a
resposta do servidor, caso não haja resposta, o cliente reenvia a
requisição. O principal problema nesse trâmite, reforça Tanenbaum
e Steen (2007), é que o cliente não consegue identificar se a falha
estava em seu envio ou na resposta do servidor e ilustra com dois
exemplos de requisição:

• “Transfira R$ 10.000,00 de minha conta para a conta X”;
• “Quero saber meu saldo”
A primeira solicitação não pode ser reenviada sem a identificação
da falha, já a segunda pode e, nesses casos, em que a operação
pode ser repetida diversas vezes sem causar danos na transação e
no sistema, ela é chamada de operação idempotente.
Para esses casos há o tratamento de falhas, uma importante área de
estudo em sistemas distribuídos e ainda há a opção da comunicação
via protocolo com conexão, como o TCP, que naturalmente já é
mais confiável pela sua estrutura e configuração. Como tem seu
desempenho confiável, independentemente da distância entre os
nós cliente e servidor, mesmo com mais lentidão quando comparado
ao UDP, ele é vastamente utilizado na comunicação pela internet.
Com a evolução das estruturas envolvendo cliente e servidor e
como deveria ser a implementação de cada um deles para atender
os interesses das aplicações, o papel de cada um deles passou a
ser menos óbvio e, assim, atualmente existem variações dessas
estruturas. Isso quer dizer que as responsabilidades de cliente e
servidor foram flexibilizadas conforme a necessidade e capacidade de
cada um. Em geral os clientes passaram a ter mais processamento e
armazenamento, até devido à evolução do hardware, e os servidores
passaram a controlar menos recursos. A Figura 2.10 ilustra essa
descrição de como podemos estabelecer o comportamento entre
cliente e servidor, variando suas responsabilidades na comunicação.
Figura 2.10 | Alternativas de organização cliente e servidor
Interface de Interface de Interface de

Interface de Interface de
usuário usuário usuário
usuário usuário
Interface de Banco de
usuário dados
Banco de Banco de Banco de Banco de

Banco de
dados dados dados dados
dados
a) b) c) d) e)

Considerando ainda a Figura 2.10, temos os chamados clientes
magros, 2.10(a) à 2.10(c), e os clientes gordos, 2.10(d) e 2.10(e).
Quanto mais à direita do esquema na Figura 2.10, mais complexo e
sofisticado acaba sendo o cliente, necessitando ainda de robustez
de elementos de hardware e segurança.
Nas implementações envolvendo RMI e RPC, o protocolo a
ser seguido é constituído de 3 passos (COULOURIS; DOLLIMORE;
KINDBERG, 2007):
• doOperation: método para invocar operações remotas, seus
argumentos são o objeto remoto, por meio do IP e porta, e
o método a ser executado, enquanto a resposta não retorna,
esse método permanece bloqueado.
• getRequest: o servidor lê as requisições e executa o serviço.
• sendReply: o servidor retorna com a resposta, fazendo com
que o método original seja desbloqueado.
A Figura 2.11 ilustra como se dá, ao longo do tempo, a
interação das mensagens nessa implementação utilizando
protocolo TCP.
Figura 2.11 | Comunicação requisição-resposta
Cliente Servidor
Mensagem de
requisição
DoOperation getRequest
•
•
(espera) Seleciona objeto
•
•
Executa método
(continuação) sendReply
Mensagem de
resposta
Fonte: adaptada de Coulouris, Dollimore e Kindberg (2007, p.147).
As estratégias envolvidas para manter a comunicação e

evitar falhas são: timeouts, que são limites de tempo, descarte

de requisições duplicadas e histórico. Essas técnicas são
consideradas em conjunto para uma comunicação com
mais confiabilidade.
2.2 | Comunicação em grupo
A comunicação em grupo se diferencia da comunicação

cliente-servidor basicamente pelos papéis que seus nós
desempenham no processo. Enquanto a ideia de cliente-servidor
se enquadra em uma distribuição vertical, a comunicação em
grupo é descrita como uma distribuição totalmente horizontal.
Existem configurações híbridas em que cliente e servidores
fazem um balanceamento de carga, como os sistemas peer-
to-peer, ou BitTorrent, de compartilhamento de arquivos. Por
mais que nos deem a impressão de serem uma comunicação
em grupo, eles não podem ser considerados totalmente
descentralizados, mas nos fazem estar mais próximos
do conceito.
A implementação totalmente descentralizada é encontrada
no Chord, implementado em topologia anel em que os nós
possuem identificadores únicos e mantêm informações
sobre seus vizinhos. A comunicação do Chord é em formato
broadcast, como encontrado no livro de Coulouris, Dollimore
e Kindberg (2007).
Uma característica natural de mensagens broadcasts é que
a mesma mensagem é enviada para todos os nós. Mesmo
uma mensagem de reconhecimento de vizinhança gera uma
quantidade exponencial de mensagens em função do número
de nós. Isso causa uma grande quantidade de mensagens, o
que impacta diretamente na complexidade da rede e em seu
overhead, que é o limite de nós que leva a rede à exaustão
e ineficiência. Podemos concluir também que devido às
características apresentadas, a rede em si não é eficiente do
ponto de vista de desempenho.
A Figura 2.12 ilustra como os nós da rede Chord são dispostos.

Figura 2.12 | Organização Chord
Nó real
{0,1}
Chaves de dados
associados
{8,9,10,11,12} {2,3,4}
{5,6,7}
As aplicações comerciais normalmente não são totalmente

descentralizadas, principalmente pelas características apresentadas.
É por isso que normalmente recaímos em arquiteturas híbridas, em
que existe uma ideia maior de gerenciamento. Aplicações como
WhatsApp, Skype, BitTorrent são bons exemplos de utilização de
arquiteturas híbridas.
Uma forma de implementação de arquiteturas híbridas é adotar
modelos que utilizam superpares, em que existem líderes em subredes
auxiliando na comunicação. Observe essa disposição na Figura 2.13:
Figura 2.13 | Organização Híbrida: Superpares

A escolha dos superpares pode ser aleatória, porém, é muito
mais estratégico optar por um nó que maximize a eficiência da rede.
Se considerarmos uma rede de sensores sem fio que costumam ter
limitações na sua capacidade de bateria e memória, por exemplo,
um superpar pode ser:
• O nó que está com a carga de energia mais completa e pode
executar mais processamento, levando mais tempo para
“cair” ou...
• O nó que está conectado à energia ou, ainda,
• O nó que possui uma condição de canal melhor em uma
comunicação sem fio, mantendo uma comunicação de
maior qualidade com o restante da rede.
Quando estudamos as características de arquiteturas, sendo elas
centralizadas, descentralizadas ou híbridas, identificamos a necessidade
de adequar o comportamento dos nós conforme idealizamos a aplicação,
certo? Para isso precisamos implementar essas adequações nos nós e
é nesse contexto que se aplicam os conceitos de interceptadores e
softwares adaptativos que estudamos na seção anterior.

A disposição de superpares é bem similar à um conceito vastamente
aplicado em Redes de Computadores, você reconhece?

Você sabia que o DNS é implementado por meio de um
sistema distribuído?
Para saber mais

Se você ficou interessado em continuar o estudo e aprofundar seus
conhecimentos, acesse o link disponível em: <https://goo.gl/Aqfxdc>.
Nele você conhecerá uma ferramenta de implementação, chamada MPI.

1. Explique qual é a diferença envolvendo arquitetura em uma distribuição

vertical e em uma distribuição horizontal. Exemplifique.
2. Considere a figura a seguir:
Fonte: <https://goo.gl/rsYWoz>. Acesso em: 17 jul. 2018.
Sobre a arquitetura disposta na imagem, assinale a alternativa correta:

a) Essa arquitetura também é chamada de requisição-resposta.
b) A arquitetura mostrada é descentralizada.
c) Por se tratar de uma rede local não é considerada um sistema distribuído.
d) Esse tipo de arquitetura não possui variações quanto aos papéis dos
nós envolvidos.
e) As mensagens enviar e descartar são inerentes nesse tipo de arquitetura.
Fique ligado
Aluno, você viu neste capítulo que os sistemas distribuídos
são implementados conforme a aplicação a que se destinam. As
implicações quanto aos papéis dos nós e o grau de confiabilidade
da aplicação irão determinar a configuração da camada middleware
adotada, bem como os protocolos que irão de fato executar a
comunicação entre os processos.

Aluno, este capítulo envolve duas outras disciplinas que são
Redes de Computadores e Sistemas Operacionais, ambas que ainda
possuem áreas de pesquisa e avanço tecnológico, sendo assim, o

assunto aqui abordado está em constante evolução e é um vasto
campo de atuação profissional melhorar a forma como ocorrem as
comunicações entre sistemas distribuídos!

1. Adaptado de ENADE (2014) Considere a figura a seguir:
Rede pública
Base de
dados II
Aplicação I
Aplicação II
Dados Base de
pessoais dados I
Fonte: <https://goo.gl/xoxALA>. Acesso em: 10 jul. 2018.
Preencha a lacuna com base na figura apresentada:

A imagem representa um sistema distribuído, em que a Base de dados I
e a Base de dados II são acessadas de forma _____ para o usuário. Embora
fisicamente separados, o _____ é adotado de tal maneira que garante a
padronização da implementação em nível de interface.
Assinale a alternativa que preenche corretamente as lacunas:
a) Transparente; middleware.
b) Descentralizada; protocolo TCP.
c) Autônoma; sistema distribuído.
d) Unificada; sistema de banco de dados.
e) Intermediada; acesso.

2. Analise a imagem a seguir:
Figura | Computadores formando um sistema distribuído
Fonte: <https://goo.gl/QU8n5o>. Acesso em: 19 jul. 2018.
Sobre os conceitos em sistemas distribuídos e analisando a rede ilustrada

na figura proposta, assinale a alternativa correta:
a) Os sistemas distribuídos devem passar ao usuário a sensação de
serem distribuídos geograficamente e logicamente.
b) A rede de dispositivos distribuídos apresentada na figura atende
à arquitetura de comunicação em grupo, onde todos os nós
executam requisições de serviços e resposta.
c) A rede mostrada na figura é claramente proposta na arquitetura
cliente-servidor, que permite essa comunicação totalmente
interligada e rápida.
d) Ao passo que a rede de sistemas distribuídos ilustrada na figura é de
arquitetura de comunicação em grupo então tem-se a mais eficiente
forma de comunicação de sistemas distribuídos.
e) A principal característica que podemos identificar na rede
apresentada é a falta da camada de middleware, por se tratar de
uma comunicação em grupo.

3. As estatísticas são contundentes quando demonstram que o celular já
se tornou o equipamento preferido dos brasileiros para acessar internet.
Segundo a Pesquisa Nacional por Amostra de Domicílios (Pnad) 2016,
realizada pelo Instituto Brasileiro de Geografia e Estatística (IBGE), 94,6% dos
internautas utilizam esse dispositivo móvel para – preferentemente – trocar
mensagens, assistir a vídeos, programas, séries e conversar por chamadas
de voz ou vídeo. Maria Lucia Vieira, gerente da pesquisa, afirma que esses
dados revelam “que as pessoas priorizam as formas de comunicação mais
fáceis e mais rápidas. ” E conclui: “Além da velocidade, o celular permite
acessar a Internet por redes sem fio públicas ou gratuitas, sem exigir uma
rede de transmissão de dados”.
Fonte: <https://goo.gl/yqyjy5>. Disponível em: 17 jul. 2018.
Sobre os aplicativos que operam como sistemas distribuídos, assinale a

alternativa correta:
a) Sempre são implementados segundo características da arquitetura
cliente-servidor.
b) As implementações cliente-servidor são encontradas em sistemas
mais teóricos e não práticos.
c) Sempre são implementados segundo características da arquitetura
de comunicação em grupo.
d) Sempre são implementados segundo características híbridas de
arquitetura, para conseguir um alto overhead na rede.
e) Costumam ser implementados em arquiteturas cliente-servidor
ou híbridas para evitar saturação de mensagens e comprometer a
eficiência da rede.
4. A comunicação nos sistemas distribuídos dá-se por meio da

comunicação entre processos e, como essa comunicação pode variar
em sua concepção, ela possui características do protocolo adotado e
da interface implementada. Sobre os conceitos de comunicação entre
processos, analise as alternativas a seguir e assinale a correta:
a) A referência a um objeto remoto costuma ser múltipla.
b) Os processos adotam a comunicação por protocolo TCP, enquanto
os objetos adotam a comunicação por protocolo UDP.
c) A camada middleware é a camada que o programador pode
facilmente adaptar conforme sua necessidade.

d) Entre os níveis de SO e de aplicação existe a camada middleware,
comum aos nós daquela aplicação.
e) Um nó com implementação de comunicação TCP consegue enviar
mensagens remotas à um nó com implementação UDP, porém,
não consegue receber requisições dele.
5. Os comandos enviados para requisição no formato send, que quer dizer

envio, ficam à espera da resposta e quando não recebem essa resposta,
muitas vezes, é necessário repetir o envio da requisição. Algumas repetições
de ações não comprometem a coerência das transações, porém, algumas
impactam de maneira ruim ou custosa para a aplicação.
Assinale a alternativa que apresenta como são chamadas as ações que
não comprometem a coerência da aplicação se repetidas:
a) Transitentes.
b) Latentes.
c) Resilientes.
d) Idempotentes.
e) Concorrentes.

Referências
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Sistemas Distribuídos: Conceitos
e Projeto. Porto Alegre: Bookman, 2007.
TANENBAUM, A. S.; STEEN, M. Sistemas distribuídos: princípios e paradigmas.
São Paulo: Person Prentice Hall, 2007.
TANENBAUM, A. S. Redes de Computadores. 4. ed. Rio de Janeiro: Elsevier, 2003a.
TANENBAUM, A. S. Sistemas Operacionais Modernos. São Paulo: Person Prentice
Hall, 2003b.

Unidade 3
Tecnologias de
implementação
Compreender o que são sistemas distribuídos baseados em
objetos, entendendo o que são objetos, sistemas distribuídos
e objetos distribuídos. Saber que esses objetos desempenham
papel de suma importância no estabelecimento da
transparência da distribuição. Entender como os arquivos
funcionam nos sistemas distribuídos e sua importância,
entendendo como milhares de pessoas pesquisam algo na
internet ao mesmo tempo e com eficiência.
Seção 1 | Objetos distribuídos, RMI

Nessa seção, apresentamos como o paradigma da orientação a
objetos pode atuar em um sistema distribuído. Iniciaremos com algumas
definições, para relembrarmos a orientação a objetos e como colocar
essa arquitetura em funcionamento. Para suportar objetos distribuídos,
temos que nos preocupar com alguns princípios básicos de sistemas
distribuídos, como tolerância a falha e escalabilidade, sabendo que
o cliente deverá pensar que todos os processos estão ocorrendo
localmente. Para comunicação, trabalhamos com invocação de método
remoto (RMI), podendo um processo acessar um objeto em qualquer
máquina. Sempre provendo agilidade e necessidades de qualquer cliente.
Seção 2 | Sistemas de arquivos distribuídos, serviços de

nomes (DNS)
Sistemas de arquivos distribuídos também são um paradigma
a ser construído em sistemas distribuídos. O que é diferente
dos sistemas de arquivos não distribuídos, é a semântica de
compartilhamento de arquivos. O DNS é o mecanismo no qual
nomes de domínios da Internet são localizados e traduzidos para
endereços de IP. O nome do domínio é uma forma mais fácil de
lembrar do que o endereço DE internet.
Nessa unidade, definiremos objetos, recordaremos as definições
de sistemas distribuídos e entenderemos qual o objetivo em
trabalhar com essas tecnologias juntas, melhorando a resposta das
requisições com sistemas distribuídos baseados em objetos.
Quando trabalhamos com objetos distribuídos, podemos
simplificar o desenvolvimento e a manutenção de sistemas, criando
partes reutilizáveis de código, os chamados objetos, e fazendo com
que objetos instalados em diferentes computadores possam se
comunicar através de uma rede.
Seção 1
Objetos distribuídos, RMI
Nessa unidade, definiremos objetos, recordaremos as

definições de sistemas distribuídos e entenderemos qual o
objetivo em trabalhar com essas tecnologias juntas, melhorando
a resposta das requisições com sistemas distribuídos baseados
em objetos.
Quando trabalhamos com objetos distribuídos, podemos
simplificar o desenvolvimento e a manutenção de sistemas, criando
partes reutilizáveis de código, os chamados objetos, e fazendo com
que objetos instalados em diferentes computadores possam se
comunicar através de uma rede.
1 | Princípios fundamentais de orientação a objetos
1.1 | Objeto - definições
Iniciaremos com a definição de Correia (2006), de que objetos

podem ter diversidade de sinônimos. Vamos considerar os objetos
computacionais como objetos que se encontram dentro de sistemas
de computador em sua concepção.
Partindo desses objetos, tentamos reproduzir as mesmas
características dos objetos existentes no mundo real, programando
comportamentos muito próximos àqueles que encontramos nos
objetos reais.
Nessa programação, um programador pode usar esses objetos
e seus comportamentos programados, sem precisar conhecer
o funcionamento interno desses comportamentos, ou seja, para
trabalhar com os objetos, precisa-se apenas conhecer o que fazer
para usá-lo.
Para Correia (2006, p. 2),
84 U3 - Tecnologias de implementação
orientação a objetos, consiste em considerar os sistemas
computacionais como uma coleção de objetos que interagem
de maneira organizada e objetos computacionais são estruturas
de programação que contêm informações e os comportamentos
que representam um objeto dentro do sistema.
Ainda, para Correia (2006, p. 8),
análise orientada a objetos consiste em definir quais

objetos fazem parte de um sistema e a maneira como se
comportam e programação orientada a objetos consiste
em utilizar objetos computacionais para implementar as
funcionalidades de um sistema.
Correia (2006) afirma que a principal vantagem da orientação a

objetos é ter em uma mesma estrutura, os dados e os processos que
são executados sobre esses dados. Isso faz com que o programa
seja mais organizado e simples, além do aumento na produtividade.
Na manutenção do objeto, há redução de custo, tempo e assegura
a certeza de uma maneira eficiente, sabendo que as variáveis
controladas estavam limitadas aos objetos modificados apenas.
Uma estrutura com eficácia de objetos, depois de criada,
permitirá acrescentar módulos adicionais no sistema que
reutilizem as funcionalidades já desenvolvidas, sem necessidade
de reprogramação. Reutilizar significa que o mesmo código
pode ser usado por sistemas diferentes, reduzindo o custo de
desenvolvimento e o risco de erros de programação.
Os objetos são organizados em classes. Uma classe define o
comportamento dos objetos dela derivados, ou seja, dois objetos da
mesma classe possuem exatamente o mesmo conjunto de atributos
e métodos, embora cada objeto possa ter valores diferentes para os
seus atributos.
Recordamos alguns pontos fundamentais de objetos e tratamento
deles, logo veremos como organizá-los junto a sistemas distribuídos.
1.2 | Sistemas distribuídos – definições

Vamos recordar alguns conceitos importantes de sistemas
distribuídos. Tanenbaum e Coulouris afirmam que sistema
U3 - Tecnologias de implementação 85
distribuído sempre será um conjunto de computadores
independentes (com de hardware ou software) que se mostram
ao usuário, como se fosse um único sistema, funcionando com
transparência e agilidade.
Agora vamos juntar objetos com sistemas distribuídos?
1.3 | Sistemas distribuídos baseados em objetos
Com a evolução da tecnologia, não há necessidade de inúmeros

recursos centralizados para conseguirmos objetivos, antes
difíceis de serem trabalhados. Podemos repartir computadores,
programas, impressoras entre outros recursos, desejando sempre
portabilidade, reusabilidade e interoperabilidade. Podemos afirmar
que na atualidade, sistemas distribuídos são fundamentais. Com a
fundamentação de sistemas distribuídos e a grande procura por
orientação a objetos, surgem os objetos distribuídos.
Para Tanenbaum (2007), temos o paradigma dos objetos
distribuídos. Em sistemas distribuídos baseados em objetos, a noção
de um objeto desempenha papel fundamental no estabelecimento
da transparência. Em princípio, tudo é tratado como objeto, e
serviços e recursos são oferecidos a clientes na forma de objetos
que eles possam invocar.
1.4 | Objetos distribuídos
Para Tanenbaum (2007), a característica fundamental de um

objeto é que ele encapsula dados, chamado de estado, e as
operações executadas nesses dados são chamadas de métodos.
Esses métodos são disponibilizados por meio de uma interface.
Um objeto pode implementar várias interfaces, bem como
dada uma definição de interface, poderá haver vários objetos
que oferecem uma implementação dela. Essa separação entre
interfaces e os objetos que implementam essas interfaces é
extremamente importante para sistemas distribuídos. Podemos
assim colocar uma interface em uma máquina, enquanto o
objeto está em outra máquina. Ilustramos essa descrição na
Figura 3.1.
Figura 3.1 | Organização comum de um objeto remoto com proxy do lado do cliente
Tanenbaum (2007) afirma que, quando um cliente se vincula a

um objeto distribuído, uma implementação da interface do objeto,
nominada proxy é carregada no espaço de endereço do cliente.
Um proxy é semelhante a um apêndice de cliente em um sistema
RPC. A única coisa que ele faz é montar invocações a métodos em
mensagens e desmontar mensagens de resposta para retornar o
resultado da invocação do método para o cliente. O objeto fica em
uma máquina do servidor, a qual oferece a mesma interface que a
máquina cliente. Requisições de invocação que chegam são primeiro
passadas para um apêndice servidor, que as desmonta para fazer
invocações de método na interface de objeto que está no servidor.
O apêndice servidor também é responsável por montar respostas e
enviar mensagens de resposta para o proxy do lado cliente.
Ainda para Tanenbaum (2007), o apêndice do lado servidor costuma
ser chamado de esqueleto, pois fornece o mínimo necessário de
meios que permitem que o middleware do servidor acesse os objetos
definidos pelo usuário. Na prática, muitas vezes ele contém código
incompleto, na forma de uma classe específica de linguagem que
precisa ser ainda mais especializada pelo desenvolvedor.
Tanenbaum (2007) nos explica que na maioria dos objetos
distribuídos, o seu estado não é distribuído, ele reside em uma
única máquina, nesse caso, somente as interfaces implementadas
pelo objeto são disponibilizadas em outras máquinas. Esses objetos
também se denominam objetos remotos. Em um objeto distribuído,
o estado em si pode ser distribuído fisicamente por várias máquinas,
mas essa distribuição também fica oculta dos clientes sob as
interfaces de objetos.
Para Orfali, Hankey e Edwards (1996), objetos distribuídos não
são aplicações completas, podem ser usados em combinações
imprevisíveis. Possuem interface bem definida, fornecem
mecanismos para a notificação de eventos, possibilitam o
gerenciamento de configuração e propriedades.
Constatamos que o objeto distribuído é uma evolução do objeto
convencional. Entretanto possui uma interface específica em que os
compiladores geram um código a mais para ser acessado por outros
objetos de maneira que o programa/objeto que o solicite desconheça
o local onde o objeto chamado está localizado, o sistema operacional
que está sendo utilizado e a linguagem na qual foi criado.
Orfali, Hankey e Edwards (1996) afirma que a tecnologia de
objetos distribuídos permite a criação de sistemas cliente/servidor
mais flexíveis, visto que os dados são encapsulados nos objetos
que ficam distribuídos pela rede o que facilita sua localização em
qualquer parte do sistema.
1.5 | Comunicação
Vamos apresentar como a comunicação é manipulada em

sistemas distribuídos baseado em objetos. Esse mecanismo, do
cliente remoto invocar um objeto, é baseado, em grande parte, em
chamadas a procedimentos remotos (RPCs).
Para suportar os objetos distribuídos, em suas funcionalidades,
foram desenvolvidos servidores de objetos avançados para hospedar
objetos. Um servidor de objetos fornece muitos serviços a objetos
básicos, entre eles recurso para armazenar objetos.
1.5.1 | RPC (Remote Procedure Call) – Chamada de

procedimento remoto.
Relembrando, Tanenbaum (2007) afirma que uma RPC visa

ocultar grande parte das complexidades da troca de mensagens
e é ideal para aplicações cliente-servidor. Para Tanenbaum (2007),
a ideia que fundamenta RPC, é fazer com que uma chamada de
procedimento remoto seja “considerada” uma chamada local.
Queremos que a RPC seja transparente, ou seja, o procedimento de
chamada não deve estar ciente de que o procedimento chamado
está executando em uma máquina diferente e vice-versa, conforme
ilustrado na Figura 3.3.
Figura 3.3 | Princípio de PRC entre um programa cliente e um programa servidor
Espera pelo resultado

Cliente
Chamada de Retorno da
procedimento remoto chamada
Servidor
Tempo
Chamada de procedimento
local e retorno de resultados
Ainda para Tanenbaum (2007), uma chamada de procedimento

remoto ocorre nas seguintes etapas:
a) O procedimento de cliente chama o apêndice de cliente do
modo normal.
b) O apêndice de cliente constrói uma mensagem e chama o
sistema operacional local.
c) O sistema operacional do cliente envia mensagem para o
sistema operacional remoto.
d) O sistema operacional remoto dá a mensagem ao apêndice
de servidor.
e) O apêndice de servidor desempacota os parâmetros e chama
o servidor.
f) O servidor faz o serviço e retorna o resultado para o apêndice.
g) O apêndice de servidor empacota o resultado em uma
mensagem e chama seu sistema operacional local.
h) O sistema operacional do servidor envia a mensagem ao
sistema operacional do cliente.
i) O sistema operacional do cliente dá a mensagem ao apêndice
de cliente.
j) O apêndice desempacota o resultado e retorna ao cliente.
Com essas etapas, nem o cliente nem o servidor ficam cientes
das etapas intermediárias ou da existência da rede, assemelhando-
se a uma chamada local.
1.6 | Middleware
A tarefa do middleware, para Coulouris (2007), é fornecer

uma abstração de programação de nível mais alto para o
desenvolvimento de sistemas distribuídos e, por meio de camadas,
abstrair a heterogeneidade da infraestrutura subjacente a fim de
promover a operação conjunta e a portabilidade. Middleware possui
a necessidade de agrupar funcionalidades comuns às diversas
aplicações distribuídas, ele deve ser independente do sistema
operacional e do hardware.
1.6.1 | Middleware de objetos distribuídos
Segundo Coulouris (2007), a principal característica dos objetos

distribuídos é que eles permitem adotar um modelo de programação
orientada a objetos para o desenvolvimento de sistemas distribuídos
e, por meio disso, ocultar a complexidade da programação distribuída.
Nessa estratégia, as entidades que se comunicam são representadas
por objetos. Os objetos se comunicam usando, principalmente,
invocação de método remoto (RMI), mas possivelmente usando
também um paradigma de comunicação alternativo (como os
eventos distribuídos). Essa estratégia relativamente simples tem
diversas vantagens importantes, incluindo:
a) O encapsulamento inerente às soluções baseadas em objetos
é apropriado à programação distribuída.
b) A propriedade relacionada da abstração de dados oferece
uma clara separação entre a especificação de um objeto e sua
implementação, permitindo aos programadores lidar exclusivamente
com as interfaces e não se preocupar com os detalhes da
implementação, como a linguagem de programação e o sistema
operacional usados.
c) Essa estratégia também proporciona soluções mais dinâmicas
e extensíveis, permitindo, por exemplo, a introdução de novos
objetos ou a substituição de um objeto por outro (compatível).
Estão disponíveis diversas soluções de middleware baseadas em
objetos distribuídos, por meio das tecnologias RMI Java e CORBA.
1.6.2 | Middleware baseado em componentes
Para Coulouris (2007), as soluções baseadas em componentes

foram desenvolvidas para superar diversas limitações observadas
pelos desenvolvedores de aplicativo que trabalham com middleware
de objeto distribuído:
a) Dependências implícitas: as interfaces de objeto não descrevem
as dependências da implementação de um objeto, tornando difícil
desenvolver sistemas baseados em objetos (especialmente por parte
de desenvolvedores externos) e, subsequentemente, gerenciá-los.
b) Complexidade de programação: a programação de middleware
de objeto distribuído leva à necessidade de dominar muitos detalhes
de baixo nível associados às implementações de middleware.
c) Falta de separação de aspectos relacionados à distribuição: os
desenvolvedores de aplicativo são obrigados a considerar detalhes
relacionados à segurança, falha de tratamento e concorrência, que
são predominantemente semelhantes de um aplicativo para outro.
d) Ausência de suporte para implantação: o middleware baseado
em objeto fornece pouco ou nenhum suporte para a implantação e
definição de configurações (potencialmente complexas) de objetos.
Em resumo, para conseguir a interação entre objetos distribuídos,

um middleware deve prover:
a) Localização transparente dos objetos.
b) Invocação de métodos local e remoto idêntica.
c) Criação de objeto local e remoto idêntica.
d) Migração de objetos transparente.
e) Facilidades para ligação (binding) de interfaces dinamicamente.
f) Diversos serviços de suporte: como Nomes, Transação,
Tempo etc.
1.7 | RMI (Remote Method Invocation) - Invocação

de método remoto
Para Tanenbaum (2007), a invocação de método remoto (RMI) é

muito semelhante a uma chamada de procedimento remoto (RPC),
quando se trata de questões como montar e transferir parâmetros.
O modo usual de prover suporte de RMI é especificar a interface de
objetos em uma linguagem de definição de interface, semelhante à
abordagem adotada por RPCs.
Tanenbaum (2007) afirma que em Java, objetos distribuídos foram
integrados à linguagem. Uma meta importante era manter o máximo
possível da semântica de objetos não distribuídos, fazendo com que
os desenvolvedores da linguagem Java tivessem como objetivo o
alto grau de transparência de distribuição, o que é muito difícil.
1.7.1 | Exemplos: Tecnologia RMI Java e CORBA
Com o uso de diversos tipos de software e hardware tornam-se

necessários aplicativos e modelos que provêm a comunicação em
diferentes interfaces tanto de hardware e software.
Como exemplos de principais suportes de middleware para objetos
distribuídos, Coulouris (2007) nos mostra o Java RMI (Remote Method
Invocation), da Oracle/Sun Microsystems, como na Figura 3.4, e o
CORBA (Common Object Request Broker Architecture), especificado
pela OMG (Object Management Group) e implementado por diversos
fabricantes de software. Também salientamos que a interface é escrita
em Interface Descrition Language (IDL).
Figura 3.4 | Java RMI
1.7.1.1 | Java RMI - Modelos de objetos distribuídos e
invocações em Java
Para Tanenbaum (2007), Java também adota objetos remotos

como a única forma de objetos distribuídos. Lembrando que objeto
remoto é um objeto distribuído, cujo estado sempre está em uma
única máquina, mas que as interfaces podem ser disponibilizadas
para processos remotos. Interfaces são implementadas do modo
usual por meio de um proxy, que oferece exatamente as mesmas
interfaces que o objeto remoto. O proxy em si aparece como um
objeto local no espaço de endereços do cliente.
Tanenbaum (2007) afirma que a única distinção feita entre objetos
locais e objetos remotos durante uma RMI é que objetos locais são
passados por valor (incluindo vetores), enquanto objetos remotos
são passados por referência. Esclarecendo, como na Figura 3.5, um
objeto local primeiro é copiado e depois a cópia é usada como valor
de parâmetro. No caso de um objeto remoto, uma referência ao
objeto é transferida como parâmetro em vez de uma cópia do objeto.
Figura 3.5 | Objeto passado por referência ou por valor
Conforme Tanenbaum (2007), um objeto remoto é construído

com base na classe do servidor e na classe do cliente. A classe do
servidor contém uma implementação da parte do objeto remoto
que executará em um servidor, ou seja, ela contém a descrição do
estado do objeto, bem como uma implementação dos métodos
que operam sobre aquele estado. O apêndice do lado do servidor, o
esqueleto, é gerado de acordo com as especificações das interfaces
de objeto.
Ainda para Tanenbaum (2007), a classe que contém uma
implementação do código do lado do cliente, é chamada classe do
cliente. Essa classe contém uma implementação de um proxy e, assim
como o esqueleto, ela também é gerada de acordo com a especificação
da interface de objeto. O que esse proxy faz, simplificadamente, é
converter cada chamada de método em uma mensagem que é enviada
à implementação do lado do servidor do objeto remoto, e converter
uma mensagem de resposta no resultado, se for uma chamada
de método. O proxy estabelece uma conexão com o servidor para
cada chamada e, na sequência, essa conexão é terminada quando a
chamada for concluída. Para cumprir essa finalidade, o proxy precisa
do endereço de rede e da porta do servidor. Essa informação, junto
com o identificador local do objeto no servidor, é sempre armazenada
como parte do estado de um proxy.
Assim sendo, um proxy tem todas as informações de que
necessita para permitir que um cliente invoque métodos do
objeto remoto. Em Java, é possível montar um proxy e enviá-
lo como uma série de bytes para um outro processo em que
ele pode ser desmontado e utilizado para invocar métodos no
objeto remoto.
Conforme Tanenbaum (2007), há vários modos para implementar
as referêcias de objeto, que vão de simples estruturas de dados
passivas que descrevem exatamente onde um objeto remoto pode
ser contatado, até código portável, que precisa apena ser invocado
por um cliente como na RMI Java.
1.7.2 | CORBA Common Object Request Broker

Architecture
O OMG (Object Management Group) foi formado em 1989, com

o objetivo de estimular a adoção de sistemas de objetos distribuídos
para usufruir as vantagens da programação orientada a objetos no
desenvolvimento de software para sistemas distribuídos, os quais
estavam se tornando muito difundidos.
Segundo Coulouris (2007), para atingir seus objetivos, o OMG
defendeu o uso de sistemas abertos baseados em interfaces
orientadas a objetos padrão. Esses sistemas seriam construídos a
partir de hardware, redes de computadores, sistemas operacionais
e linguagens de programação heterogêneos.
Uma motivação importante foi permitir que os objetos distribuídos
fossem implementados em qualquer linguagem de programação e
pudessem se comunicar uns com os outros. Portanto, foi projetada
uma linguagem de interface independente de qualquer linguagem
de implementação específica.
Os principais componentes do framework de RMI CORBA
independente de linguagem são:
a. Uma linguagem de definição de interface conhecida
como IDL.
b. Uma arquitetura.
c. Uma representação externa de dados, chamada CDR.
d. Uma forma padrão para referências de objeto remoto.
A arquitetura CORBA também admite serviços CORBA – um
conjunto de serviços genéricos úteis para aplicações distribuídas.
1.7.2.1 | RMI CORBA
Programar em um sistema RMI de multilinguagens, como

RMI CORBA, exige mais do programador, se comparado com o
desenvolvimento em um sistema RMI de linguagem única, como
RMI Java. Para Coulouris(2007), alguns novos conceitos precisam
ser aprendidos:
a. O modelo de objeto oferecido pelo CORBA.
b. A linguagem de definição de interface.
c. Seu mapeamento para a linguagem de implementação.
Outros aspectos da programação em CORBA são que, em
particular, o programador define interfaces remotas para os objetos
remotos e depois usa um compilador de interface para produzir os
proxies e esqueletos correspondentes. No entanto, no CORBA, os
proxies são gerados na linguagem do cliente e os esqueletos, na
linguagem do servidor.
1.7.2.2 | Modelo de objeto do CORBA
Coulouris (2007) afirma que no modelo de objeto do CORBA,

os clientes não são necessariamente objetos – um cliente pode
ser qualquer programa que envie mensagens de requisição para
objetos remotos e receba respostas. O termo objeto CORBA
é usado para se referir aos objetos remotos. Assim, um objeto
CORBA implementa uma interface IDL, tem uma referência de
objeto remoto e é capaz de responder às invocações de métodos
em sua interface IDL.
Um objeto CORBA pode, por exemplo, ser implementado
por uma linguagem não orientada a objeto, sem o conceito de
classe. Como as linguagens de implementação terão diferentes
noções de classe, ou mesmo nenhuma noção, o conceito de
classe não existe no CORBA. Portanto, classes não podem ser
definidas na IDL do CORBA, o que significa que instâncias de
classes não podem ser passadas como argumentos. Entretanto,
estruturas de dados de vários tipos e complexidade arbitrária
podem ser passadas como argumentos.
Como traz Coulouris (2007), linguagem de definição de
interface – ou IDL – CORBA fornece recursos para a definição
de módulos, interfaces, tipos, atributos e assinaturas de método.
Diz Pritchard (2000) que CORBA é uma das alternativas a ser
utilizada pelo fato de atuar de modo que os objetos possam se
comunicar de forma transparente ao usuário, mesmo que para
isso seja necessário interoperar com outro software, em outro
sistema operacional e em outra ferramenta de desenvolvimento.
A arquitetura CORBA define o Object Request Broker (ORB)
como um módulo intermediário entre cliente e objeto, que fica
encarregado de aceitar a 24 requisição do cliente, enviá-la para
o objeto servidor que assim que disponível retorna a resposta da
requisição ao cliente. CORBA é independente da linguagem de
programação pelo fato de ter uma Interface Definition Language
(IDL) desenvolvida em C++, que provê uma comunicação com
outras linguagens como Java, COBOL, Python, entre outras.
Para saber mais
vamos entender um pouco mais de RMI. Então vamos ler o artigo:
RMI: Primeiros passos - Revista easy Java Magazine 17. Disponível em:
<https://www.devmedia.com.br/rmi-primeiros-passos-revista-easy-
java-magazine-17/24135>. Acesso em: 26 set. 2018.

agora que você conhece os objetos distribuídos, na sua opinião, qual
será a próxima inovação de implementação para benefício do usuário?
Iniciamos com definições importantes, como objetos, sistemas

distribuídos e a junção desses dois segmentos, formando o conceito
de sistemas distribuídos baseados em objetos. Vimos que podemos
utilizar o princípio de orientação a objetos para o desenvolvimento de
sistemas distribuídos, minimizando a complexidade da programação
distribuídas. Resumindo, objetos distribuídos interagem através da rede,
estão em colaboração para atingir um objetivo, sempre fornecem
serviços (métodos) uns aos outros, trabalhamos com a interface do
objeto que nos é visível, toda a referência do objeto possui endereço
de rede. Terminamos com a invocação remota, que representa o
paradigma de comunicação comum em sistemas distribuídos.
Fique ligado
Até aqui estudamos objetos distribuídos e RMI, suas definições e
metas, com embasamento principalmente em Tanenbaum (2007)
e Coulouris (2007), que nos trazem desafios que são primordiais na
implementação de sistemas distribuídos.
Importante são as definições de objetos, sistemas distribuídos,
sistemas distribuídos baseados em objetos, objetos distribuídos,
comunicação, chamada de procedimento remoto, relembrando os
conceitos de middleware e middleware de objetos.
Encerramos esta seção com exemplos RMI Java e Corba, que
são formas de trabalharmos com os sistemas distribuídos.
1. Banca: CONSULPLAN, 2017 Órgão: TRF - 2ª REGIÃO (adaptada)

tecnologia-da-informacao-arquitetura-de-software/arquitetura-
orientada-a-objetos>. Acesso em: 13 ago. 2017.
Analise as afirmativas a seguir.

I. Em uma arquitetura de objetos distribuídos, os componentes
fundamentais do sistema são objetos que fornecem uma interface para
um conjunto de serviços fornecidos sem a necessidade de distinção entre
cliente e servidor.
II. Como alternativa, pode-se usar uma abordagem de objetos distribuídos
para implementar sistemas cliente-servidor.
III. A maior desvantagem de arquiteturas de objetos distribuídos é que são
mais complexas de projetar do que sistemas cliente-servidor.
a) II, apenas.
b) I, apenas.
c) II e III, apenas
d) I, II e III.
e) I e II, apenas.

Banca: FCC
Órgão: TRE-PE
Prova: Analista Judiciário - Análise de Sistemas
tecnologia-da-informacao-arquitetura-de-software/corba>. Acesso em:
26 set. 2018.
Arquitetura padrão proposta pelo Object Management Group (OMG)
para estabelecer e simplificar a troca de dados entre sistemas distribuídos
heterogêneos por meio de uma estrutura comum para o gerenciamento de
objetos distribuídos que é conhecida como Object Manager Architecture
(OMA). Trata-se de:
a) IDL.
b) RPC.
c) DCON.
d) CORBA.
e) COM.
Seção 2
Sistemas de Arquivos Distribuídos, Serviços de
nomes (DNS)
Segundo Coulouris (2007), os primeiros servidores de arquivos

datam dos anos 70. A princípio sistemas de arquivos foram
desenvolvidos para sistemas de computadores centralizados e
computadores com sistemas operacionais com interface para
programar e armazenar em disco.
Com a evolução, a preocupação com segurança foi inevitável,
trazendo o controle de acesso e proteção de arquivos, depois
a criptografia. Os sistemas de arquivos distribuídos suportam
o compartilhamento de informações por meio de arquivos e
recursos de hardware com armazenamento em uma intranet e
posteriormente a internet. Novamente, há a preocupação com
desempenho, confiabilidade e que o usuário fique em uma posição
de pensar trabalhar localmente.
2.1 | Sistemas de arquivos distribuídos
Um sistema de arquivos é uma parte de um sistema operacional

que oferece um repositório de dados de longa duração. Um sistema
de arquivos distribuídos é um sistema de arquivos no qual vários
servidores são responsáveis por oferecer o serviço de arquivos para
vários clientes instalados em diferentes máquinas.
Segundo Tanenbaum (2007, p. 296), “os sistemas de arquivos
distribuídos permitem que vários processos compartilhem dados
por longos períodos, do modo seguro e confiável. Por essa razão,
eles têm sido usados como a camada básica para sistemas e
aplicações distribuídos”.
Para Coulours (2007, p. 531), “um sistema de arquivos distribuído
permite aos programas armazenarem e acessarem arquivos remotos
exatamente como se fossem locais, possibilitando que os usuários
acessem arquivos a partir de qualquer computador em uma rede”.

Os servidores Web fornecem uma forma restrita de compartilhamento
de dados, na qual os arquivos armazenados de forma local no servidor
estão disponíveis para clientes em toda a Internet, mas os dados
acessados por meio de servidores Web são gerenciados e atualizados
em sistemas de arquivos no servidor, ou distribuídos em uma rede local.
Para Coulouris (2007), os sistemas de arquivos foram a princípio
feitos para sistemas de computadores centralizados e computadores
desktop como um recurso do sistema operacional que fornece uma
interface de programação conveniente para armazenamento em disco.
Subsequentemente, eles adquiriram características como controle
de acesso e mecanismos de proteção de arquivos, que os tornaram
úteis para o compartilhamento de dados e programas. Os sistemas de
arquivos distribuídos suportam o compartilhamento de informações
por meio de arquivos e recursos de hardware com armazenamento
persistente em toda uma intranet. Um serviço de arquivo bem projetado
dá acesso a arquivos armazenados em um servidor com desempenho
e confiabilidade semelhantes a (e, em alguns casos, melhores que)
arquivos armazenados em discos locais. Seu projeto é adaptado para
as características de desempenho e confiabilidade das redes locais,
portanto, eles são eficazes no fornecimento de armazenamento
persistente compartilhado para uso em intranets.
2.2 | Arquitetura de sistemas de arquivos distribuídos.
A maioria dos sistemas é construída seguindo a

arquitetura cliente-servidor, mas também existem soluções
totalmente descentralizadas.
2.2.1 | Arquiteturas cliente-servidor
Muitos sistemas de arquivos distribuídos são organizados

segundo as linhas da arquitetura cliente-servidor, sendo que
o sistema de arquivo de rede (NFS -Network File System) foi
introduzido pela Sun Microsysten e é um mecanismo que permite
o acesso a arquivos localizados remotamente on-line, como se
estivessem localmente na máquina, é um dos mais utilizados para
sistemas baseados em Unix.

Para Tanenbaum (2007), a ideia básica que fundamenta o NFS
é que cada servidor de arquivos fornece uma visão padronizada
de seu sistema local de arquivos, não importando como o sistema
local de arquivos é implementado, cada servidor NFS suporta o
mesmo modelo. O NFS vem com um protocolo de comunicação
que possibilita aos clientes acessar os arquivos armazenados em um
servidor, o que permite a um conjunto heterogêneo de processos,
que provavelmente executa em máquinas e sistemas operacionais
diferentes, compartilhar um sistema de arquivos em comum.
Segundo Tanenbaum (2007), há o serviço de arquivo remoto, no qual
é oferecido aos clientes acesso transparente a um sistema de arquivos
que é gerenciado por um servidor remoto, conforme Figura 3.6.
Figura 3.6 | Modelo de acesso remoto

Cliente Servidor
Requisições de
clientes para acessar Arquivo permanece
arquivo remoto no servidor
Ainda para Tanenbaum (2007), há o modelo de carga/atualização,

no qual um cliente acessa um arquivo localmente, após tê-lo
descarregado do servidor, como na Figura 3.7. Quando o cliente
conclui a utilização do arquivo, este é carregado de volta para o
servidor, de modo que pode ser usado por um outro cliente.
Figura 3.7 | Modelo carga/atualização

Arquivo transferido
Cliente para cliente Servidor
Arquivo velho
Arquivo novo
2. Acessos são 3. Quando o cliente conclui, o

feitos no cliente arquivo é retornado ao servidor

Segundo Tanenbaum (2007), o serviço FTP (File Transfer Protocol)
pode ser usado desse modo quando um cliente descarrega um
arquivo completo, modifica o arquivo e o devolve. Veremos, na
Figura 3.8, a utilização de um proxy web quando o browser não
utiliza a linguagem FTP.
Figura 3.8 | Proxy web
Requisição HTTP Requisição FTP
Browser Proxy web Servidor FTP
Resposta HTTP Resposta FTP
Conforme Tanenbaum (2007), um cliente acessa o sistema de

arquivos usando as chamadas de sistema fornecidas por seu sistema
operacional local, contudo, a interface do sistema de arquivos local
Unix é substituída por uma interface para sistema de arquivo virtual
(VFS- Virtual File System).
Praticamente todos os sistemas operacionais modernos
oferecem VFS. Com NFS, as operações na interface VFS são
passadas para um sistema local de arquivos ou para um componente
separado, nominado cliente NFS, que se encarrega de manipular
acesso a arquivos armazenados em um servidor remoto. Em NFS,
toda comunicação cliente-servidor é feita por meio de RPCs. O
cliente NFS implementa as operações do sistema de arquivos NFS
como RPCs para o servidor.
Tanenbaum (2007) diz que as operações oferecidas pela
interface VFS podem ser diferentes das oferecidas pelo cliente
NFS. A ideia do VFS se resume em ocultar as diferenças entre
vários sistemas de arquivos.
No lado do servidor, vemos uma organização semelhante. O
servidor NFS é responsável por manipular as requisições que chegam
do cliente. O apêndice RPC desmonta requisições e o servidor
NFS as converte em operações comuns de arquivos VFS, que em
seguida são passadas para a camada VFS. Mais uma vez, o VFS é
responsável pela implementação de um sistema de arquivo local
no qual são armazenados os arquivos propriamente ditos. Uma

vantagem importante desse esquema é que o NFS é, em grande
parte, independente de sistemas locais de arquivos. O sistema
operacional, tanto no cliente quanto no servidor, pode ser por
exemplo Unix, Windows 2000 ou até o MS-DOS, a única questão
importante é que esses sistemas de arquivos sejam compatíveis com
o modelo de sistema de arquivos oferecido pelo NFS. Por exemplo,
o MS-DOS, com seus nomes de arquivos curtos, não pode ser usado
para implementar um servidor NFS de modo totalmente transparente.
Veremos a arquitetura NFS básica para sistemas Unix na Figura 3.9.
Figura 3.9 | Arquitetura NFS básica para sistemas Unix
2.2.2 | Modelo de sistema de arquivos distribuídos
Para Tanenbaum (2007), o modelo de sistema de arquivos oferecido

pelo NFS é quase igual ao oferecido por sistemas baseados em UNIX.
Arquivos são tratados como sequencias de bytes não interpretadas e
são organizados hierarquicamente em um gráfico de nomeação no
qual os nós representam diretórios e arquivos. O NFS também suporta
ligações estritas, além de ligações simbólicas, como qualquer sistema
de arquivos Unix. Arquivos têm nome e são acessados por meio de um
manipulador de arquivo semelhante ao Unix.
Um cliente para acessar um arquivo, deve consultar seu nome
em um serviço de nomeação e obter o manipulador de arquivo
associado. Temos que levar em conta que cada arquivo possui uma

série de atributos cujos valores podem ser consultados e alterados.
Veremos no Quadro 3.1 operações gerais de arquivo suportadas
pelas versões 3 e 4 do NFS, com algumas formas de trabalho distinta
em cada versão.
Quadro 3.1 | Algumas operações de sistema de arquivo suportadas por NFS
Operação v3 v4 Descrição
Create Sim Não Criar um arquivo comum
Create Não Sim Criar um arquivo não comum
Link Sim Sim Criar uma ligação estrita com um arquivo
Symlink Sim Não Criar uma ligação simbólica com um arquivo
Mkdir Sim Não Criar um subdiretório em um diretório dado
Mknod Sim Não Criar um arquivo especial
Rename Sim Sim Mudar o nome de um arquivo
Remove Sim Sim Remover um arquivo de um sistema de arquivo
Rmdir Sim Não Remover um subdiretório vazio de um diretório
Open Não Sim Abrir um arquivo
Close Não Sim Fechar um arquivo
Lockup Sim Sim Consultar um arquivo por meio de um nome de

arquivo
Readdir Sim Sim Ler as entradas em um diretório
Readlink Sim Sim Ler o nome de caminho armazenado em uma

ligação simbólica
Getaltr Sim Sim Obter os valores de atributo para um arquivo
Setaltr Sim Sim Estabelecer um ou mais valores de atributo para

um arquivo
Read Sim Sim Ler os dados contidos em um arquivo
Write Sim Sim Escrever dados para um arquivo

Resumindo, as funções básicas do NFS, são as seguintes:

a) Leitura, criação, deleção, gravação e renomeação dos arquivos.
b) Leitura, criação, deleção, gravação e renomeação de diretórios.
c) Leitura e modificação de atributos dos arquivos.

2.2.2.1 | Modelo de sistema de arquivos distribuídos
baseado em clusters
Tanenbaum (2007) afirma que NFS é um exemplo para

sistemas de arquivos distribuídos, que trabalham de acordo
com a arquitetura cliente-servidor tradicional. Muitas vezes essa
arquitetura é estendida para clusters de servidores, com algumas
diferenças. Os clusters de servidores costumam ser usados por
aplicações paralelas e seus sistemas de arquivos associados são
ajustados de acordo com isso.
Para Tanenbaum (2007), uma técnica muito conhecida é
desmembrar arquivos em tiras, pela qual um único arquivo é distribuído
por vários servidores. Algumas vezes essa técnica não é eficaz.
Conforme Tanenbaum (2007), a Amazon e o Google oferecem
serviços a clientes web que resultam em leituras e atualizações
para uma enorme quantidade de arquivos distribuídos
literalmente por dezenas de milhares de computadores. Para
minimizar os problemas, como o de um computador funcionar
mal, o Google desenvolveu seu próprio Sistema de Arquivos
Google (GFS – Google File System). Os arquivos Google tendem
a ser enormes, com vários gigabytes, e cada um desses arquivos
contém quantidades de objetos menores. Eles são atualizados
por anexação de dados a um arquivo e não sobrescrevendo o
arquivo. Além de considerarem as falhas de servidor como norma.
Ilustramos na Figura 3.10 essa organização.
Figura 3.10 | Clustrer de servidores Google

nome de arquivo,
índice de porção
Cliente GFS Mestre
endereço de contato Estado de
servidor de
porção
Instruções
ID de porção, faixa
Servidor de Servidor de Servidor de
porção porção porção
Dados de porção
Sistema de Sistema de Sistema de
arquivo Linux arquivo Linux arquivo Linux

Tanenbaum (2007) afirma que cada cluster GFS consiste em
um único mestre com vários servidores de porção. Cada arquivo
GFS é dividido em porções de 64Mbytes cada; em seguida, essas
porções são distribuídas pelos servidores de porção. O mestre GFS
é contatado apenas para obter informações de metadados.
Um cliente GFS passa ao mestre um nome de arquivo e um índice
de porção, esperando o endereço de contato para a porção. O
endereço de contato contém todas as informações para acessar o
servidor de porção correto para obter o arquivo de porção requisitado.
Esse é um processo simples, pois o mestre GFS mantém em
essência, um espaço de nomes junto com um mapeamento de
nomes para porções. Cada porção tem um identificador associado
que permitirá a um servidor de porção consultá-lo. Depois o mestre
monitora onde a porção está localizada. As porções são replicadas
apenas para manipular falhas.
2.3 | Comunicação
Sabe-se que, quando se trata de processos, segundo Tanenbaum

(2007), sistemas de arquivos distribuídos terão tipos diferentes de
processos cooperadores, como servidores de armazenamento e
gerenciadores de arquivos.
Para a comunicação em sistemas de arquivos distribuídos,
grande parte dela é baseada em chamadas de procedimento remoto
(RPCs). A principal razão para isso é tornar o sistema independente
dos sistemas operacionais, redes e protocolos de transporte.
2.3.1 | RPCs em NFS
Para Tanenbaum (2007), em NFS, toda comunicação entre

um cliente e um servidor segue as regras do protocolo ONC
RPC (Open Network Computing). Toda a operação em NFS pode
ser implementada como uma única chamada de procedimento
remoto a um servidor de arquivos. Com a evolução das versões
NFS, e para resolver problemas de desempenho, a versão 4 suporta
procedimentos compostos pelos quais várias RPCs podem ser
agrupadas em uma única requisição, conforme Figura 3.11.

Figura 3.11 | Leitura de dados de um arquivo em NFS versão 3 (a); Leitura de dados
dados de um arquivo em NFS versão 4 (b)
2.4 | Requisitos do sistema de arquivos distribuído
Para Coulouris (2007), alguns problemas surgiram quando se

iniciou o desenvolvimento de sistemas de arquivos distribuídos, que
tiveram que se adaptar às premissas de sistemas distribuídos:
a) Transparência
Sendo o serviço de arquivo usualmente trabalhado em uma
intranet; devemos ter boa funcionalidade e desempenho.
a1) Transparência de acesso: os programas cliente não necessitam
saber onde estão os arquivos. Um único conjunto de operações é
fornecido para acesso a arquivos locais e remotos.
a2) Transparência de localização: os programas clientes devem
ver um espaço de nomes de arquivos uniforme. Os arquivos, ou
grupos de arquivos, podem ser deslocados de um servidor a outro
sem alteração de seus nomes de caminho, e os programas de
usuário devem ver o mesmo espaço de nomes onde quer que
sejam executados.
a3) Transparência de mobilidade: os programas clientes e as
tabelas de administração de sistema nos computadores clientes não
precisam ser alterados quando os arquivos são movidos.

a4) Transparência de desempenho: os programas clientes devem
continuar a funcionar satisfatoriamente, enquanto a carga sobre o
serviço varia dentro de um intervalo especificado.
a5) Transparência de mudança de escala: o serviço pode ser
expandido de forma gradativa, para lidar com uma ampla variedade
de cargas e tamanhos de rede.
b) Atualizações concorrentes de arquivos

Sempre que houver acessos ou alterações simultâneas do
mesmo arquivo, não pode haver interferências de um em outro.
Nos serviços de arquivo atuais, segue-se os padrões UNIX,
fornecendo travamento (locking) em nível de arquivo ou em nível
de registro.
c) Replicação de arquivos
Em um serviço de arquivos que suporta replicação, um arquivo
pode ser representado por diversas cópias de seu conteúdo
em diferentes locais. Isso tem duas vantagens – permite que
vários servidores compartilhem a carga do fornecimento de
um serviço para clientes que acessam o mesmo conjunto de
arquivos, melhorando a escalabilidade do serviço, e melhora
a tolerância a falhas, permitindo que, em caso de falhas, os
clientes localizem outro servidor que contenha uma cópia
do arquivo.
d) Heterogeneidade do hardware e do sistema operacional

As interfaces de serviço devem ser definidas de modo que o
software cliente e servidor possa ser implementado para diferentes
sistemas operacionais e computadores. Esse requisito é um aspecto
importante de sistemas abertos.
e) Tolerância a falhas
Como é um requisito fundamental nos sistemas distribuídos, o
serviço de arquivo distribuído continue seu funcionamento quando
houver falhas de clientes e servidores.

f) Consistência
Os sistemas de arquivos convencionais, como o fornecido no
UNIX, oferecem semântica de atualização de cópia única (one-
copy). Isso se refere a um modelo de acesso concorrente a arquivos,
no qual o conteúdo do arquivo visto por todos os processos que
estão acessando, ou atualizando determinado arquivo, é aquele que
eles veriam se existisse apenas uma cópia do conteúdo do arquivo.
g) Segurança
Praticamente todos os sistemas de arquivos fornecem mecanismos
de controle de acesso baseados no uso de listas de controle de
acesso. Nos sistemas de arquivos distribídos, há necessidade de
autenticar as requisições dos clientes para que o controle de acesso
no servidor seja baseado nas identidades corretas de usuário e para
proteger o conteúdo das mensagens de requisição-resposta com
assinaturas digitais e/ou criptografia de dados.
h) Eficiência
Um serviço de arquivo distribuído deve oferecer recursos que
tenham pelo menos o mesmo poder e generalidade daqueles
encontrados nos sistemas de arquivos convencionais, e deve obter
um nível de desempenho comparável.
2.5 | Serviço de nomes DNS (Domain Name System)
Um dos maiores serviços distribuídos de nomeação em uso

é o sistema de nomes de domínio da Internet. O DNS é usado
principalmente para consultar endereços IP de hospedeiros e
servidores de correio.
Para Tanenbaum (2007), o espaço de nomes DNS é organizado
em hierarquia como uma árvore com raiz. Um rótulo é uma cadeia,
composta por caracteres alfanuméricos na qual a utilização de
minúsculas ou maiúsculas é indiferente. O comprimento do rótulo é
de no máximo 63 caracteres; o nome de caminho é de no máximo
255 caracteres. A representação em cadeia de um nome de caminho
consiste em uma listagem de seus rótulos, começando com a
da extrema direita e separando os rótulos por um ponto. A raiz é

representada por um ponto. Por exemplo, o nome do caminho root
<<nl,vu,cs,flits> é representado pela cadeia flits.cs.vu.nl que inclui o
ponto da extrema direita para indicar o nó raiz.
Cada nó no espaço de nomes DNS tem exatamente um ramo
de entrada, com exceção do nó-raiz, o rótulo anexado ao ramo de
entrada de um nó também é usado como o nome para aquele nó.
Uma sub árvore é denominada domínio; um nome de caminho até
seu nó-raiz é chamado de nome de domínio. O conteúdo de um
nó é formado por um conjunto de registros de recursos. Há tipos
diferentes de registros de recursos, como mostrado na Figura 3.12.
Figura 3.12 | Tipos de registros de recursos que formam o conteúdo de nós no

espaço de nomes DNS
Entidade Associada Descrição
Zona Contém informações sobre a zona representada
Hospedeiro Contém um endereço IP do hospedeiro que esse nó

representa
Domínio Refere-se a um servidor de correio para manipular o

correio endereçado a esse nó
Domínio Refere-se a um servidor que manipula um serviço

específico
Zona Refere-se a um servidor de nomes que implementa a

zona representada
Nó Ponteiro simbólico para o nome primário do nó

representado
Hospedeiro Contém o nome canônico de um hospedeiro
Hospedeiro Mantém informações sobre o hospedeiro que esse nó

representa
Qualquer tipo Contém qualquer informação específica de entidade

considerada útil
Para Tanenbaum (2007), há a nomeação simples, nomeação

estruturada e nomeações baseadas em atributos. Sistemas para
nomeação precisam de um identificador para o endereço de sua entidade
associada e para isso podemos usar broadcasting e multicasting.

Para saber mais
Vamos saber um pouco mais de configuração de NFS? <https://
tisemestresse.blogspot.com/2016/08/nfs-network-file-system.html>.
Acesso em: 15 ago. 2018.

se podemos armazenar, ler, criar arquivos com o NFS, será que a
preocupação coma segurança é valorizada o suficiente?
Estudamos que sistemas de arquivos distribuídos em geral

são organizados de acordo com o modelo cliente-servidor, com
cache ao lado do cliente suporte para replicação de servidores,
conseguindo assim cumprir o requisito de escalabilidade de sistemas
distribuídos. O sistema de arquivo de rede (NFS -Network File System),
é um mecanismo que permite o acesso a arquivos localizados
remotamente on-line, como se estivessem localmente na máquina,
é um dos mais utilizados para sistemas baseados em Unix. O DNS
é usado principalmente para consultar endereços IP de hospedeiros
e servidores de correio, fazendo com que qualquer pessoa consiga,
mesmo sem se dar conta da estrutura existente, acessar a Internet.
Fique ligado
Aqui estudamos sistemas de arquivos distribuídos, em seu modelo
cliente-servidor, que possuem requisitos para funcionar, que são:
a) Transparência.
b) Atualizações concorrentes de arquivos.
c) Replicação de arquivos.
d Heterogeneidade do hardware e do sistema operacional.
e) Tolerância a falhas.

f) Consistência.
g) Segurança.
h) Eficiência.
Na sequência, vimos que o DNS, um dos maiores serviços
distribuídos de nomeação em uso, é o sistema de nomes de domínio
da internet.

Devemos estar atentos aos principais princípios de sistemas
distribuídos para podermos trabalhar com objetos distribuídos,
sempre visando a agilidade, eficiência e segurança para usuário, que
deve sempre ter a impressão de trabalhar localmente.
1. Aplicada em: 2014 Banca: CESPE Órgão: SUFRAMA, Prova: Analista de
Sistemas (adaptada)
tecnologia-da-informacao-arquitetura-de-software>. Acesso em: 28 set. 2018.
Com referência a CORBA e web services, julgue os itens subsequentes.

No CORBA, o _______________________ é o responsável por encontrar a
implementação de objeto para o pedido feito pelo cliente, preparar a
implementação de objeto para receber o pedido e transmitir os dados
do pedido.
a) ORB (object request broker).

b) WEB.
c) NFS (network file system).
d) RPC (remote procedure call).
e) IDL (interface definition language).
2. Banca: Quadrix, 2011, Órgão: Dataprev, Prova: Analista de processos

tecnologia-da-informacao-arquitetura-de-software/corba>. Acesso em:
28 set. 2018.

As siglas DCE, CORBA e OLE se referem a padrões de mercado em:
a) desenvolvimento de aplicações em ambiente distribuído.
b) definição de bancos de dados corporativos.
c) sistemas de envio de pacotes encriptados a longas distâncias.
d) desenvolvimento para WEB.
e) desenvolvimento de aplicações orientadas a objetos.
3. Banca: CESGRANRIO, 2010, Órgão: ELETROBRAS Prova: Analista de

Sistemas - Suporte Basis SAP R3
tecnologia-da-informacao-arquitetura-de-software>. Acesso em: 28 set. 2018.
No CORBA, a linguagem utilizada para definir interfaces para objetos na

rede é denominada
a) C.
b) Assembly.
c) SmallTalk.
d) VB-6.
e) IDL.
4. Complete a lacuna:
Um(a) _______________________ permite aos programas armazenarem

e acessarem arquivos remotos exatamente como se fossem locais,
possibilitando que os usuários acessem arquivos a partir de qualquer
computador em uma rede.
a) objeto distribuído.
b) sistema de arquivos distribuído.
c) interface.
d) chamada remota de procedimento.
e) web.
5. Quando temos a definição de que é organizado em hierarquia como

uma árvore com raiz. Um rótulo é uma cadeia composta por caracteres
alfanuméricos na qual a utilização de minúsculas ou maiúsculas é
indiferente. Estamos nos referindo a:
a) ORB (object request broker).

b) DNS (domain name system).
c) NFS (network file system).
d) RPC (remote procedure call).
e) IDL (interface definition language).

Referências
CORREIA, C. H. Análise orientada a objetos. Florianópolis: Visual Books, 2006.
ORFALI, R.; HANKEY, D., EDWARDS, J. The Essential Distributeds Objects Survival
Guide. John Wiley & Sons, Inc.1996.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Sistemas distribuídos: conceitos e
projeto. Bookman Companhia Ed., 2007.
OMG. CORBA Basics. Disponível em: <http://omg.org>. Acesso em: 30 jul. 2018.
TANENBAUM, A. S.; STEEN, M. van. Sistemas distribuídos: principios e paradigmas.
São Paulo: Pearce Prentice Hall, 2007.
PRITCHARD, J. COM and CORBA Side by Side: Architectures, Strategies, and
Implementations. Addison Wesley, 2000.
Unidade 4
Gerenciamento de redes
Giancarlo Michelino Gaeta Lopes
Essa unidade tem como objetivo principal estudar o aspecto
físico dos sistemas distribuídos, tratando dos elementos
de hardware, projeto e gerenciamento do sistema. Dentro
desse contexto, há enfoque em apresentar os meios físicos
de comunicação de uma rede e como são compostos os
computadores e servidores que nela podem estar presentes.
Essa abordagem foca no comparativo entre as peças que são
utilizadas nos dois tipos de máquinas, tornando você capaz de
perceber como, em alguns casos, a rede distribuída é vantajosa
em relação à rede convencional baseada em servidor.
No âmbito do projeto e gerenciamento de um sistema
distribuído, o objetivo é tornar você capaz de determinar os
elementos que devem ser utilizados para a montagem de um
sistema, e como as diferentes camadas são gerenciadas de
forma a permitir o seu funcionamento.
Seção 1 | Elementos componentes de redes

Essa primeira seção traz uma revisão dos principais elementos
de redes e uma visão geral sobre o hardware dos servidores. Desta
forma, ao final dessa seção você estará apto a estudar como projetar
e gerenciar uma rede.
Seção 2 | Projeto e gerenciamento de redes

A segunda seção trata de como projetar e gerenciar uma rede
distribuída, dando enfoque à infraestrutura necessária por meio de
um estudo de caso de umas das maiores empresas de tecnologia
do mundo. Além de abordar a infraestrutura, a seção traz uma visão
geral sobre tudo aquilo que é necessário para a operação correta do
sistema, de forma confiável e otimizada.
Nas unidades anteriores desse livro foram tratados os algoritmos,
sistemas operacionais, objetos distribuídos e sistemas de arquivos
distribuídos, mas pouca atenção foi dada à implementação física
do sistema. Assim, essa unidade traz uma visão sobre o hardware
do sistema distribuído, apresentando conceitos que levam a
compreender como projetar e gerenciar um sistema.
Os sistemas distribuídos são cada vez mais utilizados como
padrão em grandes empresas de tecnologia da informação. Desta
forma, por mais que se conheça a estrutura presente em um sistema
desse tipo, é fundamental saber como é constituída a arquitetura
física do sistema e o tipo de máquinas utilizadas. Com isso, você
estará apto a determinar o formato da solução ideal para cada tipo
de aplicação com que você se depare em sua carreira profissional.
É perceptível que cada vez mais empresas fornecem a opção
de computação e armazenamento na nuvem. Com isso, não é
mais necessário um grande investimento a nível de hardware físico,
ambiente físico especializado e equipe de manutenção. Portanto,
encontramos uma tendência e a oportunidade de se desenvolver
sistemas distribuídos escaláveis. Por outro lado, fica evidente que
um profissional capacitado a implementar fisicamente um sistema
distribuído tem uma vantagem no mercado de trabalho – algo
importante para um engenheiro de computação.
A Seção 1 desta unidade faz uma revisão dos elementos de redes
presentes no mercado, incluindo uma análise sobre a diferença entre
um computador de mesa e um servidor. A Seção 2 disserta sobre a
maneira de projetar e gerenciar um sistema distribuído, mostrando a
arquitetura necessária para o funcionamento do sistema.
Bons estudos!
Seção 1
Projeto de redes
Essa unidade tem o objetivo de levar você a saber projetar e

gerenciar redes de computadores, porém é importante conhecermos
os principais elementos físico de redes existentes no mercado antes
de estudarmos esses outros conceitos. Além disso, é importante
sabermos diferenciar o hardware necessário para a montagem
de um computador convencional e um servidor, conhecendo as
tecnologias disponíveis para cada um deles e entendendo como os
servidores detêm um poder de processamento muito maior que os
computadores convencionais.
Para que os dispositivos se comuniquem dentro de uma rede,
eles devem estar interligados dentro de um mesmo meio físico,
que pode ser cabeado ou sem fio. Assim, para que os dispositivos
se interliguem à rede, eles devem ter uma placa de interface de
rede, que apresentam diversas especificações inerentes ao tipo
de conexão de rede que será realizada e à velocidade de tráfego
de dados permitida. Aqui vale ressaltar que na grande maioria dos
computadores atuais a placa de rede é integrada à placa mãe do
dispositivo. Desta forma, podemos iniciar o estudo dessa seção
abordando os meios físicos de conexão à rede.
1.1 | Meios físicos de conexão à rede e seus

dispositivos
Dentro de nossa análise dos meios físicos, vamos tratar

inicialmente do meio cabeado ou com fio. Segundo Barrett e King
(2010), nesse tipo de conexão existem dois métodos principais
para o envio de sinais pelos cabos: a banda base é uma, e faz o
uso de uma única frequência fixa para transmissão dos dados,
utilizando toda a largura de banda do cabo para transmitir o
sinal, fazendo com que sua intensidade sofra uma atenuação
120 U4 - Gerenciamento de redes

conforme a distância de transmissão, o que demanda a utilização
de repetidores para reestabelecer o sinal. Outro método é a banda
larga, que utiliza a transmissão analógica por uma faixa contínua de
valores para a transmissão de dados, possibilitando mais de uma
transmissão por um mesmo cabo, desde que ele apresente largura
de banda suficiente; além disso, também há atenuação do sinal
conforme a distância de transmissão, o que implica na utilização
de amplificadores.
O termo “banda larga” é muito conhecido devido a sua utilização
em sistemas de internet via linha telefônica, em que o sinal de internet
é transmitido no mesmo par de fios por qual passa o sinal voz do
telefone, mas em uma frequência muito mais alta, não interferindo
no sinal de voz. Isso justifica a utilização de um filtro para a conexão
do fio de telefone ao modem de internet, que tem o objetivo de
eliminar o sinal de voz presente. Nas redes de computadores, todos
os dados trafegam com o método banda base.
O primeiro tipo de cabo utilizado para redes de computadores
foi o cabo coaxial, que praticamente não é mais utilizado para essa
aplicação. Ele apresenta internamente um fio de cobre rígido com
uma blindagem metálica externa, a fim de reduzir a interferência
eletromagnética, como pode ser observado na Figura 4.1a.
Figura 4.1 | Cabos utilizados em redes de computadores: (a) coaxial, (b) UTP, (c) STP
e (d) fibra ótica
Fonte: Barrett e King (2010, p. 46-47).
O cabo de par trançado é o mais utilizado atualmente. Pode ser

não blindado, quando é chamado de UTP (do inglês, unshielded
twisted-pair), conforme mostra a Figura 4.1b, ou blindado, o
U4 - Gerenciamento de redes 121

chamado STP (do inglês, shielded twisted-pair), conforme a Figura
4.1c. Os cabos UTP contêm oito fios trançados em quatro pares
e existem sete categorias, que variam conforme a velocidade
máxima de transmissão e a blindagem do cabo. A categoria
mais popular é a 5, chamada de Cat5, que tem capacidade para
velocidades de até 1 Gbps, com segmentos de cabo de até 100
m (BARRETT; KING, 2010). Os cabos STP também apresentam
oito fios, arranjados em quatro pares; a diferença para o UTP
está na blindagem, que envolve cada um dos pares trançados.
Ambos os cabos utilizam o conector RJ-45 para se conectarem
aos dispositivos da rede.
Para saber mais

Consulte um artigo na internet que aborda detalhadamente todas as
categorias de cabos de par trançado existentes.
MEIRELLES, Adriano. Redes, Guia Prático 2ª ed. (Atualização). Hardware.
com.br. 1 abr. 2008. Disponível em: <https://www.hardware.com.br/
livros/redes/categorias-cabos.html>. Acesso em: 15 ago. 2018.
Quando se deseja altas velocidades de transmissão por longas

distâncias, a melhor opção de cabeamento a ser utilizada é a fibra
ótica, que utiliza pulsos de luz para transmitir o sinal, tornando-a
imune à grande maioria das interferências eletromagnéticas
(BARRETT; KING, 2010). A Figura 4.1d mostra como o cabo de fibra
ótica é composto, de forma a permitir que dados sejam transmitidos
em uma velocidade de até 10 Gbps por até 100 km de distância. A
sua principal desvantagem é o preço, além da maior dificuldade de
instalação e manutenção.
Quando estamos tratando de redes cabeadas, existem
dispositivos concentradores específicos que servem para interligar
computadores e outros dispositivos, operando nas diferentes
camadas de uma rede, como pode ser observado na Figura 4.2.
Lembrando que as camadas existentes na rede são baseadas no
modelo OSI (do inglês, Open Systems Interconnection), em que
cada uma das camadas são parte do processo de transferência de
informações pela rede (FOROUZAN, 2010).

Figura 4.2 | Dispositivos utilizados em cada camada que operam na rede
Aplicação
Transporte
Rede Roteador ou switch L3
Enlace Bridge ou switch L2
Física Repetidor ou hub
Fonte: adaptada de Forouzan (2010, p. 445).
Nesse sentido, os dispositivos mais simples são o hub e repetidor,

ambos integrantes da camada física. O hub realiza conexões entre
os dispositivos em uma topologia em estrela. O seu funcionamento
ocorre por broadcast, fazendo com que todos os dispositivos ligados
a ele recebam uma informação transmitida, e fica a cargo dos
dispositivos processarem ou descartarem a informação. O repetidor
tem a função de regenerar o sinal que passa por ele, possibilitando
que o alcance seja aumentado. Ele é largamente utilizado nas redes
sem fio, como será abordado mais à frente, mas também está
presente em redes cabeadas (FOROUZAN, 2010).
O bridge tem a função de dividir ou interligar diferentes redes,
reduzindo o tráfego e compatibilizando diferentes padrões de rede.
Assim, a sua principal função é manter o tráfego separado em
ambos os lados, como pode ser visto na Figura 4.3. Desta forma, ele
opera na camada de enlace, filtrando os frames e permitindo que
passe por ele somente o tráfego dirigido a um posto de trabalho do
lado oposto (FOROUZAN, 2010).
Figura 4.3 | Duas redes interligadas por um bridge
71:2B:13:45:61:41 71:2B:13:45:61:42 64:2B:13:45:61:12 64:2B:13:45:61:13

1 2
Bridge
LAN 1 LAN 2
Fonte: Forouzan (2010, p. 448).

O roteador opera direcionando pacotes baseado em seus
endereços lógicos, portanto, trabalha na camada de rede. Ele tem
a função de interligar LANs (do inglês, Local Area Network) e WANs
(do inglês, Wide Area Network) na internet, utilizando uma tabela de
roteamento para tomar decisões sobre a rota.
Quando estamos falando dos switches temos que nos atentar
ao dispositivo de qual camada estamos nos referindo, uma vez que
existem switches L2 (camada de enlace) e switches L3 (camada de rede).
O switch L2 pode ser definido como sendo um bridge como muitas
portas e um projeto que permite um tráfego de dados mais rápido. Isso
ocorre pois ele é capaz de identificar os dispositivos conectados a ele,
possibilitando a ocorrência de mais de uma transmissão ao mesmo
tempo e aumentando a velocidade da rede local. Assim, quando se
deseja interligar mais de oito dispositivos, é preferível utilizar um switch
L2 em detrimento a um hub. O switch L3 é um roteador mais rápido
e sofisticado, com uma estrutura de comutação que possibilita uma
pesquisa de tabela e encaminhamento mais rápidos (FOROUZAN, 2010).
Agora que já sabemos os principais equipamentos que encontramos
nas redes cabeadas, é possível citar as fabricantes desse tipo de
equipamento mais conhecidas do mercado. Certamente a marca
com maior visibilidade no mercado de equipamentos de TI é Cisco,
que fabrica uma ampla gama de equipamentos, desde servidores para
grandes data centers até switches de poucas portas, incluindo softwares
de gestão de rede. Como concorrente da Cisco, e também com
uma vasta gama de produtos, aparece a Dell EMC, se destacando na
computação na nuvem. Além dela, no mercado de data centers aparece
a Arista Networks, com enfoque em empreendimentos de grande porte
(COSTA, 2017). Quando estamos falando de rede menores, aparecem
outros fabricantes também bastante conhecidos como a TP-Link,
D-Link, Netgear, Linksys, Trendnet, Zyxel e HP (ALEXA, 2018).
Na rede sem fio, não existem cabos por onde os dados são
transmitidos, aumentando a mobilidade dos dispositivos conectados
à rede. Tal característica fez com que esse tipo de rede se tornasse
extremamente popular, permitindo a conexão de praticamente qualquer
dispositivo a uma rede, seja os nossos smartphones, aparelhos de
televisão, ou qualquer outro dispositivo que utilizamos no nosso dia a dia.
Para se conectar a uma rede sem fio, o dispositivo necessita
de uma placa de rede que trate da transmissão de dados por
radiofrequência. O padrão mais utilizado atualmente para tratar

dessa transmissão é o IEEE 802.11, que foi evoluindo com o
passar do tempo de forma a permitir o tráfego de dados cada
vez mais rápido (BERRETT e KING, 2010). Os padrões aceitos
pela maioria dos dispositivos recentes são: 802.11g, que trabalha
com taxas de transmissão de até 54 Mb/s e opera na frequência
de 2,4 GHz; o 802.11n, que incorporou a tecnologia MIMO (do
inglês, Multiple-Input Multiple-Output), utilizando várias antenas
para aumentar a taxa de transmissão que pode chegar a até
600 Mb/s quando opera nas faixas de frequência de 2,4 GHz e
5 GHz simultaneamente; e o padrão mais recente disponível é
o 802.11ac, que opera exclusivamente na frequência de 5 GHz
e pode atingir velocidades de até 6 Gb/s. Vale ressaltar que as
taxas de transmissão citadas são as máximas teóricas, dificilmente
obtidas na prática devido a interferências.
O acesso a uma rede sem fio é feito usualmente por meio de um
ponto de acesso ou estação base. Aqui podemos entender que um
roteador WiFi, como o que temos em nossa casa, funciona também
como um ponto de acesso, que tem a função de estabelecer a
conectividade sem fio entre os diversos dispositivos dos quais dispomos.
Esse roteador também tem a função de conectar a LAN sem fio a uma
LAN com fio, que pode ser gerada por um modem, proporcionando
assim acesso à internet a todos os dispositivos da rede local sem fios.
Perceba que a velocidade de comunicação entre os dispositivos
da rede sem fio dependerá do ponto de acesso utilizado para
estabelecer a conexão entre os dispositivos e também da própria
capacidade dos dispositivos. Por exemplo, caso você deseje uma
velocidade de comunicação de sua rede sem fios de 300 Mb/s,
você deve garantir que o roteador e os dispositivos sejam capazes
de operar nessa velocidade. Portanto, deve utilizar um roteador com
padrão 802.11n ou 802.11ac, que seja capaz de transmitir dados na
velocidade desejada, bem como garantir que os dispositivos operem
nesses padrões e suportem tal taxa de transmissão.
Além dos roteadores que estão presentes na grande maioria das
redes wi-fi, são utilizados também os repetidores. Como já foi dito,
esses dispositivos tem a função de aumentar a intensidade do sinal
de determinada rede, nesse caso, sem fio. Assim, ele recebe o sinal
de uma rede sem fio preestabelecida e o retransmite com maior
intensidade. Com isso, há um aumento no alcance da rede sem fio
e também a possibilidade de uma maior taxa de transmissão, pois

quanto menor a intensidade do sinal sem fio, menor tende a ser a
velocidade de comunicação.
Sobre a relação entre a velocidade de comunicação e a intensidade
do sinal wi-fi, podemos considerar que quando o sinal está em sua
intensidade próxima à máxima, a taxa de transmissão será próxima à
máxima teórica dos dispositivos. Com o aumento da distância entre
o equipamento que gera o sinal (roteador) e o dispositivo conectado
na rede (seu smartphone, por exemplo) haverá uma redução da
intensidade do sinal; com isso, a velocidade de comunicação será
menor. Isso ocorrendo, a chance de falhas na transmissão será maior,
ocasionando a necessidade de retransmissões, o que naturalmente
impactará a velocidade de transmissão dos dados.
Alguns fabricantes reconhecidos na fabricação de equipamentos
para rede cabeada também figuram como ótimas opções para
soluções sem fio, principalmente para redes com uma grande
quantidade de usuários: você pode encontrar ótimas opções de
equipamentos na Cisco, TP-Link, D-Link e Dell. Além dessas, para
redes domésticas e de pequenas empresas, há outras marcas com
grande número de vendas, como a IntelBras, a Tenda e a Asus.
1.2 | Hardware de computadores e servidores
Um computador convencional apresenta como componentes

de hardware a placa-mãe, processador, memória RAM, unidade
de armazenamento (disco rígido ou SSD) e pode ter outras placas
periféricas (vídeo, rede, etc.), além de uma fonte de alimentação
e um gabinete. Com os servidores não é diferente; eles dispõem
dos mesmos componentes, porém com uma maior capacidade
de processamento e confiabilidade. Assim, existem modelos
específicos de placa-mãe, memória e unidade de armazenamento
para serem utilizados quando se deseja montar um servidor.
Para tratarmos do hardware dos servidores, vamos fazer uma
revisão sobre os componentes mais utilizados quando se deseja
montar um computador de mesa, expondo os modelos mais
utilizados atualmente e comparando-os com os componentes
utilizados nos servidores. Essa análise é válida para conseguirmos
diferenciar o hardware de um computador e de um servidor,
e também porque um sistema distribuído tem como principal

característica a utilização de diversos PCs em detrimento a um
grande servidor.
Quando está se montando um computador, o primeiro
componente que se vem em mente é o processador, que realizará
os cálculos necessários para o funcionamento dos softwares que
estão rodando no PC. Aqui existem duas grandes marcas que
dividem o mercado, a Intel e a AMD. Até o ano de 2006 havia uma
disputa acirrada de mercado entre as duas marcas, porém, devido
ao sucesso dos processadores Pentium 4 e depois da linha Core I, a
Intel passou a dominar o mercado de processadores para PCs. Nos
processadores para servidores a situação é diferente; a AMD leva
vantagem com a linha EPYC, que dispõe de processadores com
maior desempenho, segurança e menor custo (MAZETTO, 2017).
Atualmente, a principal linha de processadores para PCs da Intel
é a Core I, composta pelo Core i3 (básico), i5 (intermediário), i7
(completo) e o novo modelo i9 (top de linha). Periodicamente a
fabricante lança novas gerações desses processadores que agregam
novas tecnologias de fabricação, proporcionando um aumento no
desempenho. Os processadores para PCs de mesa da AMD são
dispostos em várias linhas de produtos: as linhas A-Series e Athlon,
que estão há bastante tempo no mercado e são modelos de entrada;
e a linha Ryzen, que tem o objetivo de disputar o mercado com a
Core I da Intel, composta pelos processadores Ryzen 3 (básico), 5
(intermediário), 7 (completo) e Threadripper (top de linha).
Os processadores para servidor geralmente apresentam uma
maior quantidade de núcleos que os para PCs, o que permite o
processamento de mais tarefas simultaneamente. Além disso, eles
são projetados para funcionar ininterruptamente, passando por testes
rigorosos de temperatura e demanda de processamento. Oferecem
ainda tecnologias que autocorrigem os erros de processamento que
ameaçam a estabilidade do processador (PASSOS, 2016). A principal
linha de processadores para servidor da AMD é a EPYC, mas a fabricante
também conta com a linha Opteron, ainda muito utilizada. A Intel
oferece uma única linha de processadores para servidor, a Xeon.
O primeiro passo para a definição da placa-mãe a ser utilizada em
PC ou em um servidor é ter escolhido o processador que será utilizado.
Isso porque os processadores dispõem de diferentes soquetes, que
variam conforme a marca e, em alguns casos, entre as linhas de

produtos de um mesmo fabricante. Assim, fica claro que quando
está se determinando os componentes que são utilizados em uma
máquina, inicialmente deve se selecionar o processador a ser utilizado.
As principais diferenças entre uma placa-mãe de PC e de
servidor é que a de servidor pode apresentar dois ou mais soquetes
para processador e uma grande quantidade de conexões para
unidades de armazenamento. Além disso, a placa para servidor visa
à confiabilidade, sendo projetada para operar por horas a fio. As
marcas de placa-mãe para os dois tipos de máquinas mais presentes
no mercado são a Gigabyte, MSI, Asus e Intel.
As memórias RAM para servidor também seguem o padrão DDR
das utilizadas em PCs. Atualmente, o padrão mais utilizado é o DDR3,
mas já existe o padrão DDR4, com maior velocidade, capacidade
e menor consumo que seu antecessor. A diferença da memória
utilizada em servidores é que ela tem a tecnologia ECC (do inglês,
Error Correction Check), que verifica se o valor presente em um
endereço de memória foi alterado por alguma interferência ou erro
(AIRES, 2016). Com isso, há uma maior confiabilidade nesse tipo de
memória. As marcas de memória para os dois tipos de máquinas
mais presentes no mercado são a Kingston e a Corsair.
Quando estamos montando um PC, nos deparamos com duas
opções de unidade de armazenamento: o disco rígido (HD), com
alta capacidade de armazenamento por um baixo custo, e o SSD
(do inglês, Solid State Disk) com alta velocidade e alto custo por Gb.
Como nos servidores a necessidade é de uma alta capacidade de
armazenamento, utilizar SSDs se torna inviável devido ao alto custo
e, assim, são utilizados discos rígidos. Esses discos para servidor
operam em até 15.000 rpm, enquanto os para PCs normalmente
operam em 5.400 rpm. Eles também dispõem de um sistema de
verificação de erros de transmissão e correção de falhas. Além disso,
em alguns casos são instalados dois HDs em paralelo, que recebem
os mesmos dados em redundância, para aumentar a confiabilidade
do equipamento. As duas marcas que figuram como as principais
fabricantes de HDs são a Seagate e a Western Digital.
Para ilustrar os componentes que são utilizados em um computador
de mesa e em um servidor, estão apresentados nas Figuras 4.4 e
4.5 o processador, a placa-mãe, a memória RAM e a unidade de
armazenamento utilizados em cada um deles, respectivamente.

Figura 4.4 | Componentes de hardware de um computador de mesa pessoal
Fonte: adaptada de <https://goo.gl/images/Bmr73V>; <https://goo.gl/images/v4ukTL>; <https://goo.gl/images/

fmdLbG>; <https://goo.gl/images/5BDDbL>; <https://bit.ly/2zvTLwW>. Acesso: 26 set.. 2018.
Figura 4.5 | Componentes de hardware de um servidor.
Fonte: adaptada de <https://goo.gl/images/3JNV8J>; <https://goo.gl/images/QYpG3U>; <https://goo.gl/

images/5dh5Tk>; <https://goo.gl/images/J7R5Y8>; <https://bit.ly/2IjaHtm>. Acesso em: 26 set. 2018.
Para saber mais

Assista a um vídeo que fala do hardware de um servidor em detalhes e
aprofunde os seus conhecimentos.
SOUZA, Paôla. Hardware de Servidores (parte 1). Disponível em: <https://
youtu.be/IcHV6TYB0qg>. Acesso em: 15 ago. 2018. (Vídeo do YouTube)

Após apresentar as diferenças entre um hardware e um PC, é
possível afirmar que a confiabilidade é o aspecto que baliza todos
os componentes utilizados em um servidor, de forma a minimizar as
possíveis falhas que possam acontecer. Aliado a isso podemos tirar
outras conclusões:
• Os computadores não dispõem de componentes
redundantes, diferentemente daquilo que ocorre com o
caso dos HDs e fonte de alimentação nos servidores.
• As peças utilizadas em servidores são mais robustas, uma vez
que elas são projetadas para funcionar 24 horas por dia e sete
dias por semana, com alta durabilidade e baixo índice de falhas.
• O desempenho de um servidor será sempre melhor do
que o de um computador, porém, quando montamos
um sistema distribuído com diversos computadores, o
poder final de processamento será semelhante entre eles,
dependendo da situação.

Considerando que você tem um orçamento limitado de, por exemplo,
15 mil reais, qual opção gerará um melhor desempenho: um servidor
único ou um sistema distribuído composto por vários computadores?
1. Quando estamos tratando de redes cabeadas, existem dispositivos

concentradores específicos que servem para interligar computadores e
outros dispositivos. Nesse contexto, os dois dispositivos mais comuns são
o hub e o switch. Escreva com as suas palavras as diferenças entre estes
dois dispositivos.
2. As peças utilizadas em um servidor apresentam características diferentes

daquelas utilizadas no computadores pessoais. Descreva ao menos uma
diferença entre os processadores, placa-mãe, memória e disco rígido
dessas máquinas.

Seção 2
Projeto e gerenciamento de redes
Ser capaz de criar um projeto em sistemas distribuídos é uma

habilidade muito importante, tornando o profissional de tecnologia
capaz de desenvolver soluções que atendam às necessidades das
mais diversas aplicações. Assim, essa seção tem como objetivo
propor uma arquitetura de sistema distribuído coerente, que
possibilita a você fazer as escolhas corretas de componentes a
serem utilizados em um projeto.
Para ilustrar esse processo de projeto, vamos nos basear em
um estudo de caso de uma das maiores empresas de tecnologia
da informação do mundo, o Google. Vamos examinar o projeto
de sistema distribuído realizado, estudando a infraestrutura física
e componentes adjacentes aplicados, para que sejam oferecidos
todos os serviços disponibilizados pela companhia, desde sua
ferramenta de busca até os sistemas operacionais para smartphones.
Deve ficar claro que o formato em que o projeto do sistema
distribuído é apresentado aqui leva em consideração que você está
a par de todos os termos, serviços e objetos existentes nos sistemas
distribuídos que foram tratados nas unidades anteriores. Portanto,
caso você tenha alguma dúvida sobre o assunto, é recomendado
que volte às unidades anteriores e reforce o aprendizado.
2.1 | Introdução ao estudo de caso
O Google é uma grande empresa com sede na cidade de Mountain

View, Estados Unidos, e que oferece como principais serviços a
pesquisa na internet e aplicações web mais gerais. O seu lucro está
ligado principalmente aos anúncios que veicula em seus serviços.
Certamente você já utilizou os serviços dessa companhia, seja por uma
simples pesquisa, caixa de e-mail, editor de documentos on-line ou
por aplicativos para smartphone. Então, perceba como essa empresa

faz parte do nosso dia a dia, oferecendo vários serviços digitais que
facilitam a nossa vida. Para sustentar essa grande quantidade de
serviços que a empresa oferece, é necessário um sistema distribuído
eficiente, que tenha requisitos extremamente exigentes em termos
de escalabilidade, confiabilidade e desempenho. Assim, analisar as
estratégias e decisões de projeto trará uma ótima ideia de como
projetar um sistema distribuído.
O principal produto do Google é o seu mecanismo de busca, o
mais utilizado no mundo (NETMARKETSHARE, 2018). A sua função
nada mais é que receber determinada consulta e retornar ao usuário
uma lista ordenada com os resultados mais relevantes sobre aquilo
que foi pesquisado. O desafio aqui está relacionado ao tamanho
da web e sua alta taxa de mudança, além da exigência de sempre
fornecer os resultados mais relevantes aos usuários.
Tal mecanismo de busca consiste em um conjunto de serviços
com o objetivo de examinar minuciosamente a web, indexar e
classificar as páginas encontradas. Cada parte desse processo está
descrita nos detalhes a seguir:
• O processo de examinar minuciosamente a web, chamado
originalmente no inglês de crawling, tem a função de
localizar e recuperar o conteúdo da internet, e passá-lo para
o subsistema de indexação. Esse processo é realizado por
um software que lê recursivamente determinada página da
internet, coletando todos os links existentes nessa página e
programando novas operações de vasculhamento.
• A indexação tem a função de produzir um índice para o
conteúdo que foi buscado, realizando um mapeamento das
palavras que aparecem nas páginas e arquivos da internet,
gravando a posição exata em que o conteúdo buscado
aparece na página, o tamanho da fonte e se há uso de
letras maiúsculas. Veja então que o processo de indexação
serve para organizar as páginas encontradas no processo
de crawling.
• Estando organizadas as páginas relacionadas ao conteúdo
pesquisado, elas passam pelo processo de classificação,
que determinará a importância das páginas encontradas.
Essa classificação leva em consideração vários fatores como
a quantidade de vezes que a página foi citada em outras

páginas (PageRank), a proximidade de palavras-chave sobre o
tema e também as informações armazenadas na indexação,
como o tamanho da fonte e uso de letras maiúsculas. Assim,
ao final do processo de classificação, as páginas terão
diferentes relevâncias, que irão determinar a posição em que
aparecerão no resultado da busca.
Logicamente que o algoritmo do mecanismo de busca
apresentado é simplificado e existem outros passos menores que
não foram descritos. Tais passos podem ser vistos na Figura 4.6, que
apresenta um esboço da arquitetura do mecanismo de busca original
do Google. Perceba que o esboço apresenta vários servidores que
são necessários para o funcionamento do mecanismo, além de
softwares específicos responsáveis por executar as tarefas dentro
dos três grandes passos descritos. Aqui fica clara a importância de
conhecer o hardware dos servidores e dos PCs comuns, a fim de
diferenciar as suas capacidades de processamento.
Figura 4.6 | Esboço da arquitetura do mecanismo de busca original do Google
Fonte: Colouris et al. (2013, p. 921).

Como já foi dito, a Google oferece uma vasta gama de
serviços, que não se limitam ao buscador. A empresa opera
também como provedor de nuvem, oferecendo softwares
em nível de aplicação pela internet, como o Google Apps,
composto de e-mail (Gmail), editor de documentos (Google
Docs), hospedagem de sites (Google Sites), comunicação
(Google Hangouts), agenda (Google Calendar), dentre outros.
Ainda como provedor de nuvem, ela oferece APIs (do inglês,
Application Programming Interface) de sistema distribuído
como serviços pela internet, sendo usadas para suportar o
desenvolvimento e hospedagem de aplicações web, chamado
de Google App Engine. Como os APIs são um conjunto de
rotinas e padrões de programação (algoritmos) para o acesso
a um aplicativo de software ou uma plataforma baseada em
web, a Google permite que outros desenvolvedores de software
criem produtos associados aos seus serviços.
Após essa visão geral sobre os serviços prestados pela Google,
conseguimos perceber que a utilização de um sistema distribuído é
a melhor opção como infraestrutura. Portanto, nas próximas seções,
vamos estudar como foi projetado o sistema distribuído que opera
nesta empresa.
2.2 | Arquitetura de projeto
Dentro do Google a infraestrutura física é voltada para

a utilização de um número muito grande de PCs comuns,
produzindo um ambiente com custo reduzido utilizando
armazenamento e computação distribuídos. A compra dos
PCs sempre é feita com objetivo de obter o melhor custo
benefício, buscando máquinas com 2 Tb de armazenamento
em disco rígido e 16 Gb de memória RAM, executando uma
versão reduzida de Linux (COLOURIS et al., 2013). Porém, ao
optar pelo uso de PCs comuns, a Google sabia que partes
da sua infraestrutura falhariam e o projeto foi feito utilizando
estratégias para tolerar tais falhas. As falhas encontradas eram:
em razão do software, a necessidade de algumas máquinas

serem reiniciadas manualmente por dia; em razão do hardware,
em uma proporção de 1/10 das falhas por software, de 2 a 3 %
dos PCs por ano, acontecendo em grande maioria nos discos
rígidos ou memórias RAM (COLOURIS et al., 2013).
Como a grande maioria das falhas acontecia em razão do
software, percebeu-se que não era vantajoso se investir em
hardwares caros e mais confiáveis. Assim, a arquitetura física
foi construída baseada na ideia de um sistema distribuído, com
diversos PCs, em detrimento a um grande servidor com alta
capacidade de processamento. Desta forma, segundo Colouris
et al. (2013), a organização física do sistema foi feita conforme
aparece na Figura 4.7, distribuída da seguinte forma:
• Os PCs são organizados em racks compostos de 40 a 80
PCs cada, com dois lados, cada lado contendo metade
dos PCs. Cada rack dispõe ainda de um switch Ethernet
modular com várias lâminas, e cada lâmina suporta oito
interfaces de rede de 100 Mbps ou uma interface de 1 Gbps.
O switch fornece conectividade para o rack e conexão
externa com outros racks e também com a internet. No
caso de um rack com 40 PCs, ele terá um switch contendo
cinco lâminas com oito interfaces de rede (100 Mbps cada),
para a conectividade dentro do rack, e mais duas lâminas
de 1 Gbps, para a conexão externa.
• Os racks são organizados em clusters, que determinam
a localização e replicação dos serviços. Cada cluster
contêm 30 ou mais racks e, por redundância, dois
switchs com alta largura de banda, responsáveis por
fornecer conexão com a internet e com outros centros
da empresa. Para aumentar a confiabilidade da instalação,
cada switch tem mais uma redundância, de enlaces para
o mundo externo.
• Os clusters ficam alocados em centros de dados do
Google espalhados pelo mundo. Não há informação
exata de quantos centros de dados existem, o que se
sabe é que sua quantidade aumentou significativamente
nos últimos anos.

Figura 4.7 | Organização da infraestrutura física do Google
Para saber mais

Conheça como é um centro de dados do Google em detalhes assistindo
ao vídeo a seguir, em inglês, que mostra uma visão em 360º de um
desses locais (Habilite a legenda em português, caso seja necessário).
GOOGLE Cloud Platform. Google Data Center 360° Tour. Disponível
em: <https://youtu.be/zDAYZU4A3w0>. Acesso em: 14 ago. 2018.
(Vídeo do YouTube)
Veja que a partir da organização física apresentada para

o Google, é possível, por analogia, projetar outros sistemas
distribuídos. A principal característica é utilizar uma grande
quantidade de PCs comuns, que devem ser agrupados em
racks, que por sua vez formam clusters. Portanto, dependendo
da capacidade de armazenamento e processamento necessária
para a sua aplicação, você deve determinar quantos PCs devem
estar dispostos em cada rack, quantos racks formarão um cluster
e quantos clusters serão necessários. Dependendo da aplicação,

você pode criar clusters específicos para executar determinada
aplicação e assim organizar o seu centro de dados por setores.
Caso você tenha uma aplicação que exija um menor poder de
processamento e armazenamento, você pode apenas montar
vários racks e associá-los em um único cluster.
Considerando a estrutura física apresentada, é possível dizer que
o Google dispõe de recursos de armazenamento e computacionais
gigantes, aliados a esquemas de redundância que possibilitam
a construção de sistemas de larga escala e tolerantes a falhas.
Com isso, podemos estimar a capacidade de armazenamento
disponível no Google. Sabendo que cada PC dispõe de 2 Tb
de armazenamento, um rack com 80 PCs fornecerá 160 Tb,
consequentemente, um cluster com 30 racks terá 4,8 petabytes.
Não é possível saber exatamente quantos PCs a empresa possui,
mas se supormos que ela possua cerca de 200 clusters, teremos
uma capacidade de armazenamento de quase 1 exabyte (1018 bytes).
Sabendo de toda essa capacidade de armazenamento, podemos
agora avaliar como esse recurso, juntamente com a sua capacidade
de armazenamento, é utilizado para oferecer os seus serviços.

Dentro de um sistema distribuído, é possível afirmar que realizar
somente o projeto da infraestrutura física é suficiente para garantir o
funcionamento desejado?
Como já foi tratado no início da unidade, para sustentar a grande

quantidade de serviços que a empresa oferece é necessário um
sistema distribuído que apresente escalabilidade, confiabilidade
e desempenho. Para atender a essas necessidades, o Google
desenvolveu uma arquitetura de sistema global, como apresentada
na Figura 4.8 (COLOURIS et al., 2013). Na figura encontramos
três camadas, em que a mais inferior mostra a plataforma de
computação, que abrange a infraestrutura física já descrita. A
camada intermediária define uma infraestrutura distribuída comum,
que fornece suporte middleware para pesquisa e computação na
nuvem. Toda a infraestrutura fornece suporte para as aplicações e
serviços do Google, presente na camada superior.

Figura 4.8 | Arquitetura global de sistemas do Google
Aplicações e serviços do Google
Infraestrutura do Google (middleware)
Plataforma do Google
Fonte: adaptada de Colouris et al. (2013).
A camada intermediária da arquitetura global de sistemas, a

infraestrutura do Google (middleware), é constituída como sendo
um conjunto de serviços distribuídos que oferecem a funcionalidade
básica para os desenvolvedores. Esse conjunto de serviços é dividido
nos subconjuntos apresentados a seguir e organizados conforme
aparece na Figura 4.9:
• Paradigmas de comunicação, que inclui serviços para
invocação remota e comunicação direta, composto pelo
componente buffers de protocolo, que oferece um formato
de serialização comum para o Google, e pelo serviço de
publicar/assinar, que dissemina de forma eficiente eventos
para um número potencialmente grande de usuários.
• Serviço de dados e coordenação, que fornece abstrações
semiestruturadas e não estruturadas para o armazenamento
de dados. Nesse subconjunto estão serviços para suportar o
acesso aos dados: o GFS, que oferece um sistema de arquivos
distribuído, otimizado para os requisitos de aplicações e
serviços do Google; o Chubby, que suporta serviços de
coordenação e a armazenamento de dados para arquivos
pequenos; e o Bigtable, que oferece um banco de dados
distribuído com acesso a dados semiestruturados.
• Serviços de computação distribuída, que são meios para
executar computação paralela e distribuída na infraestrutura
física. Eles são o MapReduce, que computa de forma
distribuída em conjuntos de dados potencialmente muito
grandes, e o Sawzall, que é uma linguagem de nível mais alto
para executar a computação de forma distribuída.

Figura 4.9 | Infraestrutura do Google
MapReduce Sawzall Computação

distribuída
Dados e
GFS Chubby Bigtable
coordenação
Paradigmas de
Buffers de protocolo Publicar-assinar
comunicação
Se fizermos uma análise mais detalhada da camada middleware

dentro da arquitetura do Google, conseguimos abstrair alguns
detalhes relacionados à forma que é feito o gerenciamento do
sistema. Portanto, agora vamos tratar mais a fundo cada um dos
blocos apresentados dentro dos três subconjuntos da Figura 4.8.
Tratando inicialmente os paradigmas de comunicação, temos
dois elementos, os buffers de protocolo e o publicar/assinar. Nos
buffers de protocolo optou-se por utilizar uma linguagem simples
para se especificar os dados que seriam tratados; com isso se obteve
uma implementação eficiente e ao mesmo tempo flexível, que pode
ser utilizada com o objetivo de serializar dados para armazenamento
ou comunicação. Optou-se também pelo suporte de um estilo
de RPC (chamada remota de procedimento, do inglês Remote
Procedure Call), recebendo uma única mensagem como parâmetro
e retornando uma unida mensagem como resultado, o que torna
o procedimento mais eficiente, extensível e suporta a evolução do
serviço. Para o projeto do componente publicar/assinar, a opção
foi utilizar uma estratégia baseada em tópicos, com garantias de
tempo real e confiabilidade, suportando uma implementação
eficiente e manutenção de modos de exibição consistentes de
maneira oportuna. Perceba que essa estratégia é menos expressiva
do que as estratégias baseadas em conteúdo e exige um algoritmo
adicional com sobrecarga associada, pontos esses que se tornam

compromissos dentro desse componente, a fim de garantir o seu
funcionamento conforme o desejado (COLOURIS et al., 2013).
Quando falamos das escolhas de projeto relacionadas ao
armazenamento de dados e à coordenação, devemos analisar três
elementos: o GFS, o Chubby e o Bigtable. Sobre o serviço GFS, a
decisão de projeto foi de utilizar um trecho de tamanho grande,
com um mestre centralizado, separando fluxos de controle e de
dados em um modelo de consistência relaxado (COLOURIS et
al., 2013). Tais decisões foram feitas com o objetivo de tornar o
serviço eficiente para grandes leituras e anexações sequenciais,
minimizando o volume de dados, mantendo o mestre com uma
visão global que informa as decisões de gerenciamento com
mínimo envolvimento no acesso a arquivos de alto desempenho.
O principal prejuízo associado a essas decisões é que os dados
podem se tornar inconsistentes. O Chubby foi implementado de
forma a permitir a leitura e escrita de arquivos inteiros, com trava
e abstração de arquivos combinadas, possibilitando o uso variado
e sendo muito eficiente para arquivos pequenos. Já o Bigtable foi
implementado de forma a utilizar uma abstração de tabela com
ênfase no monitoramento e no balanceamento de carga, criando
uma capacidade de suportar números muito grandes de clientes
em paralelo.
Dentro da computação distribuída existem dois elementos,
existem o MapReduce e o Sawzall. O MapReduce foi projetado
com o suporte inerente para computações distribuídas tolerantes a
falhas; nesse caso o programador não precisa se preocupar com o
tratamento de falhas, que é algo importante para tarefas longas sendo
executadas em infraestrutura física, em que falhas são esperadas.
O Sawzall fornece uma linguagem de programação especializada
para computação distribuída, proporcionando um suporte para o
rápido desenvolvimento de computações distribuídas complexas,
com complexidade ocultadas para o programador.
2.3 | Algoritmos de coordenação e gerenciamento
Após tomar conhecimento de como é feito o projeto de um

sistema distribuído, realizando um estudo de caso do Google,
você está apto a avaliar formas de coordenação e gerenciamento

desses sistemas. Basicamente, essas formas são algoritmos que
apresentam diferentes objetivos, mas com a mesma função: que um
conjunto de processos coordene as ações do sistema distribuído ou
concorde com um ou mais valores. Atrelado a isso, esses algoritmos
são capazes de suportar falhas e manter o sistema operacional no
caso de algum problema.
O primeiro ponto que devemos tratar é a forma que uma falha
é detectada, uma vez que ela é derivada de algum defeito ocorrido
em algum dispositivo. Para tanto, existe o detector de falha, que é
um serviço consultado pelos processos para saber se um processo
em particular falhou. Na maioria das vezes, ele é implementado por
um objeto local, para cada processo que executa o algoritmo de
detecção de falha. Aqui podemos distinguir dois tipos de detectores
de falha: o detector de falha não confiável, que produz dois valores
(suspeito ou não suspeito), que são considerados como sugestões
de que houve ou não uma falha; e o detector de falha confiável, que
é sempre preciso na detecção da falha de um projeto retornando
“não suspeito” (funciona como uma sugestão) ou “falho” (COLOURIS
et al., 2013). Com isso, chegamos à conclusão que o algoritmo
detector de falha é uma forma de gerenciar o sistema distribuído,
pois quando se sabe que um processo sofreu uma falha, é possível
tomar as medidas necessárias.
Se um grupo de processos compartilha determinado recurso ou
uma coleção deles, frequentemente é exigida a exclusão mútua para
evitar a interferência entre processos e garantir a consistência ao
acessar esses recursos. Mas, em um sistema distribuído, geralmente
nem as variáveis compartilhadas nem os recursos fornecidos por
um núcleo local podem ser usados para resolvê-los. Assim, é
necessário um algoritmo para a exclusão mútua distribuída que seja
baseada unicamente na passagem de mensagens (COLOURIS et al.,
2013). Desta forma, para a gestão correta do sistema, é interessante
ter um mecanismo genérico de exclusão mútua distribuída que
seja independente do esquema de gerenciamento de recursos
específico em questão.
Um terceiro algoritmo que auxilia na coordenação do sistema
distribuído é o algoritmo de eleição, que tem a função de escolher
um único processo para desempenhar uma função em particular
(COLOURIS et al., 2013). Um algoritmo de eleição é necessário
para, por exemplo, escolher qual processo desempenhará a função

de servidor em determinado momento. E para que isso ocorra, é
fundamental que todos os processos – incluindo os não escolhidos –
concordem com a escolha. Após a escolha, se o processo escolhido
quiser se retirar, outra eleição será exigida para escolher um substituto.
Dentro desse processo, um processo convoca a eleição se ele faz
uma ação que inicia execução em particular do algoritmo de eleição.
Para saber mais

Para conhecer mais e saber como implementar os algoritmos citados,
consulte as seções 15.2 e 15 3, iniciando na página 633 do Capítulo 15 –
Coordenação e acordo da obra que segue:
COULOURIS, G. et al. Sistemas distribuídos: conceitos e projeto. 5ª ed.
Porto Alegre: Bookman, 2013.
Lembrando que você tem acesso a esse material na biblioteca virtual,
na sua área do aluno.
1. Quando o Google optou por utilizar um sistema distribuído, composto
por vários PCs, em detrimento ao uso de servidores com alto poder de
processamento, ele sabia que falhas poderiam acontecer. Cite as falhas
que foram encontradas na topologia com vários computadores.
2. Para sustentar a grande quantidade de serviços que o Google oferece

é necessário um sistema distribuído que apresente escalabilidade,
confiabilidade e desempenho. Para atender essas necessidades, o Google
desenvolveu uma arquitetura de sistema global, composta por três
camadas. Cite quais são essas camadas e a suas funções.
Fique ligado
Nesta unidade foram apresentados os seguintes tópicos:
• Elementos componentes de redes.
• Meios físicos de conexão à rede.
• Dispositivos de rede.

• Hardware de computadores e servidores.
• Projeto de sistemas distribuídos.
• Arquitetura de projeto.
• Gerenciamento de redes.
• Algoritmos de coordenação e gerenciamento.

Ao final do estudo desta unidade, é esperado que você tenha
conhecimento sobre como é disposta a infraestrutura de um
sistema distribuído e conheça os principais elementos físicos que
a compõem. Espera-se que você saiba diferenciar as características
de um servidor e de um computador pessoal quanto ao seu
desempenho e confiabilidade, sabendo aplicar o equipamento
correto dependendo da aplicação.
Toda a rede de informática é composta por uma infinidade de
cabos de rede, que viabilizam a comunicação entre as máquinas
e com o ambiente externo. Assim, essa unidade apresentou os
principais tipos de cabos utilizados nas instalações atuais, bem
como os principais elementos de rede. Aliada a isso, também foi
feita uma análise prática do hardware utilizado em computadores
e servidores, citando as principais tecnologias e marcas existentes
no mercado.
No âmbito do projeto de sistemas distribuídos, foi apresentado
um estudo de caso do Google, de forma a permitir que conheça a sua
infraestrutura física e também as decisões de projeto relacionadas
ao software executado. Para complementar essa abordagem, foram
apresentados algoritmos que são utilizados na coordenação e
gerenciamento do sistema distribuído.

1. Para que os dispositivos se comuniquem dentro de uma rede, eles
devem estar interligados dentro de um mesmo meio físico, que pode ser
cabeado ou sem fio. Em um meio cabeado, existem vários tipos de cabos
que podem ser utilizados. Sobre os cabos que podem ser utilizados em
uma rede de computadores, considere as seguintes afirmações:

I. O cabo coaxial dispõe, internamente, de um fio de cobre
rígido, com uma blindagem metálica externa, a fim de reduzir a
interferência eletromagnética.
II. Existem dois tipos de cabos de par trançado, o UTP e o STP, que
diferem pela presença ou não de blindagem.
III. A fibra ótica utiliza pulsos de luz para transmitir o sinal, o que a torna
imune à grande maioria das interferências eletromagnéticas.
IV. A fibra ótica apresenta baixo custo e facilidade de instalação
e manutenção.
Assinale a alternativa que indica quais afirmações estão corretas:

a) Somente I e II.
b) Somente III e IV.
c) Somente I, II e III.
d) Somente II, III e IV.
e) I, II, III e IV.
2. A confiabilidade é o aspecto que baliza todos os componentes

utilizados em um servidor, de forma a minimizar as possíveis falhas que
possam acontecer. Sobre as principais características que diferenciam os
servidores dos computadores, considere as seguintes afirmações:
I. O desempenho geral de um computador de mesa é sempre maior que
de um servidor.
II. Os computadores não possuem componentes redundantes,
diferentemente daquilo que ocorre com o caso dos HDs e fonte de
alimentação nos servidores.
III. As peças utilizadas em servidores são mais robustas, pois elas são
projetadas para funcionar 24 horas por dia e ste dias por semana, com
alta durabilidade e baixo índice de falhas.
IV. Os servidores podem ser constituídos com dois processadores.
Assinale a alternativa que indica quais afirmações estão corretas:

a) Somente I e II.
b) Somente III e IV.
c) Somente I, II e III.
d) Somente II, III e IV.
e) I, II, III e IV.
3. Sobre a arquitetura dos sistemas distribuídos, considere o

seguinte trecho:
“A arquitetura global de um sistema distribuído possui três camadas que
determinam o funcionamento do sistema. A camada mais inferior é a

______________, que abrange a infraestrutura física do sistema. A camada
intermediária define uma infraestrutura distribuída comum, que fornece
suporte __________ para pesquisa e computação na nuvem. Toda a infraestrutura
fornece suporte para as _____________, presente na camada superior.”
Assinale a alternativa que completa corretamente as lacunas presentes no

texto, respectivamente.
a) plataforma de computação; middleware; aplicações e serviços.
b) de tecnologia; aos dados; informações e estudos.
c) plataforma de computação; aos dados; middleware e software.
d) de informações; ransomware; transições e trocas de informações.
e) bottom; middleware; aplicações e serviços.
4. A ideia de um sistema distribuído pode ser levada em conta na

arquitetura física de uma central de dados, utilizando diversos PCs, em
detrimento a um grande servidor com alta capacidade de processamento.
Nesse caso, esses computadores devem ser organizados de forma a
permitir o funcionamento adequado do sistema.
Sobre a organização física de um sistema distribuído montado com
diversos computadores, assinale a alternativa correta.
a) Os PCs são organizados em baias distribuídas aleatoriamente pelo

centro de dados, interligadas por meio de switchs.
b) Os PCs são organizados em racks, os racks são organizados em clusters
e os clusters compõem um centro de dados.
c) A organização de um sistema desse tipo não é importante, e o que
importa é a utilização de um servidor central wi-fi.
d) Os racks são organizados em PCs, que formam o centro de dados em
que o sistema distribuído se comunica com o mundo.
e) Os PCs são organizados em racks, os racks são organizados em centros
de dados e os centros de dados compõem um rack.
5. A camada intermediária da arquitetura global de sistemas (middleware)

é constituída como sendo um conjunto de serviços distribuídos que
oferecem a funcionalidade básica para os desenvolvedores. Esse conjunto
de serviços é subdividido em outros subconjuntos, e um deles são os
paradigmas de comunicação.
Sobre os paradigmas de comunicação, assinale a alternativa correta.

a) Fornece abstrações semiestruturadas e não estruturadas para o
armazenamento de dados e é composto pelos serviços GFS, Chubby e Bigtable.

b) São meios para executar computação paralela e distribuída na
infraestrutura física, composto pelos serviços MapReduce e o Sawzall.
c) Inclui serviços para invocação remota e comunicação direta, composto
pelos serviços MapReduce e Sawzall.
d) São meios para executar computação paralela e distribuída na
infraestrutura física, composto pelo componente buffers de protocolo e
pelo serviço de publicar/assinar.
e) Inclui serviços para invocação remota e comunicação direta, composto
pelo componente buffers de protocolo e pelo serviço de publicar/assinar.

Referências
AIRES, R. Diferença entre Memória ECC e Memória Não ECC (Memória Comum).
2016. Aires Ruy, 1 jan. 2016. Disponível em: <https://airesruy.com.br/diferenca-entre-
memoria-ecc-e-memoria-nao-ecc-memoria-comum/>. Acesso em: 12 set. 2018.
ALEXA, W. Best Ethernet Switch of 2018 – Top 10 Network Switches. ProTechLists, 1
set. 2018. Disponível em: <https://protechlists.com/best-ethernet-switches/>. Acesso
em: 15 set. 2018.
BARRETT, D.; KING, T. Redes de computadores. 1ª ed. Rio de Janeiro: LTC, 2010.
COSTA, S. Equipamentos de TI: quais as melhores marcas para o seu projeto de data
center?. AnyConsultying, 23 ago. 2017. Disponível em: <https://www.anyconsulting.
com.br/fabricantes-equipamentos-de-ti/>. Acesso em: 15 set. 2018.
COLOURIS, G. et al. Sistemas distribuídos: conceitos e projeto. 5ª ed. Porto Alegre:
Bookman, 2013.
FOROUZAN, B. A. Comunicação de dados e redes de computadores. 4ª ed. Porto
Alegre: AMGH, 2010.
MAZETTO, L. AMD leva guerra com Intel para os servidores com novo
processador Epyc. Idg Now!, 21 jun. 2017. Disponível em: <http://idgnow.com.br/ti-
corporativa/2017/06/21/amd-leva-guerra-com-intel-para-os-servidores-com-novo-
processador-epyc/>. Acesso em: 12 set. 2018.
NETMARKETSHARE. Search Engine Market Share. 2018. Disponível em: <https://net-
marketshare.com/search-engine-market-share.aspx>. Acesso em: 12 set. 2018.
PASSOS, E. Servidor versus Computador normal. Infobusiness Informática, 8 ago.
2016. Disponível em: <http://infob.com.br/servidor-versus-computador-normal/>.
Acesso em: 12 set. 2018.
SCHERES, E. Melhores Roteadores Wireless. Guia dos Melhores, 25 set. 2018.
Disponível em: <https://guiadosmelhores.com.br/melhores-roteadores-wireless/>.
Acesso em: 27 set. 2018.
TANENBAUM, A. S; STEEN, M. Sistemas distribuídos: princípios e paradigmas. São
Paulo: Pearson Prentice Hall, 2007.

Projetos de Redes e Sistemas Distribuídos PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Projetos de Redes e Sistemas Distribuídos PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Projetos de

Adriane Aparecida Loper

Vice-Presidente Acadêmico de Graduação e de Educação Básica

Dados Internacionais de Catalogação na Publicação (CIP)

Loper, Adriene Aparecida

1. Redes de computadores. I. Loper, Adriene Aparecida.

Unidade 1 | Conceitos e características dos sistemas distribuídos 9

Seção 1 - Conceitos, características e exemplos dos

Seção 1 - Introdução à comunicação entre processos 53

Seção 1 - Objetos distribuídos, RMI 84

Seção 2 - Sistemas de Arquivos Distribuídos,

Seção 1 - Projeto de redes 120

Seção 1 | Conceitos, características e exemplos dos

Seção 2 | Modelos e arquitetura de sistemas distribuídos

Caro aluno, nesta seção terá contato com um breve histórico

1. | Princípios fundamentais de sistemas distribuídos

Na década de 1980, com a introdução dos microcomputadores

12 U1 - Conceitos e características dos sistemas distribuídos

1.2 | Definição de sistemas distribuídos

Para Tanenbaum (2007, p. 1), “um sistema distribuído é um

U1 - Conceitos e características dos sistemas distribuídos 13

Computador pessoal Servidor

Estação de trabalho Impressora

A partir dessas definições, podemos observar que só os

14 U1 - Conceitos e características dos sistemas distribuídos

1.3 | Características/ metas de sistemas distribuídos

Tanenbaum (2007, p. 2) nos traz, “a meta principal de um

U1 - Conceitos e características dos sistemas distribuídos 15

Figura 1.2 | Middleware

Fonte: Tanenbaum (2007, p. 2).

Só relembrando que alguns middleware suportam apenas uma

16 U1 - Conceitos e características dos sistemas distribuídos

U1 - Conceitos e características dos sistemas distribuídos 17

18 U1 - Conceitos e características dos sistemas distribuídos

U1 - Conceitos e características dos sistemas distribuídos 19

20 U1 - Conceitos e características dos sistemas distribuídos

Para saber mais

Questão para reflexão

U1 - Conceitos e características dos sistemas distribuídos 21

Temos diversos exemplos de sistemas distribuídos, por exemplo,

1.4.1 | Internet – exemplo 1

A Internet, como podemos entender, trata-se de um grande

Figura 1.3 | Uma parte típica da Internet

Fonte: Coulouris (2007, p. 17).

22 U1 - Conceitos e características dos sistemas distribuídos

1.4.2 | Internet das Coisas (IOT) - Exemplo 2

A internet das coisas (do inglês Internet of things) – IOT surgiu

A IoT (Internet of Things, internet das coisas), algumas

1.4.3 | Intranets - Exemplo 3

Várias empresas e universidades possuem intranets, que,

U1 - Conceitos e características dos sistemas distribuídos 23

Figura 1.4 | Uma intranet típica

Fonte: Coulouris (2007, p. 18).

1.4.4 | Computação móvel e ubíqua - Exemplo 4

Couloures (2007) define que consiste da integração de

24 U1 - Conceitos e características dos sistemas distribuídos

Intranet anfitriã Intranet doméstica

Telefone Sinal de satélite GPS

Fonte: Coulouris (2007, p. 20).

1.5 | Finalizando a seção

E concluindo esta seção, a transparência é um fator muito

U1 - Conceitos e características dos sistemas distribuídos 25

Encerramos esta seção com exemplos do nosso cotidiano, que