Personal notes on software development.
For Java technologies check my dedicated site

Pages

Introdução ás Redes de Computadores

Sistemas Distribuidos

Desenvolvimento de uma aplicação distribuida do tradicional jogo de tabuleiro "4 em linha".
Trata-se de uma aplicação cliente-servidor, tendo sido desenvolvido:
  1. Servidor multithreaded (Java);
  2. Cliente standalone com comunicação por sockets;
  3. Cliente standalone com comunicação por RMI;
  4. Cliente Web (JSP/JavaBeans utilizando servidor Tomcat);
  5. Cliente standalone com comunicação por WebServices (SOAP-XML);
Todos os clientes comunicam entre si por intermédio do servidor podendo ter clientes distintos a comunicar entre si (cliente socket a comunicar com cliente RMI; socket com socket; RMI com RMI; RMI com cliente Web; Cliente Web com socket).
Requisitos funcionais:
  • criação de nova conta e login;
  • a janela principal possui um chat publico (mensagens multicast) e uma lista de jogadores que podem ser desafiados para um novo jogo (caso o desafio seja aceite é iniciada uma janela de jogo);
  • janela de jogo com o tabuleiro de jogo e chat privado (mensagens unicast);
  • tabela de HighScores com pontuações/ranking dos jogadores;
  • é ainda possivel comunicar com o servidor por intermédio de um webservice que permite aos administradores monitorizar e gerir o servidor (contas de utilizador, utilizadores online, etc.);
Requisitos não funcionais:
Clientes resistentes a falhas (falhas transitórias na conectividade com o servidor):
  • se a rede “cair” por uns instantes, os clientes receberão uma excepção que deverá ser tratada de forma a reabrir o socket com o servidor de forma transparente para o utilizador;
  • impossibilidade de perda de dados: se um utilizador enviar uma mensagem para o servidor na altura em que se perde a conectividade, essa mensagem deverá ser mantida pela aplicação que se irá encarrregar de as entregar ao servidor assim que o canal de comunicação esteja re-estabelecido;
Servidor resistente a falhas (mecanismo de replicação para tolerar falhas num servidor e fornecer alta disponibilidade do serviço):
  • o servidor tenta instalar-se num porto bem conhecido por todos os programas da aplicação distribuída. Se o servidor encontrar esse porto ocupado passa a funcionar como um “cão de guarda” do servidor primário. Periodicamente terá de enviar uma mensagem do tipo “estás_vivo?” ao servidor primário, utilizando sockets Datagram. Se este não responder por 3 vezes consecutivas, então o “cão de guarda” comuta de estado e passa a comportar-se como um servidor primário, tentando para isso ocupar o porto bem conhecido. Caso encontre o porto novamente ocupado, comuta novamente para o modo “cão de guarda”. O servidor primário e os “cães de guarda” partilham o estado relevante da aplicação através de ficheiros ou através do envio de objectos por um socket Stream. Não é imposto qualquer limite ao número de servidores/cães de guarda, pois quantos mais processos servidores/cães de guarda existirem, maior será a disponibilidade da aplicação. Este mecanismo de replicação garante que a aplicação funciona bem (e de forma transparente para os clientes) em situações de fail-over de um dos servidores e que nenhuma mensagem dos clientes é perdida durante a fase de falha e recuperação.
Protocolo de Comunicação:
Para a comunicação cliente-servidor/servidor-cliente foi necessário a definição de um tipo de mensagens com subtipos para:
No sentido cliente-servidor:
  • login;
  • obter lista de jogadores;
  • convite a um jogador;
  • aceita ou recusa convite;
  • lance do jogo;
  • enviar mensagem escrita ao adversário;
No sentido servidor-cliente:
  • lista dos jogadores disponíveis;
  • convite a um jogador;
  • início do jogo (com indicação de quem joga primeiro);
  • indicação do lance do jogo;
  • mensagem de reset, a enviar quando um jogador desiste;
  • mensagem com indicação do resultado final e dos pontos;
  • transmissão da mensagem escrita;
Detalhes de cada componente:
Servidor:
  • Multithreaded;
  • Resistente a falhas;
  • Dois modos de funcionamento: Servidor principal se o porto estiver livre; cão de guarda se o porto já estiver ocupado com um servidor principal;
Cliente com comunicação por sockets:
Usa 2 tipos de sockets para comunicação com o servidor:
  • Sockets Stream (TCP): para toda a comunicação unicast (TCP dá garantia de entrega). Nota: possivel utilização de ObjectStreams para o envio de objectos;
  • Datagram Sockets (UDP): para toda a comunicação multicast (não dá garantia de entrega possuindo, assim, menor overhead);
Cliente com comunicação por RMI:
(todo)

Cliente com comunicação por JSP e JavaBeans:
  • Trata-se de um thin client (corre dentro do browser) utilizando portanto CSS e HTML gerado dinâmicamente no lado do servidor através de JSP e JavaBeans;
  • Os JSP e JavaBeans são disponibilizados para comunicação com os clientes através do application server Tomcat (HTTP);
  • Como os JSP/JavaBeans residem na JVM do Tomcat não é possível a partilha de objectos pelo que estes comunicam de forma remota com o servidor principal (através de RMI) de forma a interagir com os restantes clientes;
  • O polling do browser para saber se existem novas mensagens de chat/jogo é feito através de HTTP Refresh sendo o período de refresh pré-definido;
Cliente com comunicação por WebService (SOAP-XML):
(todo)

Persistência:
  • contas de utilizador;
  • pontuação/rankig de cada jogador;
  • resultados das partidas;

Arquitectura da aplicação:

Conhecimentos:
fase 1:
  • programação de sockets TCP e UDP em Java;
  • serialização de objectos em Java;
  • definição de um protocolo de mensagens a nível aplicacional;
  • tratamento de excepções em ambientes distribuídos;
  • tratamento das falhas transitórias nos sockets de comunicação;
  • desenvolvimento de um mecanismo de replicação de servidores;
  • desenvolvimento de aplicações multithreaded;
fase 2:
  • programação em Java RMI
  • tratamento das falhas transitórias na rede em aplicações RMI;
  • desenvolvimento de um mecanismo de replicação de servidores, usando Java RMI
  • desenvolvimento de aplicações multi-canal, com garantia de interoperabilidade.
fase3:
  • programação de JSPs e Java Beans;
  • desenvolvimento de aplicações web dinâmicas;
  • integração de Beans com objectos RMI;
  • desenvolvimento de aplicações multi-canal, com garantia de interoperabilidade.
fase 4:
  • programação em SOAP-XML (Tomcat-Axis);
  • adquirir conhecimentos em tecnologias de Web-Services;

No comments:

Post a Comment