Usando um Servidor WebSockets Dedicado

É possível configurar uma instância do HyperServer para operar como um servidor WebSockets dedicado. Isso pode ser útil quando você tem um grande cluster e deseja redirecionar todas as conexões WebSockets para um ou mais computadores dedicados. Também pode ajudar a simplificar o gerenciamento de WebSockets no seu cluster, já que todas as conexões WebSocket podem ser monitoradas a partir de um único local.

Outro benefício importante é a escalabilidade. Como discutido em outros trechos, conexões TCP/IP são um recurso de sistema limitado. Limites teóricos como "64K conexões" costumam ser citados de forma equivocada; o limite real de conexões TCP/IP é determinado por muitos fatores. Cada instância do HyperServer rodando no mesmo SO é capaz de atender pelo menos 64K conexões TCP/IP. Dizemos "pelo menos" porque, se cada conexão se origina de um endereço IP único, o número de conexões pode ser ainda maior. Na prática, o número real de conexões simultâneas pode ser menor porque é limitado pelos recursos que o SO dedica ao subsistema TCP/IP.

Diferentemente das conexões HTTP (que podem ser reutilizadas ou recicladas), as conexões WebSocket permanecem abertas enquanto a sessão web estiver ativa. Conexões WebSocket abertas podem, portanto, consumir recursos do sistema que de outra forma seriam usados por conexões HTTP. Ao mover os WebSockets para um servidor separado, você pode garantir que as conexões WebSocket terão recursos de sistema adequados mesmo se houver milhares de sessões ativas.

Dito isso, executar um servidor WebSockets dedicado não é obrigatório mesmo para clusters grandes que contenham servidores escravos rodando no modo 2 (veja Cluster Operation Modes ). Usar um servidor WebSockets dedicado é uma escolha de arquitetura.

Você pode executar seu servidor WebSockets dedicado na mesma máquina física que outros serviços, mas vinculá‑lo a uma porta ou endereço IP diferente. Porque ele escuta em uma porta ou IP diferente, terá seu próprio limite para conexões TCP/IP de entrada e não entrará em conflito com seu servidor web uniGUI. Observe que o número total de conexões TCP/IP ainda é limitado pelos recursos gerais do sistema.

Uma vantagem adicional de usar um servidor WebSockets separado aparece ao implantar sua aplicação como um módulo (ISAPI ou Apache) e você não quer configurar uma porta auxiliar para cada instância da aplicação. Em vez disso, direcione suas aplicações para um servidor WebSockets externo rodando em outra máquina ou na mesma máquina usando portas padrão (80 ou 443) vinculadas a um IP secundário. Isso evita abrir portas extras para a internet global.

Configurando um servidor WebSockets dedicado

Um servidor WebSockets dedicado é simplesmente uma instância do HyperServer. Essa instância do HyperServer deve rodar como um serviço do Windows ou Linux. Se o IIS ou o Apache estiverem executando no mesmo servidor, configure a instância do HyperServer para que não entre em conflito com o Apache ou o IIS — execute‑a em uma porta separada ou vincule‑a a um IP secundário. Se você vinculá‑la a um IP secundário, certifique‑se de que o Apache ou o IIS não estejam vinculados a esse IP; consulte a documentação do IIS ou do Apache para remover um endereço IP de seus bindings padrão.

Uma vez que o servidor esteja configurado e em execução, ele pode atuar como um servidor WebSockets dedicado. Um exemplo detalhado pode ser encontrado na seção Setting Up the Dedicated WebSockets Server: https://unigui.com/doc/online_help/setting-up-the-dedicated-webso.htm