Is a web socket connection in javascript an inbound connection?

1.1k views Asked by At

I'm trying to make a web socket connection on my webserver. The connection is run from a client in javascript and connects to a php script on the webserver. The javascript is also placed on the webserver, but runned from a clients webbrowser.

The problem is that hostgator doesn't allow inbound socket connections unless you buy a dedicated server, but I'm not aware if this counts as an inbound socket connection.

So does anyone know if this counts as an inbound socket connection or any other web hosting sites that would allow inbound connections?

Thank you in advance :)

1

There are 1 answers

0
jfriend00 On BEST ANSWER

A websocket connection starts life as an incoming HTTP connection (usually on the same port as is being used for web requests) with some custom headers on it which is something all web servers have to be configured to accept (or they wouldn't be any use as a web server). After a brief exchange with the client, the client requests an upgrade and a switch to the websocket protocol (the initial connection was the HTTP protocol). That connection which started life as an HTTP connection then becomes a webSocket connection (if the web server agrees to the protocol switch).

So, yes it is an incoming connection to the web server, but it's an incoming HTTP connection which your web server has to already accept. webSockets were designed this way on purpose to make them highly compatible with existing HTTP networking infrastructure, firewalls, etc... so they could be used by only upgrading the HTTP server software (to support the webSocket protocol) and not changing any of the networking infrastructure.


FYI, there are other hosting issues with using webSockets. A webSocket is a continuous, long lasting socket connection. In order to use it, you typically need a continuous, long lasting server process. Many of the lower cost, shared hosting environments do not support that. They tend to accept an incoming HTTP request, dispatch it to whatever script it is supposed to run (e.g. a PHP script), let it run on that request and then the script exits and your server process does not continue to run. This works well for low cost, shared hosting because no server resources are consumed by your app when it is not actively in the middle of serving a page. But, that model won't work for webSockets where you must have a continuous server process for the webSocket to be connected to.

I don't know specifically about hostgator, but this is another issue to look into. On my shared hosting on Dreamhost, I cannot have a long running server process. On Dreamhost this requires a VPS hosting plan and from what I've read this is common for other shared hosting environments too.