Documente Academic
Documente Profesional
Documente Cultură
definio:
um SD um sistema em que os componentes situados na rede de computadores
comunicam e coordenam as suas aces apenas por passagem de mensagens.
recursos:
geridos pelo servidor e acedidos por clientes;
ou encapsulados como objectos e acedidos por outros clientes objectos.
espao fsico:
os computadores conectados numa rede podem estar, espacialmente, separados por
qualquer distncia (continentes diferentes, mesma sala, mesmo edifcio, etc);
concorrncia:
numa rede de computadores, a execuo de programas concorrentes a norma;
eu num computador, tu noutro e partilhamos ficheiros, etc;
a capacidade do sistema para tratar a partilha de recursos pode ser aumentada
adicionando mais recursos rede (mais computadores, por exemplo).
falhas independentes:
todos os sistemas de computadores podem falhar e cabe aos system designers
planear as consequncias de possveis falhas;
falhas numa rede resultam no isolamento dos computadores nessa rede (mas no
significa que deixem de estar operacionais);
cada componente do sistema pode falhar individualmente, sendo que as outras
continuam a funcionar.
1.2 - Examples of distributed systems
Google:
possui um dos maiores e mais complexos SDs da histria;
infraestrutura fsica subjacente que consiste numa grande quantidade de
computadores em rede situados em data centres por todo o mundo;
um sistema de ficheiros distribudos para suportar ficheiros pesados;
um sistema de armazenamento estruturado associado que oferece acesso
rpido a grandes datasets;
um modelo de programao que suporta a gesto de grandes computaes em
paralelo e distribudas por toda a infraestrutura fsica.
12.2 - Massively multiplayer online games (MMOGs)
os SDs passam por mudanas constantes e isso pode ser visto atravs das diversas
tendncias:
a emergncia de tecnologias de rede;
a emergncia de computao ubqua acoplada com o desejo de suportar mobilidade
do user nos SDs;
aumento da procura de servios multimdia;
os SDs como utilidade.
1.5.1 - Heterogeneidade
a Internet permite aos seus users aceder a vrios aceder a servios e executar
aplicaes atravs de uma coleco de computadores e redes;
alguns exemplos:
data types como inteiros podem ser representados de formas diferentes em diferentes
tipos de hardware (deve-se lidar com isto se se forem trocar mensagens entre
programas a correrem em diferentes hardwares);
os SOs de todos os computadores precisam de ter uma implementao dos
protocolos da Internet (e nem todos os protocolos precisam ter a mesma interface, por
exemplo, a troca de mensagens diferente em UNIX e Windows);
as diferentes linguagens de programao utilizam representaes diferentes para chars
e EDs (tais como arrays e records);
programas escritos por developers diferentes no conseguem comunicar entre si a
menos que utilizem standards comuns (por exemplo, para a representao de tipos
primitivos de data e EDs nas mensagens - para tal, temos os protocolos da Internet);
Middleware:
o termos mobile code refere-se ao ao program code que pode ser transferido de um
computador para outro e ser executado no seu destino (Java applets, por exemplo);
a abordagem da virtual machine uma forma de tornar o cdigo executvel numa
variedade de computadores host (isto , um compilador para uma linguagem em
particular gera cdigo para a virtual machine em vez de cdigo para um hardware em
particular (por exemplo, o compilador do Java produz cdigo para a JVM que o
executa por interpretao (a JVM precisa de ser implementada uma vez para cada tipo
de computador para permitir que os programas Java corram);
a forma mais usada de mobile code a incluso de programas Javascript em algumas
pginas web carregadas para client browsers (mais sobre isto em 1.6).
1.5.2 - Openness
sumarizando:
open systems so caracterizados pelos facto de os seus key interfaces serem
publicados;
open distributed systems so baseados num mecanismo uniforme de comunicao e
interfaces publicadas para acesso de recursos partilhados;
open distributed systems podem ser construdos a partir de hardware e software
heterogneos (possivelmente de diferentes fornecedores), no entanto, a conformidade
de cada componente deve ser cuidadosamente testada e verificada para o sistema
funcionar correctamente.
1.5.3 - Security
maior parte da informao que est disponvel nos SDs tem um enorme valor para os
seus users, pelo que a sua segurana de extrema importncia;
o facto de existir comunicao seja qual for a localizao, traz riscos ao nvel da
segurana associados ao facto de existir acesso livre a recursos da intranet (no
entanto, pode-se usar uma firewall para formar uma barreira volta da intranet,
restringindo o trfego que pode entrar e sair apesar de isto no garantir o uso
apropriado de recursos pelos users na intra net ou o uso de recursos na Internet (que,
neste caso, no esto protegidos por uma firewall));
num SD, os clientes enviam pedidos de acesso para aceder a dados geridos pelos
servidores o que envolve enviar informao em mensagens atravs de uma rede (por
exemplo, um Dr. pedir acesso aos dados de um paciente ou adicionar dados ficha
desse paciente, entre outros);
a segurana no se trata s de esconder o contedo das mensagens, tambm
envolve ter a certeza da identidade do user ou do agente em nome de quem a
mensagem foi enviada (no exemplo anterior, o servidor precisa de saber que o user
mesmo um Dr.);
para resolver este tipo de problema, existe o uso de tcnicas de encriptao
desenvolvidas para este propsito (mais sobre isto no Captulo 11);
apesar de tudo isto, existem ainda dois desafios ao nvel da segurana que ainda no
tm uma soluo universal:
denial of service attack, que consiste em bombardear o servio com um nmero
anormal de pedidos inteis de forma a que os users a srio, reais sejam incapazes
de utilizar o servio (mais sobre isto no Captulo 3);
security of mobile code, considerando que algum recebe um executvel de um
programa como anexo de um mail, os possveis efeitos de executar tal programa so
imprevisveis (mais sobre isto no Captulo 11).
1.5.4 - Scalability
no entanto, existem algumas tcnicas para lidar com falhas, tais como:
deteco de falhas, algumas falhas podem ser detectadas, por exemplo, checksums
podem ser utilizadas para detectar dados corrompidos numa mensagem ou num
ficheiro (no Captulo 2 explicado que muito difcil ou mesmo impossvel de
detectar algumas outras falhas, tal como um servidor remoto na Internet que tenha
crashado, ou seja, o desafio a gesto de falhas que no possam ser detectadas
mas que possam ser suspeitadas;
esconder as falhas, algumas falhas podem ser escondidas ou tornadas menos notrias
(por exemplo, mensagens podem ser retransmitidas quando no chegam ao
destinatrio ou um ficheiro pode ser escrito em dois discos para que, caso um esteja
corrompido, o outro ainda possa estar correcto);
tolerncia a falhas, muitos servios da Internet exibem falhas (no seria prtico
tentar detectar e esconder todas as falhas que possam ocorrer numa rede to grande
com tantos componentes, por exemplo, quando um web browser no consegue
contactar com um web server, no faz o user esperar, informa-o do problema);
recuperar de falhas, envolve que o design do software seja tal que permita que o
estado permanente dos dados possa ser recuperado (ou rolled back) aps um
servidor ter crashado (mais sobre isto no Captulo 17);
redundncia, os servios podem ser feitos de modo a tolerar falhas utilizando
componentes redundantes (por exemplo, deve existir sempre (no mnimo) duas rotas
diferentes entre quaisquer dois routers na Internet ou, outro exemplo, no DNS cada
nome de tabela replicado em, pelo menos, dois servidores diferentes, etc);
tanto os servidores como as aplicaes fornecem recursos que podem ser partilhados
pelos clientes num SD, pelo que existe a possibilidade de vrios clientes tentarem
aceder a um recurso partilhado ao mesmo tempo (por exemplo, uma ED que grava
lances para um leilo pode ser acedida vrias vezes medida que se aproxima o fim
do leilo);
os servios e aplicaes, geralmente, permitem que mltiplos pedidos de clientes
possam ser processados concorrentemente (supondo que cada recurso est
encapsulado como um objecto e as suas invocaes so executadas em threads
concorrentes, neste caso, possvel que vrias threads possam estar a executar
concorrentemente dentro de um objecto, o que faria com que houvesse conflito de
ambas as operaes e houvesse uma produo inconsistente de resultados);
ou seja, qualquer objecto que represente um recurso partilhado num SD deve ser
responsvel por assegurar que funciona correctamente num ambiente concorrente
(isto aplica-se tanto a servidores como a objecto em aplicaes) pelo que a
implementao de um objecto cujo o objectivo no era ser usado num SD deve fazer o
que for necessrio para que o objecto seja seguro num ambiente concorrent;
para um objecto ser seguro num ambiente concorrente, as suas operaes devem ser
sincronizadas de tal modo que os seus dados se mantenham consistentes (isto pode ser
alcanado atravs de tcnicas standard, tais como semforos, que so utilizados na
maior parte dos SOs (mais sobre isto nos Captulos 7 e 17)).
1.5.7 - Transparency
formas de transparncia:
transparncia de acesso, possibilita que recursos locais e remotos sejam acedidos
utilizando operaes idnticas;
transparncia de localizao, possibilita que os recursos sejam acedidos sem ser
conhecida a sua localizao fsica ou de rede (por exemplo, o edifcio (fsica) ou o IP
(rede));
transparncia da concorrncia, possibilita que vrios processos operem de forma
concorrente utilizando recursos partilhados sem que haja interferncia entre eles;
transparncia da replicao, possibilita que mltiplas instncias de recursos serem
utilizadas para aumentar a confiabilidade e o desempenho sem que os users e os
programadores das aplicaes tenham conhecimento das rplicas;
transparncia de falhas, possibilita ocultar falhas permitindo aos users e aos
programadores das aplicaes completarem as suas tarefas independentemente das
falhas ocorrerem ao nvel do hardware ou do software;
transparncia da mobilidade, permite o movimento de recursos e clientes dentro de
um sistema sem afectar as operaes de users ou programas;
transparncia de desempenho, permite ao sistema ser reconfigurado para melhorar o
desempenho medida que a carga varia;
transparncia da escalabilidade, permite ao sistema e aplicaes expandirem em
escala sem modificar a estrutura do sistema ou os algoritmos das aplicaes.
uma vez que os users obtenham as funcionalidades que pretendiam, tal como um
servio de ficheiros num SD, podemos perguntar sobre a qualidade do servio;
as principais propriedades dos sistemas que afectam a qualidade do servio
experienciada pelos clientes e pelos users so a confiabilidade, segurana e o
desempenho (pelo que a adaptabilidade para mudar as configuraes do sistema e a
disponibilidade de recursos reconhecido como um aspecto importante da qualidade
do servio;
a confiabilidade e a segurana so crticos no design da maior parte dos sistemas de
computadores.
1.6 - Case study: The World Wide Web
HTML:
utilizado para especificar o texto e as imagens que fazem o contedo de uma pgina
web e para especificar como so apresentados ao user
os users conseguem produzir HTML mo, utilizando um editor de texto.
URLs:
o propsito de um Uniform Resource Locator (URL) identificar um recurso;
os browsers examinam os URLs para aceder aos recursos correspondentes, isto ,
normalmente, o browser procura o URL correspondente quando o user clica num link
ou quando o browser faz fetchde um recurso embebido numa pgina web (como
uma imagem);
um URL HTTP tem dois objectivos principais (identificar em que web server se
encontram os recursos e identificar qual dos recursos do web server se pretende).
Publicar um recurso:
enquanto que tem um modelo bem definido para aceder a recursos atravs do seu
URL, publicar recursos vai depender da implementao do web server.
HTTP:
define de que maneiras os browsers e outros clientes interagem com os web servers
(mais sobre isto no Captulo 5);
Request-reply interactions, o HTTP um protocolo request-reply em que o cliente
envia um pedido de mensagem ao servidor que contm o URL do recurso pretendido,
depois o servidor procura o nome do caminho e, caso exista, envia de volta o
contedo pretendido como mensagem de resposta ao cliente (caso contrrio, envia
uma resposta como 404 Not Found);
Content types, os browsers no necessariamente capazes de tratar todo o tipo de
contedos;
One resource per request, os clientes especificam um recursos por pedido HTTP (por
exemplo, se uma pgina web tem nove imagens o web browser ir tratar dez pedidos
separados para obter a totalidade dos contedos da pgina (os browsers, tipicamente,
fazem vrios pedidos concorrentemente para reduzir o delay geral para o user);
Simple access control, regra geral, qualquer user com uma ligao rede a um web
server consegue aceder a qualquer dos seus recursos publicados.
Dynamic pages:
a maior das experincias dos users com a Web interagir com servios em vez de
recuperar dados;
por exemplo, o preenchimento de um formulrio est sujeito ao input do user, pelo
que o servidor tem de processar esse input, portanto, o URL designa um programa no
servidor (e no um ficheiro);
caso o input do user seja um conjunto razoavelmente pequeno de parmetro,
comummente enviado como o componente query do URL, utilizando o mtodo GET,
alternativamente, enviado como data adicional no pedido utilizando o mtodo
POST;
um programa que os web servers executam para gerar contedo para os seus clientes
referido como Common Gateway Interface (CGI), um programa CGI deve
conseguir analisar os argumentos que o cliente fornecer e produzir o contedo
pretendido (normalmente texto HTML), sendo que o programa vai, com frequncia,
consultar ou actualizar a base de dados ao processar o pedido.
Download Code:
um programa CGI executado no servidor;
s vezes, os designers dos servios web precisam de cdigo service-related para
executar dentro do browser, no computador do user (em particular, cdigo escrito em
Javascript [www.netscape.com] downloaded com frequncia com a pgina web,
contendo um formulrio de maneira a fornecer melhor qualidade na interaco com o
user do que aquela que os widgets padro do HTML permitem;
uma pgina Javascript melhorada pode dar ao user feedback instantneo de entradas
invlidas em vez de forar o user a verificar os valores no servidor o que iria demorar
muito mais;
o Javascript pode tambm ser utilizado para actualizar partes do contedo de uma
pgina web sem fazer fetch de uma verso completamente nova da pgina e
proceder sua re-renderizao (estes updates dinmicos ocorrem devido a aces do
user (clicar num link ou num radio button) ou quando o browser receber nova data
do servidor (neste caso, uma vez que o tempo de chegada da data no est
relacionada com nenhuma aco do user, denominada assncrona (uma tcnina
conhecida como AJAX (Asynchronous Javascript And XML) utilizada nestes casos
(mais sobre isto na Seco 2.3.2)));
uma alternativa a uma programa Javascript uma applet (uma app escrita na
linguagem Java [Flanagan 2002]) que o browser downloads automaticamente e
executa quando faz fetch da pgina web correspondente (mais sobre applets na
Seco 2.3.1).
Web services:
at agora, discutimos a Web, quase na totalidade, do ponto de vista do browser do
user;
no entanto, outros programas alm dos browsers, podem, tambm, ser clientes da
Web (...).
1.1 Give five types of hardware resource and five types of data or software resource that can
usefully be shared. Give examples of their sharing as it occurs in practice in distributed
systems. (pages 2, 14)
1.2 How might the clocks in two computers that are linked by a local network be
synchronized without reference to an external time source? What factors limit the
accuracy of the procedure you have described? How could the clocks in a large number
of computers connected by the Internet be synchronized? Discuss the accuracy of that
procedure. (page 2)
1.3 Consider the implementation strategies for massively multiplayer online games as
discussed in Section 1.2.2. In particular, what advantages do you see in adopting a single
server approach for representing the state of the multiplayer game? What problems can
you identify and how might they be resolved? (page 5)
1.4 A user arrives at a railway station that they has never visited before, carrying a PDA that
is capable of wireless networking. Suggest how the user could be provided with
information about the local services and amenities at that station, without entering the
stations name or attributes. What technical challenges must be overcome? (page 13)
1.5 Compare and contrast cloud computing with more traditional client-server computing?
What is novel about cloud computing as a concept? (pages 13, 14)
1.6 Use the World Wide Web as an example to illustrate the concept of resource sharing,
client and server. What are the advantages and disadvantages of HTML, URLs and
HTTP as core technologies for information browsing? Are any of these technologies
suitable as a basis for client-server computing in general? (pages 14, 26)
1.7 A server program written in one language (for example, C++) provides the
implementation of a BLOB object that is intended to be accessed by clients that may be
written in a different language (for example, Java). The client and server computers may
have different hardware, but all of them are attached to an internet. Describe the
problems due to each of the five aspects of heterogeneity that need to be solved to make
it possible for a client object to invoke a method on the server object. (page 16)
1.8 An open distributed system allows new resource-sharing services such as the BLOB
object in Exercise 1.7 to be added and accessed by a variety of client programs. Discuss
in the context of this example, to what extent the needs of openness differ from those of
heterogeneity. (page 17)
1.9 Suppose that the operations of the BLOB object are separated into two categories
public operations that are available to all users and protected operations that are
available only to certain named users. State all of the problems involved in ensuring that
only the named users can use a protected operation. Supposing that access to a protected
operation provides information that should not be revealed to all users, what further
problems arise? (page 18)
1.10 The INFO service manages a potentially very large set of resources, each of which can
be accessed by users throughout the Internet by means of a key (a string name). Discuss
an approach to the design of the names of the resources that achieves the minimum loss
of performance as the number of resources in the service increases. Suggest how the
INFO service can be implemented so as to avoid performance bottlenecks when the
number of users becomes very large. (page 19)
1.11 List the three main software components that may fail when a client process invokes a
method in a server object, giving an example of a failure in each case. Suggest how the
components can be made to tolerate one anothers failures. (page 21)
1.12 A server process maintains a shared information object such as the BLOB object of
Exercise 1.7. Give arguments for and against allowing the client requests to be executed
concurrently by the server. In the case that they are executed concurrently, give an
example of possible interference that can occur between the operations of different
clients. Suggest how such interference may be prevented. (page 22)
1.14 Resources in the World Wide Web and other services are named by URLs. What do the
initials URL denote? Give examples of three different sorts of web resources that can be
named by URLs. (page 26)
1.15 Give an example of an HTTP URL. List the main components of an HTTP URL, stating
how their boundaries are denoted and illustrating each one from your example. To what
extent is an HTTP URL location-transparent? (page 26)