A fiabilidade da rede sempre foi uma prioridade na arquitetura cliente/servidor da 4D. Com o 4D 21 R4, vamos um passo além: as aplicações 4D remotas podem agora lidar com breves interrupções de rede de forma transparente, sem encerrar a sessão do utilizador nem exigir qualquer intervenção manual.

O problema que estamos a resolver

As falhas de rede são uma realidade nas implementações no mundo real. Entre uma estação de trabalho cliente 4D e um servidor 4D, podem existir muitos dispositivos de rede (switches, routers, firewalls, gateways VPN, etc.) e qualquer um deles pode tornar os dois pares temporariamente inacessíveis um ao outro: um switch a reiniciar, um cabo a ser desligado e voltado a ligar, um problema de encaminhamento transitório algures ao longo do percurso. Estes eventos duram normalmente apenas alguns minutos, mas podem, mesmo assim, tornar os pares mutuamente inacessíveis.

Como funciona

Esta funcionalidade assenta na camada de transporte QUIC, que sustenta a comunicação cliente/servidor da 4D. O QUIC é, por natureza, sem ligação (funciona sobre UDP), o que significa que consegue tolerar naturalmente períodos de silêncio entre pares sem encerrar a sessão. Quando o 4D Server deteta que uma aplicação 4D remota ficou inacessível, já não encerra imediatamente a sessão. Em vez disso, mantém-na ativa e aguarda que a comunicação seja retomada.

A duração deste período de espera é controlada por um novo parâmetro da base de dados: tempo de espera da sessão QUIC (seletor 135). O valor predefinido é de 900 segundos (15 minutos), com um mínimo de 60 segundos. Define-se este parâmetro no lado do servidor e aplica-se a todas as novas sessões abertas a partir desse momento.

// Read the current timeout value
$previousTimeout:= Get database parameter(QUIC session timeout)
// Set a custom timeout window of 10 minutes

SET DATABASE PARAMETER(QUIC session timeout; 600)

Nota: a alteração deste valor afeta apenas as novas sessões. As sessões existentes mantêm o valor que lhes foi atribuído no momento em que foram abertas.

O que acontece quando um par fica inacessível

Do lado do servidor, assim que a camada QUIC reporta uma aplicação 4D remota como inacessível, a Janela de Administração do Servidor mostra o cliente 4D no estado «Inacessível ». A sessão é mantida ativa e um novo atributo unreachableSince fica disponível no Process activityobjeto .sessions[] correspondente ao cliente 4D inacessível, contando os segundos decorridos desde o último contacto.

// On the server — inspect all remote sessions
$processActivity := Process activity(Sessions only)
For each ($session; $processActivity.sessions)
   If ($session.unreachableSince # Null)
LOG EVENT (Into 4D diagnostic log;"Remoto "+$session.systemUserName+\
" inacessível há "+String($session.unreachableSince)+"s";\
Information message )
   End if

End for each

Do lado do cliente, o atributo Session.info.unreachableSince começa a contar os segundos desde a última comunicação bem-sucedida com o servidor. Apenas as janelas que estão a comunicar ativamente com o servidor passam a apresentar a mensagem «Inacessível»: a interface fica a cinzento com uma mensagem contextual (também apresentada como dica de ferramenta para janelas mais pequenas). As janelas que executam código local não são afetadas e permanecem totalmente utilizáveis. Os utilizadores podem continuar a trabalhar nas partes offline da aplicação enquanto a comunicação está a ser restabelecida.

// On the remote — check how long the server has been unreachable
If (Session.info.unreachableSince # Null)
ALERT ("Servidor inacessível há " + String(Session.info.unreachableSince) + "s")
End if

Quando a comunicação é restabelecida

Se a comunicação for restabelecida antes de o tempo de espera da sessão QUIC expirar, tudo retoma de forma transparente.

No lado do servidor:

• A janela de administração do servidor volta a colocar o cliente 4D no estado «Online».
• O atributo « unreachableSince » é removido do Process activity.sessions[] objeto correspondente ao cliente 4D recuperado.

No lado do cliente:

• O atributo «Session » «info » «unreachableSince » é removido.
• Todas as janelas afetadas recuperam o seu estado anterior.

O utilizador pode nem sequer notar que algo aconteceu.

Quando o tempo limite é excedido

Se os pares permanecerem inacessíveis entre si por um período superior ao tempo limite definido, a sessão é encerrada de forma ordenada.

Do lado do servidor:

• A sessão do cliente 4D é removida.
• É registada uma entrada de aviso no registo de diagnóstico para fins de monitorização.

No lado do cliente:

• Uma caixa de diálogo explica que a sessão foi encerrada porque o servidor estava inacessível e oferece a opção de reiniciar ou sair.
• É também apresentada uma notificação do sistema, para que o utilizador seja informado mesmo que a aplicação esteja em segundo plano. O nome e o ícone da aplicação são os definidos durante a criação da mesma.
  

Isto garante que, mesmo no pior dos casos, a experiência seja clara e informativa.

Veja em ação

O vídeo abaixo apresenta o panorama completo. Começa com o comportamento antigo utilizando o ServerNet, em que qualquer interrupção encerra imediatamente a sessão. Em seguida, demonstra o novo comportamento do QUIC em dois cenários:

• A comunicação é interrompida e, em seguida, restabelecida dentro do intervalo de tempo limite.
• A comunicação é interrompida novamente, mas, desta vez, o tempo limite é excedido e a sessão é encerrada.

Isto melhora muitas coisas para os seus utilizadores

Não é necessária qualquer programação. Não há configuração a implementar. Basta atualizar para o 4D 21 R4 e este comportamento fica disponível de imediato, para todos os utilizadores do cliente 4D.

Esta não é uma melhoria menor: resolve um dos pontos fracos mais visíveis e de longa data nas implementações cliente/servidor do 4D. Os seus clientes têm-se queixado disso. Isso acaba aqui.

E o 4D vai mais longe do que a maioria. Enquanto as aplicações web normalmente não dão aos utilizadores qualquer indicação de que perderam o acesso ao servidor (ou exigem um esforço de desenvolvimento significativo para o fazer), o 4D lida com isso de forma transparente e imediata: as janelas afetadas ficam esbatidas com uma mensagem clara, as janelas não afetadas continuam a funcionar e tudo é restaurado automaticamente quando a comunicação é retomada. Se a sua solução estiver devidamente arquitetada para separar a lógica local da dependente do servidor, os seus utilizadores podem desfrutar de uma experiência online/offline verdadeiramente contínua, sem qualquer esforço adicional.

É exatamente por isso que investimos no QUIC. Para mais contexto, leia a nossa publicação sobre o motivo pelo qual abandonámos a camada de rede legada e veja o vídeo que demonstra a resiliência do QUIC em comparação com outras camadas de rede. Também pode saber mais sobre a funcionalidade de mudança de camada de rede apresentada anteriormente.

Esta funcionalidade representa um excelente motivo para atualizar para o 4D 21 R4 e utilizar o QUIC!

---

Tem perguntas ou comentários sobre esta funcionalidade? Deixe um comentário abaixo ou contacte-nos no Fórum 4D.