Prof V Vargas, IST Jogo do Galo (Resolução) Page 1 of 39 Projecto ...

Prof V Vargas, IST Jogo do Galo (Resolução) Page 1 of 39 

Projecto de Software "Cliente/Servidor" 

Jogo do Galo (Resolução) 

{JogoDoGalo-r.doc} 

Nota introdutória: este documento tem fundamentalmente dois objectivos, a saber: 

1. apresentar uma Especificação de um Protocolo, concretamente o do Jogo do Galo (que foi o enunciado 

do Projecto Cliente-Servidor em 2004-2005). Na prática, ela resume-se ao Anexo-A (Para bom entendedor: 

submetido o enunciado de um Projecto, aguarda-se que os estudantes entreguem, como Especificação, algo 

análogo às 9 páginas por que se desenrola o Anexo-A abaixo). As páginas que o precedem destinam-se tãosomente 

a apresentar a reflexão que conduziu àquela Especificação – começando por introduzir conceitos a 

propósito: Cliente e Servidor, Primitivas, Diagramas Temporais, PDUs, sockets TCP/UDP, Arquitectura de 

Comunicações, Diagramas de Estado, Eventos e Predicados, Tabelas de Estado, etc.. 

2. apresentar uma metodologia para a Codificação desse Protocolo. Na prática, ela ocupa o Anexo-B. 

I - Preliminares: Servidor e Clientes co-residentes 

Considere-se, para simplificar, uma Associação Recreativa com um único computador (Unix) e uma Sala de 

Jogo com uns quantos Terminais. 

Quando um sócio quer jogar (o Jogo do Galo), senta-se a um Terminal, procede ao login - e continua invocando 

o programa Jogador e digitando Start. Depois, só tem que aguardar que surja um outro sócio... e que também ele 

corra o programa Jogador (num outro Terminal, é claro), todavia digitando agora Join. 

Para que as "coisas" funcionem, bastará então que esteja correndo um "mediador" entre os sócios, que aceite as 

jogadas (Play) nos teclados e lhes apresente nos ecrãs a evolução do tabuleiro... 

Para um conhecedor de Unix, será natural (fig. JdGrIa): 

- associar a cada sócio um processo Cliente - criado 

quando ele invocou o programa Jogador; 

- e conceber um processo Servidor que materialize o 

"Mediador" supracitado - e que deverá ter sido criado 

antes mesmo de os sócios correrem o Jogador: 

provavelmente, logo no power-on do computador. 

Trata-se de um cenário simples: um só computador, 

com um Servidor e um conjunto de Clientes residindo nesse mesmo computador. 

II -Preliminares: Primitivas de Comunicação 

Servidor e Clientes necessitam comunicar entre si. Em particular, aquando de uma jogada (Play), 

- o Cliente necessita comunicar ao Servidor o trio GId/Line/Column digitado pelo sócio; 

- e o Servidor necessita comunicar a ambos os Clientes a subsequente posição do tabuleiro. 

Pressuposto que tais informações (GId/Line/Column e Board) serão comunicadas através de mensagens, é 

pertinente a pergunta: Como se processará a comunicação entre 

Servidor e Clientes? 

Uma solução será fazê-lo por memória partilhada (fig. JdG-rIb): 

entre cada Cliente e o Servidor, o Sistema Operativo reserva um par 

de memórias FIFO específicas: 

- uma, dita de saída, onde o Cliente escreve mensagens para o 

Servidor ler, 

- e outra, dita de entrada, onde o Servidor escreve mensagens para o Cliente ler. 

À "composição de uma mensagem e sua escrita", e à "sua posterior leitura e interpretação", é tradicional, no 

mundo dos protocolos de comunicação, atribuir a designação de primitivas.


Concretamente, quando um sócio digitar "Play GId Line Column" (fig. JdG-rIc). 

- o respectivo Cliente Jogador deverá escrever na sua memória de saída aquele trio GId/Line/Column (isto 

designando-se de primitiva PLAY.req) 

- e, subsequentemente, o Servidor deverá proceder à sua leitura (isto designando-se de primitiva PLAY.ind) 

Os sufixos ".req" e ".ind" acrescentados a PLAY são as mnemónicas de request e indication. 

Posteriormente, o Servidor valida a jogada, e reporta-o ao Cliente: 

- o Servidor deverá escrever na memória de entrada do Cliente a sua conclusão, Ok ou Sorry (isto designandose 

de primitiva PLAY.rsp) 

- e, subsequentemente, o Cliente deverá proceder à sua leitura (isto designando-se de primitiva PLAY.cnf). 

Os sufixos ".rsp" e ".cnf" são as mnemónicas de response e confirmation. 

Se a jogada for válida, o Servidor prossegue actualizando o tabuleiro e divulgando-o aos Clientes em causa: 

- o Servidor deverá escrever na memória de entrada de cada Cliente do par de sócios em causa a posição do 

tabuleiro (isto designando-se de primitiva BOARD.req) 

- e, subsequentemente, esse Cliente deverá proceder à sua leitura (isto designando-se de primitiva BOARD.ind) 

- após o que apresentará no respectivo ecrã a posição do tabuleiro. 

Repare-se: qualquer um, Cliente ou Servidor, pode desencadear uma primitiva. 

- o Cliente recorre a PLAY.req para escrever uma Mensagem (GId/Line/Column) na sua memória de saída - 

que o Servidor lê recorrendo a PLAY.ind; subsequentemente, o Servidor recorre a PLAY.rsp para escrever outra 

Mensagem (Ok ou Sorry) na memória de entrada do Cliente - que este lê recorrendo a PLAY.cnf; 

- o Servidor recorre a BOARD.req para escrever outra Mensagem (posição do tabuleiro) na memória de 

entrada do Cliente - que este lê recorrendo a BOARD.ind. 

A primitiva PLAY diz-se confirmada - no sentido de que ao ".req" inicial se sucede uma - e uma só! - ".cnf" 

local. Com BOARD, isso não acontece: trata-se de uma primitiva não-confirmada. 

Para caracterizar cabalmente uma primitiva é então necessário especificar: 

- qual das partes a emite, 

- se é, ou não, confirmada; 

- quais os seus parâmetros (no caso, GId/Line/Column, Resultado (Ok ou Sorry) e Board). 

Adiante, serão consideradas outras primitivas mais. 

III - Preliminares: Diagramas Temporais 

A troca de mensagens entre os intervenientes (Clientes e Memórias de Comunicação) pode esquematizar-se por 

um assim denominado Diagrama Temporal. Nele, os intervenientes são representados por riscas verticais; o tempo 

corre verticalmente, de cima para baixo; pelo que a troca de Mensagens vem a ser representada por "setas" oblíquas 

(cf. JdG-rIIa, que figura a troca de Mensagens aquando de uma Jogada, Play, bem sucedida).


Três reparos: 

I. Uma "seta" estabelece o movimento físico de bits, de uma área da RAM para outra; é delimitada por uma 

ponta e uma cauda. Marcam os instantes em que respectivamente o último e o primeiro bits de uma Mensagem 

foram escritos (ou lidos) na Memória partilhada. 

II. O Diagrama não tem escala: 

Por um lado, desconhece-se a velocidade do processador; pelo que não se sabe a inclinação das setas. 

Por outro lado, não se conhece a carga do Computador no momento; pelo que se ignora o tempo de espera 

até se começar a escrever (ou ler) uma Mensagem. Por ex., desconhece-se quanto tempo decorre entre a escrita 

na Memória do resultado Ok e a subsequente escrita da posição do tabuleiro. 

III. Os Diagramas dão conta somente do movimento físico das mensagens - do espaço de endereços dum 

processo para o do outro através das memórias partilhadas. São omissos relativamente aos sinais de controlo 

trocados, cf. JdG-rIIc, que esquematiza uma possível sucessão de acontecimentos ao invocar-se PLAY.req: 

1. O Cliente preenche a mensagem num buffer seu - após o que invoca a SystemCall de escrita na memória 

de Saída; 

2. O conteúdo do buffer é transferido para essa memória; 

3. Com uma SystemCall, o Cliente solicita ao Sistema 

Operativo: alerte o Servidor, que tem algo naquela memória; 

4. O Sistema Operativo notifica o Servidor: há algo para ler… 

5. O Servidor invoca a SystemCall de leitura daquela memória; 

6. O conteúdo da memória é transferido para um buffer do 

Servidor; ele pode agora proceder ao "parse" desse buffer: concretamente, extrai dele o trio GId/Line/Column. 

7. Com uma SystemCall, solicita ao Sistema Operativo: alerte o Cliente, que a memória de Saída já foi lida (e 

por conseguinte está disponível para nova escrita); 

8. O Sistema Operativo notifica o Cliente: a memória de Saída está livre… 

PLAY.req e PLAY.ind envolvem os passos 1-3 e 5-7. Os sinais 4 e 8 destinam-se a evitar underflow e overflow: 

PLAY.ind é desencadeado no sinal 4; e PLAY.req pode consumar-se somente após o sinal 8. 

IV - Preliminares: Mensagens e PDUs 

A troca de Mensagens entre Cliente e Servidor inicia-se sempre pela invocação de primitivas .req ou .rsp; ela 

volve-se na escrita de sequência de bits nas memórias partilhadas entre ambos. A essas sequências de bits, é 

tradicional, no mundo dos protocolos de comunicação, designar de PDUS (Protocol Data Units). Deverão exibir 

uma estrutura (variável) que, no mínimo, inclua os valores dos parâmetros pertinentes àquelas primitivas. 

Por exemplo, 

- a sequência PLAY.req → PLAY.ind deverá envolver uma PDU, seja cPlay-Pdu, veiculando (sob a forma de 

três int) o trio GId/Line/Column digitado no Cliente; 

- a sequência PLAY.rsp → PLAY.cnf deverá envolver uma PDU, seja sPlay-Pdu, veiculando (sob a forma de 

um Boolean[+String]) a decisão do Servidor (Ok ou Sorry[+Reason]); 

- e a sequência BOARD.req → BOARD.ind deverá envolver uma PDU, seja sBoard-Pdu, veiculando (sob a 

forma de uma lista de ints e/ou chars) a posição do tabuleiro. 

Os prefixos "c" (em cPlay-Pdu) e "s" (em sPlay-Pdu e sBoard-Pdu) especificam qual das partes (Cliente ou 

Servidor) preencheu a PDU escrita na memória partilhada. 

A estrutura de uma PDU fica especificada quando se sabe: 

- quais os campos que a compõem, 

- se são, ou não, opcionais - e qual a respectiva ordem no seio da PDU; 

- por cada campo, qual o seu tamanho, tipo e valores aceitáveis: int, long, char, string, boolean, etc. 

Para a generalidade das Aplicações, há um campo imprescindível na estrutura da PDU: é o assim denominado 

Código do Tipo de PDU. Para o compreender, e tendo por pano de fundo o Diagrama Temporal acima, 

considerem-se, por ex., PLAY.cnf e BOARD.ind. No caso em apreço, pode afirmar-se que, para o Cliente que as 

recebe, são, ambas, previsíveis: acontecem quando, tendo invocado PLAY.req, ele recolhe o que o Servidor


escreveu na sua memória de entrada. PLAY.cnf é expectável - pois PLAY é confirmada. Quanto a BOARD.ind, 

também ela será expectável - se PLAY.cnf certificar que GId/Line/Column era válido! 

A ter em conta, porém, a eventualidade do Servidor abortar o Jogo, essa previsibilidade já não é tão certa: é 

possível que, em vez de PLAY.cnf ou BOARD.ind, o Cliente venha a receber um, seja, ABORT.ind. É então 

natural a pergunta: como é que o Cliente "sabe" que se trata de PLAY.cnf, BOARD.ind ou outra "coisa" qualquer? 

A resposta intui-se: sem ajudas, não o sabe… Convém, por conseguinte, um artifício, aliás trivial: que, na 

estrutura da PDU, se reserve um campo (conjunto de bits) para codificar o tipo de PDU em jogo. 

Isso significa que o Cliente sabe qual a primitiva a invocar somente após proceder à leitura na memória de 

entrada do Código do Tipo de PDU (Enunciado análogo vale para o Servidor). Aliás, será também esse código que 

lhe dirá como interpretar o resto do conteúdo daquela memória: quais os campos e respectivos valores em presença. 

A tabela adiante apresenta, para cada Sequência de primitivas, o Tipo de PDU envolvida, um seu possível Código, 

e os demais campos que a constituem. 

Sequência de Tipo de Código do 

Campos 

Primitivas 

PDU Tipo de PDU 

da PDU 

PLAY.req, PLAY.ind cPlay-Pdu 8 GId, Line, Column 

PLAY.rsp, PLAY.cnf sPlay-Pdu 9 Ok ou Sorry+Reason 

BOARD.req, BOARD.ind sBoard 10 GId, Board 

ABORT.req, ABORT.ind sAbort 6 GId, Reason 

Por ex., quando um jogador digita Play 4 2 3, o respectivo Cliente deverá escrever na sua memória de saída a 

PDU (e admitindo que os campos em jogo são todos eles inteiros codificados em 8-bits): 

Código do Tipo de PDU (cPlay-Pdu):8 GId:4 Line:2 Column:3 

PDU: 0000 1000 00000100 0000 0010 0000 0011 

Esse comando pode ser válido: será o caso de o jogo "4" estar decorrendo, e de ainda estar livre a posição 

linha=2,coluna=3; nesse caso, o Servidor deverá escrever na memória de entrada daquele Cliente a PDU: 

Código do Tipo de PDU (sPlay-Pdu):9 GId:4 Result:Ok 

PDU: 0000 1001 00000100 0000 0000 

Mas pode suceder que o comando não seja válido - porque, por ex., a posição referida está já preenchida; então, 

a PDU devolvida pelo Servidor será: 

Código do Tipo de PDU (sPlay-Pdu):9 GId:4 Result:Sorry Reason 

PDU: 0000 1001 00000100 0000 0001 Posição já preenchida 

Para bom entendedor: o Result é codificado como 0 (Ok) ou 1 (Sorry); e, neste último caso, a PDU transporta 

uma mensagem explicativa do erro detectado. Em alternativa, Sorry poderia veicular o código desse erro - bastando 

ao Cliente deter a lista dos códigos de erro possíveis - e correspondentes mensagens na língua materna do jogador... 

Para o caso de o Result ser Ok, o Servidor deve enviar o Tabuleiro; uma solução possível poderá ser: 

Código do Tipo de PDU (sBoard-Pdu):6 GId:4 Result:Tabuleiro 

PDU: 0000 0110 00000100 LXOLXOLLL 

(em que, por ex., LXO significa que as posições da linha são, respectivamente, "Livre", "X" e "O"). 

A concluir a abordagem a este cenário (Servidor e Clientes co-residentes), apresenta-se o esquema da 

Arquitectura do Sistema de Comunicações (fig. JdG-rIVb): 

Ambos os interlocutores apresentam uma mesma Arquitectura: 

1) um Elemento de Utilizador, que: 

- no Cliente, procede à leitura no teclado e escrita no ecrã de cada terminal;


- no Servidor, procede à gestão do jogo, à escrita e leitura de ficheiros em disco, etc.. 

- em ambos os casos, invoca as primitivas de Comunicação referidas. 

2) um Módulo de Comunicações, que executa as Primitivas referidas: procede ao empacotamento e 

desempacotamento de PDUs e à sua escrita e leitura nas Memórias partilhadas. Cabe-lhe, em particular, a 

invocação das chamadas ao Sistema Operativo relacionadas com o acesso a Memórias Partilhadas, com a 

Sincronização nesse acesso (para que, por ex., o Servidor faça uma leitura só após uma escrita pelo Cliente), etc.… 

V - Servidor e Clientes em distintos computadores 

É altura de afrontar o cenário mais geral: ao menos um sócio - ou pela sua provecta idade ou por estar doente - 

não pode deslocar-se fisicamente à Associação Recreativa. Fica em casa… mas, felizmente, dispõe de um 

"Magalhães" (perdoe-se a publicidade ao made in Portugal) - e a tentação não se faz demorar muito: que impede 

usá-lo para embarcar num Jogo remoto através da Internet com o computador naquela Associação? O cenário é 

agora outro: ao menos um Cliente reside num computador distinto daquele onde corre o Servidor (fig. JdG-rIIb). 

Como responder agora à pergunta: Como se processará a comunicação entre o Servidor e esse Cliente? 

Memória partilhada já não pode ser solução: o que existe agora entre ambos é uma porção da Internet, isto é, um 

intrincado maior ou menor de linhas e nós, com as suas memórias, processadores, modems, procedimentos, etc.. 

Pelo que a escrita e leitura de uma Mensagem em uma memória partilhada há-de agora ser substituída pelo 

"envio de uma Mensagem para a Internet e posterior recepção dessa Mensagem". Fica apenas por saber como 

levar a cabo esse tal envio e essa tal recepção… 

Ora acontece que os computadores já hoje vêem equipados de software vocacionado para este envio/recepção: 

trata-se, concretamente do assim designado software TCP/UDP (e IP). Agora, já não se fala em memória partilhada 

- mas nuns objectos especiais ditos de sockets: em lugar de se escrever e ler numa memória partilhada, escreve-se e 

lê-se em um socket (fig. JdG-rIIIa).


Pressuposto que Cliente e Servidor dispõem, cada um, dos sockets necessários à comunicação entre ambos, 

intui-se o que acontece quando um jogador digita Play; grosso modo, 

1. o Módulo de Comunicações do Cliente constrói a cPlay-Pdu, e escreve-a no seu socket; 

2. o software TCP/UDP local encarrega-se de a enviar para a Internet; 

3. a Internet encaminha essa cPlay-Pdu até ao Servidor; 

4. o software TCP/UDP do Servidor recolhe-a da Internet e apresenta-a no seu socket; 

5. o Módulo de Comunicações do Servidor lê no socket a cPlay-Pdu e interpreta-a… 

VI - Arquitectura de Comunicações do "Jogo do Galo" 

A substituição da escrita/leitura em Memória partilhada pela escrita/leitura em sockets impõe uma pergunta: 

pretende-se preservar a Arquitectura esquematizada acima (Elemento Utilizador + Módulo de Comunicações), pois 

sócios haverá que continuarão a ir jogar nos terminais da Associação Recreativa… mas, para contemplar sócios 

acedendo remotamente, que adaptações lhe deverão ser feitas? A resposta exige uma revisão às funcionalidades 

oferecidas pelo software TCP/UDP: 

Do ponto de vista do envio e recepção de dados, TCP e UDP remetem para dois tipos de serviços, a que estão 

associados duas famílias de Chamadas ao Sistema: 

- em UDP, o envio e recepção de dados logra-se com a invocação de sendto e recvfrom. Ambos operam sobre 

Blocos de octetos: com um sendto, envia-se o Bloco - e, para o receber na sua totalidade, basta um recvfrom. O 

serviço não é, porém, lá muito robusto: após sendto, o Bloco pode perder-se e não chegar ao destino… 

- em TCP, o envio e recepção de dados logra-se com a invocação de write e read. Ambos operam sobre 

Sequências de octetos: com um ou mais write, envia-se uma Sequência - e, para a receber na sua totalidade, podem 

ser necessários um ou mais read, num número que até pode não ser 

exactamente igual ao número de write. O serviço é, porém, muito mais 

robusto que UDP: após o write, é muitíssimo menor a probabilidade de a 

Sequência não chegar ao seu destino - e muitíssimo maior a probabilidade 

de os octetos serem recebidos pela mesmíssima ordem em que foram 

enviados. … 

Podem agora deduzir-se as adaptações a fazer-se (fig. JdG-rIIIb): 

1. PLAY e BOARD, concebidas no cenário "Servidor e Clientes coresidentes", 

acedem às PDUs de forma atómica: quando o Cliente invoca 

PLAY.req, a consequência é a construção de uma cPlay-Pdu - em uma 

Memória partilhada que deve ter a dimensão suficiente (em número de 

octetos) para a conter na sua totalidade. Então, quando o Servidor invoca 

PLAY.ind, fá-lo assumindo que vai ler e interpretar toda essa PDU. 

2. No ambiente sockets, esta assumpção não pode ser feita: 

- se se usar sockets-UDP, o sendto da cPlay-Pdu não garante que o 

Servidor a venha a ler: pode perder-se … 

- e, se se usar sockets-TCP, o write da cPlay-Pdu não garante que com um read o Servidor a venha a ler na 

sua totalidade… 

Isso sugere, para o "Jogo do Galo", a arquitectura de comunicações apresentada em JdG-rIVa (no Anexo-A.1). 

Parêntesis: O Nível "Transparência " 

Tal Arquitectura inclui um assim denominado nível "Transparência". A propósito, abra-se um parêntesis para 

tranquilizar o leitor. Considere, por ex., PLAY.req - que deve levar ao envio de uma cPlay-Pdu, de N=4 octetos. A 

delimitação resume-se ao seguinte: 

- proceder ao write de um certo número L de octetos (que neste Documento se assume ser 4) que veicule o 

tamanho (no caso, 4) daquela PDU; 

- e só então executar o write da própria cPlay-Pdu. 

A Internet acaba por vir a transportar um conjunto - designe-se de PDUNT - de, no total, L+N octetos:


PDU-length ocupando L=4 octetos, com o tamanho, N, da PDUMC 

PDUMC ocupando N octetos 

É possível olhar para este conjunto da seguinte maneira: designe-se de PDUMC uma PDU genérica produzida 

pelo Módulo de Comunicações; tudo se passa como se o Nível Transparência a houvera encapsulado em uma 

outra, dita de PDUNT. Em alternativa aos dois write, o nível Transparência pode então prefaciar a cPlay-Pdu com 

um campo PDU-length de L octetos, e proceder a um único write de todo o conjunto. 

Então, o nível Transparência do Servidor, quando lhe chegar essa PDUNT, deverá passar por duas etapas: 

- primeiramente, lê L octetos, para saber qual o tamanho, N (no caso, 4), da PDUMC que chegou; 

- após o que, com um ou mais read, irá lendo os octetos seguintes, até perfazer N octetos. No caso em apreço, só 

então será a hora de se executar PLAY.ind - passando duma só vez todos os octetos que compõem a cPlay-Pdu. 

Repare-se: ambos, Cliente e Servidor, registam o mesmo número (três) de Níveis de Protocolo de 

Comunicações. Entretanto, 

- visto de mais perto, o nível TCP/UDP acaba por (dever) ser considerado como uma Pilha de Níveis de 

Protocolos de Comunicações (Físico, DataLink, Network e Transporte); 

- pode eliminar-se o nível Transparência - pelo expediente de incluir na estrutura das PDUs um campo 

"Tamanho da PDU" e, consequentemente, adaptando o Módulo de Comunicações; 

- e nada impede que o Desenhador do Sistema decida repartir o Módulo de Comunicações por (Sub-)Níveis de 

protocolos (por ex., para fazer criptografia, compactar dados, re-sincronizar, etc.) 

VII - Primitivas de acesso aos Níveis de Protocolo 

VII.1: As Primitivas de acesso ao Nível TCP/UDP não deverão constituir novidade: write e read, etc.: 

Primitiva invocada por: Parâmetros 

connect Cliente Target (HostName + Port) 

accept Servidor & Source (HostName + Port) 

write (e sendto) 

read (e recvfrom) 

close 

Cliente, Servidor Socket, Buffer, Buffer-length, Flags (e Target) 

Socket, Buffer, & Buffer-length, Flags (e & Source) 

Socket 

select (puramente local) Cliente, Servidor Domain, Type, Protocol 

VII.2: Quanto às Primitivas de acesso ao Nível Transparência, bastarão, no que toca à transferência de PDUs, 

as seguintes (fig. JdG-rIVc): 

Primitiva Parâmetros 

TCP.req (e UDP.req) Socket, Buffer, Buffer-length (e Target) 

TCP.ind (e UDP.ind) Socket, Buffer, & Buffer-length (e & Source) 

em que a discriminação TCP versus UDP selecciona qual o modo como a comunicação se deve fazer: 

respectivamente por write+read ou sendto+recvfrom. 

VII.3: Já quanto às Primitivas de acesso ao Módulo de 

Comunicações, isso encontra-se em aberto. Na continuação do que se já 

discutiu acima, uma solução é começar por associar a cada comando 

(Start, Join, Play, List e Abort) uma ou mais Primitivas específicas: 

A Start, associa-se a primitiva START; ela é desencadeada pelo 

Cliente, e é confirmada: após o Utilizador digitar Start, ele deve receber 

uma resposta - que, em caso de sucesso, provém do Servidor. 

De maneira análoga, a Join, Play e List associam-se respectivamente as primitivas JOIN, PLAY e LIST. Todas 

elas são desencadeadas pelo Cliente e, com excepção da última, são confirmadas.


Em caso de sucesso de Play, o Servidor deve comunicar a subsequente "posição do Tabuleiro" a ambos os 

jogadores. Isso convida a conceber uma outra Primitiva, BOARD; ela é desencadeada pelo Servidor (após 

responder a Play) e não é confirmada. 

Quanto a List, o Servidor deve comunicar a Listagem dos Jogos: GIds e respectivos jogadores. Isso convida a 

conceber outra Primitiva, GAMELIST; é desencadeada pelo Servidor e não é confirmada. 

Quanto ao Abort, existem três cenários: 

1. um jogador digita Abort; 

2. o Servidor acaba com um Jogo abortado por algum fulano que nem sequer precisa estar a jogar: 

3. o Servidor aborta um Jogo porque o período máximo entre comandos expirou. 

Isso convida a conceber uma primitiva, ABORT, que pode ser desencadeada por qualquer uma das partes; e que, 

se for desencadeada por um Cliente e não for bem sucedida, deverá ser replicada por uma primitiva ERROR. 

Estas conclusões encontram-se sumariadas no Anexo-A.2 - num quadro que exibe, para cada Comando, as 

primitivas associadas, quem as desencadeou e os respectivos parâmetros. 

Ressalve-se, nesse quadro, o parâmetro Gf. Surge para responder à interrogação: como "emparelhar" com um 

Start a posterior réplica (Ok ou Sorry) que o Servidor irá devolver? 

- é que, por um lado, o GId é atribuído pelo Servidor: aquando de START.req, ele não é ainda conhecido; 

- de outra parte, aceita-se que o utilizador possa digitar "de rajada" vários Start - mesmo sem antes ter recebido 

a réplica ao primeiro deles. 

Gf é escolhido pelo Cliente, enviado na cStart-Pdu e depois "ecoado" pelo Servidor na subsequente réplica, 

sStart-Pdu. Repare-se, entretanto, que se poderá dispensar Gf: bastando para tal que o Servidor responda a cStart- 

Pdus pela mesmíssima ordem em que ele as for recebendo… 

VIII - Diagramas Temporais das Primitivas 

A etapa seguinte é desenhar diagramas temporais para as primitivas concebidas. Eis alguns: 

VIII .T - Nível Transparência 

Apresentam-se dois Diagramas esquematizando a sucessão de eventos desencadeada por uma TCP.req invocada 

pelo Módulo de Comunicações: 

JdG-rVa: O Nível Transparência adiciona o PDU-length e invoca write; o software TCP envia o correspondente 

Segmento para a Internet; à sua chegada ao receptor remoto, o Nível Transparência invoca read; o PDU-length é 

removido, e sinalizado o Módulo de Comunicações - podendo então emitir-se TCP.ind. 

O Diagrama para UDP.req e UDP.ind é análogo - a diferença consistindo em que, agora, não é adicionado nem 

removido nenhum PDU-length, e o par write/read vem a ser substituído por sendto/recvfrom. 

JdG-rVb: O cenário versa a eventualidade de o software TCP/UDP achar que os dados que acompanham o 

write são demasiado extensos para caberem num Segmento só: acabam por ser enviados vários Segmentos para a 

Internet. No interlocutor remoto, isso dará azo a vários read… mas a presença do PDU-length conduz a que seja 

emitida uma única TCP.ind: esta só é invocada quando a PDU já foi aí totalmente recebida…


VIII .C - Módulo de Comunicações 

Um primeiro cenário respeita a Start, cf. JdG-rVIa. Considera-se que já existe uma conexão-TCP estabelecida 

entre o Cliente e o Servidor; aquele executa START.req; esta é "ecoada" no Servidor como START.ind. Ocorre 

sucesso: o Servidor responde com START.rsp(Ok), que é "ecoada" no Cliente como START.cnf(Ok). 

Seguindo a evolução pari passu: um jogador digita Start; o Elemento de Utilizador lê o teclado, e invoca 

START.req; o Módulo de Comunicações constrói a cStart-Pdu, e invoca TCP.req; o Nível Transparência faz o 

que lhe compete… No Servidor, o Módulo de Comunicações invoca TCP.ind, após o que lê a cStart-Pdu, e 

passa os respectivos valores ao Elemento de Utilizador. Este procede à actualização das suas estruturas de 

Dados e devolve Start.rsp; o resto intui-se - e está contemplado no Diagrama… 

Nota: Se, eventualmente, já se esgotou o número de Jogos simultâneos, então o Servidor responde com 

START.rsp(Sorry), que é "ecoada" no Cliente como START.cnf(Sorry). 

No que segue, e por comodidade, 

1. TCP.req/TCP.ind e UDP.req/UDP.ind ficam implícitas: apenas se referem as cPlay-Pdu, sPlay-Pdu, 

etc.. As coisas são figuradas como se fosse o próprio Módulo de Comunicações a acrescentar/remover o 

PDU-length - e ele mesmo a invocar as primitivas write/read de acesso ao TCP. 

2. Ficam também implícitas as primitivas START.req, START.ind, etc. - no sentido de que se apresenta a 

evolução do conjunto Elemento-de-Utilizador+Módulo-de-Comunicações (e não cada um em separado). 

Com isso, perde-se uma certa coerência: a referência ao TCP é feita em termos de primitivas (write, 

read, etc.) - que não em termos das correspondentes PDUs (segmentos); já a referência ao Módulo de 

Comunicações é feita em termos das suas PDUs - que não em termos das correspondentes primitivas. 

3. Omite-se o sufixo -Pdu nos nomes das PDUs, tanto nos Diagramas como nas Tabelas dele derivadas. 

Para exemplificar, em JdG-rVIf (em Anexo) apresenta-se o Diagrama Temporal correspondente ao já 

figurado em JdG-rVIa, mas agora refeito tendo implícitas todas as primitivas excepto write e read. 

No Anexo-A.3, apresentam-se outros Diagramas Temporais concernindo o Jogo do Galo. Deverá ser trivial para 

o leitor congeminar outros cenários, nomeadamente: 

- Quanto o Abort é invocado pelo Sócio, ainda não existe a necessária conexão-TCP com o Servidor; 

- O Cliente de um (ou mais) Jogos em curso sofre um crash; o Servidor detecta-o e reporta-o aos pertinentes 

Clientes; 

- Ambos os jogadores invocam Abort… 

- Um dos jogadores invoca Start, outro invoca Join - e, precisamente nesse momento, o primeiro invoca 

Abort (fenómeno dito de colisão de Join e Abort).


Nível Transparência, Diagrama do Receptor: 

IX - Preliminares: Diagramas de Estados 

A propósito do nível Transparência, apresentou-se o cenário JdG-rVb. Quiçá o leitor tenha reparado: a acção 

empreendida pelo receptor de read não é sempre a mesma: invoca TCP.ind somente ao terceiro read (fig. JdGrVc). 

Recorde-se: 

1. O Módulo de Comunicações compõe uma PDUMC, seja, por ex., a cPlay-Pdu 01 04 02 03(16), de N=4 bytes - e 

invoca TCP.req; 

2. o Nível Transparência prefacia-a com o PDU-length - onde inscreve o valor N -, resultando a PDUNT 00 00 

00 04 01 04 02 03(16) e invoca write; 

3. o receptor começa por invocar read - para ler o tal PDU-length - ficando assim a conhecer o número de bytes 

da PDUMC; 

4. invoca então, um segundo read - para ler esses bytes - mas porventura nem todos terão chegado já da Internet; 

terá então que esperar que o software TCP lhe anuncie a chegada de mais bytes; 

5. quando isso acontecer, invoca um terceiro read - com o que acaba de ler os bytes que faltavam… É então 

altura - e só então - de passar a PDUMC ao Módulo de Comunicações, através de TCP.ind. 

O receptor precisa, portanto, em cada momento, de 

memorizar o que já aconteceu (Enunciado análogo vale 

para o transmissor). Isto remete para aquilo a que é 

tradicional, no mundo dos protocolos de comunicação, 

atribuir a designação de Estados. 

No cenário em causa, é pacífica a existência de dois 

Estados no receptor: 

- de um lado, o Estado wLength: precede a chegada do 

primeiro byte da PDUMC - e que só é abandonado quando 

forem recebidos todos os (4) bytes do PDU-length; 

- por outro lado, o Estado wLast: onde se ingressa com 

a chegada do último byte do PDU-length - e que perdura 

até chegar o último dos N bytes que compõem a PDUMC. 

Para bom entendedor, o receptor não permanece 

sempre no mesmo Estado: ele irá evoluindo de um para 

outro Estado - à medida que se forem sucedendo eventos (no caso, os read após a chegada de bytes). 

Repare-se no prefixo w nos nomes dos Estados: recordam a palavra wait. Um Estado não é definido pelo 

que se "faz" nesse Estado: é preferível pensá-lo como período de tempo em que não se faz nada! - senão 

esperar por algum evento, para decidir alguma acção - e, quando é executada, assume-se que é instantânea! 

Nomeadamente, 

- wLength é o Estado em que se espera que acabem de ser lidos 

todos os (4) bytes do PDU-length; e, quando isso acontecer, a leitura 

desse PDU-length é instantânea - tal como o é a passagem a wLast; 

- wLast é o Estado em que se espera que acabe de ser lido o último 

byte da PDUMC; e, quando isso acontecer, a invocação de TCP.ind é 

instantânea - tal como o é o regresso a wLength. 

A evolução entre os vários Estados pode ser representada de uma 

maneira apelativa (uma imagem vale mais que mil palavras…) por um 

Diagrama de Estados (fig. JdG-rVd). Neste, 

- os Estados são representados por círculos/elipses, etiquetados pelos 

seus Nomes, no caso wLength e wLast; 

- para representar as transições possíveis entre os Estados, usam-se 

"setas"; cada uma delas dirige-se do Estado actual para o seguinte. 

- tais setas são etiquetadas por um rótulo com a estrutura 

Evento [,Predicado] / Acção


No caso em apreço, 

- Primeiramente, há que ler os bytes que perfazem o PDU-length; depois, há que ler os N bytes que constituem o 

corpo da PDUMC. Pelo que será pacífica a concepção de uma Variável de Estado, seja NMax, que memorize o 

número máximo de bytes expectáveis no Estado em causa. 

- Esse valor NMax será fixado (em 4 ou PDU-length) quando se ingressa em wLength ou wLast - após o que irá 

decrescendo até zero, que é a condição de progresso para o outro Estado. Pelo que será pacífica a concepção de um 

predicado, seja p1, que é o resultado lógico (TRUE ou FALSE) da seguinte afirmação: "acabou de se ler os bytes 

que faltavam"; 

- o Evento é o termo da execução do read invocado no seguimento do sinal que anuncia a chegada de bytes da 

Internet; 

- a Acção é uma das seguintes: "iniciação de NMax", "decremento de NMax" e "invocação de TCP.ind". 

Concretamente (fig. JdG-rVd), admita-se que o receptor ingressou em wLength - tendo fixado NMax=4. 

- se for sinalizada a chegada de bytes, o receptor invoca read (solicitando a leitura de, até, 4 bytes); NMax é 

decrementado do número de bytes efectivamente lidos; 

- se p1 não se verificar (~p1 representa "ainda não se acabou de ler os bytes que faltavam, 0


O leitor poderá conferir que, em ambos os Estados, o evento read, quando p1=FALSE, conduz à mesma 

Acção, a saber: "Decrementa NMax". Isso sugere o colapso desses Estados em um único, seja wData (fig. JdGrVf), 

pelo artifício de acrescentar uma Variável de Estado mais, seja B, com o seguinte comportamento: 

- é iniciada a -1; 

- é fixada no tamanho, N, da PDUMT, quando enfim se tiverem 

lido os primeiros 4 bytes; 

- e é reposta em -1 quando se tiverem lido todos os N bytes 

dessa PDU. 

Agora, existe somente um Estado e, obviamente, uma seta 

apenas. Aquilo que muda é a Acção a executar aquando do read: 

irá depender de p1 e de um novo predicado, a saber, p2 - que 

deverá ser o resultado lógico da seguinte afirmação: "B é igual a - 

1". 

Com menos Estados, e menos setas, adivinha-se que o 

subsequente código será mais simples de desenhar, corrigir e 

manter… 

Nota: o objectivo da precedente discussão é somente a abordagem a conceitos como sejam: Estados, 

Transições, Predicados, Acções, Diagramas e Tabelas de Estado. Pelo que o Diagrama apresentado em JdGrVd 

não há-de entender-se como definitivo. De facto, ele não funciona! 

- por um lado, considere-se, nomeadamente, o caso de, em wLast, chegarem NMax+4 bytes; no Diagrama, fazse 

uma transição para wLength; todavia, não terá escapado ao leitor que, nessa situação, se deveria permanecer 

em wLast! e, se só tivessem chegado NMax+3 bytes, transitar-se-ia para wLength - mas NMax deveria ser iniciado 

a 1! 

- por outro lado, pode configurar-se read como bloqueante - isto é: quando se executa read, o Sistema 

Operativo "suspende" o programa - sem sequer conferir se o utilizador digitou entretanto algo no teclado… 

Uma solução (já entrevista no comentário que acompanha JdG-rIIc) é: que o read recolha num buffer tudo o 

que chegou da rede e se analise depois esse buffer - não devendo ser difícil ao leitor alterar o Diagrama de 

Estados em conformidade… 

- enfim, está-se pressupondo que o read se volve sempre na leitura de ao menos um byte… Ora, tal não é 

verdade: se tiver havido close por parte do interlocutor remoto, ou o seu crash, o read volve-se em 0 bytes… 

Nível Transparência, Diagrama do Transmissor: 

Ao receptor (do Cliente ou Servidor), há-de então associar-se um 

Diagrama de Estados… mas, ao transmissor, também! Porquê? A 

interrogação é legítima: no fim de contas, de que é que necessita o 

transmissor recordar-se? não lhe bastará, quando lhe é passada uma 

PDU, prefaciá-la de um PDU-length e invocar write? 

Não é bem assim! Quando se invoca write, designando um buffer 

com 4+N bytes, nem sempre isso conduz, de facto, ao envio para a 

Internet de todos eles: o software TCP pode limitar-se a enviar apenas 

os primeiros w bytes (com w≤4+N) - pelo que é preciso invocar outro 

write (sobre os restantes N-w bytes); e quiçá seja necessário outro(s) 

mais - até terem sido enviados todos os 4+N bytes. 

Com estes considerandos, é pacífica a existência de dois Estados no 

transmissor (fig. JdG-rVg): 

- de um lado, o Estado wFirst: é aquele que precede a invocação de 

TCP.req; 

- por outro lado, o Estado wNet: é aquele onde se ingressa quando o número de bytes escritos (com write) é 

inferior ao total a enviar. 

Quanto às restantes componentes do Diagrama de Estados, 

- agora, será pacífica a concepção de uma Variável de Estado, seja R, que memorize o número de bytes que 

resta escrever;


- esse valor R será fixado (em 4+N) quando se ingressa em wNet - após o que irá decrescendo até zero, que é a 

condição de reingresso em wFirst. Pelo que será pacífica a concepção de um predicado, seja p4, que é o resultado 

lógico (TRUE ou FALSE) da seguinte afirmação: "acabou de se enviar os bytes que faltavam, R==0"; 

- o Evento pode ser um dos dois seguintes: a invocação de TCP.req e o termo, Swrite, da execução de um write; 

- a Acção é uma das seguintes: "iniciação de R", "decremento de R" e "invocação de write de bytes com destino 

à Internet". 

Concretamente (fig. JdG-rVg), admita-se que o transmissor ingressou em wFirst - tendo fixado R=0. 

- se for invocada TCP.req, o transmissor acrescenta o PDU-length, fixa R=4+N e invoca write (solicitando a 

escrita de R bytes); R é depois decrementado do número de bytes efectivamente escritos; 

- se p4 se verificar, o Estado permanece sendo wFirst (seta a Este de wFirst); 

- caso contrário ("0


X.A - Preliminares: a Arquitectura Modular do Elemento de Utilizador 

A. No Cliente, 

- a leitura do teclado e a impressão no ecrã estão a cargo do Gestor da Interface; 

- o estabelecimento e fecho da conexão estão a cargo do Gestor da Conexão; 

- o Gestor dum Jogo (GM, Game Manager) dedica-se à evolução de um jogo de acordo com: 

- os comandos do utilizador; 

- os sinais (accept e close) provindos do Gestor da Conexão; 

- as PDUs recebidas da Rede. 

- o Boss: conforme ao comando digitado ou PDU recebida, sinaliza-o ao pertinente Gestor de Jogo. 

No Diagrama, esse sinal é prefixado por '-'. Eventualmente, esse Gestor poderá devolver (return) alguma 

indicação,como seja: SIGPIPE (a conexão findou) ou End (um Jogo GId acabou); ela vem prefixada por '+' 

Para não sobrecarregar os Diagrama de Estados com predicados "PDU ou Comando inválido", 

- a entrega de um comando ao Boss é feita através de um Filtro de Comandos que o verifica, alertando o 

utilizador para algum erro nele detectado; 

- uma PDU recebida é de imediato passada por um Filtro de PDUs, que a rejeita se for achada inválida. 

Considere-se um comando genérico. O Gestor da Interface lê-o, valida-o - e, se for o caso, alerta para eventuais 

erros de sintaxe; se não for o caso, reporta-o ao Boss. Este também o valida - reportando, se for o caso, eventuais 

erros (por ex., "Já se atingiu o número máximo de jogos" ou "O GId não existe"); se não for o caso, prossegue: 

- se o comando começa um jogo novo (Start ou Join), reserva-lhe um descritor livre, seja Gf, e invoca sobre ele 

o Gestor de Jogo, passando Start ou Join como argumento; 

Adiante, far-se-á recurso à expressão "corre E em X" para significar "o Boss invoca o Gestor do Jogo X, 

passando-lhe E como argumento"; a frase anterior terminaria, então: "seja Gf, e corre esse comando em Gf". 

- se se trata de Play, corre Play sobre o GId mencionado; 

- se se trata de Abort, transmite cAbort-Pdu; ademais, corre Abort nos GIds que respeitam a um Jogo local; 

- enfim, se se trata de List, envia a cList-Pdu. 

Para os casos dos comandos Start, Join e Abort, o Boss contacta o Gestor de Conexão - que, se o não tiver 

feito ainda, enviará connect ao Servidor. Quando o accept chegar, o Gestor da Conexão passa-o ao Boss - que o irá 

correr em todos os GIds; enunciado análogo vale para a chegada de close da Rede.


Enquanto não chega o close, uma PDU que venha da Rede é entregue ao Boss; este valida-a e 

- se se trata de sGameList-Pdu ou sError-Pdu, passa o respectivo conteúdo ao Gestor da Interface; 

- nos restantes casos, corre essa PDU no Gf ou GId a que ela diz respeito. 

Para bom entendedor: o Boss centra-se em eventos que não afectam nenhum jogo local (List ou mesmo Abort), 

ou que poderão afectar a mais que um, quiçá mesmo a todos (close ou mesmo connect e Abort). Os Diagramas 

adiante têm então que cobrir a ambos, Boss e Gestor de Jogo, GM. 

B. No Servidor, 

- a leitura e a escrita em disco estão a cargo do Gestor de Ficheiros; 

- o estabelecimento e fecho das conexões estão a cargo do Gestor de Conexões; 

- o Gestor de Jogo dedica-se à evolução de um jogo de acordo com: 

- as PDUs recebidas da Rede; 

- o expirar do Relógio TTTL; 

- os sinais (close) provindos do Gestor da Conexões. 

- o Boss: 

- conforme à PDU recebida ou Relógio em causa, sinaliza-o ao(s) pertinente(s) Gestor(es) de Jogo(s). 

Considere-se a chegada de um connect. O Gestor de Conexões reserva um descritor para a nova conexão - e 

devolve accept. Um eventual close que venha da Rede é entregue ao Boss - que o irá sinalizar aos Gestores dos 

Jogos que essa conexão suporta. 

Enquanto não chega o close, uma PDU que venha da Rede é entregue ao Boss, acompanhado da sua 

proveniência; este valida-a e 

- se se trata de cList-Pdu, devolve sGameList-Pdu; 

- se se trata de um cStart-Pdu, procura um descritor livre, seja GId, e corre a cStart-Pdu sobre ele; 

- nos restantes casos, determina o GId a que a PDU diz respeito, e corre a PDU sobre ele. 

Eventualmente, a PDU pode respeitar a mais que um par Cliente/Servidor; é o caso de cPlay-Pdu e cAbort-Pdu. 

Pelo que levam à tomada de decisões (envio de sBoard-Pdu e sAbort-Pdu) que afectam outro par Cliente/Servidor. 

Para bom entendedor: o Boss centra-se em eventos que não afectam nenhum Cliente específico (List), ou que 

envolvem mais que um jogo ou Cliente (close, cPlay-Pdu, cAbort-Pdu e o expirar do relógio TTTL). 

X.B - Eventos no Jogo do Galo 

Uma primeira questão é: quais os Eventos que provocam alterações em um par Cliente-Servidor? Eventos são 

algo inesperado, "aleatorio". Considerando a Arquitectura acima, o conjunto Elemento de Utilizador + Módulo de 

Comunicações deve ser sensível a três Classes de eventos: 

1. aqueles ocorridos "em cima" - nomeadamente: 

- o "input" digitado pelo jogador (Start, Join, etc.); 

- a tomada de decisões pelo Servidor, a saber: o envio de Ok/Sorry, ou do Tabuleiro ou Listagem de jogos, o 

aborto de um Jogo, o fecho da conexão, etc. 

2. aqueles ocorridos "em baixo" -, nomeadamente: 

- para passar as PDUs provenientes da Internet: cStart-Pdu, cList-Pdu, etc. 

- para sinalizar fenómenos detectados pelo software TCP/UDP, como seja: 

- a chegada de connect/accept ou close; 

3. os restantes - nomeadamente: 

- os que correspondem ao expirar de relógios, como seja: aquele, TConnext, associado ao connect, e aquele, 

TimeToLive (TTTL), associado à recepção de cStart-Pdu, cJoin-Pdu e cPlay-Pdu; 

- iniciação, eventualmente após crash da própria máquina… 

- o "signal" provocado pelo write em um socket-TCP fechado (SIGPIPE)… 

- a indicação "End" provocada pelo acabar de um Jogo… 

No Anexo-A.4a, condensaram-se num quadro os eventos significativos para cada parte: Cliente e Servidor.


Nota: por comodidade, o texto adiante assume sincronismo entre a chegada de PDUs e a subsequente 

tomada de decisões do Servidor. Por outras palavras: quando, por ex., chega uma cList-Pdu ao Servidor, 

assume-se que o tempo que ele demora a validar a PDU e a decidir enviar a Listagem de Jogos é zero! A 

consequência disso é: havendo que, na Tabela de Estados, dedicar uma linha ao evento "chegada de cList- 

Pdu", essa mesma linha cobre o evento "o Servidor decidiu enviar uma sGameList-Pdu com a Listagem". 

X.C - Estados no Jogo do Galo 

Para a execução dos comandos Start, Join, Play e Abort, exige-se uma conexão-TCP entre Cliente e Servidor. 

Em ordem ao seu estabelecimento, o Cliente precisa enviar connect - devendo o Servidor responder-lhe com 

accept. Com este pano de fundo, serão pacíficas as asserções seguintes: 

No Boss do Cliente, convirá definir três Estados, com os significados adiante: 

- closed: ainda não se iniciou o estabelecimento de uma conexão-TCP com o Servidor; 

- wAccept: tendo o jogador invocado Start, Join ou Abort, o Cliente enviou connect, está aguardando accept; 

- cConnected: já foi recebido accept após ter-se enviado connect. 

No Servidor, convirá, por cada Cliente, definir dois Estados, com os significados adiante 

- wConnect: ainda não se concluiu o estabelecimento de uma conexão-TCP com esse Cliente; 

- sConnected: já foi enviado accept após se ter recebido connect. 

X.D - Diagramas de Estados no Jogo do Galo 

Nos Anexos A.4b e A.4c, listam-se Variáveis de Estado e Predicados que convirá definir para o Jogo do Galo. 

Diagramas de Estado no Cliente: o Boss 

Em JdG-rXc (no Anexo-A.4b), apresenta-se o Diagrama de Estados do Boss - para os casos em que é 

irrelevante o Estado em que ele se encontra: 

- o jogador digita Start ou Join, mas o Cliente recorda-se que ele já embarcou em 4 Jogos (p10): apresenta 

Sorry no ecrã … 

- o jogador digita List; pelo que se fixa ListReqed=TRUE e se envia a cList-Pdu; em caso de sucesso, virá a 

receber a sGameList-Pdu, viabilizando a impressão no ecrã da listagem dos Jogos em curso (no Sistema). 

Em JdG-rXd (no Anexo-A.4b), apresenta-se o Diagrama do Boss para o caso p10=FALSE: 

- em closed, o jogador pode digitar Start ou Join. O Cliente: 

- determina o menor valor Gf cujo Role seja -1, incrementa Gc; corre o comando digitado sobre Gf; 

- envia connect ao Servidor, arma o TimeOut Tc e transita para wAccept; 

- em closed, o jogador pode também digitar Abort. O Cliente: 

- salvaguarda em AList o(s) GId(s) associados a Abort; 

- envia connect ao Servidor, arma o TimeOut Tc e transita para wAccept; 

- em closed, o jogador pode digitar Play. 

- o Cliente apresenta Sorry no ecran; 

- em wAccept, há que prever o caso de o jogador ser o Lucky Luke (precisamente ele! - que dispara mais rápido 

que a própria sombra…): tendo já digitado Start, Join ou Abort, e antes de chegar accept, invoca um desses três 

comandos… 

O Cliente procede como em closed - com a excepção de que, agora, já não envia connect nem arma o Tc. 

- em wAccept, o jogador pode digitar Play. 

- o Cliente apresenta Sorry no ecran; 

- em wAccept, o Cliente pode receber accept. Cancela Tc e: 

Se a AList não estiver vazia, isto é, o jogador digitou um ou mais Abort (p11):


- por cada GId nela salvaguardado, envia a correspondente cAbort-Pdu; 

- para cada GId que for um Jogo local (na prática, um que tenha sido associado a um Join), corre Abort 

sobre ele; 

- enfim, esvazia a AList; 

Se Gc>0 (p17), o Cliente corre accept em cada um dos Gs: 

- na prática, consoante seja S ou J, assim o Gestor de Jogos envia a cStart-Pdu ou a cJoin-Pdu; 

Na cStart-Pdu, deve inscrever-se o pertinente Gf, que deve ser ecoado pelo Servidor na 

correspondente sStart-Pdu 

Enfim: 

- se algum dos Role não é -1 (p17), transita para cConnected; 

- caso contrário (~p17), envia close, efectua cInit (inicia o Cliente) e transita para closed. 

- em wAccept, o Timeout pode expirar (o accept não vem ou atrasou-se demasiado): 

Imprime um Warning, envia close, corre Abort em cada um dos Gs{}, efectua cInit e transita para closed; 

- em wAccept, pode receber-se close: 

Cancela Tc, imprime um Warning, corre Abort em cada um dos Gs{}, efectua cInit e transita para closed; 

- em cConnected, o jogador pode digitar Start, Join ou Abort. 

O Cliente procede como em wAccept; no caso de Abort envia de imediato a cAbort-Pdu. 

- em cConnected, pode receber-se close: 

O Cliente imprime um Warning, corre Abort em cada um dos Gs{}, efectua cInit e transita para closed; 

- em cConnected, o jogador pode digitar Play. 

- se o Jogo referido não está em curso (p13), apresenta Sorry no ecran; caso contrário, corre Play nesse GId; 

- em cConnected, podem ser recebidas sStart-Pdu e sJoin-Pdu, sPlay-Pdu e sBoard-Pdu e sAbort-Pdu e sError- 

Pdu; 

- se a sJoin-Pdu, sPlay-Pdu ou sBoard-Pdu se referir a GId que não está em curso localmente (p13), é 

ignorada; caso contrário, corre-se essa PDU sobre esse GId; 

- se sStart-Pdu se referir a Gf que não está em curso (p22), é ignorada; caso contrário corre-se a sStart-Pdu 

sobre esse Gf; 

- se se receber sAbort-Pdu, 

- se algum GId que transportar ainda estiver em curso, corre-se sAbort-Pdu sobre esse GId; 

- se se receber sError-Pdu, é apresentada a Mensagem no ecran. 

Eventualmente, algumas das Acções submetidas ao Gestor de um Jogo GId (como sejam -Abort e -sBoard) 

poderão sinalizar, com +End, o seu termo. A ser o caso, decrementa-se Gc e fixa-se Role=-1 em GId. 

Diagramas de Estados no Cliente: o Gestor dum Jogo 

A partir dos Diagramas Temporais, o desenho do Gestor dum Jogo num Cliente é pacífico. Antes de mais, 

atribuem-se etiquetas, nas verticais que representam o Cliente, aos momentos de espera, isto é, àqueles que 

precedem eventos significativos. Como ex., em JdG-rVIh re-desenha-se a fig JdG-rVIg (que esquematiza o começo 

dum jogo entre dois jogadores, W e), todavia agora refeita com essas etiquetas (sublinhadas):


Na prática, cada etiqueta acaba por ser o Nome de um Estado; concretamente: 

- antes de Start (ou de Join), ambos os Clientes se encontram no Estado closed; 

- quando o jogador W digita Start, o Cliente invoca connect e transita para wAccept (espera accept); 

- quando o accept chega, o Cliente envia cStart-Pdu e transita para wsStart (espera a sStart-Pdu); 

- com a chegada de sStart-Pdu, o Cliente transita para wsBoard (espera a sBoard-Pdu); 

- quando o jogador E digita Join, o Cliente invoca connect e transita para wAccept (espera accept); 

- quando o accept chega, o Cliente envia cJoin-Pdu e transita para wsJoin (espera a sJoin-Pdu); 

- com a chegada de sJoin-Pdu, o Cliente transita para wPlay (espera uma jogada, Play); 

- quando o jogador E digita uma jogada Play, o Cliente envia cPlay-Pdu e transita para wsPlay; 

- com a chegada de sPlay-Pdu, o Cliente transita para wsBoard; 

- com a chegada de sBoard-Pdu a E, o Cliente mantém-se em wsBoard; 

- com a chegada de sBoard-Pdu a W, o Cliente transita para wPlay; 

- quando o jogador W digita uma jogada Play, o Cliente envia cPlay-Pdu e transita para wsPlay; 

- com a chegada de sPlay-Pdu, o Cliente transita para wsBoard; 

- com a chegada de sBoard-Pdu a W, o Cliente mantém-se em wsBoard; 

- com a chegada de sBoard-Pdu a E, o Cliente transita para wPlay; 

-etc… 

Repare-se: 

- em ambos os Clientes, o envio de connect é acompanhado da transição para wAccept; mas, quando o accept 

chega, W envia cStart-Pdu e E envia cJoin-Pdu. Para diferenciar este comportamento, convém uma variável-de- 

Estado, Role; é iniciada a -1 e, ao ingressar em wAccept, W fixa-a em Role=S e E fixa-a em Role=J; 

- do mesmo modo, com a chegada do tabuleiro, em wsBoard, a vez de jogar virá a caber somente a um dos 

jogadores; para o efeito, convém uma variável-de-Estado, MyTurn; é iniciada a FALSE ou TRUE, consoante Role 

for S ou J, e, sempre que um Cliente recebe o tabuleiro, ela deve mudar de valor.


Com o que fica dito, é pacífico o desenho do Diagrama de Estados correspondente ao Diagrama Temporal 

acima, cf. JdG-rXa: 

Repare-se: 

- o estado inicial é closed; 

- com o comando Start (e pressuposto que já se enviou connect), fixa-se Role e transita-se para wAccept; 

dever-se-á salvaguardar MyName (e, se for o caso de Join, GId); 

- com a chegada de accept, e consoante o valor de Role, envia-se cStart-Pdu ou cJoin-Pdu, e transita-se 

respectivamente para wsStart e wsJoin; 

- e assim por diante… 

Deve sublinhar-se: este é o Diagrama de Estados de um Jogo. Um drogado do Jogo do Galo poderá ter 

embarcado em vários jogos - e a cada um corresponde um Diagrama assim. Num deles, o Cliente poderá encontrarse 

no Estado wPlay e em outro encontrar-se, por ex., em wsBoard ou wsJoin.. 

Entretanto, deve também sublinhar-se: JdG-rXa teve em conta apenas o Diagrama Temporal em JdG-rVIg - 

pelo que se pode temer que esteja incompleto! Para o completar, a filosofia é a mesma: 

- inscrever, nos demais Diagramas Temporais, etiquetas nomeando os Estados - isto é, as situações de espera -, 

e repercutir no Diagrama de Estados acima o comportamento que aqueles Diagramas determinam; 

- de qualquer modo, e porquanto quiçá não se tenham desenhado Diagramas Temporais para todas as situações 

passíveis de ocorrer, repetir até à exaustão a seguinte metodologia: 

a. interrogar-se: para cada Estado, quais os eventos passíveis de ocorrer? 

b. investigar: para cada um desses eventos, qual o comportamento que o Cliente deve observar? 

c. e repercutir no Diagrama de Estados acima esse comportamento. 

Com o que fica dito, será pacífico o desenho final do Gestor de um Jogo em JdG-rXb (no Anexo A.4b): 

Diagramas de Estado no Servidor: o Boss 

Em JdG-rIXd (no Anexo-A.4c), apresenta-se o Diagrama de Estados do Boss para o caso em que: 

- se recebe a cList-Pdu; pelo que é enviada a sGameList-Pdu, com a listagem dos Jogos em Curso: GId e 

respectivos Names; 

Em JdG-rIXe (no Anexo-A.4c), apresenta-se o Diagrama do Boss para os restantes casos: 

- em wConnect, pode receber-se connect de um socket… 

- o Servidor deverá iniciar a respectiva SockGIds e devolver accept; e o Estado dessa conexão deverá 

transitar para sConnected. 

- em sConnected, o Servidor pode receber cStart-Pdu… 

- o Servidor deverá, se já existem 4 jogos em curso (p10), devolver sStart-Pdu(Sorry,Gf);


- caso contrário, deverá determinar o valor GId cujo All[GId].Names[S] esteja vazio e tenha sido menos 

recentemente usado, e correr cStart-Pdu sobre esse GId; 

- em sConnected, o Servidor pode receber cJoin-Pdu… 

- o Servidor deverá, se o GId referido não estiver em curso ou se já forem conhecidos os seus dois jogadores 

(p31), devolver sJoin-Pdu(Sorry); 

- caso contrário, deverá correr cJoin-Pdu sobre esse GId. 

- em sConnected, o Servidor pode receber cPlay-Pdu… 

- o Servidor deverá, se o GId referido não estiver em curso (p32), devolver sJoin-Pdu(Sorry); 

- caso contrário, deverá correr cPlay-Pdu sobre esse GId. 

- em sConnected, o Servidor pode receber cAbort-Pdu… 

O Servidor varre os GIds referidos: para cada um, 

- se não estiver em curso (p36), devolve sError-Pdu(Reason); 

- caso contrário, deverá correr -Abort sobre esse GId; 

- em sConnected, pode receber-se close: 

Varre a SockGIds, procurando Jogos em curso sobre a conexão: por cada um, corre -Abort sobre ele; 

- em sConnected, aquando do processamento de cPlay-Pdu, cAbort-Pdu, expirar do Timer ou close, o Boss 

poderá receber do Gestor de Jogos uma notificação, +End, de que um Jogo acabou. Deverá verificar, para cada uma 

das conexões que o suportam, se ele "era o último Jogo"; se o for (e não estiver ainda fechada), executa close sobre 

essa conexão. 

Diagramas de Estados no Servidor: o Gestor dum Jogo 

Seguindo a mesma filosofia seguida para o Gestor dum Jogo no Cliente, pode agora traçar-se o Diagrama de 

Estados do Gestor dum Jogo no Servidor, cf. JdG-rIXc (no Anexo-A.4c): 

XI - Tabela de Estados do Nível Superior do Jogo do Galo 

Nos Anexos A.4d e A.4e, apresentam-se as Tabelas de Estado do Jogo do Galo - naturalmente extraídas dos 

Diagramas de Estado precedentes. Ocasionalmente, 

- é invocado Sorry, significando que deve ser apresentada uma mensagem de Alerta no ecran; 

- nas quadrículas vazias dever-se-á invocar um procedimento Trace, que deverá inscrever num ficheiro "log" o 

evento ocorrido, para se poder reflectir sobre ele: pode ser um erro a corrigir necessariamente… 

XII - Estrutura das PDUs do Jogo do Galo 

Do que fica dito, será pacífico estruturar as PDUs, cf. Anexo-A.5. 

Elas incluem um conjunto de Campos - cuja estrutura poderá ser, por ex.: 

MyName, Reason: sequências de códigos Ascii de caracteres terminadas por ‘/0’. 

Nota: a adição do PDU-length para efeitos de transparência/delimitação-de-PDUs garante que o receptor sabe 

onde terminam, nomeadamente, a cStart-Pdu e a cJoin-Pdu – pelo que é desnecessário terminar MyName com ‘/0’. 

Enunciado análogo vale para os campos Reason em sStart-Pdu, sJoin-Pdu, sPlay-Pdu e sAbort-Pdu. 

Mas isso já não é bem assim para o caso de sError-Pdu – pois que, em virtude da cAbort-Pdu a que ele se deve, 

pode referir mais que um GId. Neste caso, é mesmo necessário delimitar o campo Reason – intercalando um ‘/0’ 

antes da subsequente sucessão de GIds. 

GId, Gf, Line e Column: um octeto cada um, veiculando um inteiro. 

Nota: esta representação é problemática: o Cliente e o Servidor podem representar inteiros de maneira 

diferente; por ex., 01(16) pode, para um deles, significar o inteiro “1”, e, para o outro, significar "128". Na prática, o


programador-em-C deve recorrer às funções htons (ou htonl) e ntohs (ou ntohl): antes de enviar um inteiro, deve 

convertê-lo na representação “net”, e, após recebê-lo, convertê-lo para a representação “host” local. 

Symbol: o código Ascii de “X” ou “O” 

Board: oferecem-se várias possibilidades; eis algumas delas: 

B.1 Uma sequência de Xs e Os, e Ls (estes últimos para representar casas-Livres). Por ex., o tabuleiro figurado 

em JdG-rVIIb seria representado por LXOLXLLLL: sucessivamente, assinala-se o conteúdo das três casas da 

primeira linha, depois o das três casas da segunda linha, etc.. 

B.2 Uma sequência de trios símbolo-linha-coluna – contemplando apenas as casas já ocupadas. Para o mesmo 

tabuleiro, seria agora: X12O13X22. Este método seria mais eficiente que o anterior só até à terceira jogada, 

exclusive. 

B.3 Uma sequência X[LinhaColuna…]O[LinhaColuna…]. Para o mesmo tabuleiro, seria 

agora X1222O13. Repare-se que isto “funciona” pois nenhuma linha tem o valor O. 

List: Para representar a Listagem dos Jogos já “Started”, uma possibilidade seria: uma 

sucessão de trios (ou apenas tuplos) consistindo em: 

GId, seguido de SName e, eventualmente, do JName 

Será esta representação problemática? Repare-se: os primeiros dois campos recebidos serão GId (um inteiro) e 

SName (terminado por ‘/0’). Que virá a seguir? Se o byte a seguir ao ‘/0’ é um número (entre 1 e 4), então trata-se 

de um novo GId, caso contrário, trata-se do JName. 

Este raciocínio já não é isento de erros se o número máximo de jogos for, por ex., de 256 (e não apenas 4)! É 

que o byte após o ‘/0’ pode então ser interpretado como um número ou como o código Ascii de um caracter (o das 

Maiúsculas estende-se entre 65 e 90)! Para que o Cliente saiba discernir entre os dois significados, há pois que 

acrescentar algo… Discutem-se adiante quatro possibilidades: 

More-Flag: 

No fundo, quando o Cliente acaba de ler o ‘/0’ que finda o primeiro MyName, assalta-o uma dúvida: haverá 

ainda mais algum campo MyName? O Servidor pode esclarecê-lo: logo após o ‘/0’, acrescenta uma flag, com dois 

valores possíveis, ‘1’, e ‘0’, significando respectivamente que há/não-há mais nenhum campo MyName. Então, 

pela inspecção dessa flag, o Cliente sabe se, sim ou não, se deve preparar para ler um segundo campo MyName: 

Concretamente, para veicular a informação GId=2{Costa}GId=3{Luís,Catarina}, poderia enviar-se: 

2 Costa ‘/0’ (MF=)0 3 Luis ‘/0’ (MF=)1 Catarina ‘/0’ 

Field-length: 

Repare-se: acima, é necessário enviar o termina dor ‘/0’: senão, o Cliente não sabe discernir nem a dimensão 

dos campos MyName (no ex., preenchidos com Costa, Luís e Catarina) nem, por consequência, o local onde se 

encontra a More-Flag. Se em nomes de pessoas (sem acentos e outros quiproquós) isso será pacífico, já se torna 

problemático se se enviasse, por ex., a fotografia dos jogadores: poderia acontecer que, no seio daqueles três 

campos, viesse a aparecer o byte ‘/0’ – com a consequência óbvia: uma recepção errónea… Para o evitar, uma 

solução é: preceder MyName de um byte veiculando o seu comprimento. Agora, a PDU para o caso acima seria: 

2 5 Costa 0 3 4 Luis 8 Catarina 

Repare-se: a seguir a “Costa” aparece 0, que significa: o campo seguinte (o segundo MyName) espraia-se por 0 

bytes, isto é: não existe. 

Terminador e Character-stuffing: 

O método anterior de delimitação de um campo sofre de duas vulnerabilidades: 

- por um lado, MyName não pode exceder 255 caracteres; mas isso, dirá o leitor, e com razão, resolve-se 

reservando para o Field-length mais que um byte: por ex., se lhe forem dedicados dois bytes, esse campo poderá 

estender-se até cerca de 64 Kcaracteres… 

- por outro lado, para preencher o Field-length é necessário conhecer de antemão a dimensão do campo em 

questão; ora, isso nem sempre acontece. Ou mais precisamente: para o conhecer, há que gastar um certo tempo –


atrasando portanto o começo do envio da informação. Uma solução é utilizar um caracter terminador a justapor ao 

campo, seja ‘t’. Agora, a PDU para o ex. acima seria: 

2 Costa t t 3 Luis t Catarina t 

Esse método é problemático se o campo em questão (MyName) puder conter esse terminador - a consequência 

será óbvia: uma recepção errónea…Para o superar, uma solução é: quando o ‘t’ deve ser interpretado como 

terminador, e apenas então, o Servidor deve precedê-lo de um sinal, seja ‘s’. Mas, dir-se-á: e se aquele campo 

contiver precisamente a sequência ‘st’? – é que a consequência será óbvia: uma recepção errónea… Uma solução, 

dita de character stuffing, é: se um ‘s’ deve ser entendido como byte de dados (e não como byte de sinalização), ele 

deve ser duplicado. Com isso, a PDU para o ex. acima seria, antes: 

2 Cossta st st 3 Luiss st Catarina st 

Repare-se: os 's' em Costa e Luis aparecem em duplicado; e o 't' em Catarina não é precedido de 's'. O Cliente 

seguirá uma filosofia óbvia: se o ‘s’ aparecer duplicado, considera o primeiro como sendo “de dados”, e remove o 

segundo; mas, se não aparecer duplicado, deve ser entendido como “sinal” precedendo o terminador. 

Field-type: 

Os três métodos acima concernem a dimensão do campo JName. Mas há um ponto de vista alternativo: no 

fundo, o Cliente pretende saber se o byte após o primeiro MyName deve ser lido como GId ou como início de outro 

MyName; por outras palavras, o Cliente pretende saber qual o tipo de informação a ler: inteiro ou caracter? Eis 

uma solução: preceder cada valor de um Field-type. 

No exemplo entre mãos, podem definir-se os seguintes Field-types: 

GId-type=1 SName-type=2 JName-type=3 

Então, para veicular a informação GId=2{Costa}GId=3{Luís,Catarina], poderia enviar-se 

GId-type GId SName-type Length Value JName-type Length Value 

1 2 2 5 Costa 

1 3 2 4 Luis 3 8 Catarina 

O Cliente limita-se a, antes de recolher um valor, determinar o que está lendo: um GId ou um MyName… 

Abra-se um parêntesis: os campos MyName acabam por ser representados por uma assim denominada 

estrutura TLV (Type/Lenth/Value). Intui-se que será a mais indicada para situações em que os campos não 

seguem necessariamente uma ordem pré-definida ou são opcionais. 

XIII - Apêndice: o Comando List 

O comando List (fig JdG-rVIe) foi tratado admitindo que o número máximo de Jogos em curso é 4 - pelo que a 

listagem enviada numa sGameList-Pdu cabe dentro dos limites aceitáveis por UDP (algo menos que 64 Kbytes)… 

É então legítima a pergunta: e se aquele número puder ser bem maior? Claramente, a resposta por parte do Servidor 

terá que se repartir por várias PDUs… - e, a manter-se o suporte "UDP", isso obriga a cuidados extra: quiçá nem 

todas elas cheguem ao Cliente, e as que o fizerem talvez não o façam pela ordem em que foram transmitidas... 

É importante proporcionar ao jogador a maior rapidez na visualização da listagem; para o efeito, convirá que, à 

medida que as PDUs cheguem ao Cliente, sejam de imediato apresentadas no ecran - sem por conseguinte esperar 

por aquelas que foram transmitidas anteriormente. Para que essa listagem seja coerente, cada PDU deverá veicular 

um conjunto fechado de Jogos - em vez de, a respeito de um GId, uma PDU referir o SName, e o respectivo 

JName seja referido somente na PDU seguinte: é que não se sabe se alguma das PDUs se perderá pelo caminho… 

Para o efeito, deve ser o Elemento de Utilizador - que não o Módulo de Comunicações - a repartir a Listagem 

em várias PDUs (fig JdG-rVIi )…


E há que definir a estrutura da sGameList-Pdu, por ex., 

- o código da sGameList-Pdu, 12; 

- uma sequência de: 

- um GId, sob a forma de um inteiro; 

- um SName-Length, representando o comprimento do SName; 

- esse SName; 

- um JName-Length, representando o comprimento do JName associado ao Join; 

- esse JName (se o JName-length for não-nulo); 

- uma Flag "MG", que será "1" se, e apenas se, a seguir ao Jogo corrente, se segue a especificação de 

mais outro Jogo. 

Eis um exemplo: 

12 4 5 Costa 8 Catarina 1 5 4 Joao 0 1 6 4 Luis 5 Maria 0 

Nota: o enunciado postula que a Listagem seja suportada por UDP; se fora suportada por TCP, poder-se-ia 

acrescentar às PDUs algo que ajudasse o Cliente a perceber quando é que a Listagem termina. Da discussão 

precedente, adivinham-se quatro possibilidades: 

- terminar cada sGameList-Pdu com uma MoreFlag - que só é 0 na última sGameList-Pdu… 

- incluir na primeira sGameList-Pdu um campo veiculando o número de sGameList-Pdu que se irão enviar… 

- findar a última sGameList-Pdu com um terminador de listagem, seja 'T', sinalizá-lo com 's' - e aplicar 

character stuffing… 

- conceber um novo tipo de PDUs, seja sEnd-Pdu, com o código 13, sem quaisquer parâmetros - e enviá-la logo 

após a última sGameList-Pdu…


Anexo A: Especificação do Jogo do Galo 

A.1: Arquitectura de Comunicações 

A arquitectura de comunicações do Jogo do Galo desdobra-se em (fig JdG-rIVa): 

- um nível inferior, materializado no par TCP/UDP, a cargo do Sistema Operativo; 

- um nível Transparência, ou de delimitação de PDUs, que converte invocações ("ecos" de PLAY.req, 

PLAY.ind, etc.) orientadas às PDUs em invocações (write, read) orientadas ao "Fluxo de octetos" - e vice-versa; 

- o Módulo de Comunicações, que empacota as PDUs e as passa ao nível Transparência - e vice-versa; 

- o elemento utilizador, no nível superior, que faz a interface: 

- no Cliente, com o terminal e o ecran através de que o Utilizador interage; 

- no Servidor, com o sistema de ficheiros onde se regista a evolução dos eventos; 

- em ambos os casos, com as Comunicações - invocando PLAY.req, PLAY.ind, etc... 

A.2: Primitivas de Comunicação 

Com. Primitiva .req por: Parâmetros 

Start START.req, START.ind Cliente MyName, Gf 

START.rsp, START.cnf Gf, Resultado: Ok, GId, YourSymbol 

Ou Gf, Sorry + Reason] 

Join JOIN.req, JOIN.ind Cliente MyName, GId 

JOIN.rsp, JOIN.cnf GId, Resultado: Ok, YourSymbol: X 

Ou GId, Sorry [+ Reason] 

Play PLAY.req, PLAY.ind Cliente GId, Line, Column 

PLAY.rsp, PLAY.cnf GId, Resultado: Ok 

Ou GId, Sorry [+ Reason] 

BOARD.req, BOARD.ind Servidor GId, Posição do Jogo; 

List LIST.req, LIST.ind 

(para os dois jogadores) Continue ou End + Winner: Name ou None 

Cliente 

GAMELIST.req, GAMELIST.ind Servidor None ou GId/Name(s) [,…] 

Abort ABORT.req, ABORT.ind Cliente GId [,…] 

ABORT.req, ABORT.ind Servidor 

(para os dois jogadores) 

GId 

ERROR.req, ERROR.ind Servidor GId, Reason 

A.3 - Diagramas Temporais 

Start: 

Start é executado sobre TCP. Existem dois cenários possíveis para a sua execução: 

1. já existe uma conexão-TCP estabelecida entre o Cliente e o Servidor. 

Para tal cenário, apresentam-se dois diagramas: em todos, começa-se por executar, no Cliente, START.req; 

ela é "ecoada" no Servidor como START.ind.


JdG-rVIf: existe sucesso em Start: O Servidor responde com START.rsp(Ok), que é "ecoada" no Cliente 

como START.cnf(Ok). 

JdG-rVIb: não existe sucesso em Start: No entrementes, ocorreu um crash do Servidor, pelo que o Cliente, 

ao detectá-lo, gera localmente Sorry. 

2. ainda não existe nenhuma conexão entre o Cliente e o Servidor. 

Para tal cenário, apresentam-se dois diagramas; em ambos, começa-se por estabelecer uma conexão-TCP 

entre o Cliente e o Servidor. 

JdG-rVIc: o accept é devolvido e recebido - e executa-se START.req… 

JdG-rVId: o Servidor não está ligado… pelo que não chega qualquer accept; este cenário pode ser detectado 

com um relógio, armado aquando da leitura do Start: ao fim de um certo período de tempo, ele expira - e pode 

dar-se a (má) notícia ao sócio… 

(Bem entendido, se o accept chegar, aquele relógio é cancelado) 

Join: 

Join é também executado sobre TCP. Os respectivos Diagramas acabam por ser análogos aos de Start. 

Play: 

Play é também executado sobre TCP - e somente pode ser executado sobre um Jogo já lançado com Start + 

Join. Deve ser pacífico traçar os respectivos Diagramas…


JdG-rVIg: O Diagrama representa o começo de um jogo entre dois jogadores: um deles invoca Start, o outro 

invoca Join. O último faz então uma jogada (Play) - após o que o tabuleiro é divulgado a ambos; então, o primeiro 

digita, também ele, a sua jogada (Play)… Adiante-se que se utiliza extBoard para sinalizar uma decisão (o envio 

do Tabuleiro) desencadeada por um evento externo ao par Client/Servidor afectado por essa decisão 

List: 

List é executado sobre UDP. 

JdG-rVIe: existe sucesso em List. 

JdG-rVIj: existe insucesso em List. O Servidor ainda não foi activado, pelo que o Cliente não aprsenta 

qualquer listagem. 

Abort: 

Abort é também executado sobre TCP. Os Diagramas que se seguem contemplam alguns cenários possíveis. 

Adiante-se que neles se utiliza extAbort para sinalizar uma decisão do Servidor (nomeadamente, o envio de 

sAbort-Pdu) desencadeada por um evento externo ao par Client/Servidor afectado por essa decisão. 

JdG-rVIIIa: Um dos jogadores, quiçá por achar que houve empate (ou porque está em má posição e não gosta 

de perder…) invoca Abort. O Servidor sinaliza-o ao outro jogador.


JdG-rVIIIb: Algum "brincalhão", que não um dos fulanos jogando, faz-lhes uma partida de Carnaval: invoca 

Abort. Na prática, o Servidor recebe uma cAbort-Pdu, e sinaliza-o aos Clientes desses fulanos. 

JdG-rVIIIc: No decorrer de um jogo, expira o Timeout após a última PDU recebida no Servidor; este sinaliza-o 

aos Clientes dos dois jogadores. 

JdG-rVIIId: Alguém, que não um dos jogadores, invoca Abort - mas sem sucesso (por ex., porque o Jogo 

referido já havia terminado, entretanto). O Servidor sinaliza-lhe isso mesmo. 

JdG-rVIIIe: O Servidor sofre um crash. Os Clientes (já com conexões estabelecidas com o Servidor), ao 

detectá-lo, geram localmente a Indicação de Aborto do Jog 

Eventos "de cima" 

Eventos "de baixo" 

Chegada de PDUs 

A.4a: Lista de Eventos 

Cliente Servidor 

Comandos do Jogador: 

Start, Join, Abort, Play, List 

sStart-Pdu, sJoin-Pdu 

sPlay-Pdu, sBoard-Pdu 

sGameList-Pdu 

sAbort-Pdu, sError-Pdu 

Tomada de Decisões: 

Ok ou Sorry+Reason 

Board, GameList, Error 

cStart-Pdu, cJoin-Pdu, 

cPlay-Pdu, cList-Pdu, 

cAbort-Pdu 

Sinais oriundos do TCP accept, close connect, close 

Eventos "internos" Iniciação do Cliente Iniciação do Servidor 

Relógio TConnect 

Relógio TTTL 

End, SIGPIPE 

End, SIGPIPE


JdG- rXc e JdG-rXd: o Boss no Cliente 

JdG-rXb: o Gestor de um Jogo no Cliente 

A.4b: Diagramas de Estado do Cliente 

Variáveis de Estado: 

- Gc: contabiliza o número de Jogos que o Cliente tem em curso (pode ter até 4); 

- uma Tabela de Descritores, Gs[4], dos Jogos em curso (até um máximo de 4); memoriza, por cada um, 

- Role, iniciado a -1, que conterá S=0 ou J=1 consoante tenha sido executado Start ou Join; 

- Name, que será o argumento MyName associado a Start ou Join; 

- o GId (GameId) atribuído pelo Servidor; 

- o Símbolo local (X ou O) atribuído pelo Servidor; 

- MyTurn, que será TRUE se e somente se a próxima Jogada couber ao jogador local. 

- State, que regista o Estado actual do Jogo. 

- uma Lista, AList, contendo os GIds associados a comandos Abort;


- ListReqed: será TRUE se e somente se foi enviada a cList-Pdu; 

Inicialmente, há que invocar-se cInit, que deverá fixar Gc=0, ListReqed=FALSE, e iniciar AList e Gs. 

Predicados: 

- p10, valor lógico da afirmação "Gc é igual a 4"; 

- p11, valor lógico de "AList não está vazia"; 

- p12, valor lógico de "um GId assinalado num Abort ou sAbort-Pdu é local"; 

- p13, valor lógico de "GId assinalado em Play ou s-Pdu não está em curso"; 

- p14, valor lógico de "Line assinalada em Play inválida"; 

- p15, valor lógico de "Column assinalada em Play inválida "; 

- p17, valor lógico de "após o cicloA,existem algum Gs{} com Role≠-1"; 

- end, valor lógico de "a jogada termina o Jogo"; 

- p19, valor lógico de "o GId assinalado num Join não é válido"; 

- p21, valor lógico de "MyName assinalado num Join não é válido"; 

- p22, valor lógico de "Gf assinalado em sStart-Pdu não está em curso"; 

- p38, valor lógico de "não há Jogos em curso sobre esta conexão"; 

JdG-rIXd e JdG-rIXe: o Boss no Servidor 

JdG-rIXc: o Gestor de um Jogo no Servidor 

A.4c: Diagramas de Estado do Servidor 

Variáveis de Estado: 

- Gc: contabiliza o número de Jogos que o Servidor tem em curso (pode ter até 4);


- uma Tabela de Descritores, All[4], dos Jogos em curso (até um máximo de 4); memoriza, por cada um, 

- Names [S..J] que serão os argumentos MyName associados a Start e Join, 

no que segue abreviados para SName e JName, respectivamente; 

- Sockets [SSock.. JSock] que serão os identificadores das conexões por onde chegaram cStart e cJoin; 

- STurn, que será SSock ou JSock consoante a próxima Jogada couber ao emissor do Start ou ao do Join. 

- Board, a posição actual do Tabuleiro. 

- uma Lista, SockGIds, por cada Conexão estabelecida, referindo os GIds que a utilizam; 

Inicialmente, deve invocar-se o procedimento sInit, que deverá fixar Gc=0. 

Predicados: 

- p10, valor lógico da afirmação "Gc é igual a 4"; 

- p31, valor lógico de "o GId assinalado num cJoin-Pdu não é válido"; 

- p32, valor lógico de "o GId assinalado num cPlay-Pdu não é válido"; 

- p33, valor lógico de "Line assinalada em cPlay-Pdu inválida"; 

- p34, valor lógico de "Column assinalada em cPlay-Pdu inválida "; 

- p35, valor lógico de "não é a vez deste jogador" ou seja: "Sock ≠ STurn" ; 

- p36, valor lógico de "o GId assinalado em cAbort-Pdu não está em curso"; 

- p37, valor lógico de "a conexão para o Cliente deixou de ter Jogos em curso"; 

- p38, valor lógico de "não há Jogos em curso sobre esta conexão"; 

Boss no Cliente: 

A.4d: Tabelas de Estado do Cliente 

closed WAccept cConnected 

Start Gc++,Tc,connect,-Start{Gf} Gc++,-Start{Gf} Gc++,-Start{Gf} 

Join Gc++,Tc,connect,-Join{Gf} Gc++,-Join{Gf} Gc++,-Join{Gf} 

Play Sorry Sorry p13:Sorry 

~p13:-Play{GId} 

Abort AList++{GId},Tc,connect AList++{GId} cAbort; 

p12:-Abort{GId} 

sStartPdu -p22:-sStart{Gf} 

sJoinPdu -p13:-sJoin{GId} 

sPlayPdu -p13:-sPlay{GId} 

sBoardPdu -p13:-sBoard{GId} 

sAbortPdu -p38:Abort{GId} 

sErrorPdu Sorry 

accept ~Tc; 

p11: ciclo{AList}:{cAbort}; 

p17:ciclo{Gs}:-accept 

⇒cConnected 

-p17:close 

close 

⇒closed 

~Tc;Sorry;ciclo{Gs}:-Abort; 

⇒closed 

TConnect Sorry; ciclo{Gs}:-Abort; close; 

⇒closed 

Estado do Boss: Qualquer 

List ListRqed=T,cListPdu 

Sorry; 

⇒closed


Gestor dum Jogo {Gf/GId} no Cliente: 

closed wAccept 

accept Role==J: cJoin 

⇒wsJoin 

Role==S: cStart 

⇒wsStart 

Start Role{Gf}=S 

⇒wAccept 

Join Role{Gf}=J 

⇒wAccept 

Abort +End 

⇒closed 

wsStart wsJoin wPlay wsPlay wsBoard 

Play Sorry p33∨p34:Sorry 

~p33∧~p34:cPlay 

⇒wsPlay 

Sorry Sorry 

sStart Ok: MyTurn=F 

⇒wsBoard 

Sorry: +End 

⇒closed 

sJoin Ok:MyTurn=T 

⇒wPlay 

Sorry: +End 

⇒closed 

sPlay Ok: 

⇒wsBoard 

Sorry: 

⇒wPlay 

sBoard end:+End 

⇒closed 

MyTurn:MyTurn=F 

⇒wsBoard 

~MyTurn:MyTurn=T 

⇒wPlay 

Abort +End 

+End 

+End 

+End +End 

⇒closed ⇒closed ⇒closed ⇒closed ⇒closed 

A.4e: Tabelas de Estado do Servidor 

Adiante, apresentam-se várias Tabelas. Adiante-se que, na coluna à esquerda, as PDUs (e close) vêem 

acompanhadas de uma referência à conexão por onde chegaram ao Servidor). 

Boss no Servidor: 

wcStart sConnected 

cStart 

p10:sStart{SSock,Gf,Sorry,Reason} 

{SSock} 

~p10: Gc++,-cStart{GId,SSock} 

cJoin 

{JSock} 

p31:sJoin{JSock,GId,Sorry,Reason} 

~p31:-cJoin{GId,JSock} 

cPlay 

p32:sPlay{Sock,GId,Sorry,Reason} 

{Sock} 

~p32: -cPlay {Sock,GId} 

cList sGameList {GameList} sGameList{GameList} 

connect Accept


close 

{Sock} 

cAbort 

{Sock} 

Gestor dum Jogo {GId} no Servidor: 

⇒sConnected 

ciclo{SockGIds}: -Abort{Sock,GId} 

⇒wcStart 

ciclo{GIds em cAbort}: 

p36:sError{Sock,Reason,GId} 

~p36: -Abort{Sock,GId} 

wcStart wcJoin wcPlay 

-cStart 

{SSock} 

sStart{SSock,Ok},TTTL ⇒wcJoin 

-cJoin 

{JSock} 

sJoin{JSock,Ok},STurn=J Sock,TTTL ⇒wcPlay 

-cPlay 

sPlay{Sock,Sorry} Sock≠STurn: sPlay{Sock,GId,Sorry} 

{Sock} 

Sock==STurn: 

end: ~TTTL, sPlay{Sock,GId,Ok}, 

sBoard{SSock..JSock,GId,end}, +End 

⇒wcStart 

~end: sPlay{Sock,GId,Ok}, 

sBoard{SSock..JSock,GId,~end}, 

STurn =~STurn,TTTL 

TTTL sAbort,+End {GId} 

sAbort{SSock..JSock,GId}, +End 

⇒wcStart 

⇒wcStart 

-Abort 

{Sock} 

~SSock: ~TTTL, sAbort{SSock}, +End 

⇒wcStart 

~TTTL; +End, 

~SSock: sAbort{SSock,GId} ~JSock: sAbort{JSock,GId} 

⇒wcStart 

A5: Estrutura das PDUs 

PDU Cód Parâmetros PDU Cód Parâmetros 

cStart 1 Gf MyName 

sStart 2 Gf GId Symbol 

cJoin 3 GId MyName 

cAbort 5 GId GId… 

cPlay 8 GId Line Column 

sJoin 

2 Gf 0 Reason 

4 GId 1 Symbol 

4 GId 0 Reason 

sAbort 6 GId Reason 

sError 7 Reason GId GId… 

sPlay 9 GId Sorry Reason 

9 GId Ok 

sBoard 10 GId Board 

cList 11 sGameList 12 GameList


Anexo B: Codificação do Jogo do Galo 

Convirá recapitular a metodologia percorrida a propósito do desenho do "Jogo do Galo": 

- num primeiro passo, abordou-se a sua Arquitectura de Comunicações… 

e, logo de seguida, a Arquitectura Modular do Elemento de Utilizador; 

- o passo seguinte centrou-se num elenco das Primitivas de Comunicação… 

e no desenho dos respectivos Diagramas Temporais - apresentando as situações normais, e outras não tão 

normais assim: crashs, etc.. 

- a partir daí, "deduziu-se" um conjunto de Diagramas Temporais… 

e, deles, chegou-se enfim às Tabelas de Estado. 

Quando - e somente quando! - tais Tabelas estiverem especificadas, será hora de passar à codificação do 

protocolo nalguma linguagem de programação! Atalhos eventualmente tomados (como sejam a codificação antes 

da especificação) são sinónimo de desperdício de tempo, mormente na fase de debug/teste… 

A codificação faz-se a partir das Tabelas de Estado! Adiante, e para não dispersar a atenção, a discussão ir-se-á 

centrar na Tabela do Gestor dum Jogo {GId} no Servidor (no Anexo A.4e); fica todavia subentendido: para 

completar o desenho de toda a Aplicação, é preciso, uma a uma, atender a todas as Tabelas a que se chegou! 

B.1: Acções Elementares 

Um relance de olhos àquela Tabela de Estados permite fazer um elenco das assim designadas Acções 

elementares: aparecem no seio das quadrículas, e são assim chamadas por não serem redutíveis a outras mais 

elementares. São elas: 

Acção Elementar Significado Parâmetros 

sStart Preencher e enviar a sStart-PDU Socket, Gf, Resultado [+Reason ou GId+Symbol] 

sJoin Preencher e enviar a sJoin-PDU Socket, GId, Resultado [+Reason ou Symbol] 

sPlay Preencher e enviar a sPlay-PDU Socket, GId, Resultado [+Reason] 

sBoard Preencher e enviar a sBoard-PDU Socket, GId, Board [+end] 

sAbort Preencher e enviar a sAbort-PDU Socket, GId, Reason 

TTTL Armar o relogio TimeToLive GId 

~TTTL Cancelar o relogio TimeToLive GId 

+End Sinalizar ao Boss o termo do Jogo 

Uma primeira etapa na codificação consiste, precisamente, em estabelecer, par i passu, um elenco de 

procedimentos elementares, um para cada uma das supracitadas Acções Elementares. No caso, e na suposição de se 

utilizar a linguagem-C, ele poderá resolver-se nos procedimentos: 

int sStart ( Socket, Gf, Result, Reason, GId, Symbol ) ; 

int sJoin ( Socket, GId, Result, Reason, Symbol ) ; 

int sPlay ( Socket, Resultado , Reason ) ; 

int sBoard ( Socket, Board ) ; 

int sAbort ( Socket, GId, Reason) ; 

int FireTTL ( GId ) ; 

int CancelTTL ( GId ) ; 

Um ponto obrigatório nesta etapa - porquanto há que codificar sStart, sJoin, etc. - é o estabelecimento definitivo 

da estrutura das PDUs - se é que isso ainda não foi feito. Um outro ponto é escrever aqueles procedimentos 

elementares recorrendo: 

- às primitivas oferecidas pelo nível inferior (no caso, sendto e write)… 

- e (nomeadamente nos casos que envolvem a gestão do relógio) às chamadas ao sistema operativo específicas 

ao computador em que se há-de executar o protocolo. 

B.2: Acções Atómicas: 

Codificadas as acções elementares, é altura de considerar aquilo que se poderá designar de Acções Atómicas: 

acções que preenchem cada uma das quadrículas da Tabela em causa, e assim chamadas por não deverem nunca


ser interrompidas. Pressuposto que no estado-S acontece o evento-E, as correspondentes acções a tomar devem ser 

executadas e o estado-seguinte assumido - sem quebra do fluxo de controlo do programa: somente depois será hora 

de atender a algum outro evento. 

Na prática, ir-se-ão constituir tantas Acções Atómicas quantas as quadrículas da Tabela de Estados. Ei-las, 

devendo o leitor reparar no nome escolhido para as designar: sempre o Nome-dum-Evento e o Nome-dum-Estado - 

unidos pela partícula Over. 

wcStart wcJoin wcPlay 

-cStart cStartOverwcStart cStartOverwcJoin cStartOverwcPlay 

-cJoin cJoinOverwcStart cJoinOverwcJoin cJoinOverwcPlay 

-cPlay cPlayOverwcStart cPlayOverwcJoin cPlayOverwcPlay 

TTTL TTLOverwcStart TTLOverwcJoin TTLOverwcPlay 

-Abort AbortOverwcStart AbortOverwcJoin AbortOverwcPlay 

O passo seguinte intui-se: trata-se de, quadrícula a quadrícula, elaborar as Acções Atómicas a partir dos 

verdadeiros tijolos que são as Acções Elementares; chegar-se-á a 15 procedimentos: 

int cStartOverwcStart ( ) 

{sStart (S Sock, Gf, Ok, NULL , GId, Symbol ) ; FireTTL ( GId ) ; State=wcJoin ; return (0)} 

int cJoinOverwcJoin ( ) 

{sJoin (JSock, GId, Ok, Symbol ) ; STurn= JSock; FireTTL ( GId ) ; State=wcPlay ; return (0)} 

int AbortOverwcJoin ( ) 

{if ( Sock != SSock) { 

sAbort (Sock, GId, Reason) ; CancelTTL ( GId ) ; State=wcStart ; return ( End ) ; }} 

etc. 

Por mor de simplificação, foram omitidos alguns detalhes, nomeadamente os Argumentos dos procedimentos. 

Entretanto, repare o leitor: a terminar cada um deles, e quando existe mudança de Estado para um outro Estado, 

ocorre uma instrução da forma genérica State=NextState. 

B.3: O Núcleo do Protocolo 

Codificadas as Acções do protocolo, é hora de abordar o núcleo (kernel). Será pacífico entendê-lo como um 

ciclo "eterno"… Por cada iteração, 

- começa-se por aguardar o próximo evento; 

- acontecido algum evento, determina-se a Acção Atómica a tomar quando acontece o evento sucedido; 

- invoca-se essa Acção; 

- no final, volta-se a aguardar o próximo evento… 

Em linguagem-C, ter-se-ia algo do género: 

gKeepGoing = TRUE ; 

do { /* Ciclo eterno, até gKeepGoing==FALSE */ 

ActiveSocketCount = WaitNextEvent ( ) ; /* Aguarda o proximo evento */ 

Action = GetHandler ( ActiveSocketCount , & Off ) ; /* Determina a Acção a executar */ 

if ( Action ) RetVal = Action ( & Off ) ; /* Executa a Acção Atomica */ 

} while ( gKeepGoing ) ; 

Adiante, aprofunda-se esta abordagem. Em particular, no Kernel constam dois novos procedimentos: 

WaitNextEvent e GetHandler. Como codificá-los? 

B.4: WaitNextEvent 

WaitNextEvent pode codificar-se de uma maneira assaz simples: mediante a invocação de uma chamada ao 

Sistema Operativo, select…


ActiveSocketCount = select ( Width , & ReadFds , NULL , NULL , TimeOut ) ; 

Na prática, está-se requerendo ao Sistema Operativo que bloqueie o processo: ele fica suspenso até que ocorra 

um evento significativo - ou, mais formalmente: até que fique "ready" um "file-descriptor", no sentido de que se 

pode proceder a "read" nesse file-descriptor sem temer ficar bloqueado. O tempo de espera pode ser indefinido ou 

limitado por um TimeOut. A instrução após o select é executada somente após tal evento ocorrer. Tais filedescriptors 

podem ser os do teclado, de sockets ou pipes. 

B.5: Handler de um Evento: 

Após WaitNextEvent, o Kernel invoca GetHandler. Considere-se, por exemplo, que o evento ocorrido 

foi a chegada de uma PDU cStart; acontece que WaitNextEvent apenas informa que chegou mais uma PDU – 

porém sem discernir qual foi! Há, pois, que, primeiro que tudo, analisar essa PDU - para saber de que tipo é –, e 

somente depois se poderá invocar o pertinente Procedimento (no caso, cStartOver… )… Por outras palavras: as 

Acções Atómicas acima não podem ser invocadas directamente aquando da ocorrência de um evento – há que fazêlo 

a partir dum procedimento genérico de tratamento desse evento, designemo-lo de Handler do evento, como seja: 

- OnUserCommand, Handler de um comando do Utilizador (Start, Join, Abort, Play, List); 

- OnUDPData, Handler de uma PDU chegando por um socket-UDP; 

- OnConnect, Handler de um connect (chegando ao socket-listen do Servidor); 

- OnAccept, Handler de um accept (chegando ao socket do Cliente por onde se emitiu connect); 

- OnTCPData, Handler de uma PDU chegando por um socket-TCP (cStart, sStart; etc.); 

- OnTimeout, Handler do expirar de um relógio. 

- OnSignal, Handler de um signal (SIGINT, SGALRM, SIGPIPE ou outro). 

Intui-se então que GetHandler devolve um destes Handlers – e que é ele quem vem a invocar a pertinente 

Acção Atómica. 

B.6: GetHandler 

GetHandler pode codificar-se de uma maneira assaz simples: mediante um Teste ao valor de retorno de 

select, ActiveSocketCount: 

- se for 0, isso significa tão somente que, desde que se invocou select, passou um tempo TimeOut - sem que 

nenhum dos file-descriptors tenha ficado "ready". Conclusão: GetHandler deve devolver OnTimeout. 

- se for -1, e errno!= EINTR, então houve erro; mas, se errno=EINTR, então houve uma interrupção - de que o 

expirar do relógio (posto a correr com alarm) é exemplo. Conclusão: GetHandler pode devolver NULL - ou 

algo mais preciso, com a designação genérica OnErr ou OnEintr… 

- se 1≤ ActiveSocketCount, e estiver On o bit em ReadFds correspondente ao file-descriptor do teclado, 

isso significa que alguém premiu o teclado. Conclusão: GetHandler deve devolver OnUserCommand. 

- se 1≤ ActiveSocketCount, e estiver On o bit em ReadFds correspondente ao file-descriptor de algum 

socket, isso significa que houve acitividade nesse socket: chegou algum Segmento da Internet (ou o socket ficou 

closed). Conclusão: GetHandler deve devolver, consoante o caso: OnUDPData, OnConnect ou OnTCPData… 

- e devolver, em Off, o socket em que houve actividade. 

B.7: Associação de Acções Genéricas a Sockets 

O procedimento select executa-se sobre uma máscara, seja MasterMask, de tamanho Width. Para que as 

coisas aconteçam como se disse, é necessário – antes da invocação de Kernel: 

- um procedimento, seja InitMasterMask, de inicialização dessa máscara; 

- a serem usadas comunicações por UDP, um procedimento, seja StartNetAccess(SOCK_DGRAM), de 

inicialização das comunicações-UDP – que devolva um UDPSocket para tais comunicações; 

- a serem usadas comunicações por TCP, um procedimento, seja StartNetAccess(SOCK_STREAM), de 

inicialização das comunicações-TCP – que devolva um ListenSocket para servir eventuais connects; 

- por cada posição na máscara a usar, uma instrução, seja AddToMasterMask, que a associe a uma das Acções 

de inicialização supracitadas; eis exemplos:


AddToMasterMask ( gKeyboard , OnUserCommand , … ) ; 

AddToMasterMask ( UDPSocket , OnUDPData , … ) ; 

AddToMasterMask ( ListenSocket , OnConnect , … ) ; 

em que gKeyboard = fileno ( stdin ) ; 

Repare-se que AddToMasterMask pode vir a ser invocada mais tarde, nomeadamente aquando da chegada de 

um connect - a que o Servidor respondeu com accept: 

AddToMasterMask ( DataSocket , OnTCPData , … ) ; 

Com estes cuidados, a chegada de, por exemplo, uma PDU cStart desbloqueia WaitNextEvent; a 

subsequente invocação de GetHandler devolve OnTCPData (e o socket Off em que ela foi recebida); intui-se que 

este deverá começar por invocar read sobre Off, analisar o tipo de PDU e, enfim, invocar a pertinente Acção 

Atómica (que deverá ser uma das seguintes: cStartOverwcStart, cStartOverwcJoin ou cStartOverwcPlay)… 

B.8: A Tabela de Acções Atomicas: 

Detectado o tipo da PDU recebida, intui-se que a eleição da pertinente Acção atómica específica, como seja 

cStartOverwcJoin, envolve um fluxo assaz monótono: 

Determinação de TypeOfPDU (por análise da PDU recebida) ; 

if (TypeOfPDU == cStart ) { 

if ( State == wcStart ) 

cStartOverwcStart ( ) ; 

else if ( State == wcJoin) 

cStartOverwcJoin ( ) ; 

else… 

} 

else if (TypeOfPDU == cJoin ) { 

} 

else if (TypeOfPDU == cPlay ) { 

} 

etc.. 

Em vez da sequência if / else, pode-se utilizar uma sequência de switch / case, como seja: 

switch (TypeOfPDU) { 

case cStart : 

switch ( State ) { 

case wcStart : 

cStartOverwcStart ( ) ; 

break ; 

case wcJoin: 

cStartOverwcJoin ( ) ; 

break ; 

etc.. 

São soluções pouco eficientes e flexíveis. Eis uma mais inteligente e elegante: defina-se um tipo, ActionType: 

typedef int ( * ActionType ) ( void * Parameter ) ; 

Na prática, o ActionType é um procedimento, com um parâmetro do tipo void*, que devolve um int. 

De seguida, define-se uma Tabela de acções atómicas, ActionsTable, com tantas linhas e colunas quantas as que 

a Tabela de Estados em causa tem; cada posição "linha/coluna" dessa ActionsTable será ocupada por um 

procedimento - precisamente aquele que codifica a acção atómica estabelecida na correspondente quadrícula 

"linha/coluna" daquela Tabela de Estados: 

ActionType ActionsTable [ 5 ] [ 3 ] = { 

cStartOverwcStart , cStartOverwcJoin , cStartOverwcPlay , 

cJoinOverwcStart , cJoinOverwcJoin , cJoinOverwcPlay ,


cPlayOverwcStart , cPlayOverwcJoin , cPlayOverwcPlay , 

TTLOverwcStart , TTLOverwcJoin , TTLOverwcPlay , 

AbortOverwcStart , AbortOverwcJoin , AbortOverwcPlay 

} ; 

Atribuem-se de seguida, a cada Estado - wcStart, wcJoin e wcPlay - e Classe-de-Evento - cStart, cJoin, cPlay, 

TTL e Abort - considerados, um valor inteiro entre 0 e, respectivamente, o número-de-colunas-menos-1 e o 

número-de-linhas-menos-1, inclusivé: 

# define wcStart 0 /* Identificação das colunas */ 

# define wcJoin 1 

# define wcPlay 2 

# define cStart 0 /* Identificação das linhas */ 

# define cJoin 1 

# define cPlay 2 

# define TTL 3 

# define Abort 4 

No caso em apreço (recepção de cStart), a Classe-de-Evento é 0; quanto ao Estado, convirá registar a sua 

evolução num descritor associado ao socket Off em causa - iniciado aquando do connect/accept que activou esse 

socket. 

Conhecendo-se o State, então a Acção Atómica a invocar será ActionsTable [ Event ] [ State ] – e não mais é 

necessária a sequência if /else ou switch / case acima… 

B.9: Outras Inicializações: 

Antes de invocar o Kernel, quiçá se tenha que: 

- declarar o Handler do ctrl-C, com, por ex.: SetSignalCatcher ( SIGINT , OnSIGINT ) ; 

- declarar que se deve ignorar um eventual SIGPIPE, com: SetSignalCatcher ( SIGPIPE , SIG_IGN ) ; 

- declarar o Handler do relógio, com SetSignalCatcher ( SIGALRM , OnALRM ) ; 

(O leitor pode aceder a web.ist.utl.pt/~ist10898/public/Projectos/CSources/index.htm, e proceder ao download 

dos ficheiros Signals.c - que codifica SetSignalCatcher – e TCPAndUDPServer.c – que codifica um exemplo de 

OnSIGINT). 

Ademais, será de bom tom inicializar/limpar as estruturas de dados pertinentes a cada socket… 

B.10: Relógios: 

Eventualmente, é preciso recorrer a múltiplos relógios – e todavia o computador encontra-se limitado a um 

único relógio físico. Como contornar esssa limitação? 

Uma solução é construir uma lista de descritores de relógios lançados (mas ainda não-expirados), ordenados 

cronologicamente (pelo instante em que irão expirar) e acedida por quatro procedimentos: 

InitTimerModule, para iniciar aquela lista e registar (com SetSignalCatcher) o Handler do signal 

SIGALRM: ele deve ser tratado por OnTimeout; 

LaunchTimer, para se poder incluir nessa lista um novo descritor, indicando: 

- o instante em que deve expirar, 

- o Procedimento que deve ser invocado se ele expirar, 

- e o eventual Argumento de que esse Procedimento necessitará. 

Eis um exemplo: TimerId = LaunchTimer ( cPeriod , OnTTL , … ) ; 

CancelTimer, para remover um descritor daquela lista 

GetRemainingTime, para indicar quanto tempo falta para o primeiro relógio expirar. 

Resta, apenas, utilizar uma de duas chamadas ao Sistema: select e alarm.


- select deve ser invocado quando podem ser múltiplos os eventos exteriores a que o processo deve reagir, como 

seja a chegada de dados (UDP ou TCP), pedidos de conexão, o expirar de relógios e o premir do teclado... Se não 

ocorrer nenhum dos eventos expectáveis durante o Período de tempo referido no select, ele irá devolver 0 - e 

GetHandler irá devolver OnTimeout... 

- alarm pode ser invocado quando, de facto, um único evento é expectável. Eis algumas possibilidades: 

- a chegada dum Segmento (UDP ou TCP) a um Cliente que não espera por mais nada: antes de recvfrom ou 

read, executa LaunchTimer e alarm, e depois executa CancelTimer. Se não chegar nenhum segmento 

até ao Período de tempo em causa, o relógio irá expirar, e é executado OnTimeout… 

- o expirar dum período máximo de pausa obrigatória: antes de pause, executa LaunchTimer e alarm. Ao 

fim de algum Período de tempo, o relógio irá expirar, e é executado OnTimeout… 

OnTimeout deve varrer a lista de relógios e, para cada um que deveria ter expirado antes do momento actual, 

remove-o da lista e executa o Procedimento associado (registado aquando do LaunchTimer que o criou) 


de ficheiro Timers.c conforme ao que fica dito). 

B.11: Interrupções 

Por "atómica" que se reinvidique uma dada Acção, o que é facto é que ela demorará sempre um tempo maior ou 

menor a chegar ao fim: ela não é nunca instantânea! Por via disso, pode suceder que, enquanto ela se executa, 

venha a acontecer algum evento! Por exemplo: pode o relógio TTTL expirar quando se está processando a chegada 

de uma cPlay-Pdu (e aquele ainda não foi cancelado). Vice-versa, pode chegar uma cPlay-Pdu (que se atrasou) 

quando se está já processando o precedente expirar do relógio - mas, de facto, isto não é problemático: bastará 

invocar select só após o termo da ActionTable[] correspondente ao tratar do TimeOut. 

Com o fito de não quebrar o curso das Acções atómicas, uma solução é: 

- construir uma lista-dos-eventos-pendentes-de-análise; 

- sempre que ocorrer um evento no curso de execução de uma Acção atómica, suspendê-la por instantes, para 

invocar um Handler que registe esse evento naquela lista, e retomar de imediato a execução daquela Acção; 

- no fim, e antes de voltar a aguardar o próximo evento, em select, investigar primeiro se aquela lista está vazia; 

e, se o não estiver, proceder como se o evento que ela regista tivesse acontecido precisamente agora. 

O Kernel ficaria então: 

gKeepGoing = TRUE ; 

do { /* Ciclo eterno, até gKeepGoing==FALSE */ 

ActiveSocketCount = WaitNextEvent ( ) ; /* Aguarda o proximo evento */ 

Action = GetHandler ( ActiveSocketCount , & Off ) ; /* Determina a Acção a executar */ 

if ( Action ) RetVal = Action ( & Off ) ; /* Executa a Acção Atomica */ 

while ( NotEmptyList ( PendingEventsList )) { 

PendingEvent = GetFirstOf (PendingEventsList ) ; 

PendingAction = GetPendingAction (PendingEvent ) ; 

RetVal = PendingAction (& Off ) ; /* Executa a Acção Atomica */ 



B.12: Servindo Acções Longas a múltiplos Clientes… 

Pode a execução de uma Acção Atómica ser por demais demorada. No Servidor, será algo problemático: como 

que um Cliente lhe cativa toda a atenção, enquanto os demais ficam "a ver navios". Pelo que, salvo indicação em 

contrário, um Servidor deve servir os múltiplos Clientes em paralelo, isto é: gastando um slot de tempo com um 

deles, depois um slot (com a mesma duração) com outro, etc., e depois voltar a gastar um slot com o primeiro, um 

slot com o segundo – e assim sucessivamente… Um continuum de ciclos em que por cada um gasta um slot com 

um Cliente - ao invés de acabar o trabalho requisitado pelo primeiro antes de passar ao segundo.

Prof V Vargas, IST Jogo do Galo (Resolução) Page 39 of 39 

Em ordem a lográ-lo, uma praxis comum é desencadear (com fork), por cada Cliente, um processo que lhe seja 

dedicado – relegando para o Sistema Operativo a repartição do tempo do CPU pelas várias Acções concorrentes. 

Mas existe uma alternativa – que é a de fazer confluir todos os Clientes sobre um mesmo Processo – e fazê-lo 

repartir o seu tempo – de uma maneira igualitária - pelos vários Clientes. Isso significa que a execução de uma 

Acção Atómica – se perdurar tempo demasiado! – deve ser repartida por vários slots de tempo. 

Seja, por exemplo, o caso da transmissão de um ficheiro deveras grande. Em vez de o transmitir todo para um 

Cliente, e somente depois ir servir os demais, poder-se-á fazer o seguinte: 

- enviar uma parte dele; 

- invocar um procedimento, seja SetPendingAction ( Off , Action ), que registe que no socket Off há 

uma Action temporariamente suspensa à espera de vez para continuar a executar-se; 

- regressar a WaitNextEvent, todavia configurando o Timeout do select de modo a não exceder 1. 

Então, WaitNextEvent ficará bloqueado não mais que 1. 

Quando WaitNextEvent se desbloquear – e, se for o caso de a razão para tal ter sido um evento significativo, se 

ter executar o pertinente Handler -, dever-se-á varrer todos os sockets activos: se houver algum em que esteja 

registado um Acção suspensa à espera de vez, dever-se-á conceder-lhe mais algum tempo de execução… 

- no final, regressar a WaitNextEvent – todavia configurando novamente o Timeout do select de modo a não 

exceder 1 (se ainda houver alguma Action temporariamente suspensa à espera de vez). 


do ficheiro Kernel.c - que codifica alguns dos procedimentos acima). 

B.13: Comentários a terminar 

Nível Transparência: A Arquitectura de Comunicações inclui um "Nível Transparência". Em termos de 

programação, isso conduz à inserção de código que saiba lidar com o PDU-length - em particular, que invoque a 

pertinente ActionTable somente quando toda a PDU tiver sido já recolhida para um buffer; 

PDUs inválidas: A Arquitectura Modular do Elemento de Utilizador inclui um "Filtro de PDUs"; ele deverá 

conferir a validade de uma PDU provinda de um socket, rejeitando-a se for caso disso. Em termos de programação, 

bastará invocar esse Filtro imediatamente antes de invocar a ActionTable.

Prof V Vargas, IST Jogo do Galo (Resolução) Page 1 of 39 Projecto ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?