Instituto Superior Técnico MEEC/MEAR. Programação de Sistemas

Transcrição

1 Instituto Superior Técnico MEEC/MEAR Programação de Sistemas António Grilo Renato Matias Rui Gustavo Crespo Antonio DOT Grilo AT inov DOT pt rms AT comp DOT ist DOT utl DOT pt rgc AT comp DOT ist DOT utl DOT pt Projecto 2009/10 1º relatório 1º relatório projecto PSis 2009/10 Página 1/8

2 Contents 1. Introdução Unidades de execução Servidor Jogos HF Cliente Canais de comunicação Socket do servidor Tubo de despertar Tubo de actualização dos canais Tubo de acesso à tabela classificativa Tubo informativo sobre a tabela classificativa Tarefas Inscrição num desafio Introdução de um comando do jogador Introdução de um comando do administrador de sistema Actualização do estado do desafio... 7 Bibliografia Introdução O presente documento descreve uma arquitectura possível de um simulador de sistema de registo de pagamentos em auto-estradas. Na arquitectura são descritos: Unidade de execução (processos e fios de execução) [1] Canais de comunicação entre os processos ("pipes" e "sockets") [1]. A definição de mensagens e a sequência de passos executados na realização das tarefas indicadas no enunciado do projecto [2] não são descritas aqui, sendo deixadas para os grupos projectistas. Os grupo projectistas são livres de assumir a arquitectura e a implementação que entender. 1º relatório projecto PSis 2009/10 Página 2/8

3 2. Unidades de execução Para o simulador são propostos os processos descritos graficamente na figura 1, para o programa cliente, e na figura 2 para o servidor. Nalguns processos são lançados diversos fios de execução ( threads ). Nas figuras são usadas as seguintes regrepresentações: Processo: círculo Fio de execução ( thread ): corda vertical dentro do processo Tubo ( pipe ): rectângulo inserido no processo leitor com arco dirigido vindo do processo leitor. O arco é etiquetado com as mensagens enviadas pelo tubo. Socket: relâmpago Ficheiro: disco Armazém de dados: duas barras horizontais Para cada processo são listados: Objectivos do processo Fluxos de execução 2.1 Servidor O servidor ServNoon tem três objectivos: Processar todos os pedidos vindos dos clientes, via socket. Actualizar a tabela dos vencedores de topo. Processar os pedidos vindos do terminal. O servidor ServNoon possui três processos: Jogos, Relógio e HF. Relógio Canais Jogos actualizar Desafios Jogadores despertar pedido, actualização resposta HF HallOfFame Top10 Figura 1 Diagrama do servidor Jogos A. Jogos, executado no lançamento do servidor, tem por objectivos 1º relatório projecto PSis 2009/10 Página 3/8

4 Recolher informação de inicialização. Criar os tubos e lançar os processos HF e Relógio. Processar todos os pedidos vindos dos clientes. Processar os pedidos vindos do terminal. O processo possui três tipos fios de execução: Despacho, que aceita um pedido de conexão vindo de um cliente, entregando o socket ao Desafio apropriado. Desafio (um por cada desafio a decorrer) que recebem os pedidos dos dois jogadores envolvidos e envia os novos estados. [Nota: para simplificar o projecto, neste caso apenas, os docentes aceitam que o grupo projectista utilize um select]. Terminal, que responde às solicitações introduzidas pelo administrador. Nota: os desafios também podem ser implementados por processos, embora esta opção seja menos eficiente. B. O processo Relógio acorda os desafios em cada intervalo de tempo (movimento de balas e/ou jogadores) pelo tubo ( pipe ) apropriado. Na mensagem é indicado qual o intervalo esgotado. O processo Relógio mantém na memória um registo Canais com todos os tubos ( pipes ) de despertar o desafio. C. O processo Jogo mantém na memória dois registos: Desafios, com o estado e o fio de execução dos desafios a decorrer. Jogadores, com os nomes de todos os jogadores que participaram em, pelo menos, um desafio. A estrutura dos registos é determinada pelos projectistas HF HF gere as mensagens vindas do processo Jogos, a tabela HallOfFame e o ficheiro. Em caso de alteração, o ficheiro é actualizado. O processo HF inicializa e mantém na memória a tabela HallOfFame, com a listagem dos 10 jogadores com mais desafios e os jogadores correntes. Sempre que a tabela dos 10 melhores for alterada, o ficheiro Top10 é actualizado. 2.2 Cliente O cliente CliNoon tem dois objectivos: Transferir todas as ordens geradas pelo jogador a partir do teclado. Actualizar o estado do jogo no terminal. 1º relatório projecto PSis 2009/10 Página 4/8

5 O cliente CliNoon possui um único processo: Jogador. Jogador Figura 2 Diagrama do cliente O processo possui dois fios de execução: Ordem, que recebe do terminal a ordem do cliente e a reenvia para o servidor. Actualização, que recebe a actualização do estado do desafio e actualiza o terminal. 1º relatório projecto PSis 2009/10 Página 5/8

6 3. Canais de comunicação Os canais de comunicação entre os processos são listados nas Figuras 1 e 2 por: Setas etiquetadas com mensagens para identificar tubos ( pipes ). Um rectângulo indica o processo leitor das mensagens enviados pelo tubo. Relâmpagos, etiquetados com mensagens, para identificar sockets. O sentido do relâmpago indica os processos escritor e leitor. Nas secções seguintes são descritas, informalmente, o conteúdo das mensagens que circulam em cada canal de comunicação. 3.1 Socket do servidor As mensagens enviadas pelo socket são definidas pelos projectistas. Nota: devem ter todas os mesmo comprimentos, se necessário usar padding. 3.2 Tubo de despertar A mensagem deve ter dois campos: 1. Caractere indicativo da mensagem: C -impulso de relógio, J -segundo jogador 2. Inteiro, com dado extra: a. para C, o bit menos significatica indica movimentação de balas e o segundo bit menos significatica indica movimentação dos jogadores. Assim (1): movimentar balas (2): movimentar jogador e (3): movimentar balas e jogadores. b. para J, identifica o socket do segundo jogador. A dimensão da mensagem é sempre igual a 1+sizeof(int). 3.3 Tubo de actualização dos canais As mensagens enviadas pelo tubo ( pipe ) são definidas pelos projectistas. 3.4 Tubo de acesso à tabela classificativa As mensagens enviadas pelo tubo ( pipe ) são definidas pelos projectistas. 3.5 Tubo informativo sobre a tabela classificativa As mensagens enviadas pelo tubo ( pipe ) são definidas pelos projectistas. 1º relatório projecto PSis 2009/10 Página 6/8

7 4. Tarefas Nesta secção são listados, em pseudo-código, as etapas de implementação de cada uma das seguintes tarefas: a. Inscrição num desafio. b. Introdução de um comando do jogador. c. Introdução de um comando do administrador de sistema d. Actualização do estado desafio, por parte do servidor. 4.1 Inscrição num desafio 1. Um cliente faz o connect() para o servidor. 2. O servidor faz o accept() e lê do cliente o identificador do desafio e do jogador. a. Se o desafio não existir, cria-o na base de dados. Se não houver thread disponível para tratar o desafio, cria-o. Por fim, passa o controlo a uma thread desafio, enviando o socket criado. b. Se o desafio existir e faltar o segundo jogador, i. Passa à thread desafio através do tubo despertar, a mensagem contendo o socket criado. A thread desafio calcula as posições aleatórias dos jogadores e inicia o jogo enviando o estado inicial aos dois jogadores. ii. O despacho envia uma mensagem ao Relógio para indicar a activação do desafio. c. Se o desafio existir com os dois jogadores, rejeita o pedido com mensagem de erro. 3. O desafio espera num mutex pela inscrição do primeiro jogador e depois fica à espera em select, do socket e do tubo despertar. a. Se a mensagem do socket for desistência do jogador, actualiza a base de dados, fecha o socket, marca a thread como disponível para novo desafio e volta a esperar no mutex. b. Se receber do tubo a inscrição do segundo jogador, actualiza a base de dados e fica à espera de comandos/relógio por select(). 4.2 Introdução de um comando do jogador O pseudo-código é determinado pelos projectistas. 4.3 Introdução de um comando do administrador de sistema O pseudo-código é determinado pelos projectistas. 4.4 Actualização do estado do desafio O pseudo-código é determinado pelos projectistas. 1º relatório projecto PSis 2009/10 Página 7/8

8 Bibliografia [1] A.S. Tanenbaum; Modern Operating Systems, Prentice-Hall, [2] A. Grilo, R.M. Silva, R.G. Crespo; Projecto de jogo em rede. Programação de Sistemas-MEAer e MEEC, º relatório projecto PSis 2009/10 Página 8/8