Nome: Thomas Oliveira Rocha Sampaio Silva e Bruno Uhlmann Marcato

1) Muitos algoritmos distribuídos requerem a utilização de um processo coordenador.

Até que ponto esses algoritmos são realmente considerados distribuídos?
Algoritmos distribuídos são considerados distribuídos quando envolvem a colaboração e a
comunicação entre componentes distribuídos para realizar tarefas em um ambiente
distribuído. A presença de um coordenador pode ser necessária em certos momentos, mas
isso não invalida a natureza distribuída do sistema em sua maioria.

2) Apresente um exemplo com a tabela a seguir, do acesso a uma região crítica (RC)
com o algoritmo distribuído de Ricart-Agrawala com quatro nós que tentam acessar a
região crítica ao mesmo tempo. Assuma que o índice do nó é o mesmo do seu
timestamp, e a tabela inicial em cada processo é a que segue:

Host Quer RC FIFO REQUEST FIFO REPLY

P1 TRUE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

A ordem das respostas é definida como segue:

1) P2 REPLY P1 6) P1 REPLY P4
2) P3 REPLY P1 7) P3 REPLY P2
3) P4 REPLY P1 8) P4 REPLY P2
4) P1 REPLY P2 9) P2 REPLY P3
5) P1 REPLY P3 10) P2 REPLY P4

1) P2 REPLY P1
P2 tira P1 da REPLY
P1 tira P2 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 TRUE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

2) P3 REPLY P1

P3 tira P1 da REPLY
P1 tira P3 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 TRUE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

3) P4 REPLY P1

P4 tira P1 da REPLY
P1 tira P4 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 TRUE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

(P1 pode acessar a RC)

4) P1 REPLY P2
P1 tira P2 da REPLY
P2 tira P1 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 TRUE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

5) P1 REPLY P3

P1 tira P3 da REPLY
P3 tira P1 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 TRUE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

6) P1 REPLY P4

P1 tira P4 da REPLY
P4 tira P1 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 FALSE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

7) P3 REPLY P2

P3 tira P2 da REPLY
P2 tira P3 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 FALSE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

8) P4 REPLY P2

P4 tira P2 da REPLY
P2 tira P4 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 FALSE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

(P2 pode acessar a RC)

9) P2 REPLY P3

P2 tira P3 da REPLY
P3 tira P2 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 FALSE P2,P3,P4 P2,P3,P4

P2 TRUE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

10) P2 REPLY P4

P2 tira P4 da REPLY
P4 tira P2 da REQUEST

Quer RC? FIFO_REQUEST FIFO_REPLY

P1 FALSE P2,P3,P4 P2,P3,P4

P2 FALSE P1,P3,P4 P1,P3,P4

P3 TRUE P1,P2,P4 P1,P2,P4

P4 TRUE P1,P2,P3 P1,P2,P3

3) Sabendo-se que apenas uma ficha pode existir na arquitetura Token Ring, caso a
Ficha seja perdida, como uma nova pode ser gerada?

Para lidar com a perda da ficha, normalmente existem procedimentos para regenerá-la ou
recuperá-la. Uma abordagem simples é que, se um dispositivo detectar que a ficha está
perdida (por exemplo, devido a um timeout), ele pode esperar por um período aleatório
antes de tentar gerar uma nova ficha. Isso ajuda a evitar colisões quando vários dispositivos
tentam gerar uma nova ficha simultaneamente.

4) Em uma comunicação multicast, qual arquitetura de sistemas distribuídos é

recomendada para uma aplicação de chat? Justifique a sua resposta. A arquitetura
cliente-servidor é recomendada para uma aplicação de chat multicast devido à sua
capacidade de centralizar o controle, garantir escalabilidade, consistência, facilitar
manutenções e atualizações, além de proporcionar uma base mais sólida para a
implementação de medidas de segurança.

5) Como o coordenador é escolhido em um algoritmo distribuído de eleição do

valentão? Dê um exemplo.
O algoritmo de eleição do valentão em sistemas distribuídos é um processo que permite a
seleção de um novo coordenador em caso de falha do coordenador atual. Ele funciona com
nós enviando mensagens "ELEIÇÃO" para nós com índices mais altos, e os nós de índice
superior respondendo e pedindo para o nó eleito parar de enviar mensagens. Após isso, os
nós de índices mais altos iniciam novas eleições, enviando "ELEIÇÃO" para nós com
índices ainda mais altos. O nó que recebe "ELEIÇÃO" de índice mais baixo responde e
pede para o emissor parar, e se não houver resposta, ele se torna o novo coordenador e
envia "COORDENADOR" para todos. Por exemplo, se em uma rede distribuída de
computadores, o nó 5 detecta a falha do coordenador e inicia o processo de eleição, ele
enviará "ELEIÇÃO" para os nós 6, 7, 8, etc. Se o nó 8 responder, pedindo para parar, o
processo continua até que o nó de índice mais baixo que não recebe resposta se torne o
novo coordenador, notificando todos os outros nós.
6) Como o coordenador é escolhido em um algoritmo distribuído de eleição de anel?
Dê um exemplo.

No algoritmo de eleição de anel, o coordenador é escolhido com base no processo que

possui o ID mais alto no anel. Inicialmente, todos os processos marcam a si mesmos como
não-participantes (PARTICIPANTE=F). O processo que inicia a eleição se marca como
participante (PARTICIPANTE=T) e envia uma mensagem de ELEIÇÃO com seu próprio ID
para o vizinho. Quando um processo recebe uma mensagem de ELEIÇÃO com um ID maior
do que o seu, encaminha a mensagem e se marca como participante. Se receber uma
mensagem com um ID menor, substitui o ID na mensagem pelo seu próprio ID e a
encaminha. Se um processo receber uma mensagem com o mesmo ID que enviou, ele se
torna o coordenador, marcando a si mesmo como não-participante e envia uma mensagem
de ELEITO com seu próprio ID. Quando os processos recebem a mensagem de ELEITO,
eles também se marcam como não-participantes, encerrando a eleição.

Exemplo:
Suponhamos que temos 4 processos (A, B, C e D) em um anel, e seus IDs são 10, 15, 8 e
20, respectivamente. O processo D inicia a eleição e se marca como participante, enviando
uma mensagem de ELEIÇÃO com seu ID para o processo A. O processo A, ao receber a
mensagem com o ID 20 (maior que o seu próprio ID 10), encaminha a mensagem para o
processo B e se torna participante. O processo B, ao receber a mensagem com o ID 20, a
encaminha para o processo C e se torna participante. O processo C, ao receber a
mensagem com o ID 20, a encaminha de volta para o processo D, que agora recebe sua
própria mensagem. Dessa forma, o processo D se torna o coordenador, marca-se como
não-participante e envia uma mensagem de ELEITO com seu próprio ID para os outros
processos, encerrando a eleição. Todos os processos, ao receberem a mensagem de
ELEITO, marcam-se como não-participantes, e o coordenador (D) é escolhido.

7) Na arquitetura Token Ring, como evitar que duas mensagens de eleição percorrem
a rede simultaneamente?
É possível implementar um controle de acesso ao token durante eleições. Nesse método, o
nó que inicia a eleição solicita e obtém uma permissão especial para transmitir, retendo
exclusivamente o token durante o processo de eleição. Isso assegura que apenas um nó
por vez tenha autorização para conduzir uma eleição, prevenindo conflitos e garantindo a
ordem adequada.

8) No middleware EJB, o que é uma conexão stateful e uma conexão stateless? Dê

um exemplo de aplicação de cada um deles.
Uma conexão stateful mantém o estado da conversação entre chamadas do cliente e do
servidor. Isso significa que o estado da sessão do cliente é retido entre as chamadas,
permitindo a continuidade e a persistência das informações associadas à sessão.
Exemplo de Aplicação: Uma aplicação de carrinho de compras online pode usar uma
conexão stateful para manter o estado do carrinho do cliente entre as várias operações
(adicionar item, remover item, finalizar compra). O estado do carrinho é mantido do início ao
fim da sessão do cliente.

Uma conexão stateless não mantém informações de estado entre chamadas do cliente e do
servidor. Cada chamada é independente e não há persistência de informações entre elas.
Isso facilita a escalabilidade, pois não há necessidade de armazenar e recuperar o estado
do cliente.
Exemplo de Aplicação: Um exemplo seria um serviço de autenticação. Cada solicitação de
autenticação é tratada independentemente, sem a necessidade de manter informações de
estado entre as solicitações. O servidor trata cada solicitação de autenticação como uma
operação isolada.

9. Implemente a atividade prática do Laboratório 3 e informe o link da sua

Implementação no Github.

SistemasDistribuidosSDCO8A/Lab3/src at main ·
BrunoMarcato/SistemasDistribuidosSDCO8A (github.com)

10. Implemente a atividade prática do Laboratório 4 e informe o link da sua

Implementação no Github.

https://github.com/BrunoMarcato/SistemasDistribuidosSDCO8A/tree/main/lab4