|
| 1 | +# **CacheX Protocol: Request and Response Format** |
| 2 | + |
| 3 | +## **Request Format** |
| 4 | +CacheX follows a **binary protocol** for efficient parsing and communication. Each request consists of **multiple arguments** encoded in a structured format. |
| 5 | + |
| 6 | +### **Structure** |
| 7 | +| Field | Type | Description | |
| 8 | +|--------|--------|-------------| |
| 9 | +| `nstr` | `uint32_t` | Number of arguments (e.g., `SET key value` has 3 arguments) | |
| 10 | +| `len1` | `uint32_t` | Length of the first argument | |
| 11 | +| `str1` | `char[]` | First argument (e.g., `"SET"`) | |
| 12 | +| `len2` | `uint32_t` | Length of the second argument | |
| 13 | +| `str2` | `char[]` | Second argument (e.g., `"key"`) | |
| 14 | +| `lenN` | `uint32_t` | Length of the Nth argument | |
| 15 | +| `strN` | `char[]` | Nth argument | |
| 16 | + |
| 17 | +### **Binary Layout** |
| 18 | +``` |
| 19 | ++------+-----+------+-----+------+-----+-----+------+ |
| 20 | +| nstr | len | str1 | len | str2 | ... | len | strN | |
| 21 | ++------+-----+------+-----+------+-----+-----+------+ |
| 22 | + 4B 4B ... |
| 23 | +``` |
| 24 | + |
| 25 | +### **Example** |
| 26 | +#### **SET Request** |
| 27 | +**Command:** `SET key value` |
| 28 | +**Binary Format (Network Order)** |
| 29 | +``` |
| 30 | +[ 0x00000003 ] // Number of arguments (3) |
| 31 | +[ 0x00000003 ] // Length of "SET" |
| 32 | +[ "SET" ] // Command |
| 33 | +[ 0x00000003 ] // Length of "key" |
| 34 | +[ "key" ] // Key |
| 35 | +[ 0x00000005 ] // Length of "value" |
| 36 | +[ "value" ] // Value |
| 37 | +``` |
| 38 | + |
| 39 | +#### **GET Request** |
| 40 | +**Command:** `GET key` |
| 41 | +**Binary Format** |
| 42 | +``` |
| 43 | +[ 0x00000002 ] // Number of arguments (2) |
| 44 | +[ 0x00000003 ] // Length of "GET" |
| 45 | +[ "GET" ] // Command |
| 46 | +[ 0x00000003 ] // Length of "key" |
| 47 | +[ "key" ] // Key |
| 48 | +``` |
| 49 | + |
| 50 | +--- |
| 51 | + |
| 52 | +## **Response Format** |
| 53 | +The response contains a **status code** followed by optional **data**. |
| 54 | + |
| 55 | +### **Structure** |
| 56 | +| Field | Type | Description | |
| 57 | +|-----------|--------|-------------| |
| 58 | +| `length` | `uint32_t` | Total response length (excluding itself) | |
| 59 | +| `status` | `uint32_t` | Response status code | |
| 60 | +| `data` | `char[]` | (Optional) Response data | |
| 61 | + |
| 62 | +### **Binary Layout** |
| 63 | +``` |
| 64 | ++--------+-----------+ |
| 65 | +| length | status | |
| 66 | ++--------+-----------+ |
| 67 | +| data |(optional) | |
| 68 | ++--------------------+ |
| 69 | + 4B ... |
| 70 | +``` |
| 71 | + |
| 72 | +### **Response Status Codes** |
| 73 | +| Code | Meaning | |
| 74 | +|-------|---------| |
| 75 | +| `0` (`RES_OK`) | Success | |
| 76 | +| `1` (`RES_ERR`) | Error | |
| 77 | +| `2` (`RES_NX`) | Key not found | |
| 78 | + |
| 79 | +--- |
| 80 | + |
| 81 | +### **Example Responses** |
| 82 | +#### **SET Response** |
| 83 | +``` |
| 84 | +[ 0x00000004 ] // Response length (4 bytes for status) |
| 85 | +[ 0x00000000 ] // Status: RES_OK (0) |
| 86 | +``` |
| 87 | + |
| 88 | +#### **GET Response (Key Found)** |
| 89 | +``` |
| 90 | +[ 0x00000009 ] // Response length (4 bytes for status + 5 bytes data) |
| 91 | +[ 0x00000000 ] // Status: RES_OK (0) |
| 92 | +[ "value" ] // Data: "value" |
| 93 | +``` |
| 94 | + |
| 95 | +#### **GET Response (Key Not Found)** |
| 96 | +``` |
| 97 | +[ 0x00000004 ] // Response length (4 bytes for status) |
| 98 | +[ 0x00000002 ] // Status: RES_NX (2) |
| 99 | +``` |
| 100 | + |
| 101 | +#### **Invalid Command Response** |
| 102 | +``` |
| 103 | +[ 0x00000004 ] // Response length (4 bytes for status) |
| 104 | +[ 0x00000001 ] // Status: RES_ERR (1) |
| 105 | +``` |
| 106 | + |
| 107 | +--- |
| 108 | + |
| 109 | +Handles large requests with up to **200,000 arguments** safely. |
0 commit comments