SocketCluster - A Highly parallelized WebSocket server cluster to make the most of multi-core machines/instances.
Complete documentation available at: http://socketcluster.io/
29 July 2016 (v5.0.0)
You can now finally run SocketCluster as a Cluster (SCC) - We have just released a set of images to DockerHub along with some .yaml config files for Kubernetes (see kubernetes/ directory at the root of this repo). This means that you can now (relatively easily) deploy and scale SocketCluster on up to 1000 machines/nodes running Kubernetes - You literally just have to upload each .yaml file one by one using
kubectl create -f <service-definition.yaml> and then add your SSL/TLS key and cert to your provider (see
kubernetes/sc-ingress.yaml). It's been tested on a Rancher v1.1.0 (http://rancher.com/) Kubernetes cluster (We haven't yet tested on Google Container Engine). The cluster can be automatically scaled up and down (using the
kubectl scale command) and the channels will be re-sharded automatically across available nodes.
SCC is made up of 4 different services which can be scaled independently. We will add more documentation in the near future on how to get started. Also we will add information on how to extend SCC with your own code to you can build entire, highly scalable apps on top of it (without having to learn about distributed systems).
What use cases are SCC built for?
SCC differs from existing pub/sub systems and message queues in the following ways:
SCC is primarily intended as a frontend/web facing realtime service/framework - This in itself makes it quite different from most realtime pub/sub and MQ systems like RabbitMQ, NSQ, Kafka and Redis which are mostly intended purely for backend use. That said, you CAN use SC as a backend-only system if you like.
RabbitMQ, NSQ, Kafka are optimized for dealing with predefined realtime queues/channels with very high throughput - They're not very good at handling high-churn. SCC is designed to handle channel churn - It can create and destroy channels dynamically at a rate of about 10K channels per second per process (and scaled linearly accross multiple nodes). Each SC channel can handle about 20K messages per second (this is much lower than what you could handle per channel/queue with Kafka for example). So basically, it's good if you want to have a system where you have millions of users who just create and destroy millions of unique channels on the fly as they navigate through an app (for example).
SCC is a framework; from the beginning, it was designed so that you could add your own middleware and business logic... Ultimately, we want SCC to replace the need for Backend as a Service... Though there is still a long way to go.
Note that we have plans to offer a hosted Kubernetes platform (built on top of Rancher) - Where you will be able to easily deploy your SCC apps to Kubernetes running on your own infrastructure of choice (including Amazon EC2 and custom infrastructure). If this sounds interesting to you, please sign up to https://baasil.io/ - We will email you when it's ready.
µWS has been bundled with SC as an optional WebSocket server for a few months now. Based on our testing, we found µWS to be several times faster than the WS module.
As of v5.0.0 - We have made µWS our default WebSocket server engine. We still bundle the old WS module for backwards compatibility with older systems - You can roll back to the WS module by setting the
wsEngine option of SocketCluster to
'ws'. This switch to µWS shouldn't affect any existing code that you have (it has already been tested in production for several months by many users of SC) but it's important to be aware of this change.
22 July 2016 (v4.7.0)
16 January 2016 (v4.2.0)
SocketCluster is a fast, highly scalable HTTP + realtime server engine which lets you build multi-process realtime servers that make use of all CPU cores on a machine/instance. It removes the limitations of having to run your Node.js server as a single thread and makes your backend resilient by automatically recovering from worker crashes and aggregating errors into a central log.
SocketCluster has been tested for memory leaks. The last full memory profiling was done on SocketCluster v0.9.17 (Node.js v0.10.28) and included checks on worker and broker processes.
No memory leaks were detected when using the latest Node.js version. Note that leaks were found when using Node.js versions below v0.10.22 - This is probably the Node.js 'Walmart' memory leak - Not a SocketCluster issue.
There are two ways to install SocketCluster.
Setup the socketcluster command:
npm install -g socketcluster
sudo npm install -g socketcluster
socketcluster create myapp
Once it's installed, go to your new myapp/ directory and launch with:
Access at URL http://localhost:8000/
npm install socketcluster
You will also need to install the client separately which you can get using the following command:
npm install socketcluster-client
The socketcluster-client script is called socketcluster.js (located in the main socketcluster-client directory)
It is recommended that you use Node.js version >=0.10.22 due to memory leaks present in older versions.
In order to run SocketCluster over HTTPS, all you need to do is set the protocol to 'https' and provide your private key and certificate as a start option when you instantiate SocketCluster - Example:
var socketCluster =workers: 3brokers: 3port: 8000appName: 'myapp'workerController: 'worker.js'protocol: 'https'protocolOptions:key: fscert: fspassphrase: 'passphase4privkey';
The protocolOptions option is exactly the same as the one you pass to a standard Node HTTPS server: http://nodejs.org/api/https.html#https_https_createserver_options_requestlistener
You can create an app on top of SocketCluster's docker image. The SC container can be run standalone or as a base image for your own container.
The official SocketCluster container on DockerHub is here: https://hub.docker.com/r/socketcluster/socketcluster/
The Dockerfile for the base image is here: https://github.com/SocketCluster/socketcluster/blob/master/sample/Dockerfile
To use the SocketCluster container as your base image, your app's Dockerfile might look like this:
FROM socketcluster/socketclusterMAINTAINER John SmithLABEL version="1.0.0"LABEL description="Custom app based on SocketCluster"WORKDIR /usr/src/COPY . /usr/src/RUN npm installEXPOSE 8000CMD ["npm", "start"]
Then you can just build your container using:
docker build -t my-socketcluster-app:v1.0.0 .
Note that there are more ways to run SocketCluster with Docker. You can also mount your own volumes and point to custom worker.js and broker.js files which are inside those volumes using environment variables. You can see the environment variables which are used by SocketCluster here: https://github.com/SocketCluster/socketcluster/blob/master/sample/server.js
Docker volumes allow you to sneak your own directories (containing your own worker.js and broker.js source files) into the SocketCluster container without having to rebuild the image (good for development). Read this section on volumes to get an idea of how they work with Docker: https://docs.docker.com/engine/userguide/containers/dockervolumes/
Note that if you want to attach any volumes to your SocketCluster container, you should mount them to the
/usr/src/ path (inside the container) - That's the root directory from which SC loads user-defined source code.
For example, if you wanted to quickly run SocketCluster with your own workerController file (
worker.js), you could just put your
worker.js file inside a
/home/my-username/controllers/ directory (on your host system) and then bundle it into the container as a volume by running a command like this (example):
docker run -d -v /home/my-username/controllers/:/usr/src/controllers/ -e "SOCKETCLUSTER_WORKER_CONTROLLER=/usr/src/controllers/worker.js" socketcluster/socketcluster
-dflag just tells Docker to run the container in the background.
-vflag tells docker to mount the
/home/my-username/controllers/directory (which is on your host machine) and map it to the
/usr/src/controllers/(inside the SocketCluster container).
-eflag allows you to define custom environment variables. Here we are just using the SOCKETCLUSTER_WORKER_CONTROLLER env var to tell SocketCluster to use the worker.js file which is inside the volume which we just mounted to the container at path
socketcluster/socketclusteris the Docker image.
To contribute; clone this repo, then cd inside it and then run npm install to install all dependencies.
(The MIT License)
Copyright (c) 2013-2016 SocketCluster.io
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.