ID | IEP-76 |
Author | |
Sponsor | |
Created |
|
Status | DRAFT |
Thin client protocol will be the primary way to interact with Ignite 3.0 from code.
Adapt Ignite 2.x protocol for Ignite 3.0. Main differences are:
ClientConnectorConfiguration
class.MsgPack is used for data serialization.
Ignite data types defined in IEP-54 map to MsgPack data types the following way:
Ignite Type | Size | MsgPack Type | Notes |
---|---|---|---|
Bitmask(n) | ⌈n/8⌉ bytes | bin8 / bin16 / bin32 | |
IntX, UintX | 1-8 bytes | fixint / intX / uintX | Integer types are interchangeable when possible. fixint (1 byte) can be passed as a value for uint64 column. |
Float | 4 bytes | float32 | |
Double | 8 bytes | float64 | |
Number([n]) | Variable | ext16 (up to 2^8 - 1 bytes) | Extension 1 |
Decimal | Variable | ext16 (up to 2^8 - 1 bytes) | Extension 2 |
UUID | 16 bytes | fixext16 | Extension 3 |
String | Variable | str | |
Date | 3 bytes | fixext4 | Extension 4 |
Time | 4 bytes | fixext4 | Extension 5 |
Datetime | 7 bytes | fixext8 | Extension 6 |
Timestamp | 8 bytes | timestamp 64 | |
Binary | Variable | bin32 (up to 2^32 - 1 bytes) |
"Extension X" is a MsgPack extension type (up to 128 extension types are allowed).
All messages, request and response, except handshake, start with unsigned integer
message length (excluding the length itself).
positive fixint / uint8 / uint16 / uint32 / uint64 | 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 / uint | Payload length |
positive fixint | Version major |
positive fixint | Version minor |
positive fixint | Version patch |
positive fixint | 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 / uint | Payload length |
positive fixint | Server version major |
positive fixint | Server version minor |
positive fixint | 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). |
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 | |
short | Operation code |
long | 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 | |
long | Request id (see above) |
int | Status code (0 for success, otherwise error code) |
string | Error message (present only when status is not 0) |
... | Operation-specific data |
Operation codes and request ids are omitted everywhere below for brevity.
TODO