REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2007 / 2008

Transcrição

1 Departamento de Engenharia Electrotécnica REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2007 / 2008 Mestrado Integrado em Engenharia Electrotécnica e de Computadores 4º ano 8º semestre 2º Trabalho prático: Jogo de dominó distribuído utilizando o serviço de nomes e de trading da arquitectura CORBA Luis Bernardo

2 1. OBJECTIVOS Criação de uma aplicação distribuída, que usa a invocação remota de objectos e os serviços de nomes e de trading da arquitectura CORBA. O problema consiste na realização de um jogo de dominó distribuído. A aplicação permite a cada jogador jogar uma partida de dominó em rede. A agência Dominó é responsável por arrancar o jogo, e por coordenar a distribuição das peças, a ordem de jogo e a validade das jogadas. Cada agência recebe o registo dos clientes locais, mas coordena-se com outras agências para redistribuir os jogadores, criando jogos com jogadores oriundos de várias agências. Para tornar o jogo mais interessante, cada utilizador realiza uma aposta antes de começar a jogar. Como no jogo do dominó convencional, ganha o primeiro jogador que ficar sem peças. Cliente Dominó Cliente Dominó Agência Dominó Trader A aplicação é composta por dois tipos de programas: um programa para os clientes poderem realizar as apostas (Cliente Dominó); um programa servidor de dominó (Agência Dominó). São fornecidas implementações de código aberto do cliente e acesso a uma implementação da agência Dominó nos computadores do laboratório 3.3-X. Pretende-se que seja desenvolvida pelos alunos uma agência Dominó. 2. Especificações 2.1 Interfaces O conjunto de interfaces do jogo Dominó está declarado no ficheiro DominoIf.idl no módulo DominoIf. Este módulo inclui a definição das interfaces e de tipos de dados auxiliares usados nas funções das interfaces. Foram definidos quatro tipos de interfaces para interligar os dois tipos de programas: Cli_Login : A interface utilizada para realizar o registo de clientes na agência Domino, que é registada no serviço de nomes; Cli_Jogo : A interface utilizada por clientes para realizarem as jogadas, e sinalizar mudanças de estado; Cli_Callback : A interface utilizada pela agência para sinalizar as jogadas, e testar a actividade dos clientes; 1

3 Cli_Transfer : A interface utilizada para realizar a transferência de jogadores entre agências, que é registada no serviço de trading. O módulo inclui vários tipos de dados adicionais, usados nas funções das interfaces: typedef double Euros; // Unidade monetária typedef octet Numero; // Numero entre 0 e 7; 7==ausente // Definição das peças de dominó struct Peca { Numero a; Numero b; // A peça (a=7,b=7) significa peça ausente // Definicao do conjunto de pecas enviado no inicio do jogo // para cada jogador typedef Peca PecaInicial[3]; O tipo Peca define uma peça de dominó, ou o estado do jogo dominó (os valores das duas extremidades do jogo). Quando o jogo arranca, cada jogador recebe três peças iniciais, podendo pedir mais durante o jogo. A peça (7,7) tem o significado especial de peça ausente. As peças normais estão compreendidas entre (0,0) e (6,6). Relembra-se que como os tipos de dados estão declarados dentro do módulo DominoIf são referenciados no software a desenvolver como DominoIf.Peca, por exemplo Interface Cli_Login A interface Cli_Login define uma operação: // Interface cliente-agência (Login clientes) interface Cli_Login { boolean Join_game(in string nome, in Euros valor_aposta, in Cli_Callback callback, out Cli_Jogo jogo, out string razao); Esta interface é usada nos clientes para se ligarem a um jogo numa agência. A operação Join_game recebe como argumentos o nome do apostador (nome), o valor da aposta (valor_aposta), e uma referência para o objecto de callback do cliente (callback). A agência cria um objecto local do tipo Cli_Jogo, sinalizando posteriormente o início do jogo, ou a transferência para outra agência, através da interface Cli_Callback. A função retorna uma referência para o jogo criado (jogo), que poderá ser null em caso de erro. O campo razao permite à agência devolver uma descrição textual ao cliente sobre o que aconteceu durante a operação, e deve ser sempre preenchido com uma string válida Interface Cli_Jogo A interface Cli_Jogo define três operações: // Interface client-server (Jogo clientes) interface Cli_Jogo { boolean Joga(in Peca nova, in boolean at_a_side); boolean Get_peca_nova(out Peca peca); oneway void GiveUp(); // Desiste Esta interface é usada nos clientes para dar comandos para as agências. A função GiveUp é usada para sair de um jogo ou cancelar um registo de aposta. Caso se saia antes do arranque do 2

4 jogo, o jogador deve receber o dinheiro apostado, senão deve perder o dinheiro. A função Joga é usada para colocar uma peça no dominó na posição A (se at_a_side == true) ou na posição B (se at_a_side == true) do estado do jogo. O jogador passa a vez jogando uma peca inválida (7 7), uma vez que não é possível passar objectos a null em CORBA. A agência deve validar a jogada, retornando false caso ela não seja válida, ou não seja a vez do jogador. A função Get_peca_nova é usada para pedir mais uma peça, podendo retornar false caso já não haja mais peças ou não seja a vez do jogador. Dentro do tempo de jogo (10 segundos), o jogador pode pedir quantas peças quiser, mas só pode jogar uma peça Interface Cli_Callback A interface Cli_Callback define seis operações: // Interface server-client (Callback client) interface Cli_Callback { boolean InicioJogo(in PecaInicial pecas, in Cli_Jogo jogo); void update_ref(in Cli_Jogo jogo); // Actualiza referência boolean Jogo(in Peca state, in boolean vez); boolean FimJogo(in Euros premio); void Timeout(); // Perdeu a vez - demasiado tempo sem jogar oneway void update_state(in short jogadores, in Euros valor); Esta interface é usada nos clientes para receber informação das agências. A operação InicioJogo permite à agência sinalizar o início de um jogo, fornecendo o conjunto inicial de peças ao cliente e a interface de Cli_Jogo associada ao jogador. Esta interface também pode ser actualizada em qualquer altura utilizando-se a operação update_ref. A operação Jogo é invocada durante o jogo, cada vez que o estado do jogo muda, indicando quais são os números nas extremidades do bloco (state), e se é a vez do jogador jogar (vez). Para passar a indicação que se está no início do jogo, sem estado, é usado o estado (7 7). A operação FimJogo sinaliza o fim de um jogo, indicando o valor do prémio ganho. A operação Timeout é invocada pela agência para sinalizar que terminou o tempo para jogar (10 segundos), e que o jogo passou a outro jogador. A operação update_state é invocada enquanto o jogo não começa para informar os jogadores da agência sobre o número de participantes e o valor do prémio de jogo. Esta operação é do tipo oneway, não sendo garantida a sua entrega Interface Cli_Transfer A interface Cli_Transfer define uma operação: // Interface server-server (Transferência de clientes) interface Cli_Transfer { boolean transfer_player(in Cli_Jogo new_jogo, out string nome, out Cli_Callback callback, out Euros bet, out string razao); Esta interface é usada entre agências para pedir a transferência do jogador que fez uma aposta mais ainda não está associado a um jogo, que fez a maior aposta. A operação recebe como argumento de entrada a nova referência para o objecto Cli_Jogo que vai ficar associada ao cliente (new_jogo), e retorna os dados do cliente transferido, incluindo: o nome (nome), a referência para o objecto de callback (callback), o valor da aposta (bet). A operação retorna true caso seja aceite a transferência de um jogador, ou false em caso contrário (por exemplo, se entre a consulta ao trader e o pedido de transferência deixou de haver jogadores livres). O 3

5 campo razao permite à agência devolver uma descrição textual ao cliente sobre o que aconteceu durante a operação, e deve ser sempre preenchido com uma string válida. 2.2 Agência de dominó Deve desenvolver uma Agência de Dominó capaz de suportar vários jogos em paralelo. A agência de dominó é a aplicação responsável por manter toda a informação referente aos jogos activos, e aos clientes que realizam uma aposta e aguardam o início do jogo. Quando a agência arranca, oferece uma interface Cli_Login, de maneira a permitir que clientes se liguem à agência (através de uma aplicação cliente). A interface DominoIf.Cli_Login deve ser registada no servidor de nomes com um nome único no sistema (e.g. demo01), de forma a permitir a coexistência de várias agências em simultâneo. Os clientes usam o nome da agência para realizar a associação inicial. Cada agência deverá também registar a interface Cli_Transfer no serviço de trading, permitindo a partilha dos jogadores à espera de iniciarem o jogo entre as várias agências. Para se iniciar um jogo é necessário haver pelo menos um número mínimo de dois jogadores, embora o administrador da agência possa definir um número diferente de jogadores por jogo. O administrador define também um tempo máximo de espera até ao início do jogo, altura onde o jogo deve começar desde que existam pelo menos dois jogadores à espera nas agências disponíveis na rede Registo dos jogos no trader A interface Cli_Transfer deve ser registada com o serviço DominoService, definido no ficheiro DominoIf.st: #include "DominoIf.idl" module DominoIf { service DominoService { interface Cli_Transfer; mandatory property string server_name; mandatory property short number_players; mandatory property Euros highest_bet; Os registos incluem uma propriedade estática (server_name o nome da agência que arrancou o jogo) e duas propriedades dinâmicas, que devem retornar em cada instante o número de jogadores na agência à espera de iniciarem um jogo (number_players) e a maior aposta registada na agência por um jogador que ainda não começou a jogar (highest_bet). Quando um jogador inicia o jogo, deixa de ser contabilizado nas duas propriedades indicadas Associação de clientes a um jogo Sempre que a agência recebe um novo Join_game de um cliente, a agência deve activar um relógio com o tempo máximo que o administrador do sistema definiu para a espera (obtido com a função getplaytime) de um jogo. O jogo começa quando o número de jogadores locais à espera atingir o valor limite definido pelo administrador do sistema (obtido com a função getplayn), ou após o tempo máximo de espera, desde que existam pelo menos dois jogadores à espera. Quando expira o tempo de espera, a agência deve usar o serviço de trading para procurar 4

6 e transferir jogadores de outras agências, tentando atingir o número pedido pelo administrador. Os clientes podem sair da agência em qualquer altura. Caso um cliente abandone uma agência antes do jogo começar, a agência deve devolver o valor aposta. Caso contrário, o cliente perde o valor da aposta, que reverte para o vencedor do jogo. No fim do jogo, a agência sinaliza o fim de jogo com o método Cli_Callback.FimJogo indicando o prémio ganho por cada jogador. Os clientes que devem repetir os todos os procedimentos de ligação para jogar um novo jogo Jogo do dominó Durante o arranque de um novo jogo, a agência deve ordenar aleatoriamente todas as peças de dominó, controlando a sua distribuição inicial, e durante o jogo através da operação Get_peca_nova. Cada jogo deve ser encapsulado num objecto que mantém um estado do jogo (quais são os números das duas extremidades do jogo, quem é o próximo a jogar, etc.). Os jogadores são avisados através da operação Jogo que chegou a sua vez de jogar, tendo até 10 segundos para jogar uma peça, passar, ou pedir peças. Caso um jogador deixe passar 5 vezes sem jogar, o jogador deve ser excluído do jogo pela agência. O jogo termina quando o número de jogadores desce até um, ou caso um jogador fique sem peças. O jogo fica empatado caso ao fim de duas séries de rodadas a todos os jogadores ninguém consiga jogar nenhuma peça. A agência deve validar a invocação das operações sobre a interface Cli_jogo, verificando se a operação é válida para a fase da sessão da agência Desenvolvimento da agência Dominó Deve desenvolver uma Agência de Dominó, partindo da interface gráfica representada à direita. O botão Activar é usado para arrancar e registar os objectos Cli_Login e Cli_Transfer nos serviços de nomes e de trading, associados respectivamente aos endereços IP e portos representados em NS e TS. Os objectos são registados com o nome representado em Nome. A agência de dominó apresenta a informação referente aos apostadores registados localmente através da tabela indexada pelo nome do utilizador (Nome), onde consta o valor da aposta (Aposta), o nome do jogo (Jogo), e o estado do jogo (Estado). Caso um jogador não esteja associado a um jogo, é apresentado o número de jogo -1. No caso representado na figura está um jogo a decorrer (o 1 ) com os jogadores user_00 e user_01, e está o jogador user_02 à espera de iniciar o seu jogo. O estado indica o valor das peças nas extremidades do jogo e quem está a jogar. Os campos de texto N e Time definem o número ideal de jogadores para arrancar um jogo e o tempo máximo de espera por jogadores. O botão Iniciar tem o mesmo efeito que o expirar do relógio associado ao jogador seleccionado na tabela abaixo arranca com o jogo se já houver pelo menos dois jogadores disponíveis. O botão Abortar termina o jogo que estiver seleccionado. Finalmente, o botão Limpar limpa o conteúdo da caixa de texto no fim da janela, onde se ecoam mensagens para o administrador da agência. É fornecido um projecto NetBeans com a interface gráfica mais um conjunto de classes de suporte apresentadas abaixo. 5

7 2.3 Cliente de dominó O cliente de dominó começa por obter as referências para a Agência e para o serviço de nomes (usando os dados do campo NameServer), quando se selecciona o botão Active. Quando se selecciona o botão Jogar, pesquisa no serviço de nomes a agência com o nome Agência e liga-se a ela com a operação Join_game. Os parâmetros passados nesta operação são obtidos das caixas Nome (nome de utilizador) e Aposta (valor apostado). A aplicação cliente controla o saldo do jogador em Saldo, verificando se a aposta é inferior ao saldo. A partir do momento em que está ligado, o cliente recebe informações sobre o número de participantes e sobre o prémio de jogo. A partir do momento em que a agência inicia o jogo, o cliente monitoriza o estado das sessões, apresentando o estado do jogo ao utilizador (Peças do jogo) com a indicação de quando é a sua vez (estado a verde ou vermelho), e na caixa Estado do Jogo. O utilizador pode seleccionar qualquer uma das peças disponíveis para jogar (representadas no canto superior direito) ou passar (jogar sem seleccionar nenhuma peça, enviando (7 7) para a agência), com o botão Escolher, ou pedir novas peças com o botão Pedir, apenas durante a sua vez. O botão Reiniciar reinicia o cliente no estado inicial, com um saldo de 100. Para sair deve usar-se o botão Active. Finalmente, o botão Limpar limpa o conteúdo da caixa de texto no fim da janela. É fornecido um cliente totalmente realizado com o código aberto. 3. MÓDULOS FORNECIDOS Para facilitar o desenvolvimento da agência, são fornecidos: o código fonte do cliente e acesso a um executável da agência Bingo; os ficheiros DominoIf.idl e DominoIf.st com a definição das interfaces e do serviço; o ficheiro corba_thread.java para correr a tarefa CORBA em paralelo com o processamento dos eventos gráficos; o ficheiro NS_Client.java para facilitar o acesso ao serviço de nomes; os ficheiros de definição da interface gráfica da agência, com o código inicial da agência em Agencia.java. O trabalho deve ser desenvolvido utilizando o JDK Embora pareça que corre com Java 5 ou Java 6, a plataforma OpenORB não funciona correctamente nestas versões de Java. Não se esqueça de arrancar os Servidores de Nomes e de Trading antes de correr os executáveis da aplicação. 3.1 Desenvolvimento do trabalho O trabalho vai ser desenvolvido em cinco semanas, onde a primeira semana é principalmente uma aula de introdução à programação de aplicações CORBA com OpenORB em Java. Propõe-se que sejam definidas as seguintes metas para a realização do trabalho: 1. na primeira aula (de aprendizagem) deve realizar os exercícios propostos na Introdução ao desenvolvimento de aplicações CORBA em Java. Também deve preparar o projecto para desenvolver a agência; 6

8 2. no fim da segunda aula deve ter realizado o registo e cancelamento do objecto Cli_Login no serviço de nomes, e começado a realizar a operação Join_game, com a definição de classes que realizam as interfaces Cli_Login e Cli_Jogo; 3. no fim da terceira aula deve ter realizado a operação Join_game apenas para clientes locais, com a definição de toda as estruturas de dados de suporte. Deve também ter iniciado o desenvolvimento da tarefa de controlo do jogo (sorteio de peças, sequenciação de jogadas, temporização). Pode usar uma thread para controlar as temporizações para cada jogo; 4. no fim da quarta aula deve ter terminado a tarefa de controlo do jogo para clientes locais. Deve ter iniciado a realização do objecto Cli_Transfer que suporta a transferência de clientes, e o seu registo no serviço de Trading; 5. no fim da última aula deve ter acabado de realizar a agência, incluindo a pesquisa no serviço de trading por outros clientes à espera de jogo caso não existam clientes disponíveis na agência local em número suficiente. A aplicação deve ser testada, corrigindo-se os últimos erros de programação. 3.2 Postura dos Alunos Cada grupo deve ter em consideração o seguinte: Não perca tempo com a estética de entrada e saída de dados Programe de acordo com os princípios gerais de uma boa codificação (utilização de indentação, apresentação de comentários, uso de variáveis com nomes conformes às suas funções...) e Proceda de modo a que o trabalho a fazer fique equitativamente distribuído pelos membros do grupo. DATAS LIMITE A parte laboratorial é composta por dois trabalhos de avaliação. A duração prevista para o primeiro trabalho é de 4 semanas. O segundo trabalho tem início no dia 17 de Abril. O quadro seguinte mostra os dias das aulas de laboratório e as datas provisórias de entrega de cada trabalho de avaliação (P) e as datas previstas para os testes teóricos (T). Março 2008 Maio L L L L2 P P L T2 Abril 2008 Junho L1 P T L Não há RIT L L2 extra