Sistema distribuído e paralelo, Esquemas de Sistemas Distribuídos

Baixe Sistema distribuído e paralelo e outras Esquemas em PDF para Sistemas Distribuídos, somente na Docsity!

Sistemas Distribuídos

Relatório dos Trabalhos 1 e 2

12 de Novembro de 2006

Informação dos Autores Grupo Diogo Emanuel de Almeida Guerra – 501041522 – [email protected] Hugo Andre Dias Pereira Vieira Cura – 501041532 – [email protected] Bernardo Montezuma de Carvalho Planas Raposo – 501021206 – [email protected] Horas gastas no trabalho 1º Meta - 30 Horas 2º Meta - 10 Horas Introdução O trabalho pedido consistia na implementação do popular jogo quatro-em-linha em Java, utilizando um dos ambientes gráficos do mesmo. Como se trata de uma cadeira de Sistemas Distribuídos, o verdadeiro desafio deste trabalho era a ligação entre os vários clientes e servidores, isto através de duas abordagens diferentes. Para tal o trabalho foi dividido em duas fases: numa primeira etapa implementámos todo o ambiente gráfico e construímos a aplicação para suportar apenas ligações por Sockets (TCP e UDP), de seguida foi-nos pedido que desenvolvessemos uma nova versão da aplicação, desta vez suportando também ligações RMI. Este relatório visa explicar um pouco mais detalhadamente os pormenores da nossa aplicação, a que nós demos o nome de Quattro. O documento inclui descrição da arquitectura da aplicação, uma lista dos testes efectuados, um pequeno manual e outros detalhes que considerámos relevantes.

desistir do jogo. Todas estas acções são enviadas para o servidor por TCP e processadas no mesmo à excepção do envio de mensagens de chat globais.

RMI

No cliente de RMI, a aplicação é constituida pela mesma classe gráfica Game4L e por uma ClientRmi que comunica com o servidor. Foi criada uma thread TempThread que simplesmente auxilia o ClientRmi em janelas gráficas para que o servidor quando executa remotamente métodos do cliente, não fique bloqueado à espera. Todas as acções disponibilizadas no cliente baseado em sockets são executadas no cliente RMI, em que as threads Senders são substituídas por métodos do servidor chamados pelo cliente e as threads Listeners são substituídas por métodos do cliente chamados pelo servidor.

Servidor

O servidor usado é comum às duas implementações e tanto recebe ligações de clientes por sockets, como por RMI. Cada servidor assim que iniciado, tenta ligar-se à porta definida, se esta tiver livre, age como servidor principal, se não, age como watchdog.

Watchdog

É criada uma thread Server4LPinger com uma flag a indicar se o watchdog tem que actuar em modo RMI ou em modo socket, e fica em wait à espera que a thread referida lhe faça o notify. Se for escolhido o modo socket, a thread Pinger vai ligar-se por UDP ao servidor principal (à thread Server4LResponder) e pinga-o todos os segundos para garantir que o servidor principal está sempre activo. Se for escolhido o modo RMI, a thread Pinger vai fazer o lookup do servidor e também todos os segundos acede ao método ping. Ao fim de 3 falhas, a thread notifica a thread principal (servidor em modo watchdog) que passa a actuar como servidor principal.

Servidor Principal

O servidor principal, assim que estabelece o socket, faz rebind à instância de si mesmo, para poder aceitar ligações RMI. Se anteriormente era watchdog, faz load a todos os ficheiros de dados no disco e no fim fica à espera de ligações TCP. Criam-se threads para envio e recepção de sockets UDP, Server4LUdpSender e Server4LUdpListener respectivamente. Para clientes RMI, os métodos são acedidos remotamente pelo cliente, dependendo de cada acção. Para clientes TCP, para cada socket que é estabelecido, é criada uma Server4LThread que gere toda a comunicação com esse cliente. Esta thread cria também uma Server4LThread2 que vai funcionar como thread que envia informação para o cliente quando a thread que a cria está bloqueada à espera de receber informação dos clientes. Assim que a thread recebe algum request, processa-o e executa na thread principal, podendo aceder a outro cliente (TCP ou RMI). Existem várias estruturas para guardar os dados, todas elas baseadas em hashtables. Existem 6 hashtables cuja chave é o nome do utilizador, à excepção da hashtable games que tem como chave o id do jogo:

• Clients – contém objectos PlayerInfo. Toda a informação dos clientes (incluíndo a thread ou o stub de RMI) autenticados;
• Clients_backup – contém objectos OnlineUser2. Backup do PlayerInfo da hashtable anterior, mas sem os objectos não serializáveis.
• Users – contém objectos User. Registo de todos os users registados no servidor.
• Games – contém objectos Game. Registo de todos os jogos activos no momento.
• Busy – contém inteiro com o game_id. Registo de todos os utilizadores que estão ocupados a jogar.
• Old_users – contém objectos OnLineUser2. Esta hashtable é preenchida com uma cópia do clients_backup (este é inicializado novamente) quando um watchdog entra em modo servidor principal, e serve como um buffer para users que façam o retry, ou seja, quando um user se reconecta, o servidor vai verificar se está neste sitio, e se estiver aproveita a sua informação e remove-o de lá. Formato das Mensagens Para enviar mensagens entre o cliente e o servidor, na versão em que a comunicação se processa a partir de sockets, utilizámos objectos do tipo Packet. Cada Packet é constituído por um código que identifica o tipo de mensagem, e um objecto com o conteúdo, que pode ser de diversos tipos.

A integração entre as duas possibilidades de comunicação (Sockets e RMI) é feita de forma completamente transparente para o cliente, sendo toda a informação processada no servidor. Assim sendo, o servidor ao receber a informação de um client verifica qual é o tipo de ligação que este utiliza e responde-lhe usando o mesmo tipo, permitindo assim que clientes com diferentes ligações comuniquem entre si através do servidor e sem qualquer alteração visível para o cliente. Manual do Utilizador

Servidor

O primeiro passo para se inicializar o servidor é efectuar o login. Esta imagem mostra a janela de login, onde temos de preencher os campos de modo a entrar no servidor. Os campos são, a password, o porto(port), o número máximo de utilizadores(max users) e o modo em que queremos utilizar os watch dogs. O campo port e max users tem também valores default no caso de não serem preenchidos. Sendo que port tem um valor de 7000 e max users de 10. Após um login bem sucedido vamos ao encontro da seguinte janela: Nesta janela temos uma visão geral do interface que nos permite utilizar o servidor.

Para se inicializar o servidor temos de aceder à opção start no Menu, como nos indica a figura seguinte. Após o start, temos um exemplo do servidor já em funcionamento: Analisando a figura podemos ver algumas zonas distintas, nomeadamente, um log dos eventos realizados no servidor, a lista de utilizadores registados, bem como a lista de utilizadores online.

Cliente

Após ter configurado e inicializado um servidor ou tendo conhecimento do endereço de um servidor, pode então começar a utilizar o nosso cliente. Ao executar o cliente irá ter uma vista geral do ambiente gráfico da aplicação.

Options

Nas options podemos optar entre a utilização de uma ligação via Sockets ou RMI

Stastistics

Nas statistics podemos consultar os resultados dos nossos jogos.

Help

O help apenas mostra a informação dos autores. Após explorarmos o menu vamos então ver como se inicia a ligação ao servidor. Como já vimos anteriormente para fazermos o login basta ir ao lobby no menu e carregar em login. Ao faze-lo vamos ter à seguinte janela: Aqui temos de preencher detalhes de ligação ao servidor, nomeadamente o endereço e o porto (valores que podem ser os default, localhost e 7000, respectivamente). Além disso temos de preencher os campos com os dados da conta de utilizador. Caso não tenha uma, ser-lhe-à perguntado se quer registar um novo utilizador, devendo dizer que sim, de modo a poder usufruir da aplicação. Efectuado que foi o login, temos agora a àrea de conteúdos com mais elementos, como se pode ver na figura seguinte:

2. Criar os stubs utilizando os comandos: rmic ClientRmi rmic Server4L
3. Para se poder utilizar o servidor é necessário iniciar o RMI Registry: start rmiregistry
4. Finalmente já se pode correr os servidores e clientes. Para isso basta: java ServerFrame (para o servidor) java Game4L (para o cliente) Testes Efectuados

Cliente

Ligação RMI – RMI

• Conectar-se ao servidor – OK
• Ver estatísticas pessoais – OK
• Desafiar jogador – OK
• Jogar – OK
• Desistir do jogo – OK
• Aceitar rematch – OK
• Rejeitar rematch – OK
• Utilizar o chat – OK
• Desconectar-se do servidor – OK
• Terminar cliente RMI durante o jogo – OK

Ligação RMI – Sockets

• Conectar-se ao servidor – OK
• Ver estatísticas pessoais – OK
• Desafiar jogador – OK
• Jogar – OK
• Desistir do jogo – OK

• Aceitar rematch – OK
• Rejeitar rematch – OK
• Utilizar o chat – OK
• Desconectar-se do servidor – OK
• Terminar cliente RMI durante o jogo – OK
• Terminar cliente Sockets durante o jogo – OK

Ligação Sockets – Sockets

• Conectar-se ao servidor – OK
• Ver estatísticas pessoais – OK
• Desafiar jogador – OK
• Jogar – OK
• Desistir do jogo – OK
• Aceitar rematch – OK
• Rejeitar rematch – OK
• Utilizar o chat – OK
• Desconectar-se do servidor – OK
• Terminar cliente Sockets durante o jogo – OK

Servidor

Servidor Principal

• Inicializar servidor – OK
• Definir limite de utilizadores – OK
• Desligar servidor – OK
• Adicionar utilizador – Não implementado
• Apagar utilizador – Não implementado
• Editar utilizador – Não implementado Watchdogs RMI
• Pingar servidor principal – OK
• Entrar como servidor principal – OK