Releases · SocketCluster/socketcluster
v17.3.1 v16.0.1 v14.3.0 v14.2.0setAuthEngine(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-scworkerSOCKETCLUSTER_SERVER_PORT environment variable to SCC_BROKER_SERVER_PORT.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.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.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.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.SCSocket to SCServerSocket.sc-uws version.authStateChange event on the server side socket (SCSocket) which is has similar behavior as the authStateChange event on the client-side SCSocket.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.scc-broker-client@5.0.0 (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
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.sc-uws; it's a drop-in replacement for uws.Upgraded SCC:
scc-state:v2.0.0 (Dockerhub)scc-broker:v2.0.0 (Dockerhub)scc-broker-client@3.0.0 (npm)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).
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.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
MIDDLEWARE_HANDSHAKE property to MIDDLEWARE_HANDSHAKE_WS - The corresponding string value was also renamed from handshake to handskakeWS.You can’t perform that action at this time.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4