Websockets on shared hosting: not possible because of shared hosting itself or because of non-php integrations?

Question

I want to run a basic chat application on my shared hosting. I would use a PHP Websockets implementation library, Ratchet.

However, when I go to my shared hosting (Hostgator) websockets information page, it stated:

PHP Socket Support? If you are connecting out, it should work. We do not allow clients to bind to local ports for incoming.

What does it mean? Can I create my own websocket running the command via ssh? I would use this basic code in order to run it.

require dirname(__DIR__) . '/vendor/autoload.php';

$server = IoServer::factory(
    new HttpServer(
        new WsServer(
            new Chat()
        )
    ),
    8081
);

$server->run();

I noticed there were similar questions but most of the answers were saying it's not possible because the questioner was trying to use Node.js or Python websockets libraries, which are not supported on most of the shared hosting.

Answer 1

Main answer

Shared hosting will generally allow you to listen on a high port, e.g. the one you are using. However, there will be a number of problems in practice.

Firstly, the web server will probably only allow 80 (HTTP) and 443 (HTTPS) inbound, so a port of 8081 would be blocked by the firewall. Your PHP listener would attach to the port, but would wait patiently for traffic that never comes.

Secondly, some shared hosts will have a load balancer in front of them, and they might only be configured to forward HTTP traffic. Since Web Sockets are a different protocol, they won't be set up to forward that. The same problem with ports is repeated here too - non-standard ports won't be forwarded.

To solve these problems, you need your own web server, where you can open ports (and set up load balancers) in whatever way you like. This is pretty cheap to do these days - for the price of a couple of cafe coffees per month, you can rent a small virtual server. It won't have as much RAM as a shared server, but it will be a lot more flexible.

Design issues

I would draw attention also to using non-standard ports for Web Sockets to service a web application on standard 80/443 ports. This is not always a good idea. The non-standard ports will work fine on desktops and standard home internet connections, but for some office or mobile internet connections, you might get into a pickle.

It is better to put a load balancer in front of your app and then let it route traffic (Web Socket or HTTP) based on the protocol signature. This will allow you to use multiple protocols per port. If you are interested in exploring this, I recommend Traefik with Docker containers - I have set this up and it works very well indeed.