Re: Questao 1 da prova

[Nelson Posse Lago <PROTECTED>]

Ja' que ninguem mais comentou, resolvi responder a mim mesmo :-)

Par a venda de lugares numerados, o esquema baseado em um servidor central
me parece inescapavel; afinal, e' preciso que todos os PDVs tenham uma
ideia aproximada do "status" de todos os ingressos numerados, e que esse
"status" possa ser verificado no momento da venda.

Mas a venda de lugares na "geral" pode prescindir do servidor central. O
servidor pode simplesmente distribuir os ingressos entre os PDVs de acordo
com o trafego esperado de cada um deles (por exemplo, calculado a partir
do trafego gerado no jogo anterior): quem vende mais recebe uma "cota"
maior.

Alem de distribuir os ingressos, o servidor fornece, para cada PDV, uma
referencia para um outro PDV "backup": cada PDV comunica cada operacao de
venda nao para o servidor central, mas para seu PDV "backup". O servidor
pode escolher os PDVs "backup" com base no volume de operacoes de cada um:
um PDV que gera muitas operacoes deve ser "backup" de um PDV que gera
poucas operacoes, e vice-versa. Se essa complementaridade nao puder ser
"perfeita" (ou seja, existem 50 PDVs que geram um grande trafego e apenas
20 que geram pouco trafego), alguns PDVs podem usar o proprio servidor
central como seu "backup". Assim, sempre que o sistema estiver
sobrecarregado, um "upgrade" na conectividade ou capacidade do servidor
deve resolver o problema, mas enquanto isso nao acontecer a capacidade
disponivel no sistema estara' sempre com alto grau de utilizacao.

Com isso, cada vez que um ingresso na geral e' vendido, a informacao
referente a essa venda fica armazenada em dois lugares; o trafego de dados
com o servidor e' minimizado e o uso da banda de cada PDV e' otimizado (os
de muito trafego usam a maior parte da sua banda para o trafego de seus
proprios dados e apenas um pouco dela para o trafego de seu "backup";
ja' os de pouco trafego aproveitam sua banda "ociosa" para receber os
dados de "backup" que lhe sao enviados). Provavelmente uma banda bem
pequena em cada PDV (algo como 9600bps) deve ser suficiente.

Ao longo do dia, em momentos em que o trafego de dados esta' relativamente
baixo, os PDVs podem enviar (com compactacao) partes do "log" das suas
operacoes para o servidor central. As operacoes que nao forem enviadas ao
longo do dia podem ser enviadas `a noite. O servidor central deve apenas
ingorar quando receber duas notificacoes de uma mesma operacao (isso deve
acontecer sempre: tanto o PDV que da' origem a uma operacao quanto seu
backup enviam o "log" da operacao).

Se um PDV nao conseguir se comunicar com seu "backup" para enviar o
registro de uma operacao, o PDV envia esse registro para o servidor
central e solicita um novo PDV "backup".  Um PDV com muito pouco trafego
pode ser o "backup", por exemplo, de um PDV de muito trafego e de um
outro de trafego medio. Se nao for possivel registrar uma operacao em um
PDV "backup", o sistema pode estornar a venda ou criar um "log" em papel.

Imagino que seja razoavel supor que o volume de vendas de cada PDV varie
entre os jogos, pois provavelmente as torcidas nao estao distribuidas
geograficamente de forma homogenea. Assim, o volume de vendas de cada PDV
pode ser recalculado periodicamente e essa informacao pode ser enviada
para o servidor central; este, por sua vez, pode provocar a reconfiguracao
dos "backups" dos PDVs de acordo com a necessidade do sistema.

Alem disso, com base nessa mesma informacao, o sistema pode retirar uma
parte dos ingressos ainda disponiveis em um PDV que vendeu menos que o
previsto para coloca-los `a disposicao em um outro PDV que vendeu mais que
o previsto.  PDVs com numero de ingressos muito baixo em relacao ao total
ainda disponivel (o servidor deve ser capaz de manter uma estimativa desse
numero) podem "pedir socorro" ao servidor antes de o servidor perceber
"sozinho" a necessidade de reconfiguracao. Com isso, os ingressos devem
acabar quase simultaneamente em todos os PDVs (imagino que com diferenca
menor que 1h).

Basta garantir que essas trocas de informacoes entre os PDVs e o servidor
nao ocorram simultaneamente (por exemplo, pode-se fazer os PDVs iniciarem
as trocas de mensagens a cada 1h + um intervalo de tempo aleatorio) para
garantirmos que o uso da banda do servidor seja minimo.

Os problemas desse sistema sao:

- cada PDV precisa ser capaz de armazenar estado; mas isso e' quase uma
  necessidade da venda de ingressos numerados, entao nao vejo grande
  problema nisso. Provavelmente o melhor e' colocar uma unidade de
  disquete em cada PDV (ugh! Disquete... ugh! Mas acho que e' o sistema de
  armazenamento persistente mais barato que ha'...).

- Cada PDV precisa estar online o tempo todo; isso provavelmente nao e'
  muito viavel economicamente; o mais adequado, provavelmente, seria
  trabalhar desconectado, armazenando estado, e conectando `a rede
  periodicamente (p. ex., a cada 2 horas) para enviar os dados. O problema
  e' que assim se perde a tolerancia a falhas pedida pelo prof. (mas
  imagino que a relacao custo/beneficio de trabalhar offline valha a pena
  o risco).

- Quando os dados nao sao totalmente enviados para o servidor ao longo do
  dia, o servidor precisa ficar ligado durante a noite. Em tempos de
  racionamento de energia isso pega mal ;-)

- O sistema e' meio complicado!

Bom, e' isso. Nao sei se essa ideia e' uma grande viagem ou se e'
interessante...

Ate' +
Nelson

--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth