THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
...
"Extension X" is a MsgPack extension type (up to 128 extension types are allowed).
Integer data types, varint encoding
MsgPack provides multiple data types for integer values. When encoding a value, smallest data type for that value is picked automatically.
"int" is used below to denote int format family. Values such as payload size, request ID, error codes, are encoded this way - using variable number of bytes based on the value.
Message format
All messages, request and response, except handshake, start with unsigned integer message length (excluding the length itself).
- Any MsgPack unsigned integer type can be used, so that shorter messages use smaller type to encode length. Empty message will be single 0 byte.
- Maximum message length is 2147483647 (Integer.MAX_VALUE and maximum byte array length in Java)
| positive fixint / uint8 / uint16 / uint32 / uint64 int | Length of Payload |
| ... | Payload |
...
| Request | |
|---|---|
| 4 bytes | Magic number 49 47 4E 49, or "IGNI". Helps identifying misconfigured SSL or other apps probing the port. |
| fixint / uintint | Payload length |
| positive fixintint | Version major |
| positive fixintint | Version minor |
| positive fixintint | Version patch |
| positive fixintint | Client code (1 for JDBC, 2 for general-purpose client) |
| bin | Features (bitmask) |
| map (int → any) | Extensions (auth, attributes, etc). Server can skip unknown extension data (when client is newer). |
...
| Response | |
|---|---|
| 4 bytes | Magic number 49 47 4E 49, or "IGNI". Helps identifying misconfigured SSL or different server on the port. |
| fixint / uintint | Payload length |
| positive fixintint | Server version major |
| positive fixintint | Server version minor |
| positive fixintint | Server version patch |
| boolean | Success flag |
| string | When success flag is false: Error message |
| bin | When success flag is true: Server features (bitmask) |
| map (int → any) | When success flag is true: Extensions (auth, attributes, etc). Client can skip unknown extension data (when server is newer). |
Client Operations
Upon successful handshake client can start performing operations by sending a request with specific op code. Each operation has it's own request and response format, with a common header.
| Request |
| int | Operation code |
| int | Request id, generated by client and returned as-is in response |
| ... | Operation-specific data |
TODO: server → client notifications, how do we handle them easier?
| Response | |
| int | Type = 0 |
| int | Request id |
| int | Error |
| code (0 for success |
| ) | |
| string | Error message ( |
| when |
| error code is not 0) | |
| ... | Operation-specific data |
Clients should expect notification messages at any moment after the successful handshake.
| Notification | |
| int | Type = 1 |
| int | Notification code |
| ... | Notification-specific data |
Operation codes and request ids are omitted everywhere below for brevity.
Risks and Assumptions
TODO
...
Overview
Content Tools
Apps