To-Do #27

To-Do:

utilizar um servidor centralizado de registro/localização (algo como o ZooKeeper, só que bem mais simples)

• Adicionar "Desincronismo"
• Sugestão de nome Keeper (parâmetro: --keeper)
• No miner e tracer, parâmetros --keeper-ip e --keeper-port
• Todo mundo mantem uma conexão ativa com o Keeper para:
  • Receber info de novos peers (ip, port, tipo)
  • Receber atualização de lease time do heartbeat
  • Enviar heartbeats (e.g. a cada 20 segundos o peer diz que "tá vivo")
  • Se o peer (trader ou miner) não enviar heartbeats, é considerado como falho e todos os demais peers são notificados
• NOTA: é o Keeper que faz as conexões (que ficam ativas para info e heartbeat) com os peers. assim, se o Keeper persistir os dados (ip, porta, tipo), ele pode falhar e voltar ao ar na sequência. algo simples e prático de implementar.
• tracer e miner fazer uma conexão inicial com o Keeper para registro
• depois do registro, Keepler fazer a conexão com o tracer e o miner que acabaram de se registrar (é esta conexão que é mantida aberta/ativa para as info e heartbeat)

Programa main vai ter três tipos:

• keeper
• miner
• tracer
• Os três requerem os parâmetros --keeper-ip e --keeper-port

coisas nos trackers e miners:

• Remover espera ativa (tentativa ativa de conexão)
• Persistência de dados: salvar em arquivo a lista que guarda os blocos
• Implementar tolerância a falha (sair e voltar, mas continuar funcionando)

coisas diversas:

• Função que envia o bloco inteiro para um novo usuário
• Incluir parametrição nos traders (exemplo: usuário define X transações/s)
• Implementar sistema de votação/consenso
• Um script único para iniciar tudo:
  • 1 Keeper
  • N miners
  • M tracers
• Melhorar a parte de visualização e acompanhamento do funcionamento dos miners e traders
• Scripts para casos de teste específicos
  • Exemplo: testes de falha do Keeper
  • Exemplo: testes de falha de traders
  • Exemplo: testes de falha de miners

Coisas Futuras:

• Interface gráfica