Grátis: 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 ... – Questões Respondidas

Sistemas Operacionais

Colégio Objetivo

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.

Estudando com Questões

há 2 anos

Estudando com Questões

há 2 anos

Sistemas distribuídos

Sistemas distribuídos

Respostas

Ed

há 2 anos

Com base na descrição fornecida, pode-se afirmar que o sistema distribuído teve uma falha por queda.

Essa resposta te ajudou?

0

0

left-side-bubbles-background

right-side-bubbles-background

Crie sua conta grátis para liberar essa resposta. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Ainda com dúvidas?

Envie uma pergunta e tenha sua dúvida de estudo respondida!

Essa pergunta também está no material:

Sistemas distribuídos

Sistemas distribuídos

Mais perguntas desse material

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.

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.

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.
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 program

A. V – F.
B. V – V.
C. F – V.
D. F – F.
E. F – F.

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. Sistema multimí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, é feita uma eleição aleatória entre os nós operários para que um deles assuma o papel de coordenador.
E. Assim que os computadores participantes do grupo de nós percebem que não há um coordenador, cada nó operário assume o papel de coordenador temporariamente até que um novo nó seja designado.

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.