16

The WebSocket standard hasn't been ratified yet, however from the draft it appears that the technology is meant to be implemented in Web servers. pywebsocket implements a WebSocket server which can be dedicated or loaded as Apache plugin.

So what I am am wondering is: what's the ideal use of WebSockets? Does it make any sense to implement a service using as dedicated WebSocket servers or is it better to rethink it to run on top of WebSocket-enabled Web server?

tunnuz
  • 23,338
  • 31
  • 90
  • 128

1 Answers1

30

The WebSocket protocol was designed with three models in mind:

  • A WebSocket server running completely separately from any web server.
  • A WebSocket server running separately from a web server, but with traffic proxied to the websocket server from the web server (allowing websocket and HTTP traffic to co-exist on the same port)
  • A WebSocket server running as a plugin in the web server.

The model you pick really depends on the application you are trying to build and some other constraints that may limit your choices.

For example, if your application is going to be served from a single web server and the WebSocket connection will always be back to that same server, then it probably makes sense to just run the WebSocket server as a plugin/module in the web server.

On the other hand if you have a general WebSocket service that is usable from many different web sites (for example, you could have continuous low-latency traffic updates served from a WebSocket server), then you probably want to run the WebSocket server separate from any web server.

Basically, the tighter the integration between your WebSocket service and your web service, the more likely you will want to run them together and on the same port.

There are some constraints that may force one model or another:

  • If you control the server(s) but not the incoming firewall rules, then you probably have no choice but to run the WebSocket server on the same port(s) as your HTTP/HTTPS server (e.g. 80 and 443). In which case you will have to use a web server plugin or proxy to the real WebSocket server.
  • On the other hand, if you do not have super-user permission on the server where you are running the WebSocket server, then you will probably not be able to use ports 80 and 443 (below 1024 is generally a privileged port range) and in that case it really doesn't matter whether you run the HTTP/S and WebSocket servers on the same port or not.
  • If you have cookie based authentication (such as OAuth) in the web server and you would like to re-use this for the WebSocket connections then you will probably want to run them together (special case of tight integration).
kanaka
  • 70,845
  • 23
  • 144
  • 140
  • 2
    Awesome answer again @kanaka. In the same way I like the idea of [separation of concerns](http://en.wikipedia.org/wiki/Separation_of_concerns) when writing code I also like to follow this idea through to architecture. In some cases the plugin model is fine but when it comes to building larger applications, or if the message rate reaches a certain level, separating the web server, for the web application functionality, and the WebSocket server, for realtime bi-directional functionality, is a good idea IMHO. This is a concern I have about all the apps being built with node.js and socket.io. – leggetter Nov 22 '11 at 10:55
  • 2
    @leggetter, on the other hand, if the web service and WebSocket are part of the same concern, then the [principle of functional cohesion](http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29) applies and would push towards keeping them together. For example, if the initial page load is via HTTPS and then parts of the page are updated in real-time using data sent over WebSockets and that new data is closely related (and has the same access controls, etc) to what was originally served over HTTPS, then it may make more sense for the web service and WebSockets to be a cohesive unit. – kanaka Nov 28 '11 at 15:09
  • 1
    Agreed. Some architectures are going this way. One might be single page style apps. I've not done a lot of research in this area as yet but I think [SocketStream](https://github.com/socketstream/socketstream) potentially fits the bill, although they do actually let you swap out the underlying communication mechanism (socket.io/Pusher). – leggetter Nov 29 '11 at 21:11
  • Why is it a common practice that people use external services like pusher or ably and don't deploy a websocket server on their own? – Amin Jun 07 '22 at 14:27