Changelog History
-
v14.3.0 Changes
October 09, 2018- โฌ๏ธ Bump dependencies.
-
v14.2.0 Changes
September 20, 2018- ๐ Deprecated
setAuthEngine(authEngine)
andsetCodecEngine(codecEngine)
methods. You should now pass a customauthEngine
andcodecEngine
as options to theSCWorker
constructor. See theconstructor
method here: https://socketcluster.io/#!/docs/api-scworker
- ๐ Deprecated
-
v14.1.1 Changes
August 29, 2018- 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 toSCC_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
andscc-broker-client
) need to match each other.
-
v13.1.3 Changes
May 13, 2018- 0๏ธโฃ 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 byauthAlgorithm
). 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 theoptions
object which is passed to theverifyToken
method of theauthEngine
; this means that if a customauthEngine
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 matchingactive
(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
toSCServerSocket
. - โฌ๏ธ Bumped
sc-uws
version.
- 0๏ธโฃ You can now pass an optional
-
v12.0.0 Changes
April 29, 2018- โ Added a new
authStateChange
event on the server side socket (SCSocket) which is has similar behavior as theauthStateChange
event on the client-side SCSocket. - โ Added a new
authenticationStateChange
event on the server (SCServer) which is essentially the same as the socketauthStateChange
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
- โ Added a new
-
v11.3.1 Changes
April 15, 2018- โฌ๏ธ 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 theclusterMappingEngine
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 largescc-broker
instances that have more than one worker process - In this case, it should help to distribute the load more evenly across processes inside thescc-broker
instance. You can set theclusterClientPoolSize
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- 0๏ธโฃ Made
ws
the default WebSocket engine for maximum compatibility; a large number of users have been complaining aboutuws
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 foruws
.
- โฌ๏ธ Upgraded SCC:
-
v11.1.0 Changes
March 27, 2018โฌ๏ธ 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).
-
v10.0.0 Changes
February 19, 2018- Renamed
MIDDLEWARE_HANDSHAKE
property toMIDDLEWARE_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 theMIDDLEWARE_HANDSHAKE_WS
middleware). Unlike withMIDDLEWARE_HANDSHAKE_WS
, withMIDDLEWARE_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 toMIDDLEWARE_HANDSHAKE_WS
- The corresponding string value was also renamed fromhandshake
tohandskakeWS
.
- Renamed
-
v9.3.3 Changes
February 09, 2018๐ Fix bug with top level (master process)
--inspect
and--debug
flags not working. -
v9.3.0 Changes
January 09, 2018โ Added async/await support for the worker and broker controller
run
methods. See #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 theexchange
property instead. - โ Removed support for the deprecated
getSocketURL()
method of the SocketCluster master instance.
- โ Removed support for the deprecated