Anterior: Introdução |
Próximo: Como instalar o ALua 5.0 |
Uma aplicação ALua é composta por um grupo de processos que executam em múltiplas máquinas e que se comunicam através de uma rede. Entre os processos de uma aplicação existe um espaço de endereçamento único, que é gerenciado por um daemon que deve estar executando em cada máquina. Este daemon age como um intermediário na troca de mensagens entre os processos.
Cabe ao daemon:
Cada processo ALua possui um interpretador Lua e um loop de eventos que gerencia o recebimento de dados da rede de comunicação e da interface do usuário. Os processos se comunicam usando a operação de envio assíncrona. A chegada de uma mensagem é tratada como um evento, isto é, não há uma operação explícita de recebimento de mensagem.
O ALua trata as mensagens como pedaços de código Lua e os executa. Essa execução é feita de forma atômica, ou seja, cada mensagem recebida é executada por completo antes da próxima mensagem ser tratada, eliminando a existência de concorrência em um mesmo processo. Em consequência disso, a estrutura do programa precisa ser especial: os trechos de código devem ser tipicamente pequenos e não bloqueantes para permitir o tratamento das outras mensagens que chegam e evitar a ocorrência de deadlock. Caso uma ação maior seja necessária, o processo pode quebrá-la em partes menores e enviá-las para si mesmo por meio de novas mensagens. A ausência de concorrência simplifica aspectos da programação distribuída, uma vez que não há a necessidade de tratar questões de sincronização dentro de um mesmo processo.
O método de identificação de um processo dentro de uma aplicação pode ser delegado ao processo criador dos processos filhos, ou facultado ao daemon. No primeiro caso, cabe a aplicação especificar nomes distintos para os processos a serem criados. Caso contrário, a identificação de um processo pelo daemon se baseia nas direções do daemon associado no protocolo de endereçamento IPv4. Além destas informações, é utilizado um número que identifica unicamente o processo, dentre os demais que o daemon vier a ter. Por exemplo, suponha um daemon rodando na porta 1234 de uma máquina com IP 192.168.8.2. Possíveis identificadores de processos deste daemon seriam então: 44@192.168.8.2:1234, 68@192.168.8.2:1234, 27@192.168.8.2:1234. Desta maneira, não só cada processo é identificado unicamente, como o identificador passa a conter todas as informações necessárias para localizar o processo.
Stricto-sensu, há três maneiras básicas de implementar a comunicação entre dois processos A e B de uma aplicação ALua:
Veja alguns exemplos:
No processo A:
tabA = {a, b, c}
msg = string.format("tabB=%s", alua.tostring(tabA))
alua.send("B", msg)
O processo A irá criar no processo B a variável tabB com o valor da sua variável tabA. A função alua.tostring() faz parte da API do ALua e permite serializar dados. Ela se faz necessária uma vez que as mensagens transmitidas entre os processos devem ser strings.
No processo A:
msg = [[alua.send ("A", "print("..processa(x)..")")
alua.send("B", msg)
A enviará para B uma mensagem para executar processa(x) e, então, enviar uma mensagem de volta para A para que este possa mostrar o resultado. Exemplos mais completos podem ser encontrados mais adiante e na própria distribuição do ALua, no diretório "samples". Uma aplicação exemplo é mostrada no final deste documento.
Uma importante extensão feita no ALua foi a implementação de múltiplos canais de comunicação. Originalmente existia apenas um canal, o de controle entre um processo e o daemon - com um único tratador para as mensagens recebidas por um processo. Desse modo, todas as mensagens deveriam ser tratadas da mesma forma, o que, como já foi dito, consiste em executá-las como pedaços de código Lua.
Quando uma aplicação precisa manipular mensagens de diferentes modos essa extensão permite criar canais adicionais, associando a cada um deles o tratador apropriado. O canal original (canal de controle) ligado ao daemon local foi mantido com a função de trocar código Lua. Os canais adicionais estabelecem comunicação direta entre dois processos que podem estar ou não na mesma máquina, a comunicação através desse canal não é intermediada pelo daemon.
A implementação dos canais de comunicação segue o modelo cliente/servidor. Desse modo, cada canal possui de um lado um servidor e do outro um cliente. Nos dois processos associados a um canal é possível definir manipuladores para os eventos de leitura, escrita e fechamento do canal. Do lado do servidor é possível ainda definir um manipulador para o evento de conexão de um novo cliente. Ao implementar as funções que serão tratores de eventos, é necessário considerar os argumentos que serão passados quando essas funções forem chamadas na ocorrência dos respectivos eventos. Nos eventos de escrita de dados, conexão de clientes e fechamento de um canal, o gerente passa como argumento o canal. No caso do evento de leitura, o canal e os dados recebidos.
Uma observação importante deve ser feita com relação ao evento de escrita. Enquanto existir um manipulador definido para esse evento, o gerenciador de eventos irá chamá-lo, mesmo que isso implique em reescrever dados no canal. Isso significa que, se os mesmos dados não devem ser reescritos, o tratador do evento deve garantir isso, disponibilizando novos dados ou cancelando o tratamento do evento.
Outra importante extensão do ALua foi a inclusão do pacote LuaTimer e a conseqüente adição de duas novas funcionalidades na API: inclusão e remoção de temporizadores associados a uma função. Em linhas gerais, um temporizador consiste da especificação de uma freqüência que uma função deve ser executada. Os temporizadores não interrompem um evento em execução, eles respeitam a característica de execução ininterrúpta dos eventos. Assim, os temporizadores não garantem a execução em tempo determinado, por exemplo, se um evento gaste um tempo longo para ser executado, vários temporizadorees podem ser ativados, sendo estes executados logo após o evento terminar.
Última atualização: 20-Mai-2008 16:37