socketcluster

See website https://socketcluster.io/ for v17.3.1 docs.

See website https://socketcluster.io/ for v16.x.x docs.

• Bump dependencies.

• Deprecated setAuthEngine(authEngine) and setCodecEngine(codecEngine) methods. You should now pass a custom authEngine and codecEngine as options to the SCWorker constructor. See the constructor method here: https://socketcluster.io/#!/docs/api-scworker

• SCC: Added detailed error messages if some SCC components are not compatible with others.
• SCC: Fixed bug related to 'max stack size exceeded' error when a certain configuration is used.
• SCC: Renamed SOCKETCLUSTER_SERVER_PORT environment variable to SCC_BROKER_SERVER_PORT.

Breaking change

• SCC: v6.x.x components have been released; from now on, the major version numbers of all SCC components (scc-state, scc-broker and scc-broker-client) need to match each other.

• You can now pass an optional authVerifyAlgorithms array (of strings) to the main SocketCluster instance (used for JWT auth verification). If not specified, by default the algorithm will be the same for both JWT signing and verification (determined by authAlgorithm). The consequence of this change is that while you can only sign with one algorithm, the verification could accept multiple algorithms.
• The SC server adds a socket property to the options object which is passed to the verifyToken method of the authEngine; this means that if a custom authEngine is provided, it can use data from the socket itself (e.g. cookie or query string) to aid in performing the verification.
• Added a destroy method on the server side socket to make it more consistent with the client side socket. Also added a matching active (boolean) property which can be used to check if the socket was destroyed.
• An error event will be emitted on the socket if the user tries to emit a reserved event on that socket.
• Renamed SCSocket to SCServerSocket.
• Bumped sc-uws version.

• Added a new authStateChange event on the server side socket (SCSocket) which is has similar behavior as the authStateChange event on the client-side SCSocket.
• Added a new authenticationStateChange event on the server (SCServer) which is essentially the same as the socket authStateChange except that the first argument to the handler is a socket object and it captures the event across all active sockets.
• Breaking changes to socketcluster-client https://github.com/SocketCluster/socketcluster-client/releases/tag/v12.0.0

• Upgraded SCC:

  • [email protected] (npm)

  • Added support for skeleton-based rendezvous hashing by default - This means that adding or removing scc-broker instances to the cluster now requires fewer channel migrations that before - This means that downtime will affect a much smaller subset of channels when scaling out or scaling back. The more machines/instances there are in the cluster, the fewer channels will be affected when new machines/instances are added. You can use the old mapping engine by setting the clusterMappingEngine option in SC to 'simple' here: https://github.com/SocketCluster/socketcluster/blob/72d301146c37efa3de52b8acfc532767c1ec6cc6/sample/server.js#L37

  • Added support for connection pooling so that a SocketCluster instance can now interact with an scc-broker instance through more connections; this is useful if you want to use large scc-broker instances that have more than one worker process - In this case, it should help to distribute the load more evenly across processes inside the scc-broker instance. You can set the clusterClientPoolSize option in SC; it defaults to 1 - Ideally this number should remain in the single-digit range. See https://github.com/SocketCluster/socketcluster/blob/72d301146c37efa3de52b8acfc532767c1ec6cc6/sample/server.js#L38

• Made ws the default WebSocket engine for maximum compatibility; a large number of users have been complaining about uws not working on some systems - It's better to have a default that always works out of the box (as not to scare away new users) and to make optimizations optional.

Breaking change

• Switched to a custom uWS JS binding/module sc-uws; it's a drop-in replacement for uws.

• Upgraded SCC:

  • scc-state:v2.0.0 (Dockerhub)
  • scc-broker:v2.0.0 (Dockerhub)
  • [email protected] (npm)
    This upgrade was about simplifying and improving the stability and reliability of SCC. As part of this upgrade, SCC's graceful scale-out feature was removed in favour of a simpler approach; this means that scaling out the cluster may now incur a few seconds worth of lost messages on some channels; on the positive side, the cluster is now a lot more reliable overall. Some heavy users of SCC had reported occasional issues with channels going out of sync in earlier versions (which necessitated restarting nodes in the cluster). The new version is simpler and better tested (see https://github.com/SocketCluster/scc-integration-tests).

• Made it so that 'unsubscribe' events will trigger before the 'disconnect' event on the server - Before it used to be inconsistent (depending on IPC latency between worker and broker processes).

• Renamed MIDDLEWARE_HANDSHAKE property to MIDDLEWARE_HANDSHAKE_WS to make it clear that it is executed as part of the low-level WebSocket protocol handshake (before the SocketCluster socket has been instantiated on the server side). This middleware line offers the earliest possible opportunity to block connections before they are made - The downside is that due to security restrictions in the WebSocket protocol, it is not possible to pass back custom errors to the client during this phase of the connection.
• Added a new MIDDLEWARE_HANDSHAKE_SC middleware type which lets you control the flow at the SocketCluster protocol handshake level (this runs after the MIDDLEWARE_HANDSHAKE_WS middleware). Unlike with MIDDLEWARE_HANDSHAKE_WS, with MIDDLEWARE_HANDSHAKE_SC, you can pass back custom status codes to the client when blocking requests; the client can use this status code to determine its behaviour. This middleware line can be used to authenticate sockets using HTTP query strings instead of JWT tokens.

Example:

  var scServer = worker.scServer;

  scServer.addMiddleware(scServer.MIDDLEWARE_HANDSHAKE_SC, (req, next) => {
    setTimeout(() => {
      var err = new Error('Failed MIDDLEWARE_HANDSHAKE_SC');
      err.name = 'SCHandshakeError';
      // Block connection with custom 4501 status code.
      // The client will receive this code as the first argument
      // to the 'disconnect' event handler.
      next(err, 4501);
    }, 200);
  });

Breaking change

• Renamed MIDDLEWARE_HANDSHAKE property to MIDDLEWARE_HANDSHAKE_WS - The corresponding string value was also renamed from handshake to handskakeWS.

Fix bug with top level (master process) --inspect and --debug flags not working.

Added async/await support for the worker and broker controller run methods. See https://github.com/SocketCluster/socketcluster/issues/351

The createHTTPServer method on the worker can also now resolve asynchronously.

Potentially breaking changes

• Removed support for the deprecated global property on the worker and server objects - You should now use the exchange property instead.
• Removed support for the deprecated getSocketURL() method of the SocketCluster master instance.

This version fixes an issue with the scServer.clients object and scServer.clientsCount value not being updated correctly under certain specific scenarios. See https://github.com/SocketCluster/socketcluster-server/pull/21

In addition to fixing the issue, this version introduces a few changes.

Potentially breaking changes

• On the server socket, the disconnect event used to trigger whenever the socket lost the connection at any stage of the handshake/connection cycle. That meant that the disconnect event could get triggered on the socket before the connection event had been triggered on the scServer object (which was strange). Also there was no way to know the specific phase of the cycle when the connection ended (before or after the handshake). Now the disconnect only triggers after the handshake has completed. To catch a lost connection during the handshake phase, you should use the connectAbort event on the socket or connectionAbort event on the server. If you need a catch-all to capture any kind of connection termination at any phase of the cycle, you should now use the socket's new close event or the server's new closure event. Note that this change does not affect the disconnection event on the server; only the disconnect event on the socket. Also note that this change should only affect you if you have written logic inside a scServer.on('handshake', handler) handler - If you just use the scServer.on('connection', handler) handler (and thus don't try to access sockets before they are fully connected), then the behaviour of disconnect will not have changed from what it was before.

Non-breaking changes

• Added a new scServer.pendingClients property which is a hashmap similar to scServer.clients except that it contains sockets which have not yet completed the handshake (and therefore are still in the 'connecting' state). Also, a matching scServer.pendingClientsCount property was added.
• The connectAbort event has been present on client sockets for a long time but not on server sockets until now. A new connectAbort event was added to the socket and a matching connectionAbort event was added on the scServer object.
• As mentioned in the 'potentially breaking changes' section above, a new catch-all close event has been added to the socket to replace the disconnect event which had ambiguous meaning. You can also listen to lost socket connections from the scServer using the closure event.

See https://github.com/SocketCluster/socketcluster/issues/333

Special thanks to @mauritslamers for coming up with this proposal and for doing the initial work for this release.

This release improves the way SC bootstraps different processes to give more control to the developer.
As a result of this update, the boilerplate logic for entry points to various processes within SC has changed.

The entry point for the worker controller (worker.js) used to be:

// SocketCluster decides when the run() function is invoked.

module.exports.run = function (worker) {
    // Custom worker logic goes here.

    worker.scServer.on('connection', (socket) => {
        // Handle the new connection.
    })
};

but now it is:

var SCWorker = require('socketcluster/scworker');

class Worker extends SCWorker {
  run() {
    // Custom worker logic goes here.
    // You can reference to the worker in here with 'this'.

    this.scServer.on('connection', (socket) => {
        // Handle the new connection.
    });
  }
}

new Worker();

Note that you can use any of the approaches mentioned in issue #333 but the class-based approach is the default recommended approach (unless you need to support really old versions of Node.js).
The new approach was inspired from Java's Runnable interface for threads (except in the case of SC, we have specialized processes instead of threads) see https://docs.oracle.com/javase/tutorial/essential/concurrency/runthread.html.

As part of this change, you can now override the SCWorker's createHTTPServer() method to return your own custom HTTP server for SC to use (it needs to be compatible with the default Node.js HTTP server though). This should make it easier to use other back end frameworks with SC.

For more details on the new worker boilerplate see https://socketcluster.io/#!/docs/api-scworker
For more details on the new broker boilerplate see https://socketcluster.io/#!/docs/api-broker

Breaking changes

• exchange.run(...) should be renamed to exchange.exec(...) throughout your code (run now has a special meaning related to the various process controllers).
• When requiring the master SocketCluster object (e.g. in server.js), it should now be const SocketCluster = require('socketcluster'); instead of const SocketCluster = require('socketcluster').SocketCluster;
• New entry point boilerplate for worker.js https://github.com/SocketCluster/socketcluster/blob/de9757cdb078805bfa0f808687b5e6a8e2ef5c20/sample/worker.js
• New entry point boilerplate for broker.js https://github.com/SocketCluster/socketcluster/blob/de9757cdb078805bfa0f808687b5e6a8e2ef5c20/sample/broker.js
• New entry point boilerplate for workerCluster process; it's similar to the new worker.js and broker.js format but you need to import the SCWorkerCluster base class using var SCWorkerCluster = require('./scworkercluster');
• No more initController - Since the developer now has full control over the instantiation of various process controllers, it became pretty useless and didn't fit into the new model.
• No more httpServerModule option - You can now simply override the SCWorker's createHTTPServer() method to achieve the same thing.
• For Docker/Kubernetes SCC there is no more master.js file, now you can just provide your own server.js into the volume container to be your master process https://github.com/SocketCluster/socketcluster/blob/de9757cdb078805bfa0f808687b5e6a8e2ef5c20/sample/server.js

No breaking API changes from 7.x.x but it makes an addition to the SC protocol which may affect codecs and other SC plugins which interact directly with the SC protocol.

• Added subscription batching. This allows you to batch channel subscriptions together to reduce the number of WebSocket frames required to subscribe to multiple channels. This should result in a significant performance improvement when subscribing to a large number of unique channels in a short period of time - It should also help to improve the performance of re-connections (automatic re-subscriptions) when clients handle a large number of channels. Note that channels are non-batching by default - You need to set the batch option to true when subscribing to a new channel in order to allow a channel to be batched. See the subscribe method here: https://socketcluster.io/#!/docs/api-scsocket-client

Note that v7.0.x shouldn't have any major breaking changes from 6.8.0.

• Updated SocketCluster version number to match the new major client version number 7.x.x.
• Fixed issue with socket.setAuthToken(data, options) expiresIn option being ignored; also improved error handling related to the socket.setAuthToken function.

• Removed all remaining traces of domains in SC.
• Removed custom sc-emitter in favor of component-emitter for the client and server SCSocket objects.

Possible breaking change:

• SC no longer uses domains internally to capture errors (Node.js has deprecated them); instead, SC now listens to 'error' events directly on the server and sockets which is creates. This means that you should never use the removeAllListeners('error') on objects created by SC as this will destroy SC's internal error handling. Note that the Node.js documentation explicitly recommends against removing listeners in this way. See https://nodejs.org/api/events.html#events_emitter_removealllisteners_eventname

• Refactored the code, especially in and around the sc-broker module.
• Improved visibility of broker errors (better stack traces).
• Improved visibility of errors throughout SC in general.
• Brokers recover from crashes faster.
• Broker actions and messages now have improved buffering so broker crashes/recovery should be more seamless.
• Improved buffering for all IPC messages: sendToBroker, sendToWorker and sendToMaster...
• Improved tests around brokers.

• Added the ability for processes to easily respond to messages from other processes over IPC via callbacks. A new callback argument was added to sendToWorker, sendToBroker and sendToMaster methods throughout SC (see updated API docs on https://socketcluster.io website).
• Added buffering to sendToWorker function on master - Previously, if the workerCluster wasn't ready yet or was down, invoking socketCluster.sendToWorker(...) would trigger an error - Now the messages will be buffered and delivered as soon as the workerCluster is ready.

• Improved error handling and logging across processes - This should account for cases where invalid objects or values are thrown or emitted as errors.