Skip to content
DiceDB

Supported Protocols

DiceDB supports 3 ways to connect to the database:

  1. TCP-RESP
  2. HTTP
  3. WebSockets

TCP-RESP

RESP is a standard protocol over TCP, developed by redis. This is the default mode of communication with dicedb and allows dice to be a drop-in replacement for Redis.

NameValueConfiguration
Default Port7379server.port in config file

To use Dice over TCP/RESP, you can use the official DiceDB CLI or use any Redis CLI/SDKs for non-dice features.

HTTP

Clients can also connect to DiceDB over HTTP. This allows clients to connect to dice over the web stack, enabling frontends to have direct access to dice.

NameValueConfiguration
Default Port8082--http-port flag

For all commands except QWATCH, the HTTP API is synchronous and will return the result of the command immediately.

For QWATCH, we use SSE to be able to respond with changes to the result set of the queries.

To understand the request and response format better, please refer to the HTTP Protocol documentation.

When to use HTTP

  • To connect to dice from a web frontend.
  • When you do not have access to a raw TCP connection.
  • With small number of queries you want to QWATCH.
  • Integrate dice with other web services using HTTP Webhooks.

Limitations

  • QWATCH uses SSE or Server Sent Events, and current implementation of HTTP in DiceDB is based on HTTP 1.1. This means that there would be a limit to how many queries you can QWATCH at a time (ref).
  • QWATCH using SSE also implies that the connection is stateful and the client needs to handle reconnections in case of network failures.

WebSockets

WebSockets protocol on DiceDB allows clients to connect to dice over a persistent websocket connection. This allows clients to connect to dice over the web while also being able to bypass the limitations of SSE. Websocket being a full-duplex protocol, allows clients to send and receive messages simultaneously.

NameValueConfiguration
Default Port8379--websocket-port flag

To understand the request and response format better, please refer to the WebSockets Protocol documentation.

When to use WebSockets

  • To connect to dice from a web frontend and maintain a persistent connection.
  • To QWATCH a large number of queries.
  • In cases wher you need large amount/high frequency of live updates being pushed from dice to the client.
  • To build real-time applications with high frequency of updates like collaborative editing, real-time gaming, etc.

Limitations

  • WebSockets are not supported in all browsers. Please refer to the MDN WebSockets documentation for more information.
  • WebSockets are stateful connections and need to be managed by the client. This means that the client needs to handle reconnections in case of network failures.
  • In case of faster updates than the client can handle, the standard WebSocket from the browser does not implement a built-in backpressure mechanism. This means the device memory can fill up until the client handles the messages.