Using a Dedicated WebSockets Server

It is possible to configure a HyperServer instance to operate as a dedicated WebSockets server. This can be useful when you have a large cluster and you want to redirect all WebSockets connections to one or more dedicated computers. It can also help simplify WebSockets management in your cluster, as all WebSocket connections can be monitored from one location.

Another important benefit is scalability. As discussed elsewhere, TCP/IP connections are a limited system resource. Theoretical limits such as "64K connections" are often misquoted; the actual TCP/IP connection limit is determined by many factors. Each HyperServer instance running in the same OS is able to serve at least 64K TCP/IP connections. We say "at least" because if each connection originates from a unique IP address the number of connections can be even higher. In practice, the actual number of simultaneous connections can be lower because they are limited by resources the OS dedicates to the TCP/IP subsystem.

Unlike HTTP connections (which can be reused or recycled), WebSocket connections stay open as long as the web session is active. Open WebSocket connections can therefore consume system resources that might otherwise be used for HTTP connections. By moving WebSockets to a separate server, you can ensure WebSocket connections have adequate system resources even if there are thousands of live sessions.

That said, running a dedicated WebSockets server is not mandatory even for large clusters that contain slave servers running in mode 2 (see Cluster Operation Modes). Using a dedicated WebSockets server is a design choice.

You can run your dedicated WebSockets server on the same physical machine as other services, but bind it to a different port or IP address. Because it listens on a different port or IP it will have its own limit for incoming TCP/IP connections and won't conflict with your uniGUI web server. Note that the total number of TCP/IP connections is still constrained by overall system resources.

A further advantage of using a separate WebSockets server appears when deploying your application as a module (ISAPI or Apache) and you don't want to configure an auxiliary port for each application instance. Instead, direct your applications to an external WebSockets server running on a different machine or on the same machine using default ports (80 or 443) bound to a secondary IP. This avoids opening extra ports to the global internet.

Setting up a dedicated WebSockets server

A dedicated WebSockets server is simply a HyperServer instance. This HyperServer instance should run as a Windows or Linux service. If IIS or Apache runs on the same server, configure the HyperServer instance so it does not conflict with Apache or IIS — either run it on a separate port or bind it to a secondary IP. If you bind it to a secondary IP, ensure that Apache or IIS are not binding to that IP; consult IIS or Apache documentation to remove an IP address from their default bindings.

Once the server is set up and running it can serve as a dedicated WebSockets server. A detailed example can be found in the Setting Up the Dedicated WebSockets Server section: https://unigui.com/doc/online_help/setting-up-the-dedicated-webso.htm