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:
- Servidor multithreaded (Java);
- Cliente standalone com comunicação por sockets;
- Cliente standalone com comunicação por RMI;
- Cliente Web (JSP/JavaBeans utilizando servidor Tomcat);
- Cliente standalone com comunicação por WebServices (SOAP-XML);
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.);
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;
- 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.
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;
- 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;
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;
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);
(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;
(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;
- 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.
- 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.
- programação em SOAP-XML (Tomcat-Axis);
- adquirir conhecimentos em tecnologias de Web-Services;
No comments:
Post a Comment