REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2004 / 2005

UNIVERSIDADE NOVA DE LISBOA Faculdade de Ciências e Tecnologia Departamento de Engenharia Electrotécnica REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2004 / 2005 Licenciatura em Engenharia Electrotécnica e de Computadores 4º ano 8º semestre 2º Trabalho prático: Realização do jogo do dominó sobre CORBA http://tele1.dee.fct.unl.pt Luis Bernardo

1. OBJECTIVOS Criação de uma aplicação distribuída, que use 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 com vários clientes. 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. Também é responsável por procurar jogos activos para os utilizadores. Para tornar o jogo mais interessante, cada utilizador realiza uma aposta antes de começar a jogar. A gestão de utilizadores é realizada por um servidor dedicado (UserDB), que emite certificados de aposta, que são validados pelas agências antes de aceitar um novo jogador. Como no jogo do dominó convencional, ganha o primeiro jogador que ficar sem peças. Cliente Dominó1 Cliente Dominó2 Agência Dominó User DB A aplicação é composta por três tipos de programas: um programa para os clientes poderem realizar as apostas (Cliente Dominó); um programa servidor de jogo dominó (Agência Dominó); um programa repositório de utilizadores (UserDB). São fornecidas implementações do cliente, UserDB e um início de realização da agência dominó, apenas com uma interface gráfica. Também é fornecido o acesso a uma implementação da agência dominó nos computadores do laboratório. Pretende-se que seja desenvolvida pelos alunos uma agência dominó compatível com o protocolo especificado nas secções seguintes. 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 dos tipos de dados auxiliares usados nas funções das interfaces. Foram definidos sete tipos de interfaces para interligar os três tipos de programas: UserDB_admin : A interface utilizada para criar e destruir utilizadores no UserDB a partir da aplicação clientes, controlado com uma palavra de passe de administração; UserDB_cli : A interface utilizada pelos clientes para consultar o seu saldo, e para pedir e cancelar certificados; 1

UserDB_serv : A interface utilizada pelas agências para validar os certificados recebidos dos clientes, e para depositar os prémios de jogo; Cli_jogo : A interface utilizada por clientes para enviar os comandos de jogo para as agências (pedir peças, jogar peças, desistir, iniciar jogo, etc.); Cli_callback_jogo : A interface pela agência para enviar informação para os clientes (estado do jogo, sinalizar inicio e fim do jogo, sinalizar vez, e sinalizar fim do tempo disponível para jogar; Cli_Login : A interface usada pelos clientes para iniciarem ou pedirem a associação a um jogo às agências; Jogo_Login : A interface usada pelas agências para juntarem clientes a jogos existentes; O módulo também define o formato dos certificados emitidos pelo UserDB: // Certificado - na vida real está cifrado struct Certificado { string nome; Euros valor; string key; string ior_serv_userdb; Um certificado identifica um utilizador, identificado pelo nome que para efeitos deste programa se considera único (nome), o valor da aposta (valor), um número de chave do certificado (key), e a referência para o objecto UserDB emissor do certificado no formato IOR (Interoperable Object Reference). Note-se que num sistema real este certificado vem assinado digitalmente, e a chave é enviada cifrada de maneira a apenas a agência poder ler. Para além deste tipo são definidos tipos de dados adicionais, comuns a várias as interfaces: // Unidade monetária typedef double Euros; // Tipo de pesquisa que a agencia pode realizar enum TipoJogo { MAXIMIZE_CASH, MAXIMIZE_PLAYERS, ALWAYS_NEW // Numero entre 0 e 6 typedef octet Numero; // Definição das peças de dominó struct Peca { Numero a; Numero b; // Definicao do conjunto de pecas enviado no inicio do jogo typedef Peca PecaInicial[3]; O tipo TipoJogo define o tipo de serviço que um cliente pode pedir à agência durante a ligação inicial. 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 inicias, podendo pedir mais durante o jogo. 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, ou DominoIf.TipoJogo, e as constantes do TipoJogo são referenciadas como DominoIf.TipoJogo.MAXIMIZE_CASH, por exemplo. 2.1.1 Interface UserDB_admin A interface UserDB_admin define duas operações: 2

// Interface cliente-userdb para gestor interface UserDB_admin { boolean Create_user(in string passwd_admin, in string nome, in string passwd, in Euros saldo); boolean Delete_user(in string passwd_admin, in string nome); As operações Create_user e Delete_user permitem respectivamente, criar e destruir utilizadores do jogo. Estas operações são validadas por uma palavra de passe de administração (passwd_admin), e são executadas por utilizadores identificados por nomes únicos (nome). Como não deve haver dois utilizadores no sistema com o mesmo nome, a criação falha se o nome proposto já existir, retornando a função false. Durante a criação de um utilizador é fornecida a palavra de passe do utilizador (passwd) e o saldo inicial do utilizador (saldo). A destruição também pode falhar se o nome não existir. 2.1.2 Interface UserDB_cli A interface UserDB_cli define três operações e uma excepção: // Interface cliente-userdb para clientes interface UserDB_cli { exception UtilizadorInvalido { Euros GetSaldo(in string nome, in string passwd) raises (UtilizadorInvalido); boolean Play(in string nome, in string passwd, in Euros aposta, out Certificado cert) raises (UtilizadorInvalido); boolean Cancel_play(in string nome, in string passwd, in Certificado cert) raises (UtilizadorInvalido); A operação GetSaldo permite obter o saldo actual do utilizador. As operações Play e Cancel_play permitem respectivamente, criar e cancelar um certificado. Estas operações são são executadas para um utilizador identificado pelo nome (nome) e validadas pela palavra de passe do utilizador (passwd). A operação Play recebe o valor da aposta (aposta) e retorna um certificado (cert), podendo retornar false em caso de falha (e.g. palavra de passe invalidade, saldo insuficiente, etc.). A partir do momento em que o certificado é emitido, o saldo do utilizador é decrementado do valor da aposta. A operação Cancel_play permite cancelar um certificado, desde que este ainda não tenha sido bloqueado por uma agência. Retorna false para erros no certificado ou na palavra de passe. As três funções retornam uma excepção de utilizador (UtilizadorInvalido), caso o nome não exista da base de dados. 2.1.3 Interface UserDB_serv A interface UserDB_serv define duas operações: // Interface server-userdb interface UserDB_serv { // Bloqueio de certificado boolean lock_cert(in Certificado cert, out string key); // Libertação de certificado, actualizando o saldo boolean update_user(in Certificado cert, in string key, in Euros valor); 3

A operação lock_cert permite à agência bloquear o certificado recebido do utilizador, garantindo que o utilizador não retira o dinheiro da aposta a meio do jogo. A função retorna uma chave secreta (key) que apenas é conhecida da agência, e que é usada como parâmetros de entrada na operação update_user, para validar a agência. Nesta segunda operação, o parâmetro (valor) contém o valor a depositar na conta do utilizador, que deve ser sempre maior ou igual a zero. A operação lock_cert falha quando o certificado não é válido, retornado false. A operação update_user também pode falhar retornando false. 2.1.4 Interface Cli_callback_jogo A interface Cli_callback_jogo define cinco operações: // Interface client-server (Callback client) interface Cli_callback_jogo { boolean InicioJogo(in PecaInicial pecas); boolean FimJogo(in Euros premio); boolean Jogo(in Peca state, in boolean vez); void Timeout(); // Demasiado tempo para 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. 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 inválido (7 7), porque o CORBA não permite passar objectos a null. A operação FimJogo sinaliza o fim de um jogo, indicando o valor do prémio. A operação Timeout é invocada pela agência para sinalizar que terminou o tempo para jogar, e que perdeu a vez. A operação update_state é invocada enquanto o jogo não começa para informar os jogadores ligados ao jogo sobre o número de participantes e o valor do prémio de jogo, permitindo-lhe decidir sobre quando se começa a jogar. Esta operação é do tipo oneway, não sendo garantida a sua entrega. 2.1.5 Interface Cli_jogo A interface Cli_jogo define quatro 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 boolean start_game(out string resultado); Esta interface é usada nos clientes para dar comandos para as agências. A operação start_game solicita o arranque de um jogo, podendo falhar caso ele já esteja activo. A função GiveUp é usada para sair de um jogo. Caso se saia antes do arranque do 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) ou na posição B 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 4

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. 2.1.6 Interface Cli_Login A interface Cli_Login define uma operação: // Interface client-agência (Login clientes) interface Cli_Login { boolean Join_game(in Certificado cert, in Cli_callback_jogo callback, in TipoJogo tipo, in double limiar, out Cli_jogo jogo, out string razao); Esta interface é usada nos clientes para se ligar a um jogo numa agência. A operação Join_game recebe um certificado (cert) como argumento, que identifica o utilizador e o valor da aposta, e uma indicação do tipo de serviço pretendido: MAXIMIZE_CASH a agência deve pesquisar no serviço de trading pelo jogo com o maior valor de prémio. Se limiar for superior a zero, indica o valor mínimo de aposta a considerar. Se não houver nenhuma oferta compatível falha, e deve retornar false. MAXIMIZE_PLAYERS a agência deve pesquisar no serviço de trading pelo jogo com o maior valor de participantes. Se limiar for superior a zero, indica o valor mínimo de participantes a considerar. Se não houver nenhuma oferta compatível falha, e deve retornar false. ALWAYS_NEW deve criar um jogo local à agência, e registá-lo no serviço de trading. 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. 2.1.7 Interface Jogo_Login A interface Jogo_Login define uma operação: // Interface server-server (Login cruzado de clientes) interface Jogo_Login { boolean Join_game(in Certificado cert, in Cli_callback_jogo callback, out Cli_jogo jogo, out string razao); Esta interface é usada nas agências para associarem clientes que efectuaram um Join_game através da interface Cli_Login a um jogo criado por outro jogador. Esta operação usa um subconjunto dos argumentos da função homónima, com o mesmo significado. 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ó é o objecto responsável por manter toda a informação referente aos jogos activos. 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. g01), de forma a permitir a coexistência de várias agências em simultâneo. 5

Os jogos criados localmente deverão registar a interface Jogo_Login no serviço de trading durante a fase de angariação de novos jogadores, removendo-a após o início do jogo. 2.2.1 Registo dos jogos no trader A interface Jogo_Login deve ser registada no serviço DominoService, definido no ficheiro DominoIf.st: #include "DominoIf.idl" module DominoIf { service DominoService { interface Jogo_Login; mandatory property string server_name; mandatory property short number_players; mandatory property Euros bet_amount; Os registos incluem uma propriedade estática (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 associados ao jogo (number_players) e o valor total de apostas no jogo (bet_amount). O registo deve ser retirado imediatamente antes de arrancar o jogo, impedindo que mais clientes se tentem associar ao jogo. 2.2.2 Associação de clientes a um jogo Sempre que a agência recebe um novo Join_game de um cliente, a agência deve validar o certificado junto do UserDB de maneira a garantir o valor da aposta, memorizando a chave obtida. Caso um cliente abandone um jogo antes dele começar, a agência deve depositar no UserDB o valor aposta. Caso contrário, deve cancelar o certificado depositando zero, revertendo o valor para o vencedor do jogo. No fim do jogo, a agência liberta todos os certificados dos jogadores, e sinaliza o fim de jogo para os clientes que devem repetir os todos os procedimentos de ligação para jogar um novo jogo. 2.2.3 Jogo do dominó Durante o arranque do 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. O jogo termina caso o número de jogadores desça até um, ou caso um jogador consiga ficar 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. 2.3 Cliente de dominó O cliente de dominó começa por obter as referências para o UserDB e Agência, quando se selecciona o botão "Active". Quando se selecciona o botão "jogar" liga-se ao UserDB para obter um certificado e a uma agência com a operação Join_game. A partir desse momento recebe 6

informações sobre o número de participantes e sobre o prémio de jogo, podendo qualquer cliente decidir arrancar com o jogo em qualquer instante premindo o botão "Iniciar". A partir desse momento, o cliente monitoriza o estado das sessões, apresentando o estado do jogo ao utilizador com a indicação de quando é a sua vez (estado a verde ou vermelho). 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 "Reset" reinicia o cliente no estado inicial. Para sair deve-se usar o botão "Active". A última linha permite criar e destruir utilizadores, e limpar a caixa de texto. O programa obtém a interface da agência de dominó e do UserDB através do serviço de nomes, pesquisando a interface registada com os nomes indicados nas caixas de diálogo. 2.4 UserDB O UserDB realiza as três interfaces deste componente, registando duas delas no serviço de nomes acrescentando o sufixo "_cli" e "_admin" ao nome na caixa de diálogo. Este componente usa memória não volátil para manter a base de dados de utilizados, perdendo todo o seu conteúdo quando é parada. 3. MÓDULOS FORNECIDOS Para facilitar o desenvolvimento da agência, são fornecidos: o executável do cliente, UserDB e acesso a um executável da agência Domino; os ficheiros DominoIf.idl e DominoIf.st com as definições das interfaces; 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 simplificar o acesso ao serviço de nomes; os ficheiros de definição da interface gráfica da agência. 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 é 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: 0. aula de aprendizagem deve ler a documentação da Introdução ao CORBA, e realizar os exercícios propostos; 1. no fim da primeira 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, 7

com a definição de uma classe de suporte para o jogo (pode ser usada a realização do objecto Jogo_Login) e de clientes (pode ser a realização do objecto Cli_jogo); 2. no fim da segunda aula deve ter realizado a operação Join_game com a definição de toda as estruturas de dados de suporte, e a activação dos objectos Jogo_Login e Cli_jogo, que permitem ligar os clientes ao jogo); 3. no fim da terceira aula deve estar a trabalhar na rotina 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 última aula deve ter acabado de realizar a agência, testando e corrigindo os últimos erros de programação. 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 dois membros do grupo. DATAS LIMITE A parte laboratorial é composta por dois trabalhos de avaliação. A duração prevista para cada um deles é de 5 semanas. A parte prática tem o seu início formal na semana de 7 de Março. O quadro seguinte mostra as datas de entrega de cada trabalho de avaliação (P) e as datas previstas para os testes teóricos (T): Março 2005 Maio 2005 1 1 2 3 4 5 9 1 2 3 4 5 6 7 2 6 7 8 9 10 11 12 10 8 9 10 11 12 13 14 3 13 14 15 16 17 18 19 11 15 16 17 18 P2 20 21 20 21 22 23 24 25 26 12 22 23 24 25 26 27 28 4 27 28 29 30 31 13 29 T2 31 Abril 2005 Junho 2005 4 1 2 13 1 2 3 4 5 3 4 5 6 7 8 9 14 5 6 7 8 9 10 11 6 10 11 12 13 P1 15 16 12 13 14 15 16 17 18 7 17 18 19 T1 21 22 23 19 20 21 22 23 24 25 8 24 25 26 27 28 29 30 26 27 28 29 30 8