Standard HyperServer Cluster

In a standard HyperServer cluster there is only one HyperServer instance with several Nodes which are part of the cluster. In this mode all WebSocket requests will be served by the HyperServer instance itself. Nodes will not connect to WebSocket clients directly. The HyperServer instance will operate as a WebSockets server too.

Standalone Server and Windows Service

In this mode configuration is very simple.

[hyper_server]

server_direct_url=http://localhost:8077

You must provide a value for the server_direct_url parameter. This URL will be used by Nodes to connect to the HyperServer and relay the messages to it. When BroadcastMessage method is called the related Node must send the message to the HyperServer, so HyperServer can broadcast it to all WebSocket clients. That's why Nodes must know at which URL our HyperServer is located. There is no way for Nodes to find this URL automatically, so it must be provided by populating the server_direct_url parameter.

For a default HyperServer setup where it accepts calls on port 8077 this value can be:

• http://localhost:8077

You can also use a global URL or local URL for this parameter:

• http://192.168.1.32:8077

• http://myserver.com:8077

• https://myserver.com:8077

If you are going to provide a secure URL make sure that latest versions of SSL DLL files are copied to the HyperServer root folder.

WebSockets configuration can be left with default parameters:

[websockets]

enabled=1
aux_port=0
max_queue_length=1000
binding=
global_binding=
global_port=0
external_server_url=
external_server_token=
app_domain=

There is no need to change any parameters in the websockets section for the standalone/Windows service mode — you can leave them with default values.

ISAPI or Apache Module

If you deploy your HyperServer as a module (ISAPI or Apache) things can be more complicated. In this case the module itself is unable to serve the incoming WebSocket requests directly — see the IIS & Apache Deployment section for details: https://unigui.com/doc/online_help/iis--apache-deployment.htm. You should consider Binding to a Different Port or IP Address: https://unigui.com/doc/online_help/binding-to-a-different-port-or.htm.

Here we assume you are not using a Dedicated WebSockets Server: https://unigui.com/doc/online_help/using-a-dedicated-websockets-s.htm.

Adjust server_direct_url to point to your module/DLL:

[hyper_server]

server_direct_url=http://localhost/myapp/app.dll

This can be a local or global URL. If the Nodes and HyperServer DLL run on the same computer it is OK to provide a local URL provided your ISAPI application is bound to localhost. Otherwise provide a global URL such as http://myserver.com/myapp/app.dll.

Using an Auxiliary Port

One way to provide WebSocket functionality for an ISAPI DLL application is serving WebSocket requests through an auxiliary port. Example: the ISAPI web application uses non-secure connections on port 80, and you use port 81 for WebSocket requests.

[websockets]

enabled=1
aux_port=81
max_queue_length=1000
binding=
global_binding=
global_port=0
external_server_url=
external_server_token=
app_domain=

This makes the ISAPI DLL internally run a dedicated HTTP server that listens on port 81 and is used to accept and serve WebSocket calls.

Binding to a Different IP

If you don't want to use an auxiliary port you can bind the internal WebSockets server to a different IP address. To do this your server must have more than one global IP address. For example, if your server has two global IPs: 80.12.1.1 and 80.12.1.2, you can configure your ISAPI server to bind to the first IP and configure the HyperServer DLL to use the second IP using the binding parameter:

[websockets]

enabled=1
aux_port=0
max_queue_length=1000
binding=80.12.1.2
global_binding=
global_port=0
external_server_url=
external_server_token=
app_domain=

If your application uses a secure connection, WebSocket connections must be done over wss. You must configure your ssl.cfg file with correct settings, and provide a separate domain for your secure domain if it is bound to a secondary IP. These steps must be repeated for each HyperServer instance in your network. If you have a single HyperServer instance in your network it may be reasonable to go through these configurations, but as you add HyperServer instances the configuration must be repeated with different dedicated ports or IP addresses.

For these reasons the documentation strongly recommends Using a Dedicated WebSockets Server, especially if you deploy your application or HyperServer as an ISAPI or Apache module: https://unigui.com/doc/online_help/using-a-dedicated-websockets-s.htm.