Mais sobre Canais de Transporte
Como descrito anteriormente, você tem várias opções ao escolher um canal de transporte. Um canal de transporte é um canal de comunicação que o HyperServer usa para enviar dados para e receber dados de Nodes.
Na imagem acima, canais de transporte (mostrados em azul) são usados para comunicar-se com Nodes. Com base no tráfego de entrada, o HyperServer pode criar um ou mais transports para comunicar-se com cada Node. Então, ao mesmo tempo, pode haver múltiplos canais de transporte conectados ao mesmo Node. Um canal de transporte é uma camada transparente que retransmite as requisições de cliente recebidas para o Node relacionado. Ele transporta os dados da requisição do cliente do HyperServer para o Node usando várias tecnologias de comunicação entre processos.
Atualmente dois tipos de canais de transporte estão disponíveis: HTTP Transport Channel e Named Pipe Transport Channel. Named Pipe está atualmente disponível para Windows, mas uma versão para Linux será implementada em breve.
HTTP Transport Channel
Este canal é implementado com base no protocolo HTTP. Está disponível tanto nas plataformas Windows quanto Linux.
Vantagens:
Disponível em todas as plataformas (Windows e Linux)
Bem depurado e amplamente testado ao longo dos anos
Atualmente a única opção para comunicar-se com ServerNodes em uma farm de servidores HyperServer (Inter-server communication)
Desvantagens:
Sobrecarga adicional que degrada o desempenho
Herdar limitações do protocolo TCP/IP, como limite dinâmico de portas
Mais lento em comparação com outros métodos de comunicação entre processos
Pode levar ao esgotamento de portas TCP sob tráfego intenso (Veja: Additional Network Settings)
Exige atribuir um intervalo único de portas para evitar colisão de portas. (Ajustar o parâmetro start_port é obrigatório)
Named Pipe Transport Channel
Este canal é implementado usando a API Named Pipe do sistema operacional. Usar named pipes é um método popular para realizar comunicação entre processos.
Vantagens:
Implementado nativamente usando a API do sistema operacional (Nenhuma biblioteca externa é usada)
Muito menos sobrecarga (As requisições são transmitidas diretamente na memória e transferidas usando chamadas da API de named pipe)
Aumento de desempenho geral de até duas vezes em comparação com o HTTP transport channel. (Testado usando uniGUI stress test tool com 32 Nodes e uma aplicação básica uniGUI)
Muito mais escalável (O número máximo de pipes abertos é limitado apenas pelos recursos do sistema)
Não requer atribuir uma porta ou um nome. Um nome de pipe único é obtido a partir do parâmetro token do HyperServer, que é uma string única. (o parâmetro start_port ainda é usado combinado com o parâmetro token para criar um nome de pipe único)
Desvantagens:
Atualmente implementado apenas para Windows
Não é adequado para comunicação entre servidores. Portanto, o HyperServer continuará usando o legado HTTP transport para comunicar-se com ServerNodes em um cluster HyperServer.
Cada canal de pipe requer um nome único, assim o HyperServer pode conectar-se aos seus Nodes criando uma conexão de pipe usando esse nome. A seguinte fórmula é usada para criar um nome único para pipes:
PipeName := PipeNamePrefix + token + '_' + IntToStr(start_port + nodeId)
Default Transport Channel
Para manter compatibilidade retroativa, o canal de transporte padrão continua sendo o HTTP transport channel. Um parâmetro de configuração chamado transport_type escolhe o canal de transporte. O valor padrão é 0, o que significa que o HTTP transport channel será usado. Desenvolvedores que desejam escolher um canal Named Pipe devem alterar esse valor para 1.
For HTTP Transport
For Named Pipe Transport
Esta configuração deve ser feita para cada instância do HyperServer separadamente. Então, se você tiver várias instâncias do HyperServer em seu cluster, essa configuração deve ser aplicada para cada HyperServer.
Ao alterar seu canal de transporte de HTTP transport para Named Pipe transport pela primeira vez, é recomendável realizar um teste extensivo em uma máquina local antes de aplicá-lo ao seu servidor de produção. Você sempre pode reverter para HTTP transport se encontrar problemas. Os arquivos de log da aplicação uniGUI conterão códigos de erro e mensagens para ajudar a diagnosticar problemas.
A imagem abaixo mostra a aba Transport da página de monitoramento do servidor HyperServer. Neste exemplo a instância do HyperServer usa duas instâncias de transport: uma para Named Pipe e outra para HTTP transport. O canal Named Pipe é usado para comunicar-se com Nodes locais e o canal HTTP é usado para comunicar-se com ServerNodes remotos. Este HyperServer está configurado para usar Named Pipes (transport_type=1).
Se o tipo de transporte estiver definido como HTTP então apenas um tipo de transporte será instanciado, pois o canal HTTP será usado para comunicar-se tanto com Nodes locais quanto com ServerNodes remotos:
