Embedded Files
Milestones
Milestone 1: worker funcionando corretamente. Entregue com atraso. 90%
Milestone 2: broker funcionando corretamente.
A Agenda distribuída
Um sistema de agenda com um único arquivo, e apenas dois atributos por tupla (key e value), para simplificar.
Basicamente se dá ao usuário as operações padrão de transações e consultas que aprendemos em Bancos de Dados: Insert(key, value), que inclui uma nova chave na agenda, Delete(key), que exclui uma chave do sistema, Update(key, newValue), que altera um dado associado a uma chave, e Select(key), que retorna para quem solicitou o valor associado à chave.
O esquema de funcionamento, do ponto de vista do usuário, é descrito na figura abaixo.
Arquitetura distribuída
Ocorre, porém, que o usuário não sabe mas a arquitetura do sistema é distribuído, e a consulta que ele está fazendo pode ou não ser processada no nó em que ele atualmente está acessando. Basicamente há um conjunto de nós que colaboram nas tarefas de armazenar e gerir a agenda. Assim, para diminuir o esforço computacional de todos, cada nó é responsável por uma parte da agenda. Esta responsabilidade é definida de acordo com alguma política de distribuição de chaves. Sugestão: considerando chaves formadas por caracteres alfabéticos (de A a Z), dividir as letras do alfabeto pelo número de nós. Assim, cada nó sabe a letra inicial e final da sub faixa que lhe cabe.
O sistema, portanto, é uma rede sobreposta, em que cada nó se conecta a um posterior, a quem deve consultar caso a operação desejada não esteja sendo feita sobre uma chave que seja de sua responsabilidade. O nó que recebeu a solicitação pode efetuá-la, caso o dado seja de sua responsabilidade, ou repassá-la, caso contrário. O processo se repete até que algum nó possa efetivamente efetuar a operação. Após isso uma mensagem é retornada, percorrendo o caminho inverso, até o solicitante. Esta mensagem pode ser a confirmação da operação, em caso de êxito, uma mensagem de erro, caso o dado não esteja acessível, ou um dado, no caso de uma consulta (Select) bem sucedida.
A arquitetura do sistema é mostrada abaixo.
Importante observar que múltiplas operações podem acontecer ao mesmo tempo, de forma que os nós precisarão garantir a integridade dos dados após cada operação.
De modo geral os algoritmos, em pseudo código, são como seguem.
msg Insert(key, value) {
if key is in my resbonsibility range
perform insert (key, value) //be sure no one is inserting the same key. be sure the key is unique.
msg = "success"
else
msg = //next.insert&key,value
return msg
}
msg Delete(key) {
if key is in my resbonsibility range
if exists key
perform delete (key) //be sure no one is selecting, updating or deleting the same key
msg = "success"
else
msg = "fail! key does not exists"
else
msg = //next.delete&key
return msg
}
msg Update(key, newValue)
if key is in my resbonsibility range
if exists key
perform upsate (key, new value) //be sure no one is selecting, updating or deleting the same key
msg = "success"
else
msg = "fail! key does not exists"
else
msg = //next.upsate&key,newvalue
return msg
}
msg Select(key)
if key is in my resbonsibility range
if exists key
msg = value where key
else
msg = "fail! key does not exists"
else
msg = //next.select&key,newvalue
return msg
}
Vale observar que estes algoritmos distribuídos também funcionam como fachada, de forma que não faz diferença se a solicitação chegou de um nó vizinho da rede ou de uma aplicação de usuário rodando no mesmo nó.
Implemente, teste e apresente este sistema.
Prazos
As esquipes espontâneas devem ser formadas e enviadas para o meu e-mail até a meia noite do dia 15/07/2016 (sexta-feira).
Os estudantes cujo nome não estiver em alguma equipe espontânea até esta data será colocado em alguma equipe compulsória, COM A QUAL DEVERÁ DESENVOLVER, INEGOCIADAMENTE, O PROJETO!.
Equipes
Espontâneas
Silvano Moreira
Diego Santos
Denilson Oliveira
Ravelly Sales
Cleviton Borges
Pedro Lima
Magno
José Carlos
Marcos
Letícia Bomfim
Marcos Vinicius
Page updated
Google Sites
Report abuse