-
-
Notifications
You must be signed in to change notification settings - Fork 664
Description
Soon after Centrifugo v3 we are starting to think about v4 release. Let's look at v4 plans.
New client protocol adoption
More human-readable JSON, one-shot encode/decode (more performance), simpler introspection if required. The work already started in #499. Note that possibility to try (switch to) client protocol v2 will appear in Centrifugo v3 (possibly in v3.2.0), in v4 the plan is to make new protocol version default.
Standartization of client SDK API
All client SDKs will work according to a common spec. There is a prototype of if in Centrifugo v4 WIP docs.
Application-level pings
Protocol V2 may have a new approach to client-server pings. Pings will be sent on application protocol level, clients won't send pings to server at all – the will be able to rely on server heartbeats to understand that connection is still active. This may help to reduce CPU usage since less ping/pong frames will travel around. Also, this will unify format of pings throughout our unidirectional transports (uni Websocket, Eventsource (SSE), uni http streaming).
Disconnects: expose code to client disconnect handler and remove JSON from reason
This will allow handling disconnect codes in a custom way. Will add some performance, readability, WebTransport interop. This is also part of client protocol v2 and details can be found in #499.
Better channel security model
- Namespaces should be protected by default (introduce
publicboolean channel option and removeprotectedoption - namespaces will inheritprotectedoption behavior by default). This should resolve some confusion about current channel behavior, for example when channels sent in JWT users often think that nobody else will be able to subscribe on them. While this is not true tillprotectedoption is not enabled in namespace. - Strict channel symbol validation (allow only ASCII, it was always documented but not really enforced at the moment)
Removing usage of $ prefix to mark private channel
See #507 for motivation and details.
Faster Redis engine
Redis engine based on https://github.com/go-redis/redis should provide more perf and reduce dependencies. Additional details: centrifugal/centrifuge#210. This is not really required to be part of Centrifugo v4 - this may come in v3 or soon after v4 release. But I think it's important to mention. The work is pretty big and not really trivial but may be worth it.
When Centrifugo v4 will be released?
For Centrifugo v3 we had strict deadline right from the announce post. For v4 there is no deadline defined yet. This post will be updated as soon as things will evolve.
If anyone is interested to discuss these changes and maybe adjust them somehow at an early stage – feel free to reach out.