Websocket is the main transport in Centrifugo. It's a very efficient low-overhead protocol on top of TCP.
The biggest advantage is that Websocket works out of the box in all modern browsers and almost all programming languages have Websocket implementations. This makes Websocket a pretty universal transport that can even be used to connect to Centrifugo from web apps and mobile apps and other environments.
Default WebSocket connection endpoint in Centrifugo is:
By default, WebSocket connection uses JSON protocol internally.
Default: 65536 (64KB)
Maximum allowed size of a message received from WebSocket connection in bytes.
In bytes, by default 0 which tells Centrifugo to reuse read buffer from HTTP server for WebSocket connection (usually 4096 bytes in size). If set to a lower value can reduce memory usage per WebSocket connection (but can increase number of system calls depending on average message size).
In bytes, by default 0 which tells Centrifugo to reuse write buffer from HTTP server for WebSocket connection (usually 4096 bytes in size). If set to a lower value can reduce memory usage per WebSocket connection (but HTTP buffer won't be reused):
If you have a few writes then
websocket_use_write_buffer_pool (boolean, default
false) option can reduce memory usage of Centrifugo a bit as there won't be separate write buffer binded to each WebSocket connection.
An experimental feature for raw WebSocket endpoint -
permessage-deflate compression for websocket messages. Btw look at great article about websocket compression. WebSocket compression can reduce an amount of traffic travelling over the wire.
We consider this experimental because this websocket compression is experimental in Gorilla Websocket library that Centrifugo uses internally.
Enabling WebSocket compression will result in much slower Centrifugo performance and more memory usage – depending on your message rate this can be very noticeable.
To enable WebSocket compression for raw WebSocket endpoint set
true in a configuration file. After this clients that support
permessage-deflate will negotiate compression with server automatically. Note that enabling compression does not mean that every connection will use it - this depends on client support for this feature.
Another option is
websocket_compression_min_size. Default 0. This is a minimal size of message in bytes for which we use
deflate compression when writing it to client's connection. Default value
0 means that we will compress all messages when
websocket_compression enabled and compression support negotiated with client.
It's also possible to control websocket compression level defined at compress/flate By default when compression with a client negotiated Centrifugo uses compression level 1 (BestSpeed). If you want to set custom compression level use
websocket_compression_level configuration option.
Protobuf binary protocol
In most cases you will use Centrifugo with JSON protocol which is used by default. It consists of simple human-readable frames that can be easily inspected. Also it's a very simple task to publish JSON encoded data to HTTP API endpoint. You may want to use binary Protobuf client protocol if:
- you want less traffic on wire as Protobuf is very compact
- you want maximum performance on server-side as Protobuf encoding/decoding is very efficient
- you can sacrifice human-readable JSON for your application
Binary protobuf protocol only works for raw Websocket connections (as SockJS can't deal with binary). With most clients to use binary you just need to provide query parameter
format to Websocket URL, so final URL look like:
After doing this Centrifugo will use binary frames to pass data between client and server. Your application specific payload can be random bytes.
You still can continue to encode your application specific data as JSON when using Protobuf protocol thus have a possibility to co-exist with clients that use JSON protocol on the same Centrifugo installation inside the same channels.