Informação adicional sobre o projecto de STFTR

1. Introdução

Este documento tem como objectivo esclarecer as dúvidas que poderão surgir sobre o código fornecido para o projecto da cadeira de Sistemas Tolerantes a Faltas e Tempo Real.

Aos alunos são fornecidos os esqueletos das quatro camadas a desenvolver, bem como as classes (ServerApplRRPC e ClientApplRRPC) que definem as camadas utilizadas pelo cliente e servidor. É na classe ServerApplRRPC que se pode alterar o protocolo de ordem total a utilizar.

Cada camada contém informação sobre o tipo de eventos que aceita, necessita e fornece. Se forem criados novos tipos de eventos então estes devem ser adicionados às camadas respectivas.

2. Cliente

2.1. ClientSession

Classe que encapsula a parte do código referente à aplicação cliente. Sendo código especifico da aplicação deve concretizar a interface com o utilizador (caso exista) e a (des)serialização de argumentos (entrada e saída) usados na invocação remota de procedimentos.

2.2 RRPC Session

Esta classe concretiza a funcionalidade de RPC replicado do lado do cliente. A camada deve funcionar de uma forma independente da camada da aplicação e deve fornecer entre outros serviços:

Associar um identificador único ao pedido.
Serializar e deserializar informação específica desta camada.
Filtragem de respostas repetidas.
Envio dos pedidos aos vários servidores.
Manter informação sobre os servidores activos .

2.3. RemoteViewEvent

Este evento deve ser enviado ao Gossip Server para obter informação sobre a filiação no grupo de servidores. Para utilizar esta funcionalidade deve-se construir um evento deste tipo com o identificador do grupo que se quer consultar e propagá-lo no sentido descendente. Como resposta recebe-se um evento do mesmo tipo, no sentido ascendente, contendo os endereços dos servidores.

3. Servidor

O servidor vai ser desenvolvido sobre um conjunto de camadas que fornecem serviços de comunicação em grupo (para interagir com os restantes servidores) e de comunicação ponto-a-ponto (para interagir com os clientes).

As mensagens destinadas ou com origem no grupo devem ser do tipo GroupSendableEvent ou descendentes desta classe.

As mensagens ponto-a-ponto devem serdo tipo SendableEvent ou descendentes.

3.1. ServerSession (aplicação)

Esta camada vai ter código específico da aplicação do lado do servidor.

A camada vai ter como função:

Concretização dos métodos a invocar remotamente.
Serialização das respostas.
Deserialização dos pedidos.
Gerar e processar as actualizações em funcionamento no modo Primário/Secundário.

3.2. CoordinationSession

Esta camada tem o código de coordenação genérico do lado do servidor e deve funcionar de uma maneira independente da camada da aplicação.

A camada deve preocupar-se com:

Receber os pedidos recebidos dos clientes e reencaminhá-los para o grupo.
Enviar os pedidos para a aplicação evitando que esta execute a operação mais que uma vez.
Enviar as respostas aos clientes.
Guardar as respostas para o caso de ser necessário a sua retransmissão.

3.3. BlockOk

Este evento é recebido quando a vista (filiação) vai ser alterada, tanto por perda de elementos como a entrada de novos elementos.

Este evento depois de ser recebido deve voltar a ser enviado no sentido descendente. A partir deste momento a camada não deve enviar mais eventos até receber uma nova vista.

3.4. View

Este tipo de evento contém informação de uma nova vista e é recebido depois de ter sido enviado um BlockOk.

Só depois de receber esta vista é possivel voltar a enviar mensagens.

A sincronia virtual garante que se uma mensagem é entregue numa vista então todas os membros do grupo (que sobrevivem até à próxima vista) entregam a mensagem nessa mesma vista.

Pedro Vicente