Buscar

Sistemas distribuídos

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 6 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 6, do total de 6 páginas

Prévia do material em texto

Os dois principais modelos arquiteturais de sistemas distribuídos são: 
cliente/servidor e peer-to-peer. Uma das principais diferenças entre eles é que o 
modelo cliente/servidor é o compartilhamento de recursos entre processos clientes e 
servidores distintos. Por outro lado, o modelo peer-to-peer não considera distinção 
entre processos servidores e clientes, em que todos os processos envolvidos na 
execução de uma tarefa desempenham papeis semelhantes. 
Sobre as vantagens e desvantagens desses modelos arquiteturais, analise as 
alternativas abaixo e considere [V] para Verdadeiro e [F] para Falso. 
[ ] Em termos de implementação, a implementação do modelo cliente/sevidor é mais 
fácil quando comparada com a implementação do modelo peer-to-peer. 
[ ] Em termos de custos de implantação, a implantação do modelo cliente/servidor é 
mais barato que o modelo peer-to-peer. 
[ ] Em termos de segurança, o modelo cliente/servidor é considerado mais seguro 
que o modelo peer-to-peer. 
[ ] Em termos de disponibilidade, o modelo cliente/servidor apresenta desvantagens 
quando comparado ao modelo peer-to-peer. 
A. V – V – V – V. 
B. V – V – F – V. 
C. V – F – V – V. 
D. V – F – V – F. 
E. V – V – F – F. 
A comunicação em sistemas distribuídos é realizada por meio de troca de mensagens 
devido à carência diretamente relacionada a uma das principais dificuldades 
enfrentadas por todo e qualquer projetista de um modelo arquitetural de um sistema 
distribuído. Qual é o nome dessa carência? 
A. Ausência de relógio global. 
B. Ausência de protocolos estabelecidos entre os componentes. 
C. Ausência de padrões nas definições dos modelos arquiteturais. 
D. Ausência de um middleware responsável por prover a comunicação entre os 
componentes. 
E. Ausência de memória global compartilhada entre os componentes. 
 
RPC (Chamada de Procedimento Remota) e RMI (Invocação de Método Remota) são 
os mecanismos que permitem ao cliente invocar um procedimento ou método do 
servidor remotamente por meio do estabelecimento de comunicação entre cliente e 
servidor. Sobre as diferenças entre eles, assinale a alternativa correta. 
A. A diferença comum entre RPC e RMI é que no RPC os parâmetros passados para o 
método remoto consistem em procedimentos, enquanto no RMI os parâmetros passados 
consistem em estruturas de dados comuns. 
B. A diferença comum entre RPC e RMI é que no RPC os parâmetros passados para o 
método remoto consistem em estruturas de dados comuns, enquanto no RMI os parâmetros 
passados consistem na invocação dos métodos. 
C. A diferença comum entre RPC e RMI é que o RPC suporta apenas programação 
estruturada, enquanto o RMI suporta programação orientada a objetos. 
D. A diferença comum entre RPC e RMI é que o RPC suporta apenas programação 
procedural, enquanto o RMI suporta programação orientada a objetos. 
E. A diferença comum entre RPC e RMI é que no RPC suporta apenas programação 
procedural, portanto, é baseado em C#, enquanto no RMI suporta programação orientada 
objetos e é baseado em Java. 
Sabendo que sistemas distribuídos são constituídos de 
diferentes hardware e software, um dos propósitos de um middleware é mascarar a 
heterogeneidade. O modelo peer-to-peer é um dos principais modelos arquiteturais 
em sistemas distribuídos. Visando à comunicação nesses sistemas, o RPC (Chamada 
de Procedimento Remota) é dos paradigmas de comunicação. Ademais, a ausência 
de relógio global é uma das principais dificuldades enfrentas nesse contexto. 
Sobre modelos arquiteturais, estilos arquitetônicos e paradigmas de comunicação, 
analise as alternativas abaixo e considere [V] para Verdadeiro e [F] para Falso. 
[ ] Considerando uma aplicação que fornece o serviço de troca de e-mails, o modelo 
arquitetural peer-to-peer é sempre mais eficiente que uma arquitetura centralizada 
quando considerada uma aplicação. 
[ ] O paradigma de comunicação RPC (Chamada de Procedimento Remota) é 
necessariamente síncrono. 
[ ] Relógios lógicos também podem ser usados para sincronização de informações. 
[ ] Middleware é uma camada de software logicamente localizada entre aplicativos de 
alto nível, sistema operacional de baixo nível e recursos básicos de comunicação. 
Assinale a allternativa correta. 
A. V – F – V – F. 
B. V – V – F – V. 
C. V – V – V – F. 
D. F – F – V – F. 
E. F – F – F – V. 
 
Um dos modelos de comunicação inerente aos modelos arquiteturais é o modelo 
requisição/resposta, que se adequa à arquitetura cliente/servidor. O estilo 
arquitetônico em camadas se ajusta a esse modelo de comunicação especialmente 
quando consideramos uma arquitetura cliente/servidor de três camadas, a qual 
consiste em três camadas lógicas, as quais podem, em princípio, ser implementadas 
em máquinas separadas. A camada mais alta consiste em uma interface de usuário 
(cliente), a camada intermediária contém a implementação real e a camada mais baixa 
oferece suporte aos dados utilizados. Diante desse contexto, sabe-se que o 
mecanismo de implementação RMI se adequa ao modelo arquitetural cliente/servidor 
de acordo com o modelo de comunicação requisição/resposta e ao estilo 
arquitetônico em camadas. O principal objetivo do RMI é viabilizar a comunicação por 
meio de objetos remotos e, para tanto, utiliza dois elementos essenciais que ocultam 
os detalhes de comunicação do programador: o Stub e o Skeleton. 
Sobre o funcionamento do RMI focando nas características e nos objetivos do Stub e 
do Skeleton, assinale a alternativa correta. 
A. O Stub fica no lado do servidor e o Skeleton no lado do cliente. Os dois se 
comunicam através da rede de computadores. O objetivo do Stub é implementar a interface 
remota e serve como um espaço reservado no servidor para o objeto remoto. 
O Skeleton, por sua vez, é responsável por realizar a chamada para a implementação real 
do objeto remoto. 
B. O Stub fica no lado do cliente e o Skeleton no lado do servidor. Os dois se 
comunicam por meio da rede de computadores. O objetivo do Stub é implementar a interface 
remota e serve como um espaço reservado no cliente para o objeto remoto. O Skeleton, por 
sua vez, é responsável por realizar a chamada para a implementação real do objeto remoto. 
C. O Stub fica no lado do cliente e o Skeleton no lado do servidor. Os dois se 
comunicam por meio da rede de computadores. O objetivo do Stub é iniciar um registro de 
objeto remoto na porta especificada pelo cliente atual. O Skeleton, por sua vez, é 
responsável por realizar a chamada para a implementação real do objeto remoto. 
D. O Stub fica no lado do cliente e o Skeleton no lado do servidor. Os dois se 
comunicam por meio da rede de computadores. O objetivo do Stub é declarar um conjunto 
de métodos remotos. O Skeleton, por sua vez, é responsável por realizar a chamada para a 
implementação real do objeto remoto. 
E. O Stub fica no lado do servidor e o Skeleton no lado do cliente. Os dois se 
comunicam por meio da rede de computadores. O objetivo do Stub é declarar um conjunto 
de métodos remotos. O Skeleton por sua vez é responsável por realizar a chamada para a 
implementação real do objeto remoto. 
 
Um sistema distribuído é um sistema que utiliza diversos dispositivos 
computacionais para realizar o processamento de forma distribuída e transparente 
para seu usuário. Quando se utilizam sistemas distribuídos com alto grau de acesso 
de usuários, é interessante que estes não tenham falhas constantes, visto que seus 
usuários não irão utilizar um sistema com erros constantes. Vários sistemas podem 
ser distribuídos, mas, para que sejam tolerantes a falhas, é necessário que haja a ideia 
de que, mesmo com falhas, o sistema irá continuar funcionando, tornando-se, assim, 
um sistema distribuído tolerante a falhas. Sistemas distribuídos tolerantes a falhas 
têm, em seus conceitos e teoria, algo muito similar a outro tipo de sistema. Qual seria 
esse sistema? 
A. Sistema de arquivos distribuídos. 
B. Sistema distribuído de serviço de nomes. 
C. Sistemamultimídia distribuído. 
D. Sistema confiável. 
E. Sistema distribuído automático. 
 
 
 
 
 
 
 
Quando se fala em sistemas distribuídos, fala-se de agrupamento de recursos 
computacionais para determinado fim. Nesse contexto, há basicamente dois tipos: 
grupo simples e grupo hierárquico. Para grupos simples, existe redundância 
de links de acesso entre os nós participantes, mas, para o agrupamento hierárquico, 
existe um nó coordenador que define para qual nó operário determinada comunicação 
deve ser direcionada. Mas quando esse nó falha e não existe uma replicação direta 
para ele, o que acontece? 
A. Assim que os computadores participantes do grupo de nós percebem que não há um 
coordenador, o sistema como um todo para, sem enviar sinais de exceção aos clientes, e 
aguarda que um novo nó com a função de coordenador seja substituído. 
B. Assim que os computadores participantes do grupo de nós percebem que não há um 
coordenador, é lançada uma exceção entre os servidores operários para que eles aguardem 
novas instruções de um novo servidor coordenador. Os servidores terminam seu 
processamento atual, respondem para seus clientes e, por fim, aguardam. 
C. Assim que os computadores participantes do grupo de nós percebem que não há um 
coordenador, é feita uma eleição de forma específica e com métricas bem determinadas 
entre os nós operários para que um deles assuma o papel de coordenador. 
D. Assim que os computadores participantes do grupo de nós percebem que não há um 
coordenador, todas as conexões com os clientes são encerradas por meio de exceção, e 
um temporizador aleatório para cada nó é acionado até que haja um novo coordenador. 
Esse processo se repete até que possa haver um nó coordenador. 
E. Assim que os computadores participantes do grupo de nós percebem que não há um 
coordenador, assumem por tempo indeterminado sua própria gestão até que seja possível 
a substituição por um novo coordenador, que, ao participar do grupo, avisa para todos os 
nós de seu papel, assumindo novamente o controle. 
Existem diferentes formas de classificar um problema em um sistema 
distribuído; cada tipo remete a uma ideia específica de tratamento de erros. Se um 
sistema distribuído deixa de responder abruptamente, e o cliente, mesmo com 
tentativas repetidas de reconexão, não consegue concluir, pode-se afirmar que esse 
sistema distribuído teve uma: 
A. falha arbitrária. 
B. falha por omissão. 
C. falha por temporização. 
D. falha de resposta. 
E. falha por queda. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Entre as diversas falhas possíveis em um sistema distribuído, as falhas de 
comunicação são as mais aparentes e podem ocorrer por diversos contextos 
diferentes. Falhas de comunicação em um sistema distribuído tolerante a falhas 
podem ser classificadas em basicamente cinco tópicos: 
I. O cliente não consegue localizar o servidor. 
II. A mensagem de requisição do cliente para o servidor se perde. 
III. O servidor cai após receber uma requisição. 
IV. A mensagem do cliente para o servidor se perde. 
V. O cliente cai após enviar uma requisição. 
Algumas dessas falhas podem ser resolvidas facilmente com um mecanismo de 
contagem de tempo de requisições ou dados que já foram enviados e aguardam 
resposta. Esses cenários são: 
A. I, III, V. 
B. I, IV, V. 
C. I, II, V. 
D. I, II, III, V. 
E. II, III, IV, V. 
Para que um sistema seja tolerante a falhas, a possibilidade de continuar 
funcionando, e de forma transparente, deve ser possível. Uma ideia amplamente 
utilizada e que funciona muito bem para que essa funcionalidade seja atingida é a 
replicação de recursos computacionais; ou seja, existem cópias exatas (e 
constantemente atualizadas) que podem assumir o papel a qualquer momento que as 
máquinas de produção falharem. Diversos tipos de problemas podem ser mascarados 
por replicação de recursos computacionais, exceto: 
A. falhas de comunicação entre cliente e servidor em uma ideia peer-to-peer, visto que 
utilizam transporte orientado a conexão, e, depois de estabelecido com determinado recurso 
computacional que falha, esta não pode ser simplesmente movida pela própria tecnologia da 
conexão. 
B. falhas de comunicação entre cliente e servidor em uma ideia peer-to-peer, visto que 
utilizam transporte orientado a datagrama, e, depois de estabelecido com determinado 
recurso computacional que falha, esta não pode ser simplesmente movida pela própria 
tecnologia da conexão. 
C. falhas de comunicação entre servidores agrupados em grupo simples, visto que 
utilizam conexões dedicadas entre os nós, e, dessa forma, toda a transparência inerente ao 
contexto de sistemas distribuídos é quebrada pela necessidade de a conexão entre 
servidores ser restabelecida. 
D. falhas de comunicação entre servidores agrupados em grupo hierárquico, já que o 
nó coordenador é o ponto inicial da comunicação, e toda a transparência inerente ao 
contexto de sistemas distribuídos é quebrada pela necessidade de o nó coordenador emitir 
exceções, tanto para o servidor quanto para o cliente. 
E. falhas de processos entre servidores agrupados em grupo hierárquico, visto que o 
nó coordenador necessita realocar o processo criado para outro nó operário, e a 
transparência é quebrada, pois fica evidente ao usuário o processo de realocação de 
recursos entre servidores.

Continue navegando