Autor: Alexivic Domingo, 25 de junho de 2023

Computação IV

Resolução de Exercícios
Nome:

1. O que significa dizer que um Sistema Distribuído é transparente? Dê exemplos de

diferentes tipos de transparências.

R: Um sistema distribuído é transparente significa que ele oculta a complexidade de sua estrutura
e funcionamento, fornecendo aos usuários e aplicativos uma visão unificada e simplificada.

Existem vários tipos de transparência em sistemas distribuídos. Aqui estão alguns exemplos:

Transparência de Acesso: Oculta a forma como os recursos distribuídos são acessados.

Um exemplo é o acesso a um banco de dados distribuído como se fosse um banco de dados local.

Transparência de Localização: Esconde dos usuários e aplicativos onde os recursos estão

localizados fisicamente.

Por exemplo, em um sistema de armazenamento em nuvem distribuído, os arquivos podem ser

armazenados em vários servidores, mas o usuário não precisa se preocupar com isso.

Transparência de Migração: Permite que os recursos sejam movidos de um local para outro sem
afetar os usuários ou aplicativos que os estão utilizando.

Por exemplo, em um sistema de processamento distribuído, os processos podem ser migrados

entre diferentes servidores sem que os usuários percebam.

Transparência de falhas: O sistema distribuído pode lidar com falhas de nós ou componentes sem
que os usuários percebam ou sejam afetados diretamente.

Por exemplo, em um sistema distribuído com replicação de dados, se um servidor falhar, outros
servidores podem assumir a responsabilidade sem que os usuários sejam afetados.

Transparência de replicação: O sistema distribuído pode replicar recursos ou serviços para

melhorar a disponibilidade e a confiabilidade.

Por exemplo, em um sistema de banco de dados distribuído replicado, as consultas e atualizações

podem ser executadas em qualquer réplica, e o sistema garante que todas as réplicas permaneçam
consistentes.

2. Qual(is) é (são) a(s) motivação(ões) para projetar Sistemas Distribuídos Abertos?

R: Interoperabilidade: Isso significa que diferentes sistemas distribuídos podem se comunicar e
colaborar de maneira eficiente, mesmo que sejam desenvolvidos por diferentes fornecedores ou
organizações.

Autor: Alexivic 1
Autor: Alexivic Domingo, 25 de junho de 2023

Escalabilidade: Um sistema distribuído aberto pode incorporar novos servidores, dispositivos ou

aplicativos de diferentes fornecedores, aproveitando recursos adicionais sem grandes restrições.

Inovação: A abertura de um sistema distribuído encoraja a inovação, permitindo que terceiros

desenvolvam e integrem novos serviços, aplicativos e tecnologias no ecossistema do sistema
distribuído.

Transparência: A abertura de um sistema distribuído promove a transparência, permitindo que os

usuários tenham acesso a informações relevantes sobre o funcionamento do sistema.

Flexibilidade: Um sistema distribuído aberto oferece flexibilidade aos usuários finais, permitindo
que eles personalizem e adaptem o sistema de acordo com suas necessidades específicas.

Comunidade e colaboração: A abertura de um sistema distribuído promove a formação de

comunidades de desenvolvedores, usuários e especialistas interessados em contribuir para o
aprimoramento contínuo do sistema.

3. Cite características que possam determinar a diferença entre um Sistema Operacional de

Rede e um Sistema Operacional Distribuído.

R: Aqui estão algumas das características que podem ser consideradas para distinguir um Sistema
Operacional de Rede (NOS - Network Operating System) de um Sistema Operacional Distribuído
(DOS - Distributed Operating System):

Escopo:

NOS: O escopo de um NOS geralmente é limitado a uma rede local (LAN) ou a uma rede de área
ampla (WAN). Ele concentra-se em fornecer serviços de rede dentro dessa rede específica.

DOS: O escopo de um DOS abrange múltiplas redes ou até mesmo a Internet. Ele lida com a
interconexão e coordenação de recursos entre computadores geograficamente distribuídos.

Gerenciamento de Recursos:

NOS: Um NOS é responsável pelo gerenciamento de recursos dentro da rede, como

compartilhamento de arquivos, impressoras, permissões de acesso e políticas de segurança.

DOS: Um DOS gerencia recursos distribuídos em uma escala maior, como o gerenciamento de
recursos de armazenamento distribuído, capacidade de processamento distribuído e coordenação
de tarefas em diversos nós.

Dependência de Rede:

NOS: Um NOS depende fortemente da presença e disponibilidade da rede para fornecer seus
serviços. Se a rede estiver inacessível, muitos serviços de um NOS podem não estar disponíveis.

DOS: Um DOS também depende da rede para comunicação e compartilhamento de recursos, mas
é projetado para lidar com a desconexão e falhas de rede de forma mais robusta. Ele é capaz de
continuar operando mesmo que a conectividade de rede seja interrompida temporariamente.

Autor: Alexivic 2
Autor: Alexivic Domingo, 25 de junho de 2023

4. Quais características permitem definir uma arquitetura cliente/servidor de três camadas?

R: A arquitetura cliente/servidor de três camadas é uma abordagem comum na construção de
sistemas distribuídos, onde as funcionalidades do sistema são divididas em três camadas distintas:
apresentação, lógica de negócios e dados. As características que permitem definir essa arquitetura
são as seguintes:

Camada de apresentação (Cliente): A camada de apresentação é responsável por fornecer a

interface com o usuário ou aplicativo cliente. Ela recebe as solicitações do usuário e exibe as
informações processadas pelo servidor.

Camada de lógica de negócios (Servidor de Aplicação): A camada de lógica de negócios contém

a lógica e a funcionalidade do sistema. Ela processa as solicitações recebidas da camada de
apresentação, realiza as operações necessárias, acessa os dados da camada de dados e retorna os
resultados para a camada de apresentação.

Camada de dados (Servidor de Banco de Dados): A camada de dados é responsável pelo

armazenamento e gerenciamento dos dados do sistema. Ela fornece acesso aos dados para a
camada de lógica de negócios, permitindo a recuperação, inserção, atualização e exclusão de
dados.

5. Qual é a diferença entre distribuição vertical e distribuição horizontal?

R: As principais diferenças entre esses dois tipos de distribuição são:

Distribuição Vertical: Envolve a adição de mais recursos (como CPU, memória, armazenamento) a
um único componente ou servidor existente. O objetivo é aumentar a capacidade de
processamento e desempenho de um único nó.

Distribuição Horizontal: Envolve a adição de mais nós (servidores, máquinas virtuais) ao sistema
distribuído existente. O objetivo é distribuir a carga de trabalho entre múltiplos nós, dividindo as
tarefas entre eles.

6. Ao invés de permitir que um servidor registre-se em um daemon (como no caso de DCE-

RPC), podemos determinar que uma aplicação sempre utilize a mesma porta. Essa porta
pode ser utilizada em referências para objetos no servidor. Quais são as desvantagens
desse esquema?

R: Definir que uma aplicação sempre utilize a mesma porta para referenciar objetos no servidor, em
vez de permitir o registro em um daemon (como no caso de DCE-RPC), apresenta algumas
desvantagens, incluindo:

Conflito de portas: Se várias aplicações ou servidores tentarem utilizar a mesma porta fixa, pode
ocorrer um conflito de portas. Isso pode levar a falhas na inicialização dos serviços ou na
comunicação entre os sistemas.

Escalabilidade limitada: O uso de uma porta fixa restringe a escalabilidade do sistema. Se o

número de objetos ou instâncias do servidor aumentar significativamente, pode haver um limite na
quantidade de conexões simultâneas que podem ser estabelecidas na porta fixa.

Autor: Alexivic 3
Autor: Alexivic Domingo, 25 de junho de 2023

Restrições de Segurança: A atribuição estática de portas pode levantar preocupações de

segurança. A divulgação da porta fixa pode tornar o sistema mais vulnerável a ataques, pois os
invasores podem identificar a porta padrão e direcionar seus ataques para ela.

7. Considere a operação de leitura de um arquivo em um servidor single-threaded e em um

servidor multithreaded. O tempo para receber a requisição e realizar o processamento é
de 15 msec mais 75msec (durante esse tempo o thread “dorme”) de acesso ao disco.
Quantas requisições/segundo um servidor single- threaded pode manipular? Quantas
requisições/segundo serão manipuladas se o servidor for multithreaded?

R: Para determinar quantas requisições por segundo (RPS) um servidor single-threaded e um

servidor multithreaded podem manipular, precisamos considerar o tempo total necessário para
processar uma única requisição em cada caso.

Servidor Single-threaded:

Tempo para receber a requisição: 15 ms

Tempo de processamento (acesso ao disco): 75 ms
Tempo total por requisição: 15 ms + 75 ms = 90 ms
Para calcular as requisições por segundo, precisamos inverter o tempo total por requisição (90 ms)

Requisições por segundo = 1 / 90 ms = 11.1 RPS

Portanto, o servidor single-threaded pode manipular aproximadamente 11.1 requisições por

segundo.

Servidor Multithreaded:

Tempo para receber a requisição: 15 ms

Tempo de processamento (acesso ao disco): 75 ms (por thread)

Tempo total por requisição: 15 ms + 75 ms = 90 ms (por thread)

Vamos considerar que o servidor multithreaded possui n threads para processar as requisições
simultaneamente. Nesse caso, podemos dividir o tempo total por requisição pelo número de
threads para obter o tempo médio por requisição:

Tempo médio por requisição = Tempo total por requisição / n threads

Suponhamos que o servidor multithreaded possua 4 threads para processar as requisições

simultaneamente. Portanto:

Tempo médio por requisição = 90 ms / 4 threads = 22.5 ms

Agora, podemos calcular as requisições por segundo:

Requisições por segundo = 1 / (Tempo médio por requisição em segundos)

Requisições por segundo = 1 / (22.5 ms) = 44.4 RPS

Portanto, se o servidor for multithreaded com 4 threads, ele será capaz de manipular
aproximadamente 44.4 requisições por segundo.

Autor: Alexivic 4
Autor: Alexivic Domingo, 25 de junho de 2023

8. Compare as arquiteturas de thread worker pool e thread-per-request.

R: As arquiteturas de thread worker pool (pool de threads) e thread-per-request (thread por
requisição) são duas abordagens diferentes para o gerenciamento de threads em sistemas que
lidam com múltiplas requisições concorrentes.

Thread Worker Pool:

 As requisições são recebidas pelo sistema e colocadas em uma fila de tarefas a serem
processadas.
 As threads disponíveis no pool pegam as tarefas da fila e as processam, uma de cada vez.
 Cada thread pode processar várias requisições ao longo do tempo.
 Após o processamento, a thread fica disponível novamente para pegar outra tarefa da fila.

Thread-per-Request:

 Nessa arquitetura, cada requisição recebida pelo sistema é associada a uma nova thread
separada.
 Uma nova thread é criada para cada requisição e é responsável por todo o processamento dessa
requisição.
 Cada thread é alocada para uma requisição específica e executa as operações necessárias para
atender a essa requisição.
 Após o processamento da requisição, a thread é finalizada e liberada.

9. Mencione situações onde podem existir vantagens/desvantagens em implementar

servidores baseados em processos concorrentes em contraposição aos servidores
multithreaded.

R: A implementação de servidores baseados em processos concorrentes em contraposição aos

servidores multithreaded pode apresentar vantagens e desvantagens em diferentes situações. Aqui
estão alguns cenários onde essas abordagens podem se destacar:

Vantagens dos servidores baseados em processos concorrentes:

Isolamento de falhas: Cada processo tem seu próprio espaço de endereçamento, o que significa
que se um processo falhar, os demais processos não são afetados.

Escalabilidade em sistemas multiprocessador: Em sistemas com vários processadores ou núcleos,

os processos concorrentes podem se beneficiar da capacidade de processamento paralelo,
permitindo um melhor aproveitamento dos recursos do hardware.

Facilidade de programação: Em muitos casos, programar com processos concorrentes pode ser
mais simples do que programar com threads.

Desvantagens dos servidores baseados em processos concorrentes:

Overhead de comunicação: Os processos concorrentes geralmente precisam usar mecanismos de

comunicação interprocesso (IPC) para trocar dados e informações.

Consumo de recursos: Os processos concorrentes tendem a consumir mais recursos do sistema

em comparação com threads.

Coordenação complexa: A comunicação e a coordenação entre processos concorrentes podem

ser mais complexas do que a sincronização entre threads em um ambiente multithreaded.

Autor: Alexivic 5
Autor: Alexivic Domingo, 25 de junho de 2023

10. Comente sobre vantagens/desvantagens de limitar o número de threads de um servidor.

R: Aqui estão algumas considerações sobre as vantagens e desvantagens de limitar o número de
threads:

Vantagens de limitar o número de threads:

Controle de recursos: Limitar o número de threads permite um melhor controle dos recursos do
sistema. Threads consomem recursos como memória e recursos do sistema operacional.

Estabilidade e previsibilidade: Ter um número fixo de threads facilita a estabilidade e

previsibilidade do servidor. Um número limitado de threads permite uma melhor previsibilidade de
como o servidor se comportará em diferentes situações de carga.

Simplificação do gerenciamento: Limitar o número de threads pode simplificar o gerenciamento

e a depuração do servidor. Com um número menor de threads, é mais fácil monitorar e ajustar o
desempenho do servidor quando o número de threads é controlado.

Desvantagens de limitar o número de threads:

Capacidade de resposta limitada: Limitar o número de threads pode resultar em uma capacidade
de resposta limitada do servidor, especialmente em situações em que há um grande número de
requisições simultâneas.

Subutilização de recursos: Se o número máximo de threads for muito baixo em relação à

capacidade do servidor, pode haver uma subutilização dos recursos disponíveis.

Requisitos específicos do aplicativo: Em alguns casos, os aplicativos podem exigir um grande

número de threads para realizar tarefas paralelas intensivas em termos de computação ou para
lidar com alto tráfego concorrente.

11. Considere um processo P que requer acesso para um arquivo F. Esse arquivo está
localizado na mesma máquina onde P está executando. Quando P é movido para uma
máquina deve continuar acessando F. Como isso pode ser conseguido?

R: Para permitir que um processo P acesse o arquivo F, mesmo após ser movido para outra máquina,
algumas abordagens podem ser consideradas:

Compartilhamento de arquivos em rede: Uma maneira de garantir o acesso contínuo ao arquivo

F é por meio do compartilhamento de arquivos em rede. Isso envolve configurar o sistema de
arquivos da máquina original (onde o arquivo está localizado) para compartilhar o diretório que
contém o arquivo F. Em seguida, quando o processo P é movido para outra máquina, ele pode
acessar o arquivo F por meio da rede usando protocolos de compartilhamento de arquivos, como
SMB (Server Message Block) ou NFS (Network File System).

Armazenamento em nuvem: Outra opção é armazenar o arquivo F em um serviço de

armazenamento em nuvem, como o Dropbox, Google Drive ou Amazon S3. Nesse caso, o arquivo
estaria disponível para acesso em qualquer máquina conectada à internet. O processo P precisaria
usar as APIs ou bibliotecas fornecidas pelo serviço de armazenamento em nuvem para acessar e
manipular o arquivo F.

12. Suponha que dois processos detectam simultaneamente a perda de um coordenador e

ambos decidem forçar uma eleição usando o algoritmo de Bully. O que acontece nesse
caso?

Autor: Alexivic 6
Autor: Alexivic Domingo, 25 de junho de 2023

R: Se dois processos detectarem simultaneamente a perda de um coordenador e ambos decidirem

iniciar uma eleição usando o algoritmo de Bully, pode ocorrer uma situação de conflito conhecida
como "eleição múltipla" ou "situação de bully múltiplo".

13. O Algoritmo de Ricart e Agrawala tem um problema que se um processo “caído” e

nenhuma resposta é enviada para o processo que pediu acesso à Região Crítica, a falta de
resposta será interpretada como uma “negação” de serviço. Alguns autores sugerem que
todas as requisições sejam respondidas imediatamente com o intuito de detectar
situações de crash. Há circunstâncias onde mesmo esse método pode falhar? Em caso
positivo, comente sobre essas circunstâncias.

R: Sim, mesmo responder imediatamente a todas as requisições em um sistema usando o algoritmo

de Ricart e Agrawala pode não ser suficiente para detectar situações de crash em certas
circunstâncias. Existem cenários em que esse método pode falhar, como:

Falhas de comunicação: Se houver falhas de comunicação entre os processos, a resposta imediata

pode não ser recebida pelo processo solicitante. Isso pode ocorrer devido a problemas de rede,
perda de mensagens ou atrasos significativos.

Falhas silenciosas: Em algumas situações de falha, um processo pode falhar de maneira

"silenciosa", ou seja, ele pode parar de responder sem que os outros processos detectem sua falha.

Falsos positivos: Mesmo se um processo estiver operacional, pode ocorrer um atraso ou uma falha
temporária na comunicação que resulta em uma falta de resposta.

14. É possível sincronizar o clock de dois computadores ligados por uma rede local sem uma
referência a uma fonte externa de tempo? Quais fatores limitam a solução que você
sugeriu?

R: Embora seja difícil alcançar uma sincronização precisa entre os clocks de dois computadores sem
uma referência externa de tempo, é possível obter uma sincronização aproximada em certos
cenários. No entanto, a variação do clock local, os atrasos de rede, a precisão desejada e a tolerância
ao erro são fatores que limitam a solução e afetam a qualidade e a precisão da sincronização. Em
muitos casos, é recomendado usar protocolos de sincronização de tempo baseados em fontes
externas confiáveis para obter uma sincronização precisa e consistente.

15. No tocante à recuperação de falhas, explique o funcionamento do protocolo two-phase

commit. Procure indicar como o protocolo procede para que um abort ou um commit seja
executado.

R: O protocolo Two-Phase Commit é um mecanismo utilizado em sistemas distribuídos para

garantir a atomicidade das transações. Ele segue uma sequência de duas fases (preparação e
decisão) para garantir que todos os participantes concordem em confirmar ou cancelar a transação
de forma consistente. Isso assegura que, independentemente das falhas que possam ocorrer
durante o processo, o sistema seja capaz de manter a integridade das transações.

16. Imagine uma situação em que os assinantes de uma lista de e-mail possuem réplicas locais
dos dados enviados (escritos) para essa lista. Como administrador do software que
coordena a entrega de mensagens da lista, você deve garantir duas coisas: a. Mensagens
enviadas por um usuário devem ser lidas na ordem em que elas foram enviadas. Exemplo:
se o usuário 1 envia as mensagens A e B, todos os outros usuários devem ler as mensagens
nessa ordem: primeiro a mensagem A e depois a B; b. Mensagens enviadas por usuários

Autor: Alexivic 7
Autor: Alexivic Domingo, 25 de junho de 2023

diferentes podem ser lidas em ordem diferente, no entanto, quando dois usuários
tentarem ler, eles deverão obter o mesmo resultado. Exemplo: Se o usuário 1 enviar a
mensagem P e o usuário 2 enviar a mensagem Q, os usuários 3 e 4 podem “ler” Q antes
de P. No entanto, em um determinado intervalo de tempo, esses usuários irão “ler”
apenas Q. Após isso, eles irão “ler” apenas P. Diante do exposto, qual(is) modelo(s) de
consistência você deve implementar no software de controle de mensagens dessa lista?
Argumente a favor da sua escolha.

R: Dada a situação apresentada, em que os assinantes da lista de e-mail possuem réplicas locais
dos dados enviados para a lista, existem dois requisitos principais a serem considerados: a ordem
de entrega das mensagens de um mesmo usuário e a consistência entre os usuários ao lerem as
mensagens.

Considerando esses requisitos, uma possível escolha para o modelo de consistência seria o modelo
de consistência sequencial. Esse modelo garante a ordem total das operações realizadas por um
mesmo usuário, ou seja, as mensagens enviadas por um usuário serão lidas pelos outros usuários
na mesma ordem em que foram enviadas (requisito a).

Além disso, o modelo de consistência sequencial também assegura que as operações de diferentes
usuários sejam vistas pelos demais usuários em uma ordem global, chamada de ordem
linearizável. Isso significa que, embora as mensagens de diferentes usuários possam ser lidas em
ordens diferentes pelos assinantes, durante um determinado intervalo de tempo, todos os usuários
verão as mensagens em uma mesma ordem (requisito b).

17. No que diz respeito ao acesso a regiões críticas, como podemos diferenciar o mecanismo
de consistência fraca do mecanismo de consistência de atualização?

R: A diferença entre o mecanismo de consistência fraca e o mecanismo de consistência de

atualização está na forma como tratam as operações de leitura e escrita concorrentes. O mecanismo
de consistência fraca prioriza a leitura simultânea, permitindo que múltiplas leituras ocorram ao
mesmo tempo, enquanto o mecanismo de consistência de atualização prioriza a exclusão mútua,
permitindo apenas uma escrita por vez para garantir a consistência das operações de escrita.

18. Podem existir problemas de inconsistência quando se utilizam invocações replicadas? Em

caso positivo, como isso pode ser resolvido?

R: Sim, podem existir problemas de inconsistência quando se utilizam invocações replicadas em

sistemas distribuídos. Esses problemas podem ocorrer devido à possibilidade de atrasos na
propagação das atualizações entre as réplicas ou a ordem em que as atualizações são aplicadas em
diferentes réplicas.

Uma abordagem comum para resolver esses problemas de inconsistência é utilizar protocolos de
replicação de dados que garantam a consistência entre as réplicas.

19. Um SD que funciona 8 horas ininterruptamente mas fica desligado a noite e todo o fim
de semana é um SD com disponibilidade ou com confiabilidade? Por que?

R: Um Sistema Distribuído (SD) que funciona apenas 8 horas ininterruptamente durante o dia e fica
desligado à noite e durante todo o fim de semana pode ser considerado um SD com
disponibilidade, mas não necessariamente com confiabilidade. Vamos entender o motivo:

Autor: Alexivic 8
Autor: Alexivic Domingo, 25 de junho de 2023

O sistema descrito pode ser considerado disponível durante as 8 horas de funcionamento diário,
mas não é confiável em termos de operação contínua e fornecimento de resultados corretos em
período integral. Para ser considerado confiável, um sistema geralmente precisa estar operacional
de forma contínua e fornecer resultados consistentes e corretos ao longo do tempo.

20. Quais são os passos executados para que um usuário consiga obter um arquivo remoto
através do sistema NFS?

R: Para que um usuário consiga obter um arquivo remoto através do sistema NFS (Network File
System), os seguintes passos são executados:

 Montagem do compartilhamento NFS

 Autenticação e permissões
 Acesso ao arquivo remoto
 Manipulação do arquivo remoto
 Desmontagem do compartilhamento NFS
21. Imagine a situação exposta na figura a seguir. Um usuário deseja fazer transferência
eletrônica de dinheiro de sua conta do Banco A para o Banco B. Para tanto, esse usuário
contacta (via Internet) um servidor de transações bancárias que se encarrega de efetivar
a transferência propriamente dita. Nesse sentido, é válido notar que as operações
bancárias não são idempotentes. Ou seja, se forem repetidas, haverá mudança nos valores
originais. Assumindo que você é o responsável por implementar semânticas de execução
em cada um dos pontos (cliente com o servidor e do servidor com os bancos), quais
semânticas você adotaria para essa situação? Leve em consideração que o usuário
necessita executar a operação de transferência e que semânticas mais restritivas são mais
difíceis de implementar e tem desempenho mais reduzido. Comente sobre suas escolhas.

R: Na situação descrita, onde um usuário deseja fazer uma transferência eletrônica de dinheiro
entre os bancos A e B, é importante escolher a semântica de execução apropriada para garantir a
corretude e consistência das operações. Considerando que as operações bancárias não são
idempotentes e que é necessário executar a operação de transferência, as semânticas de execução
apropriadas podem ser:

Semântica de Execução de uma Vez (Execute-Once Semantics): Nessa abordagem, a operação

de transferência é executada apenas uma vez, garantindo que ela não seja repetida. O servidor de
transações bancárias deve ser implementado para rejeitar qualquer tentativa de duplicação da
transferência.

Autor: Alexivic 9
Autor: Alexivic Domingo, 25 de junho de 2023

Semântica de Execução Atômica (Atomic Semantics): Nessa abordagem, a operação de

transferência é tratada como uma unidade atômica, garantindo que ela seja executada
integralmente ou não seja executada de forma alguma. Isso significa que, se ocorrer algum erro
durante a transferência, todas as alterações feitas até aquele ponto devem ser desfeitas para manter
a consistência dos saldos bancários.

22. Checkpointing e Logging são duas técnicas para recuperação de mensagens. Qual é o
principal problema quando se adota um checkpointing independente? Qual a diferença
entre essas duas técnicas?

R: O principal problema do checkpointing independente é a possibilidade de perda de mensagens

entre checkpoints, o que pode levar a inconsistências nos dados. Se ocorrer uma falha após um
checkpoint, mas antes de uma mensagem ser confirmada ou enviada, essa mensagem pode ser
perdida permanentemente.

A diferença fundamental entre o checkpointing e o logging é que o checkpointing salva o estado

atual do processo em um determinado momento, enquanto o logging registra todas as operações
e eventos relevantes do sistema distribuído.

Autor: Alexivic 10