Supported Protocols
DiceDB supports 3 ways to connect to the database:
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.
| Name | Value | Configuration |
|---|---|---|
| Default Port | 7379 | server.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.
| Name | Value | Configuration |
|---|---|---|
| Default Port | 8082 | --http-port flag |
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.
- Integrate dice with other web services using HTTP Webhooks.
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.
| Name | Value | Configuration |
|---|---|---|
| Default Port | 8379 | --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.
- 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.