O protocolo FTT-SE foi pensado de modo a controlar o número de mensagens que são entregues à rede em cada momento. Contudo, nenhum protocolo ou camada usada normalmente nos sistemas operativos permite esse controlo da forma pretendida. O pro- blema que se coloca é, onde colocar uma camada FTT-SE que seja capaz de receber a Trigger Message, processá-la e executar todas as outras tarefas que um Slave FTT-SE tem que cumprir e além disso, fornecer uma interface genérica às aplicações User-Space para que estas se possam abstrair da utilização do protocolo FTT-SE. Isto é, a comunicação com a rede deve ser feita através de sockets como se o protocolo FTT-SE não existisse.
Uma série de soluções foram equacionadas para a resolução do problema. Estas serão descritas nas subsecções seguintes.
5.2.1 FTT-SE logicamente acima do eth0
Como o controlo de mensagens que são enviadas para a rede é uma das principais ca- racterísticas do protocolo, entendeu-se que a solução teria que passar por uma das cama- das inferiores, isto é, a resolução teria que controlar a interface de rede. Assim, pensou-se que uma possível solução poderia passar por filtrar e controlar as mensagens que são entregues ao interface, para isso adicionar-se-ia uma camada à pilha de rede do Kernel, como se pode observar na figura 5.4.
Figura 5.4: Camada FTT-SE logicamente acima do eth0
Na imagem estão suprimidas as camadas intermédias apenas por uma questão de sim- plificação.
A solução seria então, colocar uma camada, em Kernel-Space, imediatamente acima do eth0. Essa camada absorveria todas as mensagens que chegavam à interface, e serviria
5.2 A problemática e diferentes soluções FTT-SE 35
de ponte entre as aplicações User-Space e a interface eth0. Além disso a comunicação de outras aplicações com a interface teria que ser bloqueada, para que não fossem inseridos pacotes na rede inadvertidamente.
Esta solução resolvia todas as questões, a camada FTT-SE iria executar as funções necessárias para que o protocolo funcionasse correctamente. Mas, dois problemas foram detectados. Em primeiro lugar o desenvolvimento de uma aplicação em kernel-Space, depois o reencaminhamento de todos os pacotes que a interface recebesse para a inter- face FTT-SE. O desenvolvimento de aplicações em Kernel-Space iria exigir um estudo detalhado de como as interfaces funcionam, mas seria exequível. Contudo, o reencami- nhamento das tramas chegadas ao eth0 para o FTT-SE, não possuía uma solução aparente, ou então, iria exigir que o normal funcionamento da interface fosse alterado. O objectivo era manter a estrutura do Linux exactamente como estava, para que o protocolo pudesse ser carregado de uma forma simples, não alterando em nada o sistema operativo original.
5.2.2 FTT-SE logicamente abaixo do eth0
Uma outra solução que surgiu logo após a primeira foi construir uma arquitectura inversa. Ou seja, da mesma forma que é possível colocar a camada FTT-SE acima da de interface de rede, também pode ser possível introduzi-la abaixo, como se pode ver na figura seguinte.
Figura 5.5: Camada FTT-SE logicamente abaixo do eth0
Esta solução baseia-se no mesmo princípio da solução anterior. Mas, aqui rapida- mente foram encontrados vários problemas. O primeiro deles foi o mesmo encontrado
36 Soluções para a pilha protocolar FTT-SE
na solução anterior. Como fazer o eth0 comunicar com a camada FTT-SE e não com o device driver da placa? E como detectar qual a placa de rede que a maquina possui para comunicar com o device driver respectivo?
Esta solução aparente tornou-se bastante complicada. E optou-se por pensar em outras soluções antes de tentar resolver estes problemas.
5.2.3 FTT-SE e eth0 logicamente ao mesmo nível
Uma outra solução possível seria colocar os dois módulos ao mesmo nível e não como camadas com níveis diferentes.
Figura 5.6: FTT-SE e eth0 logicamente ao mesmo nível
Esta solução resolveria a questão da comunicação do device driver, neste caso é o eth0 que comunica com a placa, e ao mesmo tempo comunicaria com a aplicação.
O princípio de funcionamento desta solução seria bastante simples, todas as aplicações comunicam com o eth0, este envia todos os dados que receber para o módulo FTT-Slave, e por sua vez, o FTT-Slave envia para o eth0 apenas os dados que o interface deve enviar para a rede e para as aplicações.
O problema desta solução é que era necessário fazer uma alteração do funcionamento do eth0 o que não é vantajoso como já foi visto na solução anterior.
5.2.4 FTT-SE e eth0 logicamente ao mesmo nível com recurso a IP Table
Uma outra solução equacionada baseava-se no recurso à capacidade de NAT das IP Tables em Linux. A IPtable do sistema operativo iria ser configurada para redireccionar todo o tráfego do eth0 para o FTT-Slave e assim seria o módulo FTT-SE que comunicaria com as aplicações. [17]
Desta forma, todas das aplicações comunicariam com o FTT-SE e este enviaria os pacotes para o eth0 para serem encaminhados para a rede. Por outro lado, os pacotes que o eth0 recebesse iriam ser reencaminhados para o FTT-Slave.
5.2 A problemática e diferentes soluções FTT-SE 37
Figura 5.7: FTT-SE e eth0 logicamente ao mesmo nível com recurso a IP Table
A principal razão para não usar esta solução deve-se ao tempo que a ipTable toma para fazer os diferentes redireccionamentos. Essa limitação iria afectar directamente o desempenho temporal do protocolo.
5.2.5 FTT-SE e Tun/Tap
Uma solução que pareceu bastante interessante foi o uso de interface Tun/Tap. Esta tecnologia permite criar interfaces virtuais de rede, através de aplicações User-Space, sendo possível ler e escrever, facilmente nesses interfaces. A figura seguinte mostra a arquitectura idealizada. [11,14]
Figura 5.8: FTT-SE com uso da tecnologia Tun/tap
Todos processos relativos ao protocolo são realizados pela aplicação User-Space FTT- SE. As restantes aplicações ligam-se ao interface Tun/Tap Device que envia todos os dados para a aplicação FTT-SE. As aplicações que tentem comunicar com o eth0 terão o acesso negado através de uma configuração prévia da IPTable.
38 Soluções para a pilha protocolar FTT-SE
5.2.6 FTT-SE como protocolo na pilha protocolar
Uma outra solução seria introduzir o FTT-SE como protocolo, de modo a que seja possível criar sockets do tipo FTT-SE. Assim, todos os processos do protocolo seriam executados pela pilha protocolar tal como o TCP ou UDP.
Figura 5.9: Pilha TCP/IP vs Pilha FTT-SE
Esta solução iria resolver uma série de problemas relacionados com redireccionamen- tos, que foram encontrados nas soluções vistas até agora. A criação de sockets FTT-SE permitiria uma interface simples, genérica e com todas as potencialidades do protocolo. Contudo, uma solução deste tipo iria exigir muito mais tempo que o disponível e um conhecimento bastante mais profundo do Kernel Linux.
Capítulo 6
Solução Universal Tun/Tap Driver
Neste capítulo é exposta a solução adoptada. Descreve em que consiste a tecnologia Tun/Tap, assim como as suas potencialidades e possíveis aplicações. É explicada também, a estrutura do programa que foi desenvolvido para a criação da interface genérica para as aplicações